[PATCH] x86/amd: Drop allow_unsafe parameter, tune down XSA-9 mitigations

[PATCH] x86/amd: Drop allow_unsafe parameter, tune down XSA-9 mitigations

[Teddy Astie]

[-- Attachment #1: Type: text/plain, Size: 4798 bytes --]

XSA-9 mitigations prevents Xen from properly running if a affected CPU
is detected. While the vulnerability has no mitigations (aside not running
64-bits PV guests), it's only outcome is a DoS.

There is no real point in preventing Xen from working here and it would
be preferable to just log the vulnerability to the user so it can act
appropriately.

Also reword the errata message regarding that it only affects PV64 guests.

Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
---
It's hard to tell whether or not we would want to drop allow_unsafe, but
currently, Xen is allowed to boot with XSA-304 mitigations disabled
(intentionnaly) which has a similar outcome than this one.

From a user standpoint, preventing the system to boot or starting guests is
too extreme and would be in practice seen as a bug, even if it's justified
policy which can be overriden.

 docs/misc/xen-command-line.pandoc | 12 ------------
 xen/arch/x86/cpu/amd.c            | 21 +++++----------------
 xen/arch/x86/domain.c             | 14 --------------
 xen/arch/x86/include/asm/amd.h    |  2 --
 4 files changed, 5 insertions(+), 44 deletions(-)

diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
index 6c77129732..04d206f919 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -133,18 +133,6 @@ resume.
 `s3_mode` instructs Xen to set up the boot time (option `vga=`) video
 mode during S3 resume.
 
-### allow_unsafe (x86)
-> `= <boolean>`
-
-> Default: `false`
-
-Force boot on potentially unsafe systems. By default Xen will refuse
-to boot on systems with the following errata:
-
-* AMD Erratum 121. Processors with this erratum are subject to a guest
-  triggerable Denial of Service. Override only if you trust all of
-  your PV guests.
-
 ### altp2m (Intel)
 > `= <boolean>`
 
diff --git a/xen/arch/x86/cpu/amd.c b/xen/arch/x86/cpu/amd.c
index 712734a6e7..f1f4a25754 100644
--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -20,10 +20,6 @@
 
 #include "cpu.h"
 
-/* 1 = allow, 0 = don't allow guest creation, -1 = don't allow boot */
-int8_t __read_mostly opt_allow_unsafe;
-boolean_param("allow_unsafe", opt_allow_unsafe);
-
 /* Signal whether the ACPI C1E quirk is required. */
 bool __read_mostly amd_acpi_c1e_quirk;
 bool __ro_after_init amd_legacy_ssbd;
@@ -1205,19 +1201,12 @@ static void cf_check init_amd(struct cpuinfo_x86 *c)
 	if (c->family == 0x10)
 		__clear_bit(X86_FEATURE_MONITOR, c->x86_capability);
 
-	if (!cpu_has_amd_erratum(c, AMD_ERRATUM_121))
-		opt_allow_unsafe = 1;
-	else if (opt_allow_unsafe < 0)
-		panic("Xen will not boot on this CPU for security reasons"
-		      "Pass \"allow_unsafe\" if you're trusting all your"
-		      " (PV) guest kernels.\n");
-	else if (!opt_allow_unsafe && c == &boot_cpu_data)
+	if (cpu_has_amd_erratum(c, AMD_ERRATUM_121))
+	{
 		printk(KERN_WARNING
-		       "*** Xen will not allow creation of DomU-s on"
-		       " this CPU for security reasons. ***\n"
-		       KERN_WARNING
-		       "*** Pass \"allow_unsafe\" if you're trusting"
-		       " all your (PV) guest kernels. ***\n");
+			   "*** This CPU is affected with erratum 121"
+			   " 64-bits PV guests are able to cause a DoS (XSA-9) ***\n");
+	}
 
 	if (c->family == 0x16 && c->model <= 0xf) {
 		if (c == &boot_cpu_data) {
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 1d458f1372..1d3b99cd50 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -833,20 +833,6 @@ int arch_domain_create(struct domain *d,
 
     spin_lock_init(&d->arch.e820_lock);
 
-    if ( d->domain_id && cpu_has_amd_erratum(&boot_cpu_data, AMD_ERRATUM_121) )
-    {
-        if ( !opt_allow_unsafe )
-        {
-            printk(XENLOG_G_ERR
-                   "%pd: will not create domU on this CPU for security reasons\n",
-                   d);
-            return -EPERM;
-        }
-        printk(XENLOG_G_WARNING
-               "%pd: may compromise security on this CPU\n",
-               d);
-    }
-
     emflags = config->arch.emulation_flags;
 
     if ( is_hardware_domain(d) && is_pv_domain(d) )
diff --git a/xen/arch/x86/include/asm/amd.h b/xen/arch/x86/include/asm/amd.h
index d21df0741a..d8d9cd175e 100644
--- a/xen/arch/x86/include/asm/amd.h
+++ b/xen/arch/x86/include/asm/amd.h
@@ -74,8 +74,6 @@
 struct cpuinfo_x86;
 int cpu_has_amd_erratum(const struct cpuinfo_x86 *cpu, int osvw_id, ...);
 
-extern int8_t opt_allow_unsafe;
-
 void fam10h_check_enable_mmcfg(void);
 void check_enable_amd_mmconf_dmi(void);
 
-- 
2.52.0



--
Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech

Re: [PATCH] x86/amd: Drop allow_unsafe parameter, tune down XSA-9 mitigations

[Roger Pau Monné]

On Wed, Apr 22, 2026 at 06:58:06PM +0200, Teddy Astie wrote:
> XSA-9 mitigations prevents Xen from properly running if a affected CPU
> is detected. While the vulnerability has no mitigations (aside not running
> 64-bits PV guests), it's only outcome is a DoS.
> 
> There is no real point in preventing Xen from working here and it would
> be preferable to just log the vulnerability to the user so it can act
> appropriately.
> 
> Also reword the errata message regarding that it only affects PV64 guests.
> 
> Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
> ---
> It's hard to tell whether or not we would want to drop allow_unsafe, but
> currently, Xen is allowed to boot with XSA-304 mitigations disabled
> (intentionnaly) which has a similar outcome than this one.
> 
> From a user standpoint, preventing the system to boot or starting guests is
> too extreme and would be in practice seen as a bug, even if it's justified
> policy which can be overriden.
> 
>  docs/misc/xen-command-line.pandoc | 12 ------------
>  xen/arch/x86/cpu/amd.c            | 21 +++++----------------
>  xen/arch/x86/domain.c             | 14 --------------
>  xen/arch/x86/include/asm/amd.h    |  2 --
>  4 files changed, 5 insertions(+), 44 deletions(-)
> 
> diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
> index 6c77129732..04d206f919 100644
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -133,18 +133,6 @@ resume.
>  `s3_mode` instructs Xen to set up the boot time (option `vga=`) video
>  mode during S3 resume.
>  
> -### allow_unsafe (x86)
> -> `= <boolean>`
> -
> -> Default: `false`
> -
> -Force boot on potentially unsafe systems. By default Xen will refuse
> -to boot on systems with the following errata:
> -
> -* AMD Erratum 121. Processors with this erratum are subject to a guest
> -  triggerable Denial of Service. Override only if you trust all of
> -  your PV guests.
> -
>  ### altp2m (Intel)
>  > `= <boolean>`
>  
> diff --git a/xen/arch/x86/cpu/amd.c b/xen/arch/x86/cpu/amd.c
> index 712734a6e7..f1f4a25754 100644
> --- a/xen/arch/x86/cpu/amd.c
> +++ b/xen/arch/x86/cpu/amd.c
> @@ -20,10 +20,6 @@
>  
>  #include "cpu.h"
>  
> -/* 1 = allow, 0 = don't allow guest creation, -1 = don't allow boot */
> -int8_t __read_mostly opt_allow_unsafe;
> -boolean_param("allow_unsafe", opt_allow_unsafe);
> -
>  /* Signal whether the ACPI C1E quirk is required. */
>  bool __read_mostly amd_acpi_c1e_quirk;
>  bool __ro_after_init amd_legacy_ssbd;
> @@ -1205,19 +1201,12 @@ static void cf_check init_amd(struct cpuinfo_x86 *c)
>  	if (c->family == 0x10)
>  		__clear_bit(X86_FEATURE_MONITOR, c->x86_capability);
>  
> -	if (!cpu_has_amd_erratum(c, AMD_ERRATUM_121))
> -		opt_allow_unsafe = 1;
> -	else if (opt_allow_unsafe < 0)
> -		panic("Xen will not boot on this CPU for security reasons"
> -		      "Pass \"allow_unsafe\" if you're trusting all your"
> -		      " (PV) guest kernels.\n");
> -	else if (!opt_allow_unsafe && c == &boot_cpu_data)
> +	if (cpu_has_amd_erratum(c, AMD_ERRATUM_121))
> +	{
>  		printk(KERN_WARNING
> -		       "*** Xen will not allow creation of DomU-s on"
> -		       " this CPU for security reasons. ***\n"
> -		       KERN_WARNING
> -		       "*** Pass \"allow_unsafe\" if you're trusting"
> -		       " all your (PV) guest kernels. ***\n");
> +			   "*** This CPU is affected with erratum 121"
> +			   " 64-bits PV guests are able to cause a DoS (XSA-9) ***\n");

We try to avoid splitting log messages, so that people can grep easily
for them.

I would also add a add_taint(TAINT_MACHINE_INSECURE); here.

I wonder however if an update of the advisory would also be needed, as
we are modifying the applied fix, and hence the text in the advisory
no longer matches the code in Xen.

Thanks, Roger.

Re: [PATCH] x86/amd: Drop allow_unsafe parameter, tune down XSA-9 mitigations

[Andrew Cooper]

On 22/04/2026 5:58 pm, Teddy Astie wrote:
> XSA-9 mitigations prevents Xen from properly running if a affected CPU
> is detected. While the vulnerability has no mitigations (aside not running
> 64-bits PV guests), it's only outcome is a DoS.
>
> There is no real point in preventing Xen from working here and it would
> be preferable to just log the vulnerability to the user so it can act
> appropriately.
>
> Also reword the errata message regarding that it only affects PV64 guests.
>
> Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
> ---
> It's hard to tell whether or not we would want to drop allow_unsafe, but
> currently, Xen is allowed to boot with XSA-304 mitigations disabled
> (intentionnaly) which has a similar outcome than this one.
>
> From a user standpoint, preventing the system to boot or starting guests is
> too extreme and would be in practice seen as a bug, even if it's justified
> policy which can be overriden.

There is a lot of history here, including for why the panic() is
actually completely unreachable.

I actually have a very similar patch, from almost certainly more than a
decade ago.  The difference is that now I'm a maintainer and in a better
position to say that this logic really shouldn't have been taken;
certainly not in this form.

Perhaps an easier justification is that there have been issues like AMD
erratum #121 prior (e.g. Pentium LOCK CMPXCHG) and post (Zen1 has a
related errata, can't remember it off the top of my head) that went
unaddressed.

There is a reason why most OSes blanket disallow using the page leading
into the non-canonical region.  It's rife with bugs.

~Andrew

Re: [PATCH] x86/amd: Drop allow_unsafe parameter, tune down XSA-9 mitigations

[Jan Beulich]

On 24.04.2026 11:18, Andrew Cooper wrote:
> On 22/04/2026 5:58 pm, Teddy Astie wrote:
>> XSA-9 mitigations prevents Xen from properly running if a affected CPU
>> is detected. While the vulnerability has no mitigations (aside not running
>> 64-bits PV guests), it's only outcome is a DoS.
>>
>> There is no real point in preventing Xen from working here and it would
>> be preferable to just log the vulnerability to the user so it can act
>> appropriately.
>>
>> Also reword the errata message regarding that it only affects PV64 guests.
>>
>> Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
>> ---
>> It's hard to tell whether or not we would want to drop allow_unsafe, but
>> currently, Xen is allowed to boot with XSA-304 mitigations disabled
>> (intentionnaly) which has a similar outcome than this one.
>>
>> From a user standpoint, preventing the system to boot or starting guests is
>> too extreme and would be in practice seen as a bug, even if it's justified
>> policy which can be overriden.
> 
> There is a lot of history here, including for why the panic() is
> actually completely unreachable.

Deliberately so, as described in 0c7a69665110: The change done allows for
a trivial 1-line change restoring prior default behavior (in distros which
may want this).

> I actually have a very similar patch, from almost certainly more than a
> decade ago.  The difference is that now I'm a maintainer and in a better
> position to say that this logic really shouldn't have been taken;
> certainly not in this form.
> 
> Perhaps an easier justification is that there have been issues like AMD
> erratum #121 prior (e.g. Pentium LOCK CMPXCHG) and post (Zen1 has a
> related errata, can't remember it off the top of my head) that went
> unaddressed.

I agree it would be better if we were consistent in treatment of errata
(somewhat) similar in effect. I'm less sure which direction we should go
in order to achieve consistency.

Jan

Re: [PATCH] x86/amd: Drop allow_unsafe parameter, tune down XSA-9 mitigations

[Jan Beulich]

On 22.04.2026 18:58, Teddy Astie wrote:
> @@ -1205,19 +1201,12 @@ static void cf_check init_amd(struct cpuinfo_x86 *c)
>  	if (c->family == 0x10)
>  		__clear_bit(X86_FEATURE_MONITOR, c->x86_capability);
>  
> -	if (!cpu_has_amd_erratum(c, AMD_ERRATUM_121))
> -		opt_allow_unsafe = 1;
> -	else if (opt_allow_unsafe < 0)
> -		panic("Xen will not boot on this CPU for security reasons"
> -		      "Pass \"allow_unsafe\" if you're trusting all your"
> -		      " (PV) guest kernels.\n");
> -	else if (!opt_allow_unsafe && c == &boot_cpu_data)
> +	if (cpu_has_amd_erratum(c, AMD_ERRATUM_121))
> +	{

Nit: Misplaced brace (it's Linux style here). But really I don't see why
braces are added in the first place.

>  		printk(KERN_WARNING
> -		       "*** Xen will not allow creation of DomU-s on"
> -		       " this CPU for security reasons. ***\n"
> -		       KERN_WARNING
> -		       "*** Pass \"allow_unsafe\" if you're trusting"
> -		       " all your (PV) guest kernels. ***\n");
> +			   "*** This CPU is affected with erratum 121"
> +			   " 64-bits PV guests are able to cause a DoS (XSA-9) ***\n");

Why the change in indentation?

There's also punctuation missing between both parts of the log message.

Jan

Re: [PATCH] x86/amd: Drop allow_unsafe parameter, tune down XSA-9 mitigations

[Teddy Astie]

[-- Attachment #1: Type: text/plain, Size: 1648 bytes --]

Le 04/05/2026 à 12:39, Jan Beulich a écrit :
> On 22.04.2026 18:58, Teddy Astie wrote:
>> @@ -1205,19 +1201,12 @@ static void cf_check init_amd(struct cpuinfo_x86 *c)
>>   	if (c->family == 0x10)
>>   		__clear_bit(X86_FEATURE_MONITOR, c->x86_capability);
>>   
>> -	if (!cpu_has_amd_erratum(c, AMD_ERRATUM_121))
>> -		opt_allow_unsafe = 1;
>> -	else if (opt_allow_unsafe < 0)
>> -		panic("Xen will not boot on this CPU for security reasons"
>> -		      "Pass \"allow_unsafe\" if you're trusting all your"
>> -		      " (PV) guest kernels.\n");
>> -	else if (!opt_allow_unsafe && c == &boot_cpu_data)
>> +	if (cpu_has_amd_erratum(c, AMD_ERRATUM_121))
>> +	{
> 
> Nit: Misplaced brace (it's Linux style here). But really I don't see why
> braces are added in the first place.
> 

Yes, they can be removed here.

>>   		printk(KERN_WARNING
>> -		       "*** Xen will not allow creation of DomU-s on"
>> -		       " this CPU for security reasons. ***\n"
>> -		       KERN_WARNING
>> -		       "*** Pass \"allow_unsafe\" if you're trusting"
>> -		       " all your (PV) guest kernels. ***\n");
>> +			   "*** This CPU is affected with erratum 121"
>> +			   " 64-bits PV guests are able to cause a DoS (XSA-9) ***\n");
> 
> Why the change in indentation?
> 

Looks like my editor got confused with the mixed indentation of the 
file. I can fix this case for the next version of the patch.

> There's also punctuation missing between both parts of the log message.
> 

ok

> Jan
> 

Teddy


--
Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech