| Message ID | 55F6886D.1090900@huawei.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 14 September 2015 at 10:42, Shannon Zhao <zhaoshenglong@huawei.com> wrote: [..] > > It only needs to apply following patch to fix a bug in Linux kernel when > mapping EFI_MEMORY_RUNTIME memory. > Could you explain why you think efi_virtmap_init() should fail if there are no EFI_MEMORY_RUNTIME regions? The absence of such regions is allowed by the spec, so efi_virtmap_init() is correct imo to return success. If you are trying to work around the issue where Xen does not expose any Runtime Services regions, there is simply no way to do that and be still UEFI compliant. I have suggested before that we should perhaps tolerate this anyway, by considering the case where the EFI System Table has a NULL runtime services pointer. But rigging efi_virtmap_init() like this is really not the way to achieve that.
On 2015/9/14 17:09, Ard Biesheuvel wrote: > On 14 September 2015 at 10:42, Shannon Zhao <zhaoshenglong@huawei.com> wrote: > [..] > >> >> It only needs to apply following patch to fix a bug in Linux kernel when >> mapping EFI_MEMORY_RUNTIME memory. >> > > Could you explain why you think efi_virtmap_init() should fail if > there are no EFI_MEMORY_RUNTIME regions? > 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. > 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? > If you are trying to work around the issue where Xen does not expose > any Runtime Services regions, there is simply no way to do that and be > still UEFI compliant. I have suggested before that we should perhaps > tolerate this anyway, by considering the case where the EFI System > Table has a NULL runtime services pointer. But rigging > efi_virtmap_init() like this is really not the way to achieve that. >
(snip some cc's) On 14 September 2015 at 11:31, Shannon Zhao <zhaoshenglong@huawei.com> wrote: > > > On 2015/9/14 17:09, Ard Biesheuvel wrote: >> On 14 September 2015 at 10:42, Shannon Zhao <zhaoshenglong@huawei.com> wrote: >> [..] >> >>> >>> It only needs to apply following patch to fix a bug in Linux kernel when >>> mapping EFI_MEMORY_RUNTIME memory. >>> >> >> Could you explain why you think efi_virtmap_init() should fail if >> there are no EFI_MEMORY_RUNTIME regions? >> > > 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.
>>> On 14.09.15 at 11:36, <ard.biesheuvel@linaro.org> wrote: > On 14 September 2015 at 11:31, Shannon Zhao <zhaoshenglong@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. Jan
On 14 September 2015 at 12:39, Jan Beulich <JBeulich@suse.com> wrote: >>>> On 14.09.15 at 11:36, <ard.biesheuvel@linaro.org> wrote: >> On 14 September 2015 at 11:31, Shannon Zhao <zhaoshenglong@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)
>>> On 14.09.15 at 13:16, <ard.biesheuvel@linaro.org> wrote: > (I still think not using SetVirtualAddressMap() at all > would be the best approach for arm64, but unfortunately, most of my > colleagues disagree with me) Any reasons they have? I'm curious because we run x86 Xen without using this function ... Jan
diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c index e8ca6ea..bad7f87 100644 --- a/arch/arm64/kernel/efi.c +++ b/arch/arm64/kernel/efi.c @@ -233,6 +233,7 @@ void __init efi_init(void) static bool __init efi_virtmap_init(void) { efi_memory_desc_t *md; + bool status = false; for_each_efi_memory_desc(&memmap, md) { u64 paddr, npages, size; @@ -264,8 +265,11 @@ static bool __init efi_virtmap_init(void) prot = PAGE_KERNEL; create_pgd_mapping(&efi_mm, paddr, md->virt_addr, size, prot); + status = true; } - return true; + if (status) + return true; + return false; }