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
