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

From: Steve Wahl
Date: Mon Jul 08 2024 - 16:41:52 EST


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.

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

--> Steve
--
Steve Wahl, Hewlett Packard Enterprise