Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Status at a glance:

Scalar Crypto Specification:

Lightweight instruction set extensions for RV32 and RV64 HARTs.  Proposed extensions:

  • Extensions fully defined in the Scalar Crypto Specification:  KZk, Zkn, Zks, Zkr, Zkne, Zknd, Zknh, Zksed, Zksh, Zkt
  • Shared with the Bit-Manipulation Specification: ZkgZbkx, Zbkc, Zkb

Specification

  • Latest Draft Scalar Crypto Specification (v0.9.1)
  • Stable in asciidoc form now.
  • Some consistency review feedback which will be applied in subsequent functional releases:
    • aes32* and sm4* encodings will change to remove the `rt` field.
    • Change aes64ks1i "rcon" immediate to "rnum".
    • Remove packu[w] since they aren't needed for our usecase of packing bytes into words. We can use other pack instructions.
    • Break Zbk into smaller units: (Zbkc: clmul*, Zbkx: xperm.*, Zbkb: everything else)
    • Entropy source changes, including configurable access to the entropy source from S mode.

Encoding/OpCode consistency review

  • Opcodes and encodings proposed
  • Instruction extensions (instruction groupings) proposed
  • Submitted to review task group
  • The Bit-Manipulation shared subsets are being reviewed first as part of Bit-Manipulation specification review
    • Proposed as Zkg (clmul) and Zkb (specific crypto-required bit-manipulation commands)
  • The Proposed Scalar Crypto-unique subsets are next in line for review:
    • K (Krypto): 
      • Zkn (full NIST Suite):  ZKne (NIST encrypt suite), ZKnd (NIST decrypt suite), ZKnh (NIST hash suite), Zkg, Zkb (see above)
      • Zkr (random entropy source)
    • Zks (full ShangMi Suite):  Zksed (SM4 encrypt/decrypt suite), Zksh (SM3 hash suite), Zkg, Zkb (see above)
  • OpCode and Consistency Review page
  • What's next:  Respond to OpCode and Consistency Review comments, once available, and achieve consensus on any changes.
  • (warning)We need to discuss the aes32* and sm4* rt encodings.
  • Comments from others and Andrew particularly suggest that having distinct rd/rs1/rs2 is acceptable and that we over-estimated the importance of minimising encoding cost.
  • We will likely be reverting to the original form of these instructions, with separate rd/rs1/rs2 before public review.Zbkb
  • Instruction Group Names Diagram (click thumbnail for full-size image)

Image Added

Pub

Architecture & Opcode consistency review

  • The results of the review can be seen here. Scalar Crypto Arch Review Results.pdf
  • After discussion within the task group, the following changes will be made to the spec, with the changes expected to land in 0.9.4 before the end of August.
    • Stop overlapping the aes32 and aes64 opcodes. See riscv/riscv-opcodes#77
    • Clarify the effect of misa.k
    • Some updates to the entropy source and zkt detailed here.
    • Miscellaneous editorial issues.
  • Some downstream tasks for our group development partners now we are in public review.
WhoWhatStatusTask
PLCTGCCNot startedUpdate extension names: Zkb → Zbkb etc.
PLCTGCCNot startedUpdate aes32/64* encodings if applicable.
PLCTLLVMDoneUpdate extension names: Zkb → Zbkb etc.
PLCTLLVMDoneUpdate aes32/64* encodings if applicable.
IITriscv-configNot startedUpdate extension names: Zkb → Zbkb etc.
IITriscv-configNot startedUpdate instruction inclusion in different extensions
IITriscv-arch-testsNot startedBreak up K suite into Zk* extensions
IITriscv-arch-testsNot startedUpdate instruction inclusion in different extensions

