linux-kernel - Re: [PATCH v2 3/3] x86/boot: Implement early memory acceptance for SEV-SNP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAMj1kXEUAaqyySAbpdPsnNsgi=4sHV4DWDOyqMPJBptk_HiF0w@mail.gmail.com>
Date: Thu, 10 Apr 2025 15:28:05 +0200
From: Ard Biesheuvel <ardb@...nel.org>
To: Tom Lendacky <thomas.lendacky@....com>
Cc: "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>, 
	Dionna Amalie Glaze <dionnaglaze@...gle.com>, Ard Biesheuvel <ardb+git@...gle.com>, linux-efi@...r.kernel.org, 
	linux-kernel@...r.kernel.org, x86@...nel.org, Borislav Petkov <bp@...en8.de>, 
	Kevin Loughlin <kevinloughlin@...gle.com>
Subject: Re: [PATCH v2 3/3] x86/boot: Implement early memory acceptance for SEV-SNP

On Tue, 8 Apr 2025 at 17:53, Tom Lendacky <thomas.lendacky@....com> wrote:
>
> On 4/7/25 14:59, Ard Biesheuvel wrote:
> > On Mon, 7 Apr 2025 at 20:05, Tom Lendacky <thomas.lendacky@....com> wrote:
> >>
> >> On 4/7/25 04:25, Kirill A. Shutemov wrote:
> >>> On Fri, Apr 04, 2025 at 08:07:03AM -0700, Dionna Amalie Glaze wrote:
> >>>> If the GHCB is available, we should always prefer it.
> >>>
> >>> I believe we should consider the cost of code duplication in this
> >>> situation.
> >>>
> >>> If the non-early version is only used in the kexec path, it will not be
> >>> tested as frequently and could be more easily broken. I think it would be
> >>> acceptable for kexec to be slightly slower if it results in more
> >>> maintainable code.
> >>>
> >>
> >> Is accept_memory() in the decompressor or efistub only used in the kexec
> >> path?
> >>
> >
> > The EFI stub does not call accept_memory(), only the decompressor
> > does. The only use case for explicit memory acceptance in the EFI stub
>
> Since EFI stub never uses accept_memory() I looked at moving enablement
> of SEV to be before the setup of the accepted memory bitmap, as SEV
> enablement doesn't need any e820 info. But that didn't work because the
> real issue is early_setup_ghcb() calls set_page_decrypted() which calls
> set_clr_page_flags(). The latter function is not meant to work with EFI
> page tables, so there is an incompatibility.
>

I would prefer to go into the other direction, and not enable SEV at
all in the EFI stub. The core kernel will happily enable SEV anyway,
right?

> If we had a way to check for whether we are coming through the EFI stub
> vs the decompressor, then snp_accept_memory() could decide to skip
> early_setup_ghcb() when called from the EFI stub and call either
> __snp_accept_memory() from the decompressor or __page_state_change()
> from the EFI stub (the latter having to be updated to return a value).
>
> I think there are other areas that might need investigating because I
> noticed that efi_warn() is successful before efi_exit_boot_services()
> but blows up immediately after (possibly in the EFI #VC handler having
> to do with addressing the string?).
>

efi_warn() blows up because the console is gone after
ExitBootServices(). That is not SEV related.