linux-kernel - Re: [PATCH v2 2/6] RISC-V: Add a syscall for HW probing

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: <CALs-HsuwOqR+y-GriKOiRx068bgOv3qTOpsJTaA02htiiynWmw@mail.gmail.com>
Date:   Wed, 15 Feb 2023 13:14:17 -0800
From:   Evan Green <evan@...osinc.com>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Palmer Dabbelt <palmer@...osinc.com>,
        Conor Dooley <conor@...nel.org>,
        Vineet Gupta <vineetg@...osinc.com>,
        Heiko Stübner <heiko@...ech.de>,
        slewis@...osinc.com, Albert Ou <aou@...s.berkeley.edu>,
        Andrew Bresticker <abrestic@...osinc.com>,
        Andrew Jones <ajones@...tanamicro.com>,
        Anup Patel <apatel@...tanamicro.com>,
        Atish Patra <atishp@...osinc.com>,
        Bagas Sanjaya <bagasdotme@...il.com>,
        Celeste Liu <coelacanthus@...look.com>,
        "Conor.Dooley" <conor.dooley@...rochip.com>,
        Dao Lu <daolu@...osinc.com>, guoren <guoren@...nel.org>,
        Jonathan Corbet <corbet@....net>,
        Palmer Dabbelt <palmer@...belt.com>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Randy Dunlap <rdunlap@...radead.org>,
        Ruizhe Pan <c141028@...il.com>,
        Sunil V L <sunilvl@...tanamicro.com>,
        Tobias Klauser <tklauser@...tanz.ch>,
        linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-riscv@...ts.infradead.org
Subject: Re: [PATCH v2 2/6] RISC-V: Add a syscall for HW probing

On Wed, Feb 15, 2023 at 1:57 AM Arnd Bergmann <arnd@...db.de> wrote:
>
> On Mon, Feb 6, 2023, at 21:14, Evan Green wrote:
> > We don't have enough space for these all in ELF_HWCAP{,2} and there's no
> > system call that quite does this, so let's just provide an arch-specific
> > one to probe for hardware capabilities.  This currently just provides
> > m{arch,imp,vendor}id, but with the key-value pairs we can pass more in
> > the future.
> >
> > Co-developed-by: Palmer Dabbelt <palmer@...osinc.com>
> > Signed-off-by: Palmer Dabbelt <palmer@...osinc.com>
> > Signed-off-by: Evan Green <evan@...osinc.com>
>
> I'm not sure I understand the problem with
> AT_HWCAP. While the bits in AT_HWCAP and AT_HWCAP2
> are limited, I don't see us running out of new
> AT_* words to use for additional bits. Presumably
> the kernel would already have to know about the
> name of each supported HW feature and could assign
> a unique bit number to them.

Palmer can probably speak to this with more authority, but my
understanding about the motivation for an approach like this goes
something like:
 * With the nature of RISC-V, we expect a lot of these types of bits
and bobs, many more than we've seen with the likes of x86 and ARM.
 * We also expect in some cases these values to be inconsistent across CPUs.
 * While we could copy all that data into the aux vector every time,
it starts to look like a lot of data, not all programs care about all
of it, and a lot of it is static, making all the copying wasteful.
 * Another option that would solve most of this would be to point to a
vDSO data area from the aux vector. This solves the copy complaints,
but makes that vDSO data ABI, and requires it all to be known up
front.
 * So, a syscall with a vDSO function in front of it seemed like a
good combination of speed and flexibility.

You're certainly right that HWCAPn would work for what we're exposing
today, so the question probably comes down to our relative predictions
of how this data will grow.

-Evan