Re: [PATCH] x86/boot/sev: Move SEV decompressor variables into the .data section

[Changyuan Lyu]

On Thu, Feb 26, 2026 at 11:22 AM Borislav Petkov <bp@xxxxxxxxx> wrote:
>
> On February 26, 2026 7:16:11 PM UTC, Changyuan Lyu <changyuanl@xxxxxxxxxx> wrote:
> >On Wed, 4 Feb 2026 09:01:00 -0600, Tom Lendacky <thomas.lendacky@xxxxxxx> wrote
> >> As part of the work to remove the dependency on calling into the
> >> decompressor code (startup_64()) for a UEFI boot, a call to rmpadjust()
> >> was removed from sev_enable() in favor of checking the value of the
> >> snp_vmpl variable. When booting through a non-UEFI path and calling
> >> startup_64(), the call to sev_enable() is performed before the BSS section
> >> is zeroed. With the removal of the rmpadjust() call and the corresponding
> >> check of the return code, the snp_vmpl variable is checked. Since the
> >> kernel is running at VMPL0, the snp_vmpl variable will not have been set
> >> and should be the default value of 0. However, since the call occurs
> >> before the BSS is zeroed, the snp_vmpl variable may not actually be zero,
> >> which will cause the guest boot to fail.
> >>
> >> Since the decompressor relocates itself, the BSS would need to be cleared
> >> both before and after the relocation, but this would, in effect, cause all
> >> of the changes to BSS variables before relocation to be lost after
> >> relocation.
> >>
> >> Instead, move the snp_vmpl variable into the .data section so that it is
> >> initialized and the value made safe during relocation. As a pre-caution
> >> against future changes, move other SEV-related decompressor variables into
> >> the .data section, too.
> >>
> >> Fixes: 68a501d7fd82 ("x86/boot: Drop redundant RMPADJUST in SEV SVSM presence check")
> >> Cc: stable@xxxxxxxxxxxxxxx
> >> Cc: Ard Biesheuvel <ardb@xxxxxxxxxx>
> >> Tested-by: Kevin Hui <kevinhui@xxxxxxxx>
> >> Signed-off-by: Tom Lendacky <thomas.lendacky@xxxxxxx>
> >
> >Reviewed-by: Changyuan Lyu <changyuanl@xxxxxxxxxx>
> >
> >>  [...]
>
> Did you test it too to make sure it fixes your issue?

Hi Borislav,

I rebased this patch to e3c81bae4f282a6be56bc22e05e2ce3dd92ae301
and tested with the steps in
https://lore.kernel.org/all/20260226060714.1636773-1-changyuanl@xxxxxxxxxx/.
This fix works for my use case (direct kernel boot without UEFI).

Tested-by: Changyuan Lyu <changyuanl@xxxxxxxxxx>

Best
Changyuan


> Small device. Typos and formatting crap