linux-kernel - Re: [PATCH] riscv: Work to remove kernel dependence on the M-extension

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]

Date:   Thu, 10 Mar 2022 08:54:17 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Palmer Dabbelt <palmer@...belt.com>
Cc:     Arnd Bergmann <arnd@...db.de>,
        "Michael T. Kloos" <michael@...haelkloos.com>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Albert Ou <aou@...s.berkeley.edu>,
        linux-riscv <linux-riscv@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] riscv: Work to remove kernel dependence on the M-extension

On Thu, Mar 10, 2022 at 8:34 AM Palmer Dabbelt <palmer@...belt.com> wrote:
> On Wed, 09 Mar 2022 02:02:27 PST (-0800), Arnd Bergmann wrote:
> > On Wed, Mar 9, 2022 at 6:28 AM Michael T. Kloos <michael@...haelkloos.com> wrote:
>
> That'd be wonderful, but unfortunately we're trending the other way --
> we're at the point where "words in the specification have meaning" is
> controversial, so trying to talk about which flavors of the
> specification are standard is just meaningless.  I obviously hope that
> gets sorted out, as we've clearly been pointed straight off a cliff for
> a while now, but LMKL isn't the place to have that discussion.  We've
> all seen this before, nobody needs to be convinced this leads to a mess.
>
> Until we get to the point where "I wrote 'RISC-V' on that potato I found
> in my couch" can be conclusively determined not compliant with the spec,
> it's just silly to try and talk about what is.

I would argue that codifying the required extensions through kernel source
code is much stronger than interpreting a specification. Ideally the
specification
would match what the kernel requires, but it's not the end of the world if
the kernel ends up making decisions that are different: If Linux can do
runtime detection of non-M, non-A or pre-standard extensions and handle
them correctly without a notable performance impact, it can do that. Or
Linux could end up requiring things that are normally there but not
in the scope of the spec.

Regardless of who determines what the compatible subset is, I think there
is value in splitting out Kconfig options that prevent booting on normal
RV64GC machines (XIP, NOMMU, 32-bit, ...). This would probably
not include the non-M option, as long as a non-M kernel works as
expected on CPUs with the M instructions.

        Arnd