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: <ded4018d-c90f-41c7-9e54-da954bdef49e@app.fastmail.com>
Date:   Wed, 15 Feb 2023 10:56:51 +0100
From:   "Arnd Bergmann" <arnd@...db.de>
To:     "Evan Green" <evan@...osinc.com>,
        "Palmer Dabbelt" <palmer@...osinc.com>
Cc:     "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 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.

      Arnd