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

[Ard Biesheuvel]

On Mon, 8 Jul 2024 at 22:41, Steve Wahl <steve.wahl@xxxxxxx> wrote:
>
> On Mon, Jul 08, 2024 at 09:58:10PM +0200, Borislav Petkov wrote:
> > On Mon, Jul 08, 2024 at 02:29:05PM -0500, Steve Wahl wrote:
> > > Yes, this is about AMD machines which support SEV, running bare metal.
> > > ("Server" is in question, one of my testers is known to be using a
> > > laptop, so the facilities must be present in non-servers as well.)
> >
> > No, they can't be. SEV is supported only on server, not on client. This laptop
> > has a different problem it seems.
>
> Ahhh.  On the laptop, it's not looking *at* the CC blob that's the
> problem.
>
> Its looking *for* the CC blob in the EFI config table; the CC blob
> probably does not exist in that table on the laptop.  But the EFI
> config table needs to be identity mapped, to look through it and see
> that the CC blob is not there, and the EFI config table is not mapped.
>
> I think the existence of the CC blob in the EFI config table is being
> used, more or less, as a flag as to whether we need to do SEV related
> code.  Without mapping the EFI config table, we can't look for that
> blob.
>

We have run into this exact problem before - I don't have time to
check lore right now (it's 11pm here) but 'CC blob' and 'EFI config
table' are the keywords that may help you track down the thread.

So first of all, let's define some terminology:
- the EFI system table is the EFI root table that contains some magic
numbers and pointers to various other assets in memory, one of which
is:
- the EFI config table array, which is just a list of (GUID, pointer)
tuples, the length of which is recorded in the EFI system table
- an EFI config table is some asset elsewhere in memory that is
identified by its GUID.

The EFI config table array can grow and shrink at boot time, which is
why it is a separate allocation, as this allows it to be realloc()'ed.
This means any bootloader that intends to map the primary EFI table
should also map the EFI config table array, which may be elsewhere
entirely.

> > > As far as I can see it, the effort you're putting into finding a
> > > different solution must mean you find something less than desirable
> > > about the solution I have offered.  But at this point, I don't
> > > understand why;
> >
> > Why would we parse the CC blob which is destined *solely* for a SEV- *guest*,
> > when booting the baremetal kernel which is *not* a guest?
> >
> > This is the solution I'm chasing - don't do something you're not supposed to
> > or needed to do.
>
> What you're saying suggests that, maybe, my patch #2 will not be
> necessary.  The CC blob will never be present except for in a guest.
> But can you do a kexec to a new kernel within that guest?  If so,
> patch #2 might still be necessary.
>
> Anyway, I think the references you're trying to eliminate when they're
> not needed are the references used to determine if the SEV feature is
> to be used in this specific boot iteration or not.
>

It would be better if we did not have to rely on page fault handling
to map the EFI config table array this early. This is not strictly
related to SEV, but the CC blob happens to be the EFI config table
that is accessed before the page fault handler is installed.

So regardless of how we fix any SEV-guest specific issues, we should
ensure that kexec infrastructure creates the mappings of the EFI
system table and the EFI config table array upfront.