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 09:09:34 -0800 (PST)
From:   Palmer Dabbelt <palmer@...belt.com>
To:     Arnd Bergmann <arnd@...db.de>
CC:     Arnd Bergmann <arnd@...db.de>, michael@...haelkloos.com,
        Paul Walmsley <paul.walmsley@...ive.com>,
        aou@...s.berkeley.edu, linux-riscv@...ts.infradead.org,
        linux-kernel@...r.kernel.org
Subject:     Re: [PATCH] riscv: Work to remove kernel dependence on the M-extension

On Wed, 09 Mar 2022 23:54:17 PST (-0800), Arnd Bergmann wrote:
> 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

The problem here isn't the required extensions, it's that vendors can 
claim to implement an extension on hardware that doesn't exhibit any of 
the behavior the specification expresses that systems with those 
extensions must have.  The D1 is a very concrete example of this.

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

I get the value to having an option hiding these things, as users might 
shoot themselves in the foot.  I sent a patch, not sure it's exactly 
what we want but at least it's something concrete to discuss.