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: <YfThAF9U1DJx0Hja@shikoro>
Date:   Sat, 29 Jan 2022 07:38:56 +0100
From:   Wolfram Sang <wsa+renesas@...g-engineering.com>
To:     Krzysztof Adamski <krzysztof.adamski@...ia.com>
Cc:     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

Hi Krzysztof,
> 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,

For your patchset, this seems good enough for me because it is decoupled
from PSCI now. I still think a set of defines should be collected in
linux/reboot.h so they can be used in reboot handlers. This is a
different patch series, though.

> 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.

I agree with the upside having more value than the downside.

Happy hacking,

   Wolfram


Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