efi/libstub: arm64: avoid SetVirtualAddressMap() when possible

EFI's SetVirtualAddressMap() runtime service is a horrid hack that we'd
like to avoid using, if possible. For 64-bit architectures such as
arm64, the user and kernel mappings are entirely disjoint, and given
that we use the user region for mapping the UEFI runtime regions when
running under the OS, we don't rely on SetVirtualAddressMap() in the
conventional way, i.e., to permit kernel mappings of the OS to coexist
with kernel region mappings of the firmware regions. This means that, in
principle, we should be able to avoid SetVirtualAddressMap() altogether,
and simply use the 1:1 mapping that UEFI uses at boot time. (Note that
omitting SetVirtualAddressMap() is explicitly permitted by the UEFI
spec).

However, there is a corner case on arm64, which, if configured for
3-level paging (or 2-level paging when using 64k pages), may not be able
to cover the entire range of firmware mappings (which might contain both
memory and MMIO peripheral mappings).

So let's avoid SetVirtualAddressMap() on arm64, but only if the VA space
is guaranteed to be of sufficient size.

Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
 drivers/firmware/efi/libstub/arm64-stub.c | 9 +++++++++
 1 file changed, 9 insertions(+)

(use Peter's correct email address)

On Fri, 16 Sept 2022 at 12:19, Ard Biesheuvel <ardb@kernel.org> wrote:
>
> EFI's SetVirtualAddressMap() runtime service is a horrid hack that we'd
> like to avoid using, if possible. For 64-bit architectures such as
> arm64, the user and kernel mappings are entirely disjoint, and given
> that we use the user region for mapping the UEFI runtime regions when
> running under the OS, we don't rely on SetVirtualAddressMap() in the
> conventional way, i.e., to permit kernel mappings of the OS to coexist
> with kernel region mappings of the firmware regions. This means that, in
> principle, we should be able to avoid SetVirtualAddressMap() altogether,
> and simply use the 1:1 mapping that UEFI uses at boot time. (Note that
> omitting SetVirtualAddressMap() is explicitly permitted by the UEFI
> spec).
>
> However, there is a corner case on arm64, which, if configured for
> 3-level paging (or 2-level paging when using 64k pages), may not be able
> to cover the entire range of firmware mappings (which might contain both
> memory and MMIO peripheral mappings).
>
> So let's avoid SetVirtualAddressMap() on arm64, but only if the VA space
> is guaranteed to be of sufficient size.
>
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> ---
>  drivers/firmware/efi/libstub/arm64-stub.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
>
> diff --git a/drivers/firmware/efi/libstub/arm64-stub.c b/drivers/firmware/efi/libstub/arm64-stub.c
> index cd3bea25c762..4fff6c32899e 100644
> --- a/drivers/firmware/efi/libstub/arm64-stub.c
> +++ b/drivers/firmware/efi/libstub/arm64-stub.c
> @@ -31,6 +31,15 @@ efi_status_t check_platform_features(void)
>                         efi_err("This 16 KB granular kernel is not supported by your CPU\n");
>                 return EFI_UNSUPPORTED;
>         }
> +
> +       /*
> +        * If we have 48 bits of VA space for TTBR0 mappings, we can map the
> +        * UEFI runtime regions 1:1 and so calling SetVirtualAddressMap() is
> +        * unnecessary.
> +        */
> +       if (VA_BITS_MIN >= 48)
> +               efi_novamap = true;
> +
>         return EFI_SUCCESS;
>  }
>
> --
> 2.35.1
>

Hi Ard,

After entering 6.1-rc1 the efi runtime services is not working on my platform:

[    0.054039] Remapping and enabling EFI services.
[    0.054043] UEFI virtual mapping missing or invalid -- runtime services will not be available

Not sure this patch is the root cause since I see some refactor of efi codes in 6.1-rc1,
but simply reverting this make EFI runtime services works again. Tested on HiSilicon's
Kunpeng 920 arm64 server using 48 bit VA address:

