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 20:29:31 -0800 (PST)
From:   Palmer Dabbelt <palmer@...belt.com>
To:     Michael@...haelKloos.com
CC:     Christoph Hellwig <hch@...radead.org>,
        Arnd Bergmann <arnd@...db.de>,
        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 Thu, 10 Mar 2022 05:37:27 PST (-0800), Michael@...haelKloos.com wrote:
> Is there something I can do that would help alleviate your concerns or
> apprehension?

IMO this is one of those cases where having hardware is required.

I can understand the goal of providing a Linux port for the minimal 
RISC-V compatible system, but IIUC the minimal RISC-V compatible system 
is any object associated with a member of the RISC-V foundation that 
said member attests is a RISC-V system.  There's really no way to 
implement Linux on all such systems so we have to set the bar somewhere, 
and bar is generally set at "more time will be spent using this than 
maintaining it".  Systems without M have generally not met that bar, and 
I don't see anything changing now.

If you have users then I'm happy to reconsider, the goal here is to make 
real systems work.  That said: we've already got enough trouble trying 
to make actual shipping hardware function correctly, we're all going to 
lose our minds trying to chase around everything that could in theory be 
a RISC-V system but doesn't actually exist.

>
> On 3/10/2022 8:22 AM, Michael T. Kloos wrote:
>
>> Some other thoughts:
>> It sounds like I am not the first person to want this feature and I
>> probably won't be the last.  I created the change for my own reasons, the
>> same as any other contributor.  I think we all know that I can not pull
>> out some chart and say, "This many people want this and here is why."  I
>> live in central Ohio and have been doing this as a hobby.  I don't even
>> know anyone else who knows about systems and operating system development.
>> If the justification that you are looking for is that I as some
>> hypothetical developer at a major tech company is about to release a new
>> RISC-V chip without M support but we want it to run Linux, I can not
>> provide that answer.  It sounds a bit like some software or hardware,
>> chicken or the egg anyway.  Trying to maintain my own fork if people
>> start contributing patches with incompatible assembly scares me.
>>      Michael