Re: [PATCH v3 09/23] hw/uefi: add var-service-core.c

[Gerd Hoffmann]

On Wed, Feb 12, 2025 at 12:30:20PM +0100, Alexander Graf wrote:
> 
> On 12.02.25 11:24, Gerd Hoffmann wrote:
> > 
> > Why do you use confidential computing in the first place if you trust
> > the host with your EFI variables?  I'd rather see something simliar
> > running under guest control, in svsm context.
> 
> That depends heavily on your threat model. You can use a host provided
> variable store to gain variable persistence for things like boot variables
> and then have an ephemeral SVSM based TPM that you use to measure the loaded
> payloads. A malicious host can already replace your root volume, so
> extending the threat to variables is not the end of the world.

If you go depend on measured boot instead of secure boot then yes, this
might be a workable model.  Should be doable with a small svsm driver
which forwards requests to the host via svsm-controlled bounce buffer
(where the svsm has control over page properties).

> > The firmware knows all this very well though.  The OS passes a mapping
> > table to the firmware, efi runtime drivers can subscribe to mapping
> > updates and can use RT->ConvertPointer to translate addresses from
> > physical to virtual.
> > 
> > The edk2 code (https://github.com/tianocore/edk2/pull/10695) does
> > exactly that.
> > 
> > I see your driver does that too, so in theory it should work just fine.
> > I'm wondering what exactly the problem with macOS is?
> 
> You get to know the new virtual address, but ConvertPointer never tells you
> what the new *physical* address is. That means you have no idea where to DMA
> from once you're in virtual land.

Yes.  Knowing both physical and virtual address works only for memory
you allocated yourself before ExitBootServices.  So you can't pass on
pointers from the OS, you have to copy the data to a buffer where you
know the physical address instead.  Yes, some overhead.  Should still
be much faster than going to pio transfer mode ...

> > It would be nice to have nitro support merged upstream,
> > especially with BYOF coming.
> 
> Yes. Or converge on this protocol instead to simplify the firmware
> implementation

Yes, that works too and would reduce your stack of unmerged patches a
bit.

take care,
  Gerd