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.
Cheers,
Conor.
0 - https://github.com/riscv/riscv-crypto/releases/tag/v1.0.1-scalar
