arm64: efi: add check for broken efi poweroff

Commit Message

Shawn Guo March 5, 2021, 6:51 a.m. UTC

Poweroff via UEFI Runtime Services doesn't always work on every single
arm64 machine.  For example, on Lenovo Flex 5G laptop, it results in
a system reboot rather than shutdown.  Add a DMI check to keep such
system stay with the original poweroff method (PSCI).

Signed-off-by: Shawn Guo <[e-mail]>
---
 arch/arm64/kernel/efi.c | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

Comments

Ard Biesheuvel March 5, 2021, 7:01 a.m. UTC | #1

On Fri, 5 Mar 2021 at 07:51, Shawn Guo <[e-mail]> wrote:
>
> Poweroff via UEFI Runtime Services doesn't always work on every single
> arm64 machine.  For example, on Lenovo Flex 5G laptop, it results in
> a system reboot rather than shutdown.  Add a DMI check to keep such
> system stay with the original poweroff method (PSCI).
>
> Signed-off-by: Shawn Guo <[e-mail]>

What is the point of using EFI runtime services on this machine if
poweroff doesn't work either? Can't we just boot this thing with
efi=noruntime?


> ---
>  arch/arm64/kernel/efi.c | 15 +++++++++++++++
>  1 file changed, 15 insertions(+)
>
> diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c
> index fa02efb28e88..8ae0002c72f1 100644
> --- a/arch/arm64/kernel/efi.c
> +++ b/arch/arm64/kernel/efi.c
> @@ -7,6 +7,7 @@
>   * Copyright (C) 2013, 2014 Linaro Ltd.
>   */
>
> +#include <linux/dmi.h>
>  #include <linux/efi.h>
>  #include <linux/init.h>
>
> @@ -113,12 +114,26 @@ int __init efi_set_mapping_permissions(struct mm_struct *mm,
>                                    set_permissions, md);
>  }
>
> +static const struct dmi_system_id efi_reboot_broken_table[] = {
> +       {
> +               .ident = "Lenovo Flex 5G",
> +               .matches = {
> +                       DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
> +                       DMI_MATCH(DMI_PRODUCT_FAMILY, "Flex 5G"),
> +               },
> +       },
> +       { } /* terminator */
> +};
> +
>  /*
>   * UpdateCapsule() depends on the system being shutdown via
>   * ResetSystem().
>   */
>  bool efi_poweroff_required(void)
>  {
> +       if (dmi_check_system(efi_reboot_broken_table))
> +               return false;
> +
>         return efi_enabled(EFI_RUNTIME_SERVICES);
>  }
>
> --
> 2.17.1
>

Shawn Guo March 5, 2021, 7:31 a.m. UTC | #2

On Fri, Mar 05, 2021 at 08:01:02AM +0100, Ard Biesheuvel wrote:
> On Fri, 5 Mar 2021 at 07:51, Shawn Guo <[e-mail]> wrote:
> >
> > Poweroff via UEFI Runtime Services doesn't always work on every single
> > arm64 machine.  For example, on Lenovo Flex 5G laptop, it results in
> > a system reboot rather than shutdown.  Add a DMI check to keep such
> > system stay with the original poweroff method (PSCI).
> >
> > Signed-off-by: Shawn Guo <[e-mail]>
> 
> What is the point of using EFI runtime services on this machine if
> poweroff doesn't work either?

Hmm, I'm not sure how many EFI runtime services are being used by
kernel, but this is the only one broken I have seen.  Not sure we want
to disable the whole thing completely.  Also, I'm looking at commit log
of 0c5ed61adbdb ("efi/reboot: Allow powering off machines using EFI")
below.

    Not only can EfiResetSystem() be used to reboot, it can also be used to
    power down machines.

    By and large, this functionality doesn't work very well across the range
    of EFI machines in the wild, so it should definitely only be used as a
    last resort. In an ideal world, this wouldn't be needed at all.
    
    Unfortunately, we're starting to see machines where EFI is the *only*
    reliable way to power down, and nothing else, not PCI, not ACPI, works.

