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

[Steve Wahl]

On Mon, Jul 08, 2024 at 09:07:24PM +0200, Borislav Petkov wrote:
> On Mon, Jul 08, 2024 at 08:17:43PM +0200, Ard Biesheuvel wrote:
> > 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.
> 
> See upthread. I think this is about AMD server machines which support SEV
> baremetal and not about SEV-ES/SNP guests which must do attestation.
> 
> Steve?

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

> AFAIR, there was some kink that we have to parse the blob regardless which
> I didn't like either but I'd need to refresh with Tom and see whether we can
> solve it differently after all. Perhaps check X86_FEATURE_HYPERVISOR or so...
> 
> Thx for offering to help still - appreciated! :-)

You asked me to imagine if the one-liner had worked.  Yes, it would
have been a magical, easy fix!  But things should be as simple as
possible, but no simpler, and that solution is "simpler than
possible".

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; and lacking that understanding, I'm powerless to help
find alternatives that would be more acceptable.

Having kexec place these portions in the identity map before jumping
to the new kernel more closely mimics the conditions we are under when
entered from the BIOS and bootloader.  So it seems to me to be the
logical way to go.

Thanks,

--> Steve

-- 
Steve Wahl, Hewlett Packard Enterprise