Hi, On Wed, 8 Nov 2023 at 10:38, Palmer Dabbelt <pal...@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-cle...@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.hender...@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