It seems poweroff via EFI runtime services is known not working for
every machine, and was meant to be the last resort if nothing else can
power off system.  If we try PSCI first on arm64, you do not see my
patch at all :)

> Can't we just boot this thing with
> efi=noruntime?

We are trying to get arm64 laptop support into distros, and patching
kernel cmdline with 'efi=novamap' is already a pain.  We do not really
want to have more of it.

Shawn

Ard Biesheuvel March 5, 2021, 7:46 a.m. UTC | #3

On Fri, 5 Mar 2021 at 08:32, Shawn Guo <[e-mail]> wrote:
>
> On Fri, Mar 05, 2021 at 08:01:02AM +0100, Ard Biesheuvel wrote:
> > On Fri, 5 Mar 2021 at 07:51, Shawn Guo <[e-mail]> wrote:
> > >
> > > Poweroff via UEFI Runtime Services doesn't always work on every single
> > > arm64 machine.  For example, on Lenovo Flex 5G laptop, it results in
> > > a system reboot rather than shutdown.  Add a DMI check to keep such
> > > system stay with the original poweroff method (PSCI).
> > >
> > > Signed-off-by: Shawn Guo <[e-mail]>
> >
> > What is the point of using EFI runtime services on this machine if
> > poweroff doesn't work either?
>
> Hmm, I'm not sure how many EFI runtime services are being used by
> kernel, but this is the only one broken I have seen.  Not sure we want
> to disable the whole thing completely.  Also, I'm looking at commit log
> of 0c5ed61adbdb ("efi/reboot: Allow powering off machines using EFI")
> below.
>
>     Not only can EfiResetSystem() be used to reboot, it can also be used to
>     power down machines.
>
>     By and large, this functionality doesn't work very well across the range
>     of EFI machines in the wild, so it should definitely only be used as a
>     last resort. In an ideal world, this wouldn't be needed at all.
>
>     Unfortunately, we're starting to see machines where EFI is the *only*
>     reliable way to power down, and nothing else, not PCI, not ACPI, works.
>
> It seems poweroff via EFI runtime services is known not working for
> every machine, and was meant to be the last resort if nothing else can
> power off system.  If we try PSCI first on arm64, you do not see my
> patch at all :)
>
> > Can't we just boot this thing with
> > efi=noruntime?
>
> We are trying to get arm64 laptop support into distros, and patching
> kernel cmdline with 'efi=novamap' is already a pain.  We do not really
> want to have more of it.
>

I suppose we have to rely on DtbLoader for these platforms anyway,
right? That means we should be able to rely on it to publish a RT_PROP
configuration table which tells the kernel which EFI runtime services
are usable and which are not. This way, we could get rid of
efi=novamap as well.

I'd prefer to rely on that than on DMI quirks - we have not used those
at all on arm64/ARM so far, and the DMI tables are parsed relatively
late, so in some cases, DMI quirks may not be reliable.

Shawn Guo March 5, 2021, 8:02 a.m. UTC | #4

