On Wed, Nov 29, 2023 at 11:12:16AM +0000, Conor Dooley wrote:
> On Wed, Nov 29, 2023 at 10:39:56AM +0800, Jerry Shih wrote:
> > On Nov 29, 2023, at 04:12, Eric Biggers <ebiggers@xxxxxxxxxx> wrote:
> > > On Tue, Nov 28, 2023 at 05:54:49PM +0000, Conor Dooley wrote:
> > >>> +static inline bool check_aes_ext(void)
> > >>> +{
> > >>> + return riscv_isa_extension_available(NULL, ZVKNED) &&
> > >>> + riscv_vector_vlen() >= 128;
> > >>> +}
> > >>
> > >> I'm not keen on this construct, where you are checking vlen greater than
> > >> 128 and the presence of Zvkned without checking for the presence of V
> > >> itself. Can you use "has_vector()" in any places where you depend on the
> > >> presence of vector please?
> > >
> > > Shouldn't both of those things imply vector support already?
> >
> > The vector crypto extensions imply `V` extension. Should we still need to check
> > the `V` explicitly?
> > https://github.com/riscv/riscv-crypto/blob/main/doc/vector/riscv-crypto-spec-vector.adoc#1-extensions-overview
>
> The check for Zkvned is only for whether or not Zvkned has been provided
> in the DT or ACPI tables, it doesn't mean that the kernel supports the V
> extension. I could see something like a hypervisor that does not support
> vector parsing the "v" out of the DT or ACPI tables but not eliminating
> every single extension that may depend on vector support.
>
> The latter check is, IMO, an implementation detail and also should not
> be used to imply that vector is supported.
First, the RISC-V crypto files are only compiled when CONFIG_RISCV_ISA_V=y.
So in those files, we know that the kernel supports V if the hardware does.
If the hardware can indeed declare extensions like Zvkned without declaring V,
that sounds problematic. Would /proc/cpuinfo end up with the same misleading
information in that case, in which case userspace would have the same problem
too? I think that such misconfigurations are best handled centrally by having
the low-level architecture code in the kernel clear all extensions that depend
on missing extensions. IIRC there have been issues like this on x86, and that
was the fix that was implemented. See arch/x86/kernel/cpu/cpuid-deps.c
- Eric
