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

[Ard Biesheuvel]

On Wed, 12 Feb 2025 at 22:26, Alexander Graf <graf@amazon.com> wrote:
>
>
> On 12.02.25 16:18, Gerd Hoffmann wrote:
> >    Hi,
> >
> >>> 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
> > That is totally fine.  EFI drivers must register everything they need as
> > runtime memory.  Anything else can be unmapped by the OS when calling
> > EFI services.
> >
> >> and it literally memcpy()'s all preserved (virtual available) code and
> >> data to different physical addresses.
> > Uhm.  I have my doubts this copying behavior is blessed by the UEFI spec.
>
>
> I don't remember anything in the spec prohibiting it.
>

The UEFI spec clearly states that runtime services must either be
called using a 1:1 mapping, or via a virtual remapping but in that
case, SetVirtualAddresMap() must be called to inform the firmware of
the new virtual mapping.

Even if this is not clearly stated, this violates the intent of the
UEFI spec: the code reasons about mappings of physical memory,
implying that the mapping is the only thing that changes. Moving
memory contents around can only be done safely after
SetVirtualAddressMap(), making it mandatory on these systems, whereas
the spec clearly states that it is entirely optional.

But whatever OSX does on x86 is irrelevant anyway: it is vertically
integrated with the firmware, which is vaguely EFI based but does not
aim for spec compliance. The OSX EULA does not permit running it on
anything other than Apple hardware. And x86 Apple hardware will be
reaching obsolescence pretty soon, at least where future development
is concerned.

My colleague filed a USWG proposal for a EFI_MEMORY_SHARED attribute
that must be honored by the OS when creating runtime mappings, and map
the region in a way that allows access by another observer (typically
the VMM but semantically it could mean other things too)

>
> >> You simply have nothing that is all of 1) RAM (mapped as cacheable on
> >> ARM), 2) known VA 3) known PA.
> > Bummer.
> >
> >> So we really really need a fallback mechanism that works without DMA
> >> :).
> > On arm it should be relatively simple to move the buffer to device
> > memory.  Just place one more region on the platform bus, advertise
> > address + size via device tree, done.
>
>
> That will bring back all issues with cached vs non-cached memory
> accesses, no? So edk2 will always access that memory as device memory
> which means it bypasses the cache, while QEMU will access it through the
> cache. So that buffer would need to actually be MMIO memory I suppose?
>

Indeed. Presenting memory as MMIO just to trick the guest into mapping
it shared is not the right approach here, which is why we need
EFI_MEMORY_SHARED on ARM. On x86, using the EfiMemoryMappedIo type
happens to work, but it is a hack (e.g., you cannot allocate memory of
this type)