linux-kernel - Re: [PATCH] RISC-V: Show accurate per-hart isa in /proc/cpuinfo

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:   Mon, 26 Jun 2023 13:48:20 -0700 (PDT)
From:   Palmer Dabbelt <palmer@...belt.com>
To:     Conor Dooley <conor@...nel.org>
CC:     Evan Green <evan@...osinc.com>, aou@...s.berkeley.edu,
        ajones@...tanamicro.com, apatel@...tanamicro.com,
        Conor Dooley <conor.dooley@...rochip.com>,
        heiko.stuebner@...ll.eu, Paul Walmsley <paul.walmsley@...ive.com>,
        sunilvl@...tanamicro.com, linux-kernel@...r.kernel.org,
        linux-riscv@...ts.infradead.org
Subject:     Re: [PATCH] RISC-V: Show accurate per-hart isa in /proc/cpuinfo

On Mon, 26 Jun 2023 13:34:24 PDT (-0700), Conor Dooley wrote:
> On Mon, Jun 26, 2023 at 12:25:42PM -0700, Evan Green wrote:
>> On Fri, Jun 23, 2023 at 5:12 PM Conor Dooley <conor@...nel.org> wrote:
>> > On Fri, Jun 23, 2023 at 03:23:53PM -0700, Evan Green wrote:
>> > > In /proc/cpuinfo, most of the information we show for each processor is
>> > > specific to that hart: marchid, mvendorid, mimpid, processor, hart,
>> > > compatible, and the mmu size. But the ISA string gets filtered through a
>> > > lowest common denominator mask, so that if one CPU is missing an ISA
>> > > extension, no CPUs will show it.
>> > >
>> > > Now that we track the ISA extensions for each hart, let's report ISA
>> > > extension info accurately per-hart in /proc/cpuinfo.
>> >
>> > No, you can't do this as it breaks the assumptions of userspace that
>> > this shows the set supported across all harts.
>> > Sorry, but NAK.
>
>> My hope was that we were still early enough that no production systems
>> existed (yet) that actually had different ISA extensions in the set we
>> track, and therefore usermode would have been unable to make those
>> assumptions at this point. If such a system exists, and I don't know
>> if it does or not, then I agree it's too late to make a change like
>> this.
>
> You should put this information into your commit messages & not just
> hope that people understand your intent.
> Userspace does actually make these assumptions already, see for example
> this Google "cpu features" repo:
> https://github.com/google/cpu_features/tree/main
> To be quite honest, I really dislike the fragility of what they have
> implemented - with only one of the reasons being they made the mistake
> of assuming homogeneity.
>
> There's got to be a line somewhere for what constitutes buggy userspace
> and what's a regression. Up to Palmer I suppose as to what constitutes
> which.

Maybe let's just add a pretty printed version of the hwprobe info to 
/proc/cpuinfo, and then leave the ISA string alone as a legacy 
interface?

Having something so poorly defined as uABI is a bit embarassing, but 
it's our mistake so we've got to live with it.

>> I thought I'd put this out here and see if someone could point at such
>> a system; but if not it'd be great to keep /proc/cpuinfo accurate and
>> consistent with hwprobe (which does return accurate per-hart ISA
>> extension info).
>
> Just another nail in the coffin for a bad interface :)
> There are apparently some mixed c906 chips that support vector on one
> core and not the other - although it is thead vector which is not
> supported upstream yet...
>
> Other than that, SiFive stuff technically can be mixed - rv64imac &
> rv64imafdc on a bunch of the older stuff. I don't think anyone actually
> runs those sort of configurations on them though.