Re: [isa-dev] Digest for isa-dev@groups.riscv.org - 3 updates in 1 topic

[Robert Lipe]

I'm not a crypto person. I fully recognize that it's a highly specialized and complicated topic. I am, however, a RISC-V enthusiast and systems software developer that is concerned with extension fatigue and extension inflation.

Some of these ops sound useful outside of crypto. Things in Zvbb like vector rotate and vcpop could be useful in graphics utilities and general purpose computing if not in actual GPUs. This may somewhat undermine my actual point/question.

Is it really justified to have all of these in different extensions? I'm concerned that we may be catering too much to silicon vendors that want to implement one opcode and not spend the gates for the rest while the rest of us deal with explosions in -Zfoo combinations offered by compilers, assemblers, libraries, and chips. 

I realize the simple count of extensions being introduced here is somewhat inflated by some of them being groups of extensions (somewhat hinting at the problem), but is it really justified to have this being so many different extensions?

As a tangible example of the impact, look at how much time and space a compiler build spends spinning through building support libraries for each of [cimafd] and the confusion that happens when someone actually implements a chip that has multiply but doesn't have compressed opcodes. It makes building general binaries to distribute a problem because you want to ship an OS that runs on as many parts as possible, but now can't rely on 'c' being there. (I get that's a rather more pervasive extension, literally touching every opcode.)

So my question for the record:

Is it really justified to have "crypto" be so many different extensions? The right number might be more than one, but does it really need to be more than ten independently optionally implemented choices?

I'm willing to accept that you are domain experts have thought about this really hard and have already justified this and the answer is "yes", but it seems an "are you sure?" is part of public review. The combinations of flags in support libraries, generated binaries, compiler flags, and such will be a maintenance cost for a lot of groups for a long time and fewer combinations would be better than more. Our industry is already struggling to implement Vector extensions that were ratified years ago.

RJL

On Sat, Jun 24, 2023 at 6:47 AM <isa...@groups.riscv.org> wrote:

isa...@groups.riscv.org

Google Groups

Topic digest
View all topics

• Public review for RISC-V Vector Cryptography Extensions - 3 Updates

Public review for RISC-V Vector Cryptography Extensions

Krste Asanovic <kr...@sifive.com>: Jun 23 11:30PM -0700 On behalf of the Crypto Task Group, we are thrilled to announce the start of the public review period for the following proposed standard extensions to the RISC-V ISA:   Zvk - Vector Crypto (rollup of all of the following extensions) Zvbb - Vector Bit-manipulation used in Cryptography Zvbc - Vector Carryless Multiplication Zvkg - Vector GCM/GMAC Zvkned - NIST Suite: Vector AES Block Cipher Zvknha - NIST Suite: Vector SHA-2 Secure Hash: SHA-256 Zvknhb - NIST Suite: Vector SHA-2 Secure Hash: SHA-512 and SHA-256 Zvksed - ShangMi Suite: SM4 Block Cipher Zvksh - ShangMi Suite: SM3 Secure Hash Zvkn - NIST Algorithm Suite Zvknc - NIST Algorithm Suite with carryless multiply Zvkng - NIST Algorithm Suite with GCM Zvks - ShangMi Algorithm Suite Zvksc - ShangMi Algorithm Suite with carryless multiplication Zvksg - ShangMi Algorithm Suite with GCM Zvkt - Vector Data-Independent Execution Latency   The review period begins today, Tuesday June 23, 2023, and ends on Thursday July 23, 2023 (inclusive).   This extension is part of the Unprivileged Specification.   These extensions are described in the PDF spec available at: https://github.com/riscv/riscv-crypto/releases <https://github.com/riscv/riscv-crypto/releases> The latest version is https://github.com/riscv/riscv-crypto/releases/download/v20230620/riscv-crypto-spec-vector.pdf <https://github.com/riscv/riscv-crypto/releases/download/v20230620/riscv-crypto-spec-vector.pdf> which was generated from the source available in the following GitHub repo:   https://github.com/riscv/riscv-crypto/tree/master/doc/vector <https://github.com/riscv/riscv-crypto/tree/master/doc/vector> To respond to the public review, please either email comments to the public isa-dev mailing list or add issues and/or pull requests (PRs) to the RISC-V Crypto GitHub repo: https://github.com/riscv/riscv-crypto/tree/master/doc/vector <https://github.com/riscv/riscv-crypto/tree/master/doc/vector>. We welcome all input and appreciate your time and effort in helping us by reviewing the specification.   During the public review period, corrections, comments, and suggestions will be gathered for review by the RISC-V Crypto Task Group. Any minor corrections and/or uncontroversial changes will be incorporated into the specification. Any remaining issues or proposed changes will be addressed in the public review summary report. If there are no issues that require incompatible changes to the public review specification, the Unprivileged ISA Committee will recommend the updated specifications be approved and ratified by the RISC-V Technical Steering Committee and the RISC-V Board of Directors.   Thanks to all the contributors for all their hard work.   Krste Asanovic, Chair, Unprivileged ISA Committee Earl Killian, Vice-Chair, Unprivileged ISA Committee

James Cloos <cl...@jhcloos.com>: Jun 24 04:55AM -0400 quick q:   i recently read that work is underway towards a version of aes with 256-bit blocks. how will support for that be added to these extensions?   -JimC -- James Cloos <cl...@jhcloos.com> OpenPGP: 0x997A9F17ED7DAEA6

"Markku-Juhani O. Saarinen" <mj...@pqshield.com>: Jun 24 11:48AM +0200 > quick q:   > i recently read that work is underway towards a version of aes with > 256-bit blocks. how will support for that be added to these extensions?   Hi,   If such a thing is standardised, then we can consider it. However, NIST has no plans to standardize AES with 256-bit block size at the moment. This would also need to be in widespread use and offer quantitative and security advantages to to motivate inclusion into the RISC-V ISA.   From 2023 perspective it would be seem more sensible to use permutation-based cryptography in applications anyway (e.g. Keccak AEAD modes), given that FIPS 202 already specifies a 1600-bit permutation. (The security margin of 24-round Keccak f-1600 is massive compared to any variant of Rijndael, including the one with 256-bit block cipher -- which has always existed, see below.)   ps. Occasionally amateur cryptographers peddle "improved" AES-like designs; these are of varying quality and almost never worth the effort. Even if they manage to not introduce additional security problems with their modifications, it's good to remember Rijndael is a 1990s era design. We have learned much since that time. As an important example, the designers of Rijndael were not really aware of side-channel engineering considerations.   Of course a 256-bit block size version of Rijndael has existed for 25 years. NIST just standardized the 128-bit block size version as AES. *"Rijndael is an iterated block cipher with a variable block length and a variable key length. The block length and the key length can be independently specified to 128, 192 or 256 bits." * https://csrc.nist.gov/csrc/media/projects/cryptographic-standards-and-guidelines/documents/aes-development/rijndael-ammended.pdf   Cheers, - markku     Dr. Markku-Juhani O. Saarinen Staff Cryptography Architect PQShield Ltd       M: +44 0 7548 620723   E: mj...@pqshield.com W: www.pqshield.com

Back to top

You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to isa-dev+u...@groups.riscv.org.

[Nicolas Brunie]

Hello Robert,

   Thank you for you valuable point. I think the intent with the numerous vector crypto extensions is two-fold:

- allow a high level of customization where it makes sense (e.g. not everyone will want to support both full NIST and Shang-Mi suites)

- allow a common subset implemented by the ecosystem to limit fragmentation and ease standard software development

For the second point, the task groups relies on a few superset extensions (e.g. Zvkng) which were developed specifically for some profile (e.g. Zvkng is an option for the RVA23U64 profile, https://github.com/riscv/riscv-profiles/blob/main/rva23-profile.adoc#rva23u64-optional-extensions,  but none of zvknha, zvkned, zvknhb are [in a standalone fashion without being part of a larger superset]

Regards

Nicolas Brunie

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAGJ6%2BwqbndPKv%3D%3DF%2BaVgDBhuFt%2BG3hx1vQY9QE%3DYL67zJQs-wQ%40mail.gmail.com.

[Markku-Juhani O. Saarinen]

Hi,

Let me expand on Nicolas' answer a bit..

24 June 2023, 10:01, Robert Lipe <rober...@gmail.com>:

I realize the simple count of extensions being introduced here is somewhat inflated by some of them being groups of extensions (somewhat hinting at the problem), but is it really justified to have this being so many different extensions?

First of all, I totally agree that this many instruction groupings will probably not be needed in the long run. However, these are basically just names; we just don't know the most practical system configurations yet. 

The ''RISC-V answer" (the way I understand it) is that pragmatic system software projects and chip designers will target just a small number of "profiles" ( see https://github.com/riscv/riscv-profiles/ ) or otherwise "de facto" prominent configurations. Nicolas mentioned some of those already.

Example: Take the specific vector crypto supported (and required) by RISC-V Android. We give the option to makers of Android SoCs destined for the Chinese and American markets to support different subsets of instructions (the NIST/ShangMi division noted by Nicolas.) But I don't expect Android system software to support an exponential number of combinations; the Android project can simply state their system requirements (software platform).

From what I hear Android will chose one (or a small number of) vector crypto configurations. And I also expect a future RVA profiles to include just some subset(s) from this specification. Disclaimer: I'm not Google -- I don't speak for them -- and I'm not in the RV Architecture Committee either.. :)

Some of these ops sound useful outside of crypto. Things in Zvbb like vector rotate and vcpop could be useful in graphics utilities and general purpose computing if not in actual GPUs.

 

Yep, There is nothing stopping using those instructions outside crypto; note the lack of krypto "k" letter in Zvbb bit manipulation extension name. In fact, some of these instructions are in this particular specification mainly due to ratification schedule convenience, rather than pressing cryptographic needs.

A system designer can pick those bit manipulation instruction without choosing any of the cryptography-specific instructions. I recently dropped into a LLVM dev call where they were busy discussing about applying carryless multiply (CLMUL )to CRC computations. CRC is not a cryptographic checksum, but is used various protocols, and a well-optimized CRC gives a nice boost to CoreMark. So if a vendor just wants a better CoreMark and doesn't care about cryptography, they can just have Zvbc without the rest (stranger things have happened!) As a by-product they get a faster GCM mode for TLS too.

Cheers,

-markku

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAOPaMHisMcvNdjhdUd2Ku3%3DeZ3fDPcK26Agf1r1PMozpCntO1A%40mail.gmail.com.

[Robert Lipe]

Thank you, Nicolas and Markku.

I don't really know the target audience of all the specific modes and such. I just think about how things like this are implemented as libraries and compiler options passed between build systems and such and the strong desire to build binaries that work across OSes and different chips.

As long as you've thought about the possibility of company A implementing only the odd numbered options and company B implementing only the even numbered ones (crazy example, I know...) or other zany things that we've already seen silicon vendors do (no "C" in an otherwise Linux capable CPU, really?) carry on.

Android (disclaimer: former Googler here that was responsible for a very large native app binary that shipped in the reference image for several years - even including MIPS :-) ) is in a unique position to be able to somewhat dictate what the silicon will provide. "Runs Android (well)" is/will be probably one of the most valuable defacto platform groupings as I think we have yet to see official Profile support in shipping silicon yet, have we? 

RISC-V already gets a lot of smack talk in the industry for the fragmentation of the large number of extensions, the incompatible base implementations, and the deployment of chips that flat out disregard the specifications, so I just wanted to be sure that adding another dozen to the mix was justified. Please just be mindful of, say, a Chrome binary built with some combination of these running on an OS (system libraries) that was built with a different combination and running on silicon with a random-ish (well, difficult to predict) subset of all of these.

The comforting case, I suspect, is that applications are built with none of these opcodes, but call system libraries that may either use these opcodes directly (yay!) or use open-coded implementations of them that are "just" slower (boo!). Then 'only' the OS vendors have to worry about the explosion of combinations.

That's how I'd do it if I were on the Android NDK team and they have the carrot/stick to discourage applications from doing their own because Java. They have rather more control - for better and worse - on how apps for their OS are built than, say, Debian.

Good point about CRC.  Hardware CRC offload was an important step in good TCP/IP implementations back when "Fast Ethernet" was 100Mbps. I hope to never see C-Kermit binaries being built with different flags just to help XMODEM, though. :-)

