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

[Steve Wahl]

On Tue, Jul 02, 2024 at 08:32:22PM +0200, Ard Biesheuvel wrote:
> 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

We are looking at entering from kexec, and the identity map is not
completely filled in with all available RAM, especially if you use
smaller 2M pages to create the identity map.

Patches 1 and 2 are aiming to fill in the parts of the map we
potentially use before the page fault handler is established.

(And my overall problem is kexec creating the identity map with 1G
pages includes areas that are marked "reserved" by the BIOS, causing a
halt when speculatively accessed.  This is what patch 3 addresses.)

> > 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.

Currently the identity map is selectively created, and at least
from my point of view, patches 1 and 2 add in some parts that are
missed and also not covered by #PF handlers.

--> Steve

-- 
Steve Wahl, Hewlett Packard Enterprise