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

[Palmer Dabbelt]

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.

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