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

[Conor Dooley]

On Tue, Nov 07, 2023 at 06:23:05PM -0500, Tom Rini wrote:
> 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.

I did read that, but I don't think most of it is relevant to the binding
itself. His five things were:
| - U-Boot models hardware (and other things) as devices in driver model [1]

This I think should be satisfied. The Zkr CSR is a property of the CPU,
and shouldn't have its own DT node IMO. Is it problematic for U-Boot to
populate multiple devices for its driver model based on one DT node?
I know in Linux that I can create devices using something like
platform_device_register(), does U-Boot have a similar facility?
https://elixir.bootlin.com/linux/latest/source/drivers/base/platform.c#L767

| - U-Boot requires devices to be in the devicetree, with very limited
| exceptions [2]

| - Where multiple devices exist in a uclass, it is desirable to be able
| to number them [3]

I'm not sure really how this one ties in. Do you need a number for each
CPU that supports Zkr, since a system may be heterogeneous? I think that
how you treat things like that is beyond communicating support via DT
though, IMO the job of the DT is just to tell U-Boot on which CPUs it
can access the seed CSR.

| - Similarly it is useful to be able select a particular device, e.g.
| with a phandle [4]

I suppose a phandle to the CPU would work in this case.

| - U-Boot uses devicetree for configuration as it has no userspace

Cheers,
Conor.
-------------- 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/20231108/082a56ab/attachment.sig>