Re: [PATCH 0/3] Resolve problems with kexec identity mapping

[Ard Biesheuvel]

On Mon, 8 Jul 2024 at 20:12, Borislav Petkov <bp@xxxxxxxxx> wrote:
>
> On Mon, Jul 08, 2024 at 10:42:47AM -0500, Steve Wahl wrote:
> > So I looked at the code more closely, and I don't think boot_page_fault is
> > going to work prior to the call to initialize_identity_maps.  In the current
> > flow in head_64.S, that comes after load_stage2_idt, where here we were
> > trying to use it just after load_stage1_idt, quite a bit earlier.
>
> But still after setting up the #PF handlers in both cases. So it can't be
> that.
>
> > Is there a reason you want to avoid having these areas already entered
> > in the identity map setup by kexec?
>
> Well, imagine my one-liner worked. Can you think of a reason then?
>
> So, theoretically, this should be reproducible in a VM too, I'd say. If we
> could manage to get that EFI config table placed at the right address, to be
> outside of a 1G page so that it doesn't get covered by a Gb mapping.
>
> Or use "nogbpages" and then maybe perhaps with Ard's help hack up OVMF to do
> so. :)
>
> So, can someone with such a box boot with "efi=debug" on the kernel cmdline so
> that we can try to reproduce the memory layout in a VM?
>

Happy to assist, but I'm not sure I follow the approach here.

In the context of a confidential VM, I don't think the page fault
handler is ever an acceptable approach. kexec should filter out config
tables that it doesn't recognize, and map the ones that it does (note
that EFI config tables have no standardized header with a length, so
mapping tables it does *not* recognize is not feasible to begin with).

All these games with on-demand paging may have made sense for 64-bit
kernels booting in 32-bit mode (which can only map the first 4G of
RAM), but in a confiidential VM context with measurement/attestation
etc I think the cure is worse than the disease.