[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <10c385f7-1fd5-4fc7-b7cb-f3133e437a85@suse.com>
Date: Thu, 2 Jan 2025 12:57:16 +0100
From: Jürgen Groß <jgross@...e.com>
To: Andrew Cooper <andrew.cooper3@...rix.com>,
LKML <linux-kernel@...r.kernel.org>
Cc: Alex Zenla <alex@...ra.dev>, Peter Zijlstra <peterz@...radead.org>,
Josh Poimboeuf <jpoimboe@...nel.org>, Jason Baron <jbaron@...mai.com>,
Steven Rostedt <rostedt@...dmis.org>, Ard Biesheuvel <ardb@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
Borislav Petkov <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>,
x86@...nel.org, "H. Peter Anvin" <hpa@...or.com>, stable@...nel.org
Subject: Re: [PATCH] x86/static-call: Remove early_boot_irqs_disabled check to
fix Xen PVH dom0
On 21.12.24 22:10, Andrew Cooper wrote:
> __static_call_update_early() has a check for early_boot_irqs_disabled, but
> is used before early_boot_irqs_disabled is set up in start_kernel().
>
> Xen PV has always special cased early_boot_irqs_disabled, but Xen PVH does
> not and falls over the BUG when booting as dom0.
>
> It is very suspect that early_boot_irqs_disabled starts as 0, becomes 1 for
> a time, then becomes 0 again, but as this needs backporting to fix a
> breakage in a security fix, dropping the BUG_ON() is the far safer option.
>
> Fixes: 0ef8047b737d ("x86/static-call: provide a way to do very early static-call updates")
> Reported-by: Alex Zenla <alex@...ra.dev>
> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219620
> Suggested-by: Peter Zijlstra <peterz@...radead.org>
> Tested-by: Alex Zenla <alex@...ra.dev>
> Signed-off-by: Andrew Cooper <andrew.cooper3@...rix.com>
> ---
> CC: Peter Zijlstra <peterz@...radead.org>
> CC: Josh Poimboeuf <jpoimboe@...nel.org>
> CC: Jason Baron <jbaron@...mai.com>
> CC: Steven Rostedt <rostedt@...dmis.org>
> CC: Ard Biesheuvel <ardb@...nel.org>
> CC: Thomas Gleixner <tglx@...utronix.de>
> CC: Ingo Molnar <mingo@...hat.com>
> CC: Borislav Petkov <bp@...en8.de>
> CC: Dave Hansen <dave.hansen@...ux.intel.com>
> CC: x86@...nel.org
> CC: "H. Peter Anvin" <hpa@...or.com>
> CC: Juergen Gross <jgross@...e.com>
> CC: linux-kernel@...r.kernel.org
> CC: stable@...nel.org
Reviewed-by: Juergen Gross <jgross@...e.com>
>
> It's not entirely clear why PVH domU is fine but PVH dom0 is not. It crashes
> so early there's no console or useful backtrace.
I suspect that the Xen hypervisor doesn't supply a memory map for PVH dom0 via
the start_info data, while the Xen tools do so for PVH guests. This requires
dom0 to issue a hypercall very early in order to obtain the memory map.
Juergen
Download attachment "OpenPGP_0xB0DE9DD628BF132F.asc" of type "application/pgp-keys" (3684 bytes)
Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (496 bytes)
Powered by blists - more mailing lists