| Message ID | 1456153179-27214-1-git-send-email-ard.biesheuvel@linaro.org |
|---|---|
| State | New |
| Headers | show |
On Mon, Feb 22, 2016 at 03:59:39PM +0100, Ard Biesheuvel wrote: > The permanent, writable mapping of the UEFI System table is only > referenced during invocations of UEFI Runtime Services, at which time > the UEFI virtual mapping is available, which also covers the system > table (since the runtime services themselves need access to it) I'm not sure it's strictly true that the runtime services themselves need access to the system table. Why would that be necessary? Are runtime services mandated to indirect calls via the system table? I would expect that the EFI system table and EFI runtime services table are not in EfiConventionalMemory, but I'm not sure that we have the guarnatee that they're both in EfiRuntimeServices* memory.. From the spec, I couldn't find a mandate that the system table (nor the runtime services table) were in a region of EfiRuntimeServicesData memory. I suspect I'm looking in the wrong place... > So instead of creating this permanent mapping, record the virtual > address of the system table inside the UEFI virtual mapping, and > use that instead. This protects the contents of the system table > from inadvertent (or deliberate) modification. > > Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> > --- > > Something I spotted while working on the memory attribute table stuff. > Since this is low hanging fruit and otherwise completely unrelated to it, > I am posting it as a separate patch > > drivers/firmware/efi/arm-init.c | 2 ++ > drivers/firmware/efi/arm-runtime.c | 24 ++++++++++---------- > 2 files changed, 14 insertions(+), 12 deletions(-) > > diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/arm-init.c > index 022f11157acd..e995d61da747 100644 > --- a/drivers/firmware/efi/arm-init.c > +++ b/drivers/firmware/efi/arm-init.c > @@ -85,6 +85,8 @@ static int __init uefi_init(void) > efi.systab->hdr.revision >> 16, > efi.systab->hdr.revision & 0xffff); > > + efi.runtime_version = efi.systab->hdr.revision; > + > /* Show what we know for posterity */ > c16 = early_memremap_ro(efi_to_phys(efi.systab->fw_vendor), > sizeof(vendor) * sizeof(efi_char16_t)); > diff --git a/drivers/firmware/efi/arm-runtime.c b/drivers/firmware/efi/arm-runtime.c > index 848ede1587dc..6ce13d6b7122 100644 > --- a/drivers/firmware/efi/arm-runtime.c > +++ b/drivers/firmware/efi/arm-runtime.c > @@ -64,6 +64,16 @@ static bool __init efi_virtmap_init(void) > &phys, ret); > return false; > } > + /* > + * If this entry covers the address of the UEFI system table, > + * calculate and record its virtual address. > + */ > + if (efi_system_table >= phys && > + efi_system_table < phys + (md->num_pages * EFI_PAGE_SIZE)) { > + efi.systab = (void *)(efi_system_table - phys + > + md->virt_addr); > + set_bit(EFI_SYSTEM_TABLES, &efi.flags); > + } It seems very odd to me to set this given it's currently unused, and we don't have permanent access to the table. That sounds like we're just setting ourselves up for future fragility as users appear. Thanks, Mark. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On 22 February 2016 at 16:43, Mark Rutland <mark.rutland@arm.com> wrote: > On Mon, Feb 22, 2016 at 03:59:39PM +0100, Ard Biesheuvel wrote: >> The permanent, writable mapping of the UEFI System table is only >> referenced during invocations of UEFI Runtime Services, at which time >> the UEFI virtual mapping is available, which also covers the system >> table (since the runtime services themselves need access to it) > > I'm not sure it's strictly true that the runtime services themselves > need access to the system table. Why would that be necessary? Are > runtime services mandated to indirect calls via the system table? > They don't need access per se, but they are allowed to reference it, and so the memory remapping layer must make it accessible after SetVirtualAddressMap(). The spec lists explicitly which fields are still valid after ExitBootServices() > I would expect that the EFI system table and EFI runtime services table > are not in EfiConventionalMemory, but I'm not sure that we have the > guarnatee that they're both in EfiRuntimeServices* memory.. > SetVirtualAddressMap() is a runtime service, and one of the things it does is update the pointers in the system table, hence it must be located in RuntimeService memory, because anything else may be gone by this time. > From the spec, I couldn't find a mandate that the system table (nor the > runtime services table) were in a region of EfiRuntimeServicesData > memory. I suspect I'm looking in the wrong place... > We should clarify it if it is not clear (or if I turn out to be wrong) >> So instead of creating this permanent mapping, record the virtual >> address of the system table inside the UEFI virtual mapping, and >> use that instead. This protects the contents of the system table >> from inadvertent (or deliberate) modification. >> >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> >> --- >> >> Something I spotted while working on the memory attribute table stuff. >> Since this is low hanging fruit and otherwise completely unrelated to it, >> I am posting it as a separate patch >> >> drivers/firmware/efi/arm-init.c | 2 ++ >> drivers/firmware/efi/arm-runtime.c | 24 ++++++++++---------- >> 2 files changed, 14 insertions(+), 12 deletions(-) >> >> diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/arm-init.c >> index 022f11157acd..e995d61da747 100644 >> --- a/drivers/firmware/efi/arm-init.c >> +++ b/drivers/firmware/efi/arm-init.c >> @@ -85,6 +85,8 @@ static int __init uefi_init(void) >> efi.systab->hdr.revision >> 16, >> efi.systab->hdr.revision & 0xffff); >> >> + efi.runtime_version = efi.systab->hdr.revision; >> + >> /* Show what we know for posterity */ >> c16 = early_memremap_ro(efi_to_phys(efi.systab->fw_vendor), >> sizeof(vendor) * sizeof(efi_char16_t)); >> diff --git a/drivers/firmware/efi/arm-runtime.c b/drivers/firmware/efi/arm-runtime.c >> index 848ede1587dc..6ce13d6b7122 100644 >> --- a/drivers/firmware/efi/arm-runtime.c >> +++ b/drivers/firmware/efi/arm-runtime.c >> @@ -64,6 +64,16 @@ static bool __init efi_virtmap_init(void) >> &phys, ret); >> return false; >> } >> + /* >> + * If this entry covers the address of the UEFI system table, >> + * calculate and record its virtual address. >> + */ >> + if (efi_system_table >= phys && >> + efi_system_table < phys + (md->num_pages * EFI_PAGE_SIZE)) { >> + efi.systab = (void *)(efi_system_table - phys + >> + md->virt_addr); >> + set_bit(EFI_SYSTEM_TABLES, &efi.flags); >> + } > > It seems very odd to me to set this given it's currently unused, and we > don't have permanent access to the table. That sounds like we're just > setting ourselves up for future fragility as users appear. > I wondered about the purpose as well. It is only ever set, and never tested (until this patch) @Matt: any thoughts? _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Mon, Feb 22, 2016 at 04:56:57PM +0100, Ard Biesheuvel wrote: > On 22 February 2016 at 16:43, Mark Rutland <mark.rutland@arm.com> wrote: > > On Mon, Feb 22, 2016 at 03:59:39PM +0100, Ard Biesheuvel wrote: > >> The permanent, writable mapping of the UEFI System table is only > >> referenced during invocations of UEFI Runtime Services, at which time > >> the UEFI virtual mapping is available, which also covers the system > >> table (since the runtime services themselves need access to it) > > > > I'm not sure it's strictly true that the runtime services themselves > > need access to the system table. Why would that be necessary? Are > > runtime services mandated to indirect calls via the system table? > > > > They don't need access per se, but they are allowed to reference it, > and so the memory remapping layer must make it accessible after > SetVirtualAddressMap(). The spec lists explicitly which fields are > still valid after ExitBootServices() I was language-lawyering ;) I appreciate that they _can_, I just didn't think it was true that they _must_ (i.e. that they always "need to access it"). Per the below that's likely moot. > SetVirtualAddressMap() is a runtime service, and one of the things it > does is update the pointers in the system table, hence it must be > located in RuntimeService memory, because anything else may be gone by > this time. Good point. That does imply that it must be in EfiRuntimeServices* memory. > > From the spec, I couldn't find a mandate that the system table (nor the > > runtime services table) were in a region of EfiRuntimeServicesData > > memory. I suspect I'm looking in the wrong place... > > We should clarify it if it is not clear (or if I turn out to be wrong) I'm hoping that I've simply missed something. Perhaps the implication above was intentional, albeit rather opaque. Otherwise, I certainly agree a clarification would be a good thing! Mark. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On 22 February 2016 at 17:09, Mark Rutland <mark.rutland@arm.com> wrote: > On Mon, Feb 22, 2016 at 04:56:57PM +0100, Ard Biesheuvel wrote: >> On 22 February 2016 at 16:43, Mark Rutland <mark.rutland@arm.com> wrote: >> > On Mon, Feb 22, 2016 at 03:59:39PM +0100, Ard Biesheuvel wrote: >> >> The permanent, writable mapping of the UEFI System table is only >> >> referenced during invocations of UEFI Runtime Services, at which time >> >> the UEFI virtual mapping is available, which also covers the system >> >> table (since the runtime services themselves need access to it) >> > >> > I'm not sure it's strictly true that the runtime services themselves >> > need access to the system table. Why would that be necessary? Are >> > runtime services mandated to indirect calls via the system table? >> > >> >> They don't need access per se, but they are allowed to reference it, >> and so the memory remapping layer must make it accessible after >> SetVirtualAddressMap(). The spec lists explicitly which fields are >> still valid after ExitBootServices() > > I was language-lawyering ;) > > I appreciate that they _can_, I just didn't think it was true that they > _must_ (i.e. that they always "need to access it"). Per the below that's > likely moot. > Runtime services drivers must call ConvertPointer() to translate the pointer variables in their global state to their virtual equivalents. So unless a Runtime driver does not have such state at all, it needs access to the runtime services table, which is usually retrieved through the system table. So yes, you're right. And yes, it's moot :-) >> SetVirtualAddressMap() is a runtime service, and one of the things it >> does is update the pointers in the system table, hence it must be >> located in RuntimeService memory, because anything else may be gone by >> this time. > > Good point. That does imply that it must be in EfiRuntimeServices* > memory. > >> > From the spec, I couldn't find a mandate that the system table (nor the >> > runtime services table) were in a region of EfiRuntimeServicesData >> > memory. I suspect I'm looking in the wrong place... >> >> We should clarify it if it is not clear (or if I turn out to be wrong) > > I'm hoping that I've simply missed something. Perhaps the implication > above was intentional, albeit rather opaque. > > Otherwise, I certainly agree a clarification would be a good thing! > > Mark. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/arm-init.c index 022f11157acd..e995d61da747 100644 --- a/drivers/firmware/efi/arm-init.c +++ b/drivers/firmware/efi/arm-init.c @@ -85,6 +85,8 @@ static int __init uefi_init(void) efi.systab->hdr.revision >> 16, efi.systab->hdr.revision & 0xffff); + efi.runtime_version = efi.systab->hdr.revision; + /* Show what we know for posterity */ c16 = early_memremap_ro(efi_to_phys(efi.systab->fw_vendor), sizeof(vendor) * sizeof(efi_char16_t)); diff --git a/drivers/firmware/efi/arm-runtime.c b/drivers/firmware/efi/arm-runtime.c index 848ede1587dc..6ce13d6b7122 100644 --- a/drivers/firmware/efi/arm-runtime.c +++ b/drivers/firmware/efi/arm-runtime.c @@ -64,6 +64,16 @@ static bool __init efi_virtmap_init(void) &phys, ret); return false; } + /* + * If this entry covers the address of the UEFI system table, + * calculate and record its virtual address. + */ + if (efi_system_table >= phys && + efi_system_table < phys + (md->num_pages * EFI_PAGE_SIZE)) { + efi.systab = (void *)(efi_system_table - phys + + md->virt_addr); + set_bit(EFI_SYSTEM_TABLES, &efi.flags); + } } if (efi_memattr_apply_permissions(&efi_mm, efi_set_mapping_permissions)) @@ -102,16 +112,8 @@ static int __init arm_enable_runtime_services(void) memmap.map_end = memmap.map + mapsize; efi.memmap = &memmap; - efi.systab = (__force void *)ioremap_cache(efi_system_table, - sizeof(efi_system_table_t)); - if (!efi.systab) { - pr_err("Failed to remap EFI System Table\n"); - return -ENOMEM; - } - set_bit(EFI_SYSTEM_TABLES, &efi.flags); - - if (!efi_virtmap_init()) { - pr_err("No UEFI virtual mapping was installed -- runtime services will not be available\n"); + if (!efi_virtmap_init() || !efi_enabled(EFI_SYSTEM_TABLES)) { + pr_err("UEFI virtual mapping missing or invalid -- runtime services will not be available\n"); return -ENOMEM; } @@ -119,8 +121,6 @@ static int __init arm_enable_runtime_services(void) efi_native_runtime_setup(); set_bit(EFI_RUNTIME_SERVICES, &efi.flags); - efi.runtime_version = efi.systab->hdr.revision; - return 0; } early_initcall(arm_enable_runtime_services);
The permanent, writable mapping of the UEFI System table is only referenced during invocations of UEFI Runtime Services, at which time the UEFI virtual mapping is available, which also covers the system table (since the runtime services themselves need access to it) So instead of creating this permanent mapping, record the virtual address of the system table inside the UEFI virtual mapping, and use that instead. This protects the contents of the system table from inadvertent (or deliberate) modification. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> --- Something I spotted while working on the memory attribute table stuff. Since this is low hanging fruit and otherwise completely unrelated to it, I am posting it as a separate patch drivers/firmware/efi/arm-init.c | 2 ++ drivers/firmware/efi/arm-runtime.c | 24 ++++++++++---------- 2 files changed, 14 insertions(+), 12 deletions(-) -- 2.5.0 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel