Re: query regarding SEV logic in early boot

[Tom Lendacky <thomas.lendacky@amd.com>]

On 3/24/25 12:28, Ard Biesheuvel wrote:
> L.S.,
> 
> As I am trying to disentangle the Linux early SEV boot code, the
> legacy decompressor and the EFI stub, I noticed something that looks
> broken to me, but I'm not quite sure how to fix it.
> 
> When booting via the EFI stub, the following call chain may occur:
> 
> setup_e820()
>  process_unaccepted_memory()
>   arch_accept_memory()
>    snp_accept_memory()
>     early_setup_ghcb()
>      set_page_decrypted()
>       set_clr_page_flags()
> 
> where the latter function relies on mapping_info to remap the GHCB
> page as unencrypted. However, when entering via the EFI stub, this
> struct is never initialized, and so I am struggling to see why this
> works at all.

The latter function reads from the target page so that the page gets
faulted in via do_boot_page_fault(). do_boot_page_fault() calls
kernel_add_identity_map(), which calls kernel_ident_mapping_init() and
initializes the mapping_info struct.

At least that is how it is supposed to happen coming through the
decompressor. I couldn't recreate the path you sited until I tried an odd
size memory argument that was not 2M aligned (using 4097M on the qemu
command line fixed that). However, even that causes issues, because the
SEV_STATUS MSR doesn't get read until sev_enable() is called, which is
called after setup_e820(), so we actually can't even take the
snp_accept_memory() path.

But faking the SEV_STATUS MSR value does cause the code to get down to the
set_clr_page_flags() function and reading the input address contents
doesn't trigger do_boot_page_fault() to run because load_stage2_idt()
hasn't been called, which probably wouldn't matter anyway since the code
is running under the EFI page tables.

So, yes, this does appear broken.

Thanks,
Tom

> 
> For context, I am looking into splitting/refactoring the decompressor
> SEV startup code and the kernel proper's SEV startup code, in order to
> a) use PIC codegen properly, and b) allow building a EFI-only bootable
> image that does not include all the exception handling and demand
> paging.
> 
> Any ideas?