On Fri, Apr 12, 2024 at 10:32:15PM +0100, Ignat Korchagin wrote: > > > On 10 Apr 2024, at 15:11, Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > > > On Wed, Apr 10, 2024 at 08:43:24AM +0200, Ard Biesheuvel wrote: > >> On Wed, 10 Apr 2024 at 07:46, Greg Kroah-Hartman > >> <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > >>> > >>> On Wed, Apr 10, 2024 at 07:34:33AM +0200, Borislav Petkov wrote: > >>>> On Tue, Apr 09, 2024 at 06:38:53PM +0200, Pascal Ernster wrote: > >>>>> Just to make sure this doesn't get lost: This patch causes the kernel to not > >>>>> boot on several x86_64 VMs of mine (I haven't tested it on a bare metal > >>>>> machine). For details and a kernel config to reproduce the issue, see https://lore.kernel.org/stable/fd186a2b-0c62-4942-bed3-a27d72930310@xxxxxxxxxxxxxx/ > >>>> > >>>> I see your .config there. How are you booting the VMs? qemu cmdline? > >>>> > >>>> Ard, anything missing in the backport? > >>>> > >>>> I'm busy and won't be able to look in the next couple of days... > >>> > >>> As reverting seems to resolve this, I'll go do that after my morning > >>> coffee kicks in... > >> > >> Fair enough. I'll look into this today, but I guess you're on a tight > >> schedule with this release. > >> > >> Please drop the subsequent patch as well: > >> > >> x86/efistub: Remap kernel text read-only before dropping NX attribute > >> > >> as it assumes that all code reachable from the startup entrypoint is > >> in .head.text and this will no longer be the case. > > > > Given this is the only report, and it seems to be with an "odd" linker, > > I'll leave it in for now to keep in sync with 6.9-rc. If this is a > > problem, we can revert the commits in a later release at any time. > > We encountered this issue in our production machines and reproduced on a simple QEMU in standard Debian Bookworm > > Steps: > 1. Download source > 2. $ make defconfig > 3. Enable CONFIG_AMD_MEM_ENCRYPT and CONFIG_GCC_PLUGIN_STACKLEAK through make menuconfig > 4. Compile > 5. $ qemu-system-x86_64 -smp 2 -m 1G -enable-kvm -cpu host -kernel arch/x86/boot/bzImage -nographic -append "console=ttyS0” > > You will notice that the VM will go into reboot loop (same happens in our bare metal production servers). Do note that you would need a compiler with CONFIG_GCC_PLUGIN_STACKLEAK support (not the standard Debian one - unless I don’t know how to install GCC plugins) Thanks for th ereport, we have a fix for this in the latest -rc testing kernel out for review and will be in the next release in a day or so. thanks, greg k-h