On Fri, Mar 05, 2021 at 08:46:35AM +0100, Ard Biesheuvel wrote:
> On Fri, 5 Mar 2021 at 08:32, Shawn Guo <[e-mail]> wrote:
> >
> > On Fri, Mar 05, 2021 at 08:01:02AM +0100, Ard Biesheuvel wrote:
> > > On Fri, 5 Mar 2021 at 07:51, Shawn Guo <[e-mail]> wrote:
> > > >
> > > > Poweroff via UEFI Runtime Services doesn't always work on every single
> > > > arm64 machine.  For example, on Lenovo Flex 5G laptop, it results in
> > > > a system reboot rather than shutdown.  Add a DMI check to keep such
> > > > system stay with the original poweroff method (PSCI).
> > > >
> > > > Signed-off-by: Shawn Guo <[e-mail]>
> > >
> > > What is the point of using EFI runtime services on this machine if
> > > poweroff doesn't work either?
> >
> > Hmm, I'm not sure how many EFI runtime services are being used by
> > kernel, but this is the only one broken I have seen.  Not sure we want
> > to disable the whole thing completely.  Also, I'm looking at commit log
> > of 0c5ed61adbdb ("efi/reboot: Allow powering off machines using EFI")
> > below.
> >
> >     Not only can EfiResetSystem() be used to reboot, it can also be used to
> >     power down machines.
> >
> >     By and large, this functionality doesn't work very well across the range
> >     of EFI machines in the wild, so it should definitely only be used as a
> >     last resort. In an ideal world, this wouldn't be needed at all.
> >
> >     Unfortunately, we're starting to see machines where EFI is the *only*
> >     reliable way to power down, and nothing else, not PCI, not ACPI, works.
> >
> > It seems poweroff via EFI runtime services is known not working for
> > every machine, and was meant to be the last resort if nothing else can
> > power off system.  If we try PSCI first on arm64, you do not see my
> > patch at all :)
> >
> > > Can't we just boot this thing with
> > > efi=noruntime?
> >
> > We are trying to get arm64 laptop support into distros, and patching
> > kernel cmdline with 'efi=novamap' is already a pain.  We do not really
> > want to have more of it.
> >
> 
> I suppose we have to rely on DtbLoader for these platforms anyway,
> right? That means we should be able to rely on it to publish a RT_PROP
> configuration table which tells the kernel which EFI runtime services
> are usable and which are not. This way, we could get rid of
> efi=novamap as well.

Two things:

- DtbLoader is loaded as an EFI driver.  It works fine on Yoga C630, but
  it's not loaded by Flex 5G UEFI for some reason.  So DtbLoader is not
  really working on Flex 5G at this point.

- We are running not only DT kernel on these laptops but also ACPI
  kernel in which case DtbLoader shouldn't needed.

> I'd prefer to rely on that than on DMI quirks - we have not used those
> at all on arm64/ARM so far, and the DMI tables are parsed relatively
> late, so in some cases, DMI quirks may not be reliable.

I'm all ears in case there are other runtime mechanisms to get around
it. 

Shawn

Ard Biesheuvel March 5, 2021, 8:21 a.m. UTC | #5

