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

[Alexander Graf <graf@amazon.com>]

On 12.02.25 13:28, Gerd Hoffmann wrote:
> 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).


In a BYOF world it's even useful without SVSM at all, because the launch 
digest performs measurement for you, but you still want to find your 
boot variables.


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


MacOS takes over the full physical address map past ExitBootServices: 
Your code no longer has VA access to random code and it literally 
memcpy()'s all preserved (virtual available) code and data to different 
physical addresses. You simply have nothing that is all of 1) RAM 
(mapped as cacheable on ARM), 2) known VA 3) known PA.

So we really really need a fallback mechanism that works without DMA :).


Alex