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

[Alexander Graf <graf@amazon.com>]

[-- Attachment #1: Type: text/plain, Size: 5575 bytes --]


On 13.02.25 10:28, Ard Biesheuvel wrote:
> 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.


Correct, which is what boot.efi does. That mapping only tells firmware 
about the change from old VA -> new VA though.


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


The spec says that calling SetVirtualAddressMap is optional from the 
firmware's point of view. A boot loader may call it - and even depend on 
its functionality. The spec even goes further and almost endorses the 
case boot.efi does:

> The call to SetVirtualAddressMap() must be done with the physical 
> mappings. On successful return from this function, the system must 
> then make any future calls with the newly assigned virtual mappings. 
> All address space mappings must be done in accordance to the 
> cacheability flags as specified in the original address map. [...]


You can absolutely read that paragraph as "From here on, only virtual 
mappings matter".


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


I halfway agree. It's fairly trivial to make x86 Mac OS X work with 
stock edk2 [1]. All you need are a few boot services, a non-standard way 
(or BootXXX variables) to find the real boot binary and APFS driver 
(binary is included in every APFS FS) load support. The rest is a fairly 
standard compliant UEFI environment.

But I'm not sure how that's relevant to the argument that we need a way 
to perform runtime service calls without relying on DMA? In addition to 
the potential VA/PA mismatch issue, relying on DMA from RTS can quickly 
also get broken for any confidential compute environments where you need 
to take explicit action to make memory visible to the hypervisor.

All I'm asking for is an (optional) viable path that works without DMA :).


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


For something as core as a UEFI variable service that should become the 
default in a generic platform like QEMU, I don't think we should rely on 
new additions to the UEFI spec :(. Users want to be able to run old 
Operating Systems.


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


The non-hacky alternative would be to expose a real 64KiB large MMIO 
window into host memory that goes through full instruction emulation for 
every access. Then we could expose it as real MMIO target memory to RTS 
which should always work. DMA can then be an (optional) optimization on 
top to copy to/from that buffer.


Alex


[1] 
https://github.com/tianocore/edk2/compare/vUDK2018...agraf:edk2:vUDK2018-AppleSupportPkg

[-- Attachment #2: Type: text/html, Size: 9251 bytes --]