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

[Simon Glass]

Hi,

On Wed, 8 Nov 2023 at 10:38, Palmer Dabbelt <palmer at dabbelt.com> wrote:
>
> On Tue, 07 Nov 2023 15:12:16 PST (-0800), 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
>
> Also just kind of jumping in: I don't usually follow u-boot stuff, but a
> few of us ended up talking abot this.
>
> >> > 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.
>
> Not just could, but we've got systems that actually overlay
> vendor-specific behavior onto the standard encoding space.  There's a
> lot of small offenders for things like errata, but there's also stuff
> like T-Head where huge chunks of space reserved by the ISA for standard
> stuff gets reused.
>
> >> 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.
>
> FWIW, that seems generally viable to me.
>
> > 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 think we can start without the SBI interface, but I'm not 100% sure.
> I was worried about writes to "seed" somehow resulting in an information
> leak, but the spec says "The write value (in rs1 or uimm) must be
> ignored by implementations." so I think we're safe.
>
> > I'm not sure how any of the above lines up with the ARMv8.5 RNG feature
> > unfortunately.
>
> All I know is what's in this patch set
> <https://patchwork.kernel.org/project/linux-arm-kernel/patch/20191019022048.28065-2-richard.henderson@linaro.org/>.
> It looks generalyl to me like the RNDR bits in
> "cpu-features-registers.rst" would coorespond to "Zkr" being set in
> "riscv,isa-extensions" -- we don't have ISA-defined feature registers,
> hence why all this ends up shimed in via DT.

Thanks for the info.

What is the hardware architecture of the RNG? Is there a single RNG in
the SoC or does each CPU have its own? Is it configurable in any way?

>
> >
> > Cheers,
> > Conor.
> >
> > 0 - https://github.com/riscv/riscv-crypto/releases/tag/v1.0.1-scalar

Regards,
Simon