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:   Tue, 15 Feb 2022 09:44:15 +0100
From:   Alexander Sverdlin <alexander.sverdlin@...ia.com>
To:     Ard Biesheuvel <ardb@...nel.org>,
        Mark Rutland <mark.rutland@....com>
Cc:     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>,
        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>,
        Krzysztof Adamski <krzysztof.adamski@...ia.com>,
        linux-efi@...r.kernel.org
Subject: Re: [PATCH v2] arm64: move efi_reboot to restart handler

Hello Ard, Mark,

On 02/02/2022 15:01, Ard Biesheuvel wrote:
>>>> 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.

Let me outline the use case once again:

we have cases where different SoCs are integrated into more complicated
FPGA based systems where FPGA controls the reset sequence of the whole
system. Those SoCs are of different ARCHs and only one of them currently
has EFI.

So the implementation is largely platform-independent and is implemented
in Linux.

Do you suggest that in EFI case we cannot implement a conditional
reset implementation (native EFI reset vs system-wide FPGA-controlled)
in Linux any longer (because register_restart_handler() doesn't work
for EFI based ARM64 system) and need to reimplement very special
solution in EFI? 

-- 
Best regards,
Alexander Sverdlin.