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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Thu, 10 Mar 2022 23:54:24 -0500
From:   "Michael T. Kloos" <michael@...haelkloos.com>
To:     Palmer Dabbelt <palmer@...belt.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

Well at least I can take some satisfaction in that it seems that on my
2nd patch sent to the Linux kernel, I got it right the first time.  No
one has complained about problems with the code itself, just that they
don't want the feature.  I have also received no errors back from the
build bot.

For now, I will try to maintain this port on my own.  Thank you for the
consideration Palmer.

	Michael

On Thu, 2022-03-10 at 20:29 -0800, Palmer Dabbelt wrote:
> 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