linux-kernel - Re: [PATCH v2 05/19] riscv: add ISA extension parsing for vector crypto extensions

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: <20231019-nuclear-vista-ef3e0b9bef71@spud>
Date:   Thu, 19 Oct 2023 16:33:12 +0100
From:   Conor Dooley <conor@...nel.org>
To:     Clément Léger <cleger@...osinc.com>
Cc:     Evan Green <evan@...osinc.com>, Jerry Shih <jerry.shih@...ive.com>,
        linux-riscv@...ts.infradead.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
        Palmer Dabbelt <palmer@...osinc.com>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Albert Ou <aou@...s.berkeley.edu>,
        Jonathan Corbet <corbet@....net>,
        Andrew Jones <ajones@...tanamicro.com>,
        Samuel Ortiz <sameo@...osinc.com>
Subject: Re: [PATCH v2 05/19] riscv: add ISA extension parsing for vector
 crypto extensions

On Thu, Oct 19, 2023 at 11:35:59AM +0200, Clément Léger wrote:
> 
> 
> On 18/10/2023 19:26, Evan Green wrote:
> > On Wed, Oct 18, 2023 at 5:53 AM Clément Léger <cleger@...osinc.com> wrote:
> >>
> >>
> >>
> >> On 18/10/2023 03:45, Jerry Shih wrote:
> >>> On Oct 17, 2023, at 21:14, Clément Léger <cleger@...osinc.com> wrote:
> >>>> @@ -221,6 +261,22 @@ const struct riscv_isa_ext_data riscv_isa_ext[] = {
> >>>>      __RISCV_ISA_EXT_DATA(zkt, RISCV_ISA_EXT_ZKT),
> >>>>      __RISCV_ISA_EXT_DATA(zksed, RISCV_ISA_EXT_ZKSED),
> >>>>      __RISCV_ISA_EXT_DATA(zksh, RISCV_ISA_EXT_ZKSH),
> >>>> +    __RISCV_ISA_EXT_DATA(zvbb, RISCV_ISA_EXT_ZVBB),
> >>>> +    __RISCV_ISA_EXT_DATA(zvbc, RISCV_ISA_EXT_ZVBC),
> >>>> +    __RISCV_ISA_EXT_DATA(zvkb, RISCV_ISA_EXT_ZVKB),
> >>>
> >>> The `Zvkb` is the subset of `Zvbb`[1]. So, the `Zvkb` should be bundled with `Zvbb`.
> >>
> >> Hi Jerry,
> >>
> >> Thanks for catching this, I think some other extensions will fall in
> >> this category as well then (Zvknha/Zvknhb). I will verify that.
> > 
> > The bundling mechanism works well when an extension is a pure lasso
> > around other extensions. We'd have to tweak that code if we wanted to
> > support cases like this, where the extension is a superset of others,
> > but also contains loose change not present anywhere else (and
> > therefore also needs to stand as a separate bit).
> 
> For Zvbb and Zvknhb, I used the following code:
> 
> static const unsigned int riscv_zvbb_bundled_exts[] = {
> 	RISCV_ISA_EXT_ZVKB,
> 	RISCV_ISA_EXT_ZVBB
> };
> 
> static const unsigned int riscv_zvknhb_bundled_exts[] = {
> 	RISCV_ISA_EXT_ZVKNHA,
> 	RISCV_ISA_EXT_ZVKNHB
> };
> 
> Which correctly results in both extension (superset + base set) being
> enabled when only one is set. Is there something that I'm missing ?
> 
> > 
> > IMO, decomposing "pure" bundles makes sense since otherwise usermode
> > would have to query multiple distinct bitmaps that meant the same
> > thing (eg check the Zk bit, or maybe check the Zkn/Zkr/Zkt bits, or
> > maybe check the Zbkb/Zbkc... bits, and they're all equivalent). But
> > when an extension is a superset that also contains loose change, there
> > really aren't two equivalent bitmasks, each bit adds something new.
> 
> Agreed but if a system only report ZVBB for instance and the user wants
> ZVKB, then it is clear that ZVKB should be reported as well I guess. So
> in the end, it works much like "bundle" extension, just that the bundle
> is actually a "real" ISA extension by itself.
> 
> Clément
> 
> > 
> > There's an argument to be made for still turning on the containing
> > extensions to cover for silly ISA strings (eg ISA strings that
> > advertise the superset but fail to advertise the containing
> > extensions). We can decide if we want to work that hard to cover
> > hypothetical broken ISA strings now, or wait until they show up.
> > Personally I would wait until something broken shows up. But others
> > may feel differently.

I'm not really sure that those are "silly" ISA strings. People are going
to do it that way because it is much easier than spelling out 5 dozen
sub-components, and it is pretty inevitable that subsets will be
introduced in the future for extensions we currently have.

IMO, it's perfectly valid to say you have the supersets and not spell
out all the subcomponents.

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)