CONFIG_ARM64_VA_BITS_48=y
CONFIG_ARM64_VA_BITS=48

Thanks.

On 2022/9/16 18:18, Ard Biesheuvel wrote:
> EFI's SetVirtualAddressMap() runtime service is a horrid hack that we'd
> like to avoid using, if possible. For 64-bit architectures such as
> arm64, the user and kernel mappings are entirely disjoint, and given
> that we use the user region for mapping the UEFI runtime regions when
> running under the OS, we don't rely on SetVirtualAddressMap() in the
> conventional way, i.e., to permit kernel mappings of the OS to coexist
> with kernel region mappings of the firmware regions. This means that, in
> principle, we should be able to avoid SetVirtualAddressMap() altogether,
> and simply use the 1:1 mapping that UEFI uses at boot time. (Note that
> omitting SetVirtualAddressMap() is explicitly permitted by the UEFI
> spec).
> 
> However, there is a corner case on arm64, which, if configured for
> 3-level paging (or 2-level paging when using 64k pages), may not be able
> to cover the entire range of firmware mappings (which might contain both
> memory and MMIO peripheral mappings).
> 
> So let's avoid SetVirtualAddressMap() on arm64, but only if the VA space
> is guaranteed to be of sufficient size.
> 
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> ---
>  drivers/firmware/efi/libstub/arm64-stub.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/firmware/efi/libstub/arm64-stub.c b/drivers/firmware/efi/libstub/arm64-stub.c
> index cd3bea25c762..4fff6c32899e 100644
> --- a/drivers/firmware/efi/libstub/arm64-stub.c
> +++ b/drivers/firmware/efi/libstub/arm64-stub.c
> @@ -31,6 +31,15 @@ efi_status_t check_platform_features(void)
>  			efi_err("This 16 KB granular kernel is not supported by your CPU\n");
>  		return EFI_UNSUPPORTED;
>  	}
> +
> +	/*
> +	 * If we have 48 bits of VA space for TTBR0 mappings, we can map the
> +	 * UEFI runtime regions 1:1 and so calling SetVirtualAddressMap() is
> +	 * unnecessary.
> +	 */
> +	if (VA_BITS_MIN >= 48)
> +		efi_novamap = true;
> +
>  	return EFI_SUCCESS;
>  }
>  
>

[TLDR: I'm adding this regression report to the list of tracked
regressions; all text from me you find below is based on a few templates
paragraphs you might have encountered already already in similar form.]

Hi, this is your Linux kernel regression tracker. CCing the regression
mailing list, as it should be in the loop for all regressions, as
explained here:
https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html
On 19.10.22 05:24, Yicong Yang wrote:
> 
> After entering 6.1-rc1 the efi runtime services is not working on my platform:
> 
> [    0.054039] Remapping and enabling EFI services.
> [    0.054043] UEFI virtual mapping missing or invalid -- runtime services will not be available
> 
> Not sure this patch is the root cause since I see some refactor of efi codes in 6.1-rc1,
> but simply reverting this make EFI runtime services works again. Tested on HiSilicon's
> Kunpeng 920 arm64 server using 48 bit VA address:
> 
> CONFIG_ARM64_VA_BITS_48=y
> CONFIG_ARM64_VA_BITS=48
> 
> Thanks.

Thanks for the report. To be sure below issue doesn't fall through the
cracks unnoticed, I'm adding it to regzbot, my Linux kernel regression
tracking bot:

#regzbot ^introduced d3549a938b73f203ef522562ae9f2d38aa43d234
#regzbot title efi/libstub: arm64: efi runtime services stopped working
#regzbot ignore-activity

This isn't a regression? This issue or a fix for it are already
discussed somewhere else? It was fixed already? You want to clarify when
the regression started to happen? Or point out I got the title or
something else totally wrong? Then just reply -- ideally with also
telling regzbot about it, as explained here:
https://linux-regtracking.leemhuis.info/tracked-regression/