On Fri, 5 Mar 2021 at 09:02, Shawn Guo <[e-mail]> wrote:
>
> On Fri, Mar 05, 2021 at 08:46:35AM +0100, Ard Biesheuvel wrote:
> > On Fri, 5 Mar 2021 at 08:32, Shawn Guo <[e-mail]> wrote:
> > >
> > > On Fri, Mar 05, 2021 at 08:01:02AM +0100, Ard Biesheuvel wrote:
> > > > On Fri, 5 Mar 2021 at 07:51, Shawn Guo <[e-mail]> wrote:
> > > > >
> > > > > Poweroff via UEFI Runtime Services doesn't always work on every single
> > > > > arm64 machine.  For example, on Lenovo Flex 5G laptop, it results in
> > > > > a system reboot rather than shutdown.  Add a DMI check to keep such
> > > > > system stay with the original poweroff method (PSCI).
> > > > >
> > > > > Signed-off-by: Shawn Guo <[e-mail]>
> > > >
> > > > What is the point of using EFI runtime services on this machine if
> > > > poweroff doesn't work either?
> > >
> > > Hmm, I'm not sure how many EFI runtime services are being used by
> > > kernel, but this is the only one broken I have seen.  Not sure we want
> > > to disable the whole thing completely.  Also, I'm looking at commit log
> > > of 0c5ed61adbdb ("efi/reboot: Allow powering off machines using EFI")
> > > below.
> > >
> > >     Not only can EfiResetSystem() be used to reboot, it can also be used to
> > >     power down machines.
> > >
> > >     By and large, this functionality doesn't work very well across the range
> > >     of EFI machines in the wild, so it should definitely only be used as a
> > >     last resort. In an ideal world, this wouldn't be needed at all.
> > >
> > >     Unfortunately, we're starting to see machines where EFI is the *only*
> > >     reliable way to power down, and nothing else, not PCI, not ACPI, works.
> > >
> > > It seems poweroff via EFI runtime services is known not working for
> > > every machine, and was meant to be the last resort if nothing else can
> > > power off system.  If we try PSCI first on arm64, you do not see my
> > > patch at all :)
> > >
> > > > Can't we just boot this thing with
> > > > efi=noruntime?
> > >
> > > We are trying to get arm64 laptop support into distros, and patching
> > > kernel cmdline with 'efi=novamap' is already a pain.  We do not really
> > > want to have more of it.
> > >
> >
> > I suppose we have to rely on DtbLoader for these platforms anyway,
> > right? That means we should be able to rely on it to publish a RT_PROP
> > configuration table which tells the kernel which EFI runtime services
> > are usable and which are not. This way, we could get rid of
> > efi=novamap as well.
>
> Two things:
>
> - DtbLoader is loaded as an EFI driver.  It works fine on Yoga C630, but
>   it's not loaded by Flex 5G UEFI for some reason.  So DtbLoader is not
>   really working on Flex 5G at this point.
>
> - We are running not only DT kernel on these laptops but also ACPI
>   kernel in which case DtbLoader shouldn't needed.
>
> > I'd prefer to rely on that than on DMI quirks - we have not used those
> > at all on arm64/ARM so far, and the DMI tables are parsed relatively
> > late, so in some cases, DMI quirks may not be reliable.
>
> I'm all ears in case there are other runtime mechanisms to get around
> it.
>

What we could do is:
- implement missing support for dealing with RT_PROP before calling
SetVirtualAddressMap() - this would remove the need for passing
efi=novamap if RT_PROP exists and marks SetVirtualAddressMap as
supported
- implement support to the EFI stub for a Linux specific EFI variable
RtPropOverride that is either masked with the existing RT_PROP value,
or installed if no RT_PROP table exists.

This way, you would only have to set a EFI variable a single time
before boot, and the Linux kernel would take it into account every
subsequent boot. The EFI stub is guaranteed to run before anything
else, so it is guaranteed to be timely (as opposed to DMI quirks on
arm64)

Shawn Guo May 17, 2021, 12:59 a.m. UTC | #6

+ Maximilian

On Fri, Mar 05, 2021 at 08:01:02AM +0100, Ard Biesheuvel wrote:
> On Fri, 5 Mar 2021 at 07:51, Shawn Guo <[e-mail]> wrote:
> >
> > Poweroff via UEFI Runtime Services doesn't always work on every single
> > arm64 machine.  For example, on Lenovo Flex 5G laptop, it results in
> > a system reboot rather than shutdown.  Add a DMI check to keep such
> > system stay with the original poweroff method (PSCI).
> >
> > Signed-off-by: Shawn Guo <[e-mail]>
> 
> What is the point of using EFI runtime services on this machine if
> poweroff doesn't work either? Can't we just boot this thing with
> efi=noruntime?

Ard,

With Maximilian playing ACPI kernel on Microsoft Surface Pro X, this
ResetSystem service issue triggers more discussion and testing [1].
Maximilian tested it with uefi-test-runner and reported that ResetSystem
actually works [2].

Looking at the kernel dump, I'm wondering if it's because that kernel
calls into the services with assuming they are in virtual addressing
mode, while actually they are in flat physical mode instead, due to
that SetVirtualAddressMap() call is skipped (efi_novamap).

Shawn

[1] https://github.com/Sonicadvance1/linux/issues/27#issuecomment-836103896
[2] https://github.com/Sonicadvance1/linux/issues/27#issuecomment-837184892

Ard Biesheuvel May 18, 2021, 7:44 a.m. UTC | #7

