linux-kernel - Re: [PATCH 0/4] Expose the isa-string via the AT_BASE

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]

Message-ID: <878re77085.fsf@all.your.base.are.belong.to.us>
Date:   Tue, 02 May 2023 07:48:10 +0200
From:   Björn Töpel <bjorn@...nel.org>
To:     Jessica Clarke <jrtc27@...c27.com>
Cc:     Heiko Stuebner <heiko@...ech.de>,
        Palmer Dabbelt <palmer@...belt.com>,
        linux-riscv <linux-riscv@...ts.infradead.org>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Kito Cheng <kito.cheng@...ive.com>,
        Conor Dooley <conor.dooley@...rochip.com>,
        matthias.bgg@...il.com,
        Heinrich Schuchardt <heinrich.schuchardt@...onical.com>,
        Greentime Hu <greentime.hu@...ive.com>, nick.knight@...ive.com,
        christoph.muellner@...ll.eu, philipp.tomsich@...ll.eu,
        richard.henderson@...aro.org, arnd@...db.de,
        linux-kernel@...r.kernel.org,
        Heiko Stuebner <heiko.stuebner@...ll.eu>
Subject: Re: [PATCH 0/4] Expose the isa-string via the AT_BASE_PLATFORM aux
 vector

Jessica Clarke <jrtc27@...c27.com> writes:

> All I wanted was some simple extension string -> version number function
> as a standardised userspace interface... because at the end of the day
> people just want to know “can I use extension Y?”, possibly with a
> minimum version. But maybe there’s some hope that Linux libcs will
> translate such queries into poking at this hwprobe thing.

Using hwprobe to plumb such an interface for, say libcs, was what I was
envisioning.

> Though god knows what they’re going to do about vendor extensions,
> especially if those vendor extensions only get supported in vendor
> forks of the kernel (who’s allocating their encodings? Xvendorfoo
> exists to namespace them and give vendors control...).

"they're"? I'm sure your input on how to design such an interface would
be be much appreciated!

My view is that the "design upfront" strategy here hasn't really worked
out, so the hwprobe approach is to start small, and extend when there's
need. Hopefully, there will be fewer pains with this approach.

That's why I was very surprised to see this series, which introduces Yet
Another Interface.


Björn