linux-kernel - Re: [PATCH 0/2] Fix boot hang issue on Ampere Emag server

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMj1kXFTUXgaENBSYh+cGCS3wFCFunf+auk3nKwHVJWiZ7crig@mail.gmail.com>
Date:   Tue, 31 Jan 2023 08:18:49 +0100
From:   Ard Biesheuvel <ardb@...nel.org>
To:     Jia He <justin.he@....com>, "Jason A. Donenfeld" <Jason@...c4.com>
Cc:     Huacai Chen <chenhuacai@...nel.org>, linux-efi@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Alexandru Elisei <alexandru.elisei@....com>
Subject: Re: [PATCH 0/2] Fix boot hang issue on Ampere Emag server

(cc Jason for awareness)

On Tue, 31 Jan 2023 at 05:04, Jia He <justin.he@....com> wrote:
>
> I met a hung task warning and then kernel was hung forever with latest
> kernel on an Ampere Emag server.
>
> The root cause is kernel was hung  when invoking an efi rts call to set
> the RandomSeed variable during the booting stage. The arch_efi_call_virt
> call (set_variable) was never returned and then caused the hung task error.
>

Given that EFI variables work on this platform (as far as I know), the
problem may be that we are calling SetVariable() too early.

Could you double check whether setting variables works as expected?
You can use efibootmgr -t 10 as root (for example) to set the boot
timeout, and check whether the new value is retained after a reboot
(efibootmgr will print the current value for you)

Could you also please share the kernel log up until the point where it hangs?


> On the Emag server, efi_rt_services_supported(EFI_RT_SUPPORTED_SET_VARIABLE)
> is returned with "true"
>

This is as expected: if the firmware does not expose the RT properties
table, all runtime services are assumed to be available.

> Fix it by introducing the efi_get_supported_rt_services() and then determine
> to set or clear the runtime services bit of efi.flags.
>
> Jia He (2):
>   efi: libstub: Fix the retriving of supported rutime services
>   efi: Introduce efi_get_supported_rt_services() to get the runtime
>     services mask
>
>  drivers/firmware/efi/arm-runtime.c      |  5 ++++-
>  drivers/firmware/efi/efi.c              | 28 +++++++++++++++++--------
>  drivers/firmware/efi/libstub/efi-stub.c |  2 ++
>  include/linux/efi.h                     |  1 +
>  4 files changed, 26 insertions(+), 10 deletions(-)
>
> --
> 2.25.1
>