On Mon, 17 May 2021 at 02:59, Shawn Guo <[e-mail]> wrote:
>
> + Maximilian
>
> On Fri, Mar 05, 2021 at 08:01:02AM +0100, Ard Biesheuvel wrote:
> > On Fri, 5 Mar 2021 at 07:51, Shawn Guo <[e-mail]> wrote:
> > >
> > > Poweroff via UEFI Runtime Services doesn't always work on every single
> > > arm64 machine.  For example, on Lenovo Flex 5G laptop, it results in
> > > a system reboot rather than shutdown.  Add a DMI check to keep such
> > > system stay with the original poweroff method (PSCI).
> > >
> > > Signed-off-by: Shawn Guo <[e-mail]>
> >
> > What is the point of using EFI runtime services on this machine if
> > poweroff doesn't work either? Can't we just boot this thing with
> > efi=noruntime?
>
> Ard,
>
> With Maximilian playing ACPI kernel on Microsoft Surface Pro X, this
> ResetSystem service issue triggers more discussion and testing [1].
> Maximilian tested it with uefi-test-runner and reported that ResetSystem
> actually works [2].
>
> Looking at the kernel dump, I'm wondering if it's because that kernel
> calls into the services with assuming they are in virtual addressing
> mode, while actually they are in flat physical mode instead, due to
> that SetVirtualAddressMap() call is skipped (efi_novamap).
>

That looks like a firmware bug. Boot with efi=debug to figure out
whether the faulting address is a physical address that falls inside a
EfiRuntimeServicesData region.

Shawn Guo May 19, 2021, 2:05 p.m. UTC | #8

On Tue, May 18, 2021 at 09:44:12AM +0200, Ard Biesheuvel wrote:
> On Mon, 17 May 2021 at 02:59, Shawn Guo <[e-mail]> wrote:
> >
> > + Maximilian
> >
> > On Fri, Mar 05, 2021 at 08:01:02AM +0100, Ard Biesheuvel wrote:
> > > On Fri, 5 Mar 2021 at 07:51, Shawn Guo <[e-mail]> wrote:
> > > >
> > > > Poweroff via UEFI Runtime Services doesn't always work on every single
> > > > arm64 machine.  For example, on Lenovo Flex 5G laptop, it results in
> > > > a system reboot rather than shutdown.  Add a DMI check to keep such
> > > > system stay with the original poweroff method (PSCI).
> > > >
> > > > Signed-off-by: Shawn Guo <[e-mail]>
> > >
> > > What is the point of using EFI runtime services on this machine if
> > > poweroff doesn't work either? Can't we just boot this thing with
> > > efi=noruntime?
> >
> > Ard,
> >
> > With Maximilian playing ACPI kernel on Microsoft Surface Pro X, this
> > ResetSystem service issue triggers more discussion and testing [1].
> > Maximilian tested it with uefi-test-runner and reported that ResetSystem
> > actually works [2].
> >
> > Looking at the kernel dump, I'm wondering if it's because that kernel
> > calls into the services with assuming they are in virtual addressing
> > mode, while actually they are in flat physical mode instead, due to
> > that SetVirtualAddressMap() call is skipped (efi_novamap).
> >
> 
> That looks like a firmware bug. Boot with efi=debug to figure out
> whether the faulting address is a physical address that falls inside a
> EfiRuntimeServicesData region.

Last time when I was seeing reboot/poweroff broken on Flex 5G, I did not
capture any kernel dumps.  I will retry with efi=debug and see if I can
get more information.

In the meantime, could you help me understand if EFI must be running in
virtual address mode when kernel is calling into the services, or it
should work no matter EFI is running in virtual or physical address
mode?  Thanks!

Shawn

Ard Biesheuvel May 19, 2021, 2:20 p.m. UTC | #9

