[PATCH] arm*: efi: drop permanent mapping of the UEFI System table

[PATCH] arm*: efi: drop permanent mapping of the UEFI System table

[Ard Biesheuvel]

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-QSEj5FYQhm4dnm+yROfE0A@public.gmane.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);
+		}
 	}
 
 	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);
-- 
2.5.0

Re: [PATCH] arm*: efi: drop permanent mapping of the UEFI System table

[Mark Rutland]

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-QSEj5FYQhm4dnm+yROfE0A@public.gmane.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.

Re: [PATCH] arm*: efi: drop permanent mapping of the UEFI System table

[Ard Biesheuvel]

On 22 February 2016 at 16:43, Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> 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-QSEj5FYQhm4dnm+yROfE0A@public.gmane.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?

Re: [PATCH] arm*: efi: drop permanent mapping of the UEFI System table

[Mark Rutland]

On Mon, Feb 22, 2016 at 04:56:57PM +0100, Ard Biesheuvel wrote:
> On 22 February 2016 at 16:43, Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> 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.

Re: [PATCH] arm*: efi: drop permanent mapping of the UEFI System table

[Ard Biesheuvel]

On 22 February 2016 at 17:09, Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> 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-5wv7dgnIgG8@public.gmane.org> 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.

Re: [PATCH] arm*: efi: drop permanent mapping of the UEFI System table

[Matt Fleming]

On Mon, 22 Feb, at 04:56:57PM, Ard Biesheuvel wrote:
> On 22 February 2016 at 16:43, Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> wrote:
> > On Mon, Feb 22, 2016 at 03:59:39PM +0100, Ard Biesheuvel wrote:
> >> 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?

Good question. EFI_SYSTEM_TABLES was introduced over 4 years ago, but
it looks like it has never had any users. I don't remember why I added
it, probably just be to be "complete" since we had bits for all the
other tables.

If somebody wants to rip it out, I wouldn't object.

To be fair, we don't have permanent access to any of the tables - you
always have to switch to the dedicated EFI page tables before
accessing regions.