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

[Tom Rini]

On Tue, Nov 07, 2023 at 11:12:16PM +0000, Conor Dooley wrote:
> +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.

Thanks. Setting aside Simon's follow-up, this is what I was looking for.
We might have to wait for Heinrich to return from the conference to have
time to look at how to utilize the above and see what we can do from
there.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20231107/94263cd2/attachment.sig>