On Wed, 19 May 2021 at 16:05, Shawn Guo <[e-mail]> wrote:
>
> On Tue, May 18, 2021 at 09:44:12AM +0200, Ard Biesheuvel wrote:
> > On Mon, 17 May 2021 at 02:59, Shawn Guo <[e-mail]> wrote:
> > >
> > > + Maximilian
> > >
> > > On Fri, Mar 05, 2021 at 08:01:02AM +0100, Ard Biesheuvel wrote:
> > > > On Fri, 5 Mar 2021 at 07:51, Shawn Guo <[e-mail]> wrote:
> > > > >
> > > > > Poweroff via UEFI Runtime Services doesn't always work on every single
> > > > > arm64 machine.  For example, on Lenovo Flex 5G laptop, it results in
> > > > > a system reboot rather than shutdown.  Add a DMI check to keep such
> > > > > system stay with the original poweroff method (PSCI).
> > > > >
> > > > > Signed-off-by: Shawn Guo <[e-mail]>
> > > >
> > > > What is the point of using EFI runtime services on this machine if
> > > > poweroff doesn't work either? Can't we just boot this thing with
> > > > efi=noruntime?
> > >
> > > Ard,
> > >
> > > With Maximilian playing ACPI kernel on Microsoft Surface Pro X, this
> > > ResetSystem service issue triggers more discussion and testing [1].
> > > Maximilian tested it with uefi-test-runner and reported that ResetSystem
> > > actually works [2].
> > >
> > > Looking at the kernel dump, I'm wondering if it's because that kernel
> > > calls into the services with assuming they are in virtual addressing
> > > mode, while actually they are in flat physical mode instead, due to
> > > that SetVirtualAddressMap() call is skipped (efi_novamap).
> > >
> >
> > That looks like a firmware bug. Boot with efi=debug to figure out
> > whether the faulting address is a physical address that falls inside a
> > EfiRuntimeServicesData region.
>
> Last time when I was seeing reboot/poweroff broken on Flex 5G, I did not
> capture any kernel dumps.  I will retry with efi=debug and see if I can
> get more information.
>
> In the meantime, could you help me understand if EFI must be running in
> virtual address mode when kernel is calling into the services, or it
> should work no matter EFI is running in virtual or physical address
> mode?  Thanks!
>

There are really three scenarios to consider here:
- SetVirtualAddressMap() is never called
- SetVirtualAddressMap() is called with a 1:1 mapping for all
EFI_MEMORY_RUNTIME regions
- SetVirtualAddressMap() is called with an virtual remapping for all
EFI_MEMORY_RUNTIME regions.

Firmware that is working correctly should not care about which
scenario it is running under. All runtime services should simply work
as expected.

However, there are numerous examples of UEFI in the field (both x86
and ARM), where only the third scenario works, or where the second one
is needed to work around problems that occur when using the first one.

Patch

diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c
index fa02efb28e88..8ae0002c72f1 100644
--- a/arch/arm64/kernel/efi.c
+++ b/arch/arm64/kernel/efi.c
@@ -7,6 +7,7 @@ 
  * Copyright (C) 2013, 2014 Linaro Ltd.
  */
 
+#include <linux/dmi.h>
 #include <linux/efi.h>
 #include <linux/init.h>
 
@@ -113,12 +114,26 @@  int __init efi_set_mapping_permissions(struct mm_struct *mm,
 				   set_permissions, md);
 }
 
+static const struct dmi_system_id efi_reboot_broken_table[] = {
+	{
+		.ident = "Lenovo Flex 5G",
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+			DMI_MATCH(DMI_PRODUCT_FAMILY, "Flex 5G"),
+		},
+	},
+	{ } /* terminator */
+};
+
 /*
  * UpdateCapsule() depends on the system being shutdown via
  * ResetSystem().
  */
 bool efi_poweroff_required(void)
 {
+	if (dmi_check_system(efi_reboot_broken_table))
+		return false;
+
 	return efi_enabled(EFI_RUNTIME_SERVICES);
 }