Reminder for developers: When fixing the issue, add 'Link:' tags
pointing to the report (the mail this one replies to), as explained for
in the Linux kernel's documentation; above webpage explains why this is
important for tracked regressions.

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)

P.S.: As the Linux kernel's regression tracker I deal with a lot of
reports and sometimes miss something important when writing mails like
this. If that's the case here, don't hesitate to tell me in a public
reply, it's in everyone's interest to set the public record straight.

> On 2022/9/16 18:18, Ard Biesheuvel wrote:
>> EFI's SetVirtualAddressMap() runtime service is a horrid hack that we'd
>> like to avoid using, if possible. For 64-bit architectures such as
>> arm64, the user and kernel mappings are entirely disjoint, and given
>> that we use the user region for mapping the UEFI runtime regions when
>> running under the OS, we don't rely on SetVirtualAddressMap() in the
>> conventional way, i.e., to permit kernel mappings of the OS to coexist
>> with kernel region mappings of the firmware regions. This means that, in
>> principle, we should be able to avoid SetVirtualAddressMap() altogether,
>> and simply use the 1:1 mapping that UEFI uses at boot time. (Note that
>> omitting SetVirtualAddressMap() is explicitly permitted by the UEFI
>> spec).
>>
>> However, there is a corner case on arm64, which, if configured for
>> 3-level paging (or 2-level paging when using 64k pages), may not be able
>> to cover the entire range of firmware mappings (which might contain both
>> memory and MMIO peripheral mappings).
>>
>> So let's avoid SetVirtualAddressMap() on arm64, but only if the VA space
>> is guaranteed to be of sufficient size.
>>
>> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
>> ---
>>  drivers/firmware/efi/libstub/arm64-stub.c | 9 +++++++++
>>  1 file changed, 9 insertions(+)
>>
>> diff --git a/drivers/firmware/efi/libstub/arm64-stub.c b/drivers/firmware/efi/libstub/arm64-stub.c
>> index cd3bea25c762..4fff6c32899e 100644
>> --- a/drivers/firmware/efi/libstub/arm64-stub.c
>> +++ b/drivers/firmware/efi/libstub/arm64-stub.c
>> @@ -31,6 +31,15 @@ efi_status_t check_platform_features(void)
>>  			efi_err("This 16 KB granular kernel is not supported by your CPU\n");
>>  		return EFI_UNSUPPORTED;
>>  	}
>> +
>> +	/*
>> +	 * If we have 48 bits of VA space for TTBR0 mappings, we can map the
>> +	 * UEFI runtime regions 1:1 and so calling SetVirtualAddressMap() is
>> +	 * unnecessary.
>> +	 */
>> +	if (VA_BITS_MIN >= 48)
>> +		efi_novamap = true;
>> +
>>  	return EFI_SUCCESS;
>>  }
>>  
>>
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

> On 19.10.22 05:24, Yicong Yang wrote:
> >
> > After entering 6.1-rc1 the efi runtime services is not working on my platform:
> >
> > [    0.054039] Remapping and enabling EFI services.
> > [    0.054043] UEFI virtual mapping missing or invalid -- runtime services will not be available
> >
> > Not sure this patch is the root cause since I see some refactor of efi codes in 6.1-rc1,
> > but simply reverting this make EFI runtime services works again. Tested on HiSilicon's
> > Kunpeng 920 arm64 server using 48 bit VA address:
> >
> > CONFIG_ARM64_VA_BITS_48=y
> > CONFIG_ARM64_VA_BITS=48
> >
> > Thanks.

Hi,

Can you try the change below please?

+++ b/drivers/firmware/efi/arm-runtime.c
@@ -63,7 +63,7 @@ static bool __init efi_virtmap_init(void)

                if (!(md->attribute & EFI_MEMORY_RUNTIME))
                        continue;
