This might be a bit knit picky, but the the --enable-riscv=<extensions> is not quite correct.
Namely, the Zkn extension is a superset of others, currently supported and used are Zbkb, Zbkc, and Zkned.
When selecting Zkn it gets treated as if only Zkned is selected.
This means when working with a core that fully implements the Zkn or even the Zk extension, the correct string at this point needs to be --enable-riscv=zbkc,zbkb,zkn, while just specifying Zkn should be sufficient.
This does not apply to the vector set of extensions, as there simply is no Zvkn option (and I do not know if there could be one, it would depend on Zvknhb being used in the library).
I'd argue having no superset for vector extensions is less grave, the naming for the vector cryptography extensions becomes quite involved anyways.
I tried patching this myself, but I have no experience working with an autogen/configure flow.
Let me know if I left anything unclear.
-Alex
This might be a bit knit picky, but the the
--enable-riscv=<extensions>is not quite correct.Namely, the
Zknextension is a superset of others, currently supported and used areZbkb,Zbkc, andZkned.When selecting
Zknit gets treated as if onlyZknedis selected.This means when working with a core that fully implements the
Zknor even theZkextension, the correct string at this point needs to be--enable-riscv=zbkc,zbkb,zkn, while just specifyingZknshould be sufficient.This does not apply to the vector set of extensions, as there simply is no
Zvknoption (and I do not know if there could be one, it would depend onZvknhbbeing used in the library).I'd argue having no superset for vector extensions is less grave, the naming for the vector cryptography extensions becomes quite involved anyways.
I tried patching this myself, but I have no experience working with an autogen/configure flow.
Let me know if I left anything unclear.
-Alex