On 14 September 2015 at 12:39, Jan Beulich <JBeulich@xxxxxxxx> wrote: >>>> On 14.09.15 at 11:36, <ard.biesheuvel@xxxxxxxxxx> wrote: >> On 14 September 2015 at 11:31, Shannon Zhao <zhaoshenglong@xxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
