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(-)
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.techOn 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
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.
© 2016 - 2026 Red Hat, Inc.