-               if (md->virt_addr == 0)
+               if (md->virt_addr == 0 && md->phys_addr != 0)
                        return false;

                ret = efi_create_mapping(&efi_mm, md);

Hi Ard,

On 2022/10/20 21:04, Ard Biesheuvel wrote:
>> On 19.10.22 05:24, Yicong Yang wrote:
>>>
>>> After entering 6.1-rc1 the efi runtime services is not working on my platform:
>>>
>>> [    0.054039] Remapping and enabling EFI services.
>>> [    0.054043] UEFI virtual mapping missing or invalid -- runtime services will not be available
>>>
>>> Not sure this patch is the root cause since I see some refactor of efi codes in 6.1-rc1,
>>> but simply reverting this make EFI runtime services works again. Tested on HiSilicon's
>>> Kunpeng 920 arm64 server using 48 bit VA address:
>>>
>>> CONFIG_ARM64_VA_BITS_48=y
>>> CONFIG_ARM64_VA_BITS=48
>>>
>>> Thanks.
> 
> Hi,
> 
> Can you try the change below please?
> 
> +++ b/drivers/firmware/efi/arm-runtime.c
> @@ -63,7 +63,7 @@ static bool __init efi_virtmap_init(void)
> 
>                 if (!(md->attribute & EFI_MEMORY_RUNTIME))
>                         continue;
> -               if (md->virt_addr == 0)
> +               if (md->virt_addr == 0 && md->phys_addr != 0)
>                         return false;
> 
>                 ret = efi_create_mapping(&efi_mm, md);
> .
> 

Thanks for fixing this. This change works on my machine. I see you've already post a patch including
this [1]. Tested for both this change and that patch, the efi runtime services works again:

[root@localhost ~]# dmesg | grep -i efi
[...]
[    0.015321] Remapping and enabling EFI services.
[    3.821339] Registered efivars operations
[   16.347372] CPU: 0 PID: 18 Comm: kworker/0:1 Not tainted 6.1.0-rc1-efi-fix-test+ #18
[   16.674766] rtc-efi rtc-efi.0: registered as rtc0
[   16.687659] rtc-efi rtc-efi.0: setting system clock to 2022-10-21T01:53:35 UTC (1666317215)
[   16.733137] pstore: ignoring unexpected backend 'efi'
[   18.411800]     BOOT_IMAGE=/vmlinuz-6.1.0-rc1-efi-fix-test+

For arm64 part:

Tested-by: Yicong Yang <yangyicong@hisilicon.com>

[1] https://lore.kernel.org/linux-efi/20221020185416.1953242-1-ardb@kernel.org/T/#u

Thanks

[Note: this mail is primarily send for documentation purposes and/or for
regzbot, my Linux kernel regression tracking bot. That's why I removed
most or all folks from the list of recipients, but left any that looked
like a mailing lists. These mails usually contain '#forregzbot' in the
subject, to make them easy to spot and filter out.]
On 20.10.22 14:39, Thorsten Leemhuis wrote:

>> After entering 6.1-rc1 the efi runtime services is not working on my platform:
>>
>> [    0.054039] Remapping and enabling EFI services.
>> [    0.054043] UEFI virtual mapping missing or invalid -- runtime services will not be available
>>
>> Not sure this patch is the root cause since I see some refactor of efi codes in 6.1-rc1,
>> but simply reverting this make EFI runtime services works again. Tested on HiSilicon's
>> Kunpeng 920 arm64 server using 48 bit VA address:
> 
> #regzbot ^introduced d3549a938b73f203ef522562ae9f2d38aa43d234
> #regzbot title efi/libstub: arm64: efi runtime services stopped working
> #regzbot ignore-activity

#regzbot fixed-by: 37926f96302d8b6

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)

P.S.: As the Linux kernel's regression tracker I deal with a lot of
reports and sometimes miss something important when writing mails like
this. If that's the case here, don't hesitate to tell me in a public
reply, it's in everyone's interest to set the public record straight.