[Xen-devel] [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

[Ard Biesheuvel]

On 14 September 2015 at 12:39, Jan Beulich <JBeulich at suse.com> wrote:
>>>> On 14.09.15 at 11:36, <ard.biesheuvel at linaro.org> wrote:
>> On 14 September 2015 at 11:31, Shannon Zhao <zhaoshenglong at huawei.com> wrote:
>>> My understanding is that if there are no EFI_MEMORY_RUNTIME regions, it
>>> means we can't use runtime services and should not set the bit
>>> EFI_RUNTIME_SERVICES of efi.flags. But if efi_virtmap_init() return
>>> true, the bit will be set.
>>>
>>
>> As I said, if you don't want the EFI_RUNTIME_SERVICES bit to be set
>> for other reasons, don't rig efi_virtmap_init() to return false when
>> it shouldn't.
>>
>>>> The absence of such regions is allowed by the spec, so
>>>> efi_virtmap_init() is correct imo to return success.
>>>>
>>> Sorry, not well know about the spec. Could you point out where the spec
>>> says this?
>>>
>>
>> Well, I think it doesn't work that way. You are claiming that a memory
>> map without at least one EFI_MEMORY_RUNTIME constitutes an error
>> condition, so the burden is on you to provide a reference to the spec
>> that says you must have at least one such region.
>
> Sure, from a spec pov you're right. But where would runtime
> services code/data live when there's not a single region marked
> as needing a runtime mapping. IOW while the spec doesn't say
> so, assuming no runtime services when there's not at least one
> executable region with the runtime flag set could serve as a stop
> gap measure against flawed firmware.
>

That in itself is a fair point. But the argument being made was that
it is in itself a bug for no EFI_MEMORY_RUNTIME regions to exist,
while the actual purpose of the patch is to prevent the
RuntimeServices pointer from being dereferenced on platforms like Xen
that may not be able to implement them.

But actually, even in case of Xen, you will need some
EFI_MEMORY_RUNTIME regions anyway, since the f/w vendor field and the
config and runtime services table pointers are translated to virtual
addresses by the firmware, which means the OS needs to translate them
back to physical addresses in order to dereference them before the VA
mapping is up. (I still think not using SetVirtualAddressMap() at all
would be the best approach for arm64, but unfortunately, most of my
colleagues disagree with me)

-- 
Ard.