[PATCH v3 0/2] rng: Provide a RNG based on the RISC-V Zkr ISA extension

[Conor Dooley]

+CC Palmer

On Tue, Nov 07, 2023 at 05:38:37PM -0500, Tom Rini wrote:
> On Tue, Nov 07, 2023 at 10:27:50PM +0000, Conor Dooley wrote:
> > On Tue, Nov 07, 2023 at 05:10:23PM -0500, Tom Rini wrote:
> > 
> > 
> > > further clarify or not
> > > the RISC-V ISA thing that's elsewhere in this thread (and part of the
> > > kernel, not a U-Boot thing).
> > 
> > TBH, this a bit fragmented across threads, and as someone that hasn't
> > been following it it's a bit difficult to tell exactly what is being
> > asked for. Would someone be able to ask it as a direct question?
> 
> Sorry for being unclear, and thanks for asking. What I think the U-Boot
> community would like to know is, what is the device-tree based way to
> know if a RISC-V platform has the Zbb extensions

For this one, it's pretty straightforward IMO - if riscv,isa-extensions
contains "zbb", then you are safe to use those instructions. My
understanding is that relying on getting illegal instruction traps is
not a sufficient test for usability of standard extensions, as a vendor
extension could be using the same opcodes as a standard extension.

> so the RNG opcodes,
> similar (in concept at least?) to the ARMv8.5 RNG feature.

The ordinary extensions that are instructions - like Zbkb that provides
bit manipulation instructions for cryptography you will be able to rely
on riscv,isa-extensions also. Zkr is actually a CSR acting as an entropy
source and is a bit more complicated. RISC-V Cryptography Extensions
Volume I, Chapter Four [0] is the relevant thing for use of the CSR
provided by Zkr, and it says "The seed CSR is also access controlled by
execution mode, and attempted read or write access will raise an illegal
instruction exception outside M mode unless access is explicitly granted."
My take is that either the SBI implementation needs to provide S-Mode
U-Boot with an accurate devicetree (including what extensions are valid
for use in S-mode) or if the devicetree is provided as part of the U-Boot
binary then it needs to match what is available at that privilege level
on the platform. In this case, you would also be able to rely on
riscv,isa-extensions for that detection. There is an existing dt-binding
patch
<https://lore.kernel.org/linux-riscv/20231107105556.517187-6-cleger@rivosinc.com/>
that adds Zkr, and my proposal would be to document that the presence of Zkr
explicitly in riscv,isa-extensions means that the bit in mseccfg.[s,u]seed
has been set so it can be used at the current privilege level.

If that's not acceptable, and people think that having Zkr in the
devicetree means that the hardware has the extension, regardless of
usability at the present privilege level, then IMO we need an SBI ecall
defined to request entablement of the CSR & report as to whether or not
that was possible.

I'm not sure how any of the above lines up with the ARMv8.5 RNG feature
unfortunately.

Cheers,
Conor.

0 - https://github.com/riscv/riscv-crypto/releases/tag/v1.0.1-scalar
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20231107/d2f3ac5e/attachment.sig>