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

[Alexander Graf <graf@amazon.com>]

On 12.02.25 11:24, Gerd Hoffmann wrote:
>    Hi,
>
>>> +    /* read header */
>>> +    dma_memory_read(&address_space_memory, dma,
>>> +                    uv->buffer, sizeof(*mhdr),
>>> +                    MEMTXATTRS_UNSPECIFIED);
>> Depending on DMA sounds appealing at first, but can fall apart in corner
>> cases. I know of 2 cases where DMA failed for me in the EC2 equivalent of
>> this:
>>
>> 1) SEV-SNP. If you want the hypervisor to implement UEFI variable services
>> for you, the buffer region must always be in shared state. Ensuring that
>> during boot time is tricky but doable. At runtime you no longer really have
>> control over the sharability of pages.
> With SEV-SNP I don't see the point in using this.
>
> 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.


>
>> 2) Mac OS X. MacOS is the only OS I'm aware of that really makes use of
>> relocation. They move your physical pages to random locations, give you a
>> non-1:1 mapping to that and once you're in real OS land, you have no more
>> knowledge at all about the physical location of anything.
> On the host side you have no insight into this indeed.
>
> 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. Most OSs just keep a 1:1 
map of virtual to physical, but MacOS does not.


>> Also, I'm surprised you cut the variable service off at the SMM boundary
>> instead of the RTS callback boundary. Why is that cleaner/better than
>> implementing variables completely in QEMU?
> Well, the variable service /is/ completely in qemu.  See patch #6 which
> implements getvariable & friends.  edk2 serializes the variable calls
> into a buffer and sends them over to the SMM side (or to qemu with the
> patches).
>
> I didn't feel like inventing a new serialization protocol if we already
> have a proven one in the edk2 code base.  Also it is possible to send
> over more than just the variable call.  There is a variable policy
> protocol implementation (patch #8), and we also get some events
> forwarded.  More can easily be added should the need for that arise.
>
>> It would be nice to agree on a single external variable store implementation
>> :).
> 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 so we don't create needless work if someone wants to do 
an actually trivial (and reusable?) UEFI firmware for BYOF.


Alex