Thanx for the answers and for listening.

Best wishes,
RJL

[L Peter Deutsch]

I too have been concerned about the proliferation of optional extensions. I
know this is a recognized problem, and Profiles are the current approach to
mitigating it, but:

> RISC-V already gets a lot of smack talk in the industry for the
> fragmentation of the large number of extensions, the incompatible base
> implementations,

I thought the specifications were tight enough to prevent this. If this is
a significant problem, it deserves its own discussion, doesn't it?

> and the deployment of chips that flat out disregard the specifications

I know this has happened with the V and P extensions: it's a risk whenever
there is a long delay between initiation and final approval of a
commercially valuable extension. Has it been an issue otherwise? In
particular, have chips been deployed with premature implementation of crypto
instructions (scalar or vector)? Again, another discussion.

As I may have posted before, JIT code generation can also chip away some of
the minimality/performance tradeoff. For it to be effective with relatively
more specialized functionality like vector and/or crypto, the generator must
be able to match up IR library procedure calls with instructions that might
implement them; and for this, the library API must be standardized as
thoroughly as the instructions themselves. But also, I don't think that JIT
code generation, while established and important in Web browsers and for
some specialized contexts like packet filters and regular expressions, has
really percolated far enough down the software stack to be a general answer.

--

L Peter Deutsch :: Aladdin Enterprises :: Healdsburg, CA & Burnaby, BC