Re: [PATCH 6.8 271/273] x86/sme: Move early SME kernel encryption handling into .head.text

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux