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 for Android: free password hash cracker in your pocket

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

Message-ID: <YfRu86YoiFpVsqyn@localhost.localdomain>
Date:   Fri, 28 Jan 2022 23:32:19 +0100
From:   Krzysztof Adamski <krzysztof.adamski@...ia.com>
To:     Wolfram Sang <wsa+renesas@...g-engineering.com>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Peter Collingbourne <pcc@...gle.com>,
        Guenter Roeck <linux@...ck-us.net>,
        Alexander Sverdlin <alexander.sverdlin@...ia.com>,
        Matija Glavinic-Pecotic <matija.glavinic-pecotic.ext@...ia.com>,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] arm64: move efi_reboot to restart handler

Dnia Fri, Jan 28, 2022 at 08:29:06PM +0100, Wolfram Sang napisał(a):
>
>> +	/* We want this to take priority over PSCI which has priority of 129. */
>> +	.priority = 130,
>
>Is it an idea to add a #define for the PSCI priority somewhere and use
>here the define + 1? Hardcoded priorities look a bit fragile to me.
>

You are right. Our priority policy for restart handlers isn't really
good and it is hard to choose right priority just about every time a
handler is added.

That being said, after reading Mark's argumentation, I now thing that
just being before PSCI is not enough. I think that a much higher
priority should be used as it is not normal situation that you would
like to run something before efi_reboot().

I would really still like to move the efi_reboot() to the
restart_handler even if you consider running some code before
efi_reboot() crazy. Since 255 is max priorty but using it basically
does not make sense (as this would let to the exact same situation we
have now).

I would use something like 250, or even 254, just to indicate that we
know that most certainly nothing should be run before efi_reboot(), but
still allow those silly people like me, to do what they want in their
system, without the need to run the custom kernel. I think we could even
add a proper comment, so it woudld become something like:

/**
  * If you are running UEFI based system, you most certainly should let
  * efi_reboot() do a reset for you. If you think you know better, we
  * leave you a window of opportunity here by not using maximal priorty
  * here.
  */
  .priority = 250,

What is the downside of doing that? That we will run through atomic
notfier chain instead of calling efi_reboot directly? Sure this is
slightly more complicated but it works on all our platforms and is
battle proven and we don't worry about that there. And the upside is
that we give people possibility to use their beloved mechanism if they
really like to. Because flexibility is a good thing.

What do you think?

Krzysztof