linux-kernel - Re: [PATCH v2] arm64: move efi

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]

Date:   Wed, 2 Feb 2022 15:01:37 +0100
From:   Ard Biesheuvel <ardb@...nel.org>
To:     Krzysztof Adamski <krzysztof.adamski@...ia.com>
Cc:     Mark Rutland <mark.rutland@....com>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>,
        Peter Collingbourne <pcc@...gle.com>,
        Guenter Roeck <linux@...ck-us.net>,
        Wolfram Sang <wsa+renesas@...g-engineering.com>,
        Alexander Sverdlin <alexander.sverdlin@...ia.com>,
        Matija Glavinic-Pecotic <matija.glavinic-pecotic.ext@...ia.com>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] arm64: move efi_reboot to restart handler

On Wed, 2 Feb 2022 at 13:41, Krzysztof Adamski
<krzysztof.adamski@...ia.com> wrote:
>
> Dnia Tue, Feb 01, 2022 at 01:58:29PM +0000, Mark Rutland napisał(a):
> >> If we use the restart handlers only to reset the system, this is indeed
> >> true. But technically, restart handlers support the scenario where the
> >> handler does some action that does not do reset of the whole system and
> >> passes the control further down the chain, eventually reaching a handler
> >> that will reset the whole system.
> >> This can be done on non-uefi systems without problems but it doesn't
> >> work on UEFI bases arm64 systems and this is a problem for us.
> >>
> >> In other words, I would like to be able to run a restart handler on EFI
> >> based ARM64 systems, just like I can on other systems, just for its
> >> "side effects", not to do the actual reboot. Current code disables this
> >> possibility on an ARM64 EFI system.
> >
> >It sounds like two things are being conflated here:
> >
> >1) A *notification* that a restart will subsequently occur.
> >2) A *request* to initiate a restart.
> >
> >IIUC (1) is supposed to be handled by the existing reboot notifier mechanism
> >(see the reboot_notifier_list) which *is* invoked prior to the EFI reboot
> >today.
> >
> >IMO, using restart handlers as notifiers is an abuse of the interface, and
> >that's the fundamental problem.
> >
> >What am I missing?
>
> You are completly right. It is possible that I would like to be able to
> *abuse* the restart handlers as notifier. You are right that we have a
> reboot_notifier but it is not good enough for my usecase - it is only
> called, well, on reboot. It is not called in case of emergency_restart()
> so in case of a panic, this won't happen. It also is called much earlier
> than restart handlers which also makes a difference in some cases. So I
> see no other choice than to abuse the restart_handler mechanism for that.
>

Why would such a platform implement ResetSystem() in the first place
if it cannot be used?

So the right solution here is for the firmware to publish a
EFI_RT_PROPERTIES_TABLE that describes ResetSystem() as unsupported,
and Linux will happily disregard it and try something else.

Btw please cc linux-efi@...r.kernel.org and myself on future EFI
issues. I found this thread by accident.