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

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

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@xxxxxxxxxx>
> ---
> 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.