Architecture Tests

  • Test plan for the scalar-crypto specific instructions is available.
  • Imperas have a complete set of tests, written to the existing test plan, for the scalar crypto instructions and the bitmanip instructions we borrow.
    • These have been merged into the main test suite as of PR#177, with many thanks to Imperas for the contribution.
      • Spike, OVPSim and Sail all agree on the test signatures.
    • They form a base we can use to develop prototype implementations / Spike / SAIL / QEMU very easily and quickly.
  • Upstream Spike support for enabling it to work with the K test suite is being added in PR#687.
  • IIT Madras are also looking at writing the scalar crypto tests for integration into the official architectural tests repo as well.
    • Agreed SoW for IITM
    • They are re-implementing the tests as part of the blessed coverage and test generation tooling.
      • Making good progress with the simple test patterns for scalar-crypto specific instructions A/O April 7'th '21
    • We then switch over to using the IIT tests when they are finished, since they will be easier to maintain/extend going forward than the Imperas tests.
  • YAML config changes for K have been merged in. See here.
  • Update from IIT Madras as on 25-Oct
  • Status from IIT Madras as on 17-Jun:
    • All test cases and coverage reports has been generated and presented.
    • If there are any changes in future on these that is required in future, IIT Madras will enhance the scripts as per requirements.
  • Status from IIT Madras as on 20-May:
    • Real world test cases as per the test plan has been generated.
    • Currently waiting for the fixed toolchain with K extension from PLCT to test the generated test cases. All the test cases are working fine when we run against the patched toolchain
    • A PR has been raised with a pull request for this suite to be reviewed and merged in the riscv-arch tests github repo.
  • Status from IIT Madras as on 12-May:
    • Coverage report for all developed cases in CTG/ISAC has been generated and it is reported as 100%
    • Currently real world test cases are being developed as per test plan and will be completed and send for review by beginning of next week
  • Status from IIT Madras as on 05-May:
    • Resolved issues in running the rv64ik toolchain after interacting with PLCT and compile the relevant tests generated from CTG and run them on spike
    • Currently resolving issues in the running the rv64ibk toolchain. Once this is done, will generate the coverage report of the test cases built till now and share with team.
  • Status from IIT Madras as on 26-Apr:
    • Completed the coverage points specification for all 32-bit and 64-bit instructions
    • Generated test cases from the coverage points
    • Currently working on trying to install the scalar crypto enabled toolchain.

...

LLVM

  • Work will be done by PLTC PLCT lab under the group contributor model.
  • Slides from PLCT Update Weds 10'th Feb
  • As of 21'st April '21, LLVM work is mostly complete, waiting on PLCT lab for an update about merging things upstream.
    • Some small changes will be needed as we move to v1.0 of scalar crypto around encodings.
  • As of 24'st Jan '22, LLVM upstream is able to compile the assembly code of Zk* and Zbk*

Simulators

Though all listed under "simulators", these are actually a collection of formal model / virtual machine / architectural simulators / DV simulators etc.

...

  • Currently working on getting support merged in upstream in PR#80 PR#99
    • Support for all scalar-crypto dedicated instructions is present.Support for and the entropy source is still the main point of discussionpresent.
    • No support for Bitmanip . The Bitmanip TG is waiting until after the opcode and consistency review to start writing SAIL code.(warning) This PR is "paused" until the next release of the scalar crypto spec, which will bring some functional changes to the `aes32*` and `sm4*` instructionsyet.

Spike

  • Upstream support has been merged in as of PR#635
  • Support for all of scalar crypto specific instructions and entropy source.
  • The only feature left is to enable the right Bitmanip instructions when K is enabled. Currently, one must include "b" in the spike "–isa=" argument.
  • PR#649 has now been merged. Support now consistent with v0.9.0..
  • Instructions are up to date with v1.0.0

riscvOVPSimPlus

  • Imperas Commercial Simulator
  • Freeware version
  • Support forSupports:
    • Crypto-scalar v0.7.2, v0
    .81
    • .8.1, 0.9.0,  0.9.2, 1.0.0-rc1, + Bitmanip subsets
    • Bitmanip 0.90, 0.91, 0.92, 0.93-draft, 0.93, 0.94, 1.0.0
    • Functional coverage collection.

QEMU

...