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

[Ard Biesheuvel]

On Tue, 2 Jul 2024 at 19:45, Borislav Petkov <bp@xxxxxxxxx> wrote:
>
> On Mon, Jul 01, 2024 at 04:27:04PM +0200, Borislav Petkov wrote:
> > On Mon, Jun 24, 2024 at 10:13:44AM -0500, Steve Wahl wrote:
> > > These accesses are a problem because they happen prior to establishing
> > > the page fault interrupt handler that would mend the identity map.  I
> > > know very little about the AMD SEV feature but reading the code I
> > > think it may be required to do this before setting up that handler.
> >
> > Yeah, from looking at it, we should be able to establish a #PF handler that
> > early too but the devil's in the detail, especially in that early boot code.
> >
> > Lemme poke some things and people...
>
> Ard, from EFI perspective and boot services exiting, do you see any potential
> issues if we enable a pagefault handler in load_stage1_idt() in
> arch/x86/boot/compressed/head_64.S already or is the EFI pagetable not really
> "reliable" then?
>

For the first boot, this shouldn't be needed - EFI maps all of RAM so
I wouldn't expect the PF handler to fire, except when writing to code
regions that were mapped ROX by the firmware. But even then, things
should just keep working, although from a security pov, it would be
better if the r/o regions remain r/o

> Would solve the issue in this thread where the EFI config table ends up not
> mapped on some hw configurations, elegantly...
>

The #PF handler makes sense when entering via the 32-bit entrypoint,
where the asm can only map the lower 4G and is in no position to
reason about where RAM lives.

For kexec on a 64-bit system, I would expect the high-level support
code to be capable of simply mapping all of DRAM 1:1, rather than
playing these games with #PF handlers and on-demand mapping.