| Message ID | 20231205092801.1335-1-jerry.shih@sifive.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | RISC-V: provide some accelerated cryptography implementations using vector extensions | expand |
On Tue, Dec 05, 2023 at 05:27:49PM +0800, Jerry Shih wrote: > This series depend on: > 2. support kernel-mode vector > Link: https://lore.kernel.org/all/20230721112855.1006-1-andy.chiu@sifive.com/ > 3. vector crypto extensions detection > Link: https://lore.kernel.org/lkml/20231017131456.2053396-1-cleger@rivosinc.com/ What's the status of getting these prerequisites merged? - Eric
On Dec 6, 2023, at 08:46, Eric Biggers <ebiggers@kernel.org> wrote: > On Tue, Dec 05, 2023 at 05:27:49PM +0800, Jerry Shih wrote: >> This series depend on: >> 2. support kernel-mode vector >> Link: https://lore.kernel.org/all/20230721112855.1006-1-andy.chiu@sifive.com/ >> 3. vector crypto extensions detection >> Link: https://lore.kernel.org/lkml/20231017131456.2053396-1-cleger@rivosinc.com/ > > What's the status of getting these prerequisites merged? > > - Eric The latest extension detection patch version is v5. Link: https://lore.kernel.org/lkml/20231114141256.126749-1-cleger@rivosinc.com/ It's still under reviewing. But I think the checking codes used in this crypto patch series will not change. We could just wait and rebase when it's merged. The latest kernel-mode vector patch version is v3. Link: https://lore.kernel.org/all/20231019154552.23351-1-andy.chiu@sifive.com/ This patch doesn't work with qemu(hit kernel panic when using vector). It's not clear for the status. Could we still do the reviewing process for the gluing code and the crypto asm parts? -Jerry
Hi Jerry, On Wed, Dec 06, 2023 at 03:02:40PM +0800, Jerry Shih wrote: > On Dec 6, 2023, at 08:46, Eric Biggers <ebiggers@kernel.org> wrote: > > On Tue, Dec 05, 2023 at 05:27:49PM +0800, Jerry Shih wrote: > >> This series depend on: > >> 2. support kernel-mode vector > >> Link: https://lore.kernel.org/all/20230721112855.1006-1-andy.chiu@sifive.com/ > >> 3. vector crypto extensions detection > >> Link: https://lore.kernel.org/lkml/20231017131456.2053396-1-cleger@rivosinc.com/ > > > > What's the status of getting these prerequisites merged? > > > > - Eric > > The latest extension detection patch version is v5. > Link: https://lore.kernel.org/lkml/20231114141256.126749-1-cleger@rivosinc.com/ > It's still under reviewing. > But I think the checking codes used in this crypto patch series will not change. > We could just wait and rebase when it's merged. > > The latest kernel-mode vector patch version is v3. > Link: https://lore.kernel.org/all/20231019154552.23351-1-andy.chiu@sifive.com/ > This patch doesn't work with qemu(hit kernel panic when using vector). It's not > clear for the status. Could we still do the reviewing process for the gluing code and > the crypto asm parts? I'm almost ready to give my Reviewed-by for this whole series. The problem is that it can't be merged until its prerequisites are merged. Andy Chiu's last patchset "riscv: support kernel-mode Vector" was 2 months ago, but he also gave a talk at Plumbers about it more recently (https://www.youtube.com/watch?v=eht3PccEn5o). So I assume he's still working on it. It sounds like he's also going to include support for preemption, and optimizations to memcpy, memset, memmove, and copy_{to,from}_user. I think it would be a good idea to split out the basic support for kernel_vector_{begin,end} so that the users of them, as well as the preemption support, can be considered and merged separately. Maybe patch 1 of the series (https://lore.kernel.org/r/20231019154552.23351-2-andy.chiu@sifive.com) is all that's needed initially? Andy, what do you think? - Eric
On Tue, 05 Dec 2023 23:41:55 PST (-0800), ebiggers@kernel.org wrote: > Hi Jerry, > > On Wed, Dec 06, 2023 at 03:02:40PM +0800, Jerry Shih wrote: >> On Dec 6, 2023, at 08:46, Eric Biggers <ebiggers@kernel.org> wrote: >> > On Tue, Dec 05, 2023 at 05:27:49PM +0800, Jerry Shih wrote: >> >> This series depend on: >> >> 2. support kernel-mode vector >> >> Link: https://lore.kernel.org/all/20230721112855.1006-1-andy.chiu@sifive.com/ >> >> 3. vector crypto extensions detection >> >> Link: https://lore.kernel.org/lkml/20231017131456.2053396-1-cleger@rivosinc.com/ >> > >> > What's the status of getting these prerequisites merged? >> > >> > - Eric >> >> The latest extension detection patch version is v5. >> Link: https://lore.kernel.org/lkml/20231114141256.126749-1-cleger@rivosinc.com/ >> It's still under reviewing. >> But I think the checking codes used in this crypto patch series will not change. >> We could just wait and rebase when it's merged. >> >> The latest kernel-mode vector patch version is v3. >> Link: https://lore.kernel.org/all/20231019154552.23351-1-andy.chiu@sifive.com/ >> This patch doesn't work with qemu(hit kernel panic when using vector). It's not >> clear for the status. Could we still do the reviewing process for the gluing code and >> the crypto asm parts? > > I'm almost ready to give my Reviewed-by for this whole series. The problem is > that it can't be merged until its prerequisites are merged. > > Andy Chiu's last patchset "riscv: support kernel-mode Vector" was 2 months ago, > but he also gave a talk at Plumbers about it more recently > (https://www.youtube.com/watch?v=eht3PccEn5o). So I assume he's still working > on it. It sounds like he's also going to include support for preemption, and > optimizations to memcpy, memset, memmove, and copy_{to,from}_user. So I think we just got blocked on not knowing if turning on vector everywhere in the kernel was a good idea -- it's not what any other port does despite there having been some discussions floating around, but we never really figured out why. I can come up with some possible performance pathologies related to having vector on in many contexts, but it's all theory as there's not really any vector hardware that works upstream (though the K230 is starting to come along, so maybe that'll sort itself out). Last we talked I think the general consensus is that we'd waited long enough, if nobody has a concrete objection we should just take it and see -- sure maybe there's some possible issues, but anything could have issues. > I think it would be a good idea to split out the basic support for > kernel_vector_{begin,end} so that the users of them, as well as the preemption > support, can be considered and merged separately. Maybe patch 1 of the series > (https://lore.kernel.org/r/20231019154552.23351-2-andy.chiu@sifive.com) is all > that's needed initially? I'm fine with that sort of approach too, it's certainly more in line with other ports to just restrict the kernel-mode vector support to explicitly enabled sections. Sure maybe there's other stuff to do in kernel vector land, but we can at least get something going. > Andy, what do you think? I'll wait on Andy to see, but I generally agree we should merge something for this cycle. Andy: maybe just send a patch set with what you think is the best way to go? Then we have one target approach and we can get things moving. > - Eric
Hi Palmer, On Thu, Dec 7, 2023 at 1:07 AM Palmer Dabbelt <palmer@dabbelt.com> wrote: > > On Tue, 05 Dec 2023 23:41:55 PST (-0800), ebiggers@kernel.org wrote: > > Hi Jerry, > > > > On Wed, Dec 06, 2023 at 03:02:40PM +0800, Jerry Shih wrote: > >> On Dec 6, 2023, at 08:46, Eric Biggers <ebiggers@kernel.org> wrote: > >> > On Tue, Dec 05, 2023 at 05:27:49PM +0800, Jerry Shih wrote: > >> >> This series depend on: > >> >> 2. support kernel-mode vector > >> >> Link: https://lore.kernel.org/all/20230721112855.1006-1-andy.chiu@sifive.com/ > >> >> 3. vector crypto extensions detection > >> >> Link: https://lore.kernel.org/lkml/20231017131456.2053396-1-cleger@rivosinc.com/ > >> > > >> > What's the status of getting these prerequisites merged? > >> > > >> > - Eric > >> > >> The latest extension detection patch version is v5. > >> Link: https://lore.kernel.org/lkml/20231114141256.126749-1-cleger@rivosinc.com/ > >> It's still under reviewing. > >> But I think the checking codes used in this crypto patch series will not change. > >> We could just wait and rebase when it's merged. > >> > >> The latest kernel-mode vector patch version is v3. > >> Link: https://lore.kernel.org/all/20231019154552.23351-1-andy.chiu@sifive.com/ > >> This patch doesn't work with qemu(hit kernel panic when using vector). It's not > >> clear for the status. Could we still do the reviewing process for the gluing code and > >> the crypto asm parts? > > > > I'm almost ready to give my Reviewed-by for this whole series. The problem is > > that it can't be merged until its prerequisites are merged. > > > > Andy Chiu's last patchset "riscv: support kernel-mode Vector" was 2 months ago, > > but he also gave a talk at Plumbers about it more recently > > (https://www.youtube.com/watch?v=eht3PccEn5o). So I assume he's still working > > on it. It sounds like he's also going to include support for preemption, and > > optimizations to memcpy, memset, memmove, and copy_{to,from}_user. > > So I think we just got blocked on not knowing if turning on vector > everywhere in the kernel was a good idea -- it's not what any other port > does despite there having been some discussions floating around, but we > never really figured out why. I can come up with some possible > performance pathologies related to having vector on in many contexts, > but it's all theory as there's not really any vector hardware that works > upstream (though the K230 is starting to come along, so maybe that'll > sort itself out). > > Last we talked I think the general consensus is that we'd waited long > enough, if nobody has a concrete objection we should just take it and > see -- sure maybe there's some possible issues, but anything could have > issues. > > > I think it would be a good idea to split out the basic support for > > kernel_vector_{begin,end} so that the users of them, as well as the preemption > > support, can be considered and merged separately. Maybe patch 1 of the series > > (https://lore.kernel.org/r/20231019154552.23351-2-andy.chiu@sifive.com) is all > > that's needed initially? > > I'm fine with that sort of approach too, it's certainly more in line > with other ports to just restrict the kernel-mode vector support to > explicitly enabled sections. Sure maybe there's other stuff to do in > kernel vector land, but we can at least get something going. With the current approach of preempt_v we still need kernel_vector_begin/end to explicitly mark enabled sections. But indeed, preempt_v will make it easy to do function-wise, thread-wise enable if people need it. > > > Andy, what do you think? > > I'll wait on Andy to see, but I generally agree we should merge > something for this cycle. > > Andy: maybe just send a patch set with what you think is the best way to > go? Then we have one target approach and we can get things moving. Yes, I think we can split. It will introduce some overhead on my side, but at least we can get some parts moving. I was preempted by some higher priority tasks. Luckily I am back now. Please expect v4 by next week, I hope it won't be too late for the cycle. > > > - Eric
Hi Jerry, On Tue, Dec 05, 2023 at 05:27:49PM +0800, Jerry Shih wrote: > Changelog v2: > - Turn to use simd skcipher interface for AES-CBC/CTR/ECB/XTS and > Chacha20. If I understand correctly, the RISC-V kernel-mode vector support now seems to be heading down the path of supporting softirq context, as I had suggested originally. With patches 1-2 of Andy Chiu's latest patchset "[v7, 00/10] riscv: support kernel-mode Vector" (https://lore.kernel.org/linux-riscv/20231221134318.28105-1-andy.chiu@sifive.com). applied, the kernel has basic support for kernel-mode vector, including in softirq context. With that being the case, "skcipher" algorithms can just use the RISC-V vector unit unconditionally, given that skcipher only supports task and softirq context. Therefore, can you consider undoing your change that added fallbacks using the simd helper (crypto/simd.c)? Thanks! - Eric
Hi Jerry, On Thu, Dec 21, 2023 at 11:48:27PM -0600, Eric Biggers wrote: > Hi Jerry, > > On Tue, Dec 05, 2023 at 05:27:49PM +0800, Jerry Shih wrote: > > Changelog v2: > > - Turn to use simd skcipher interface for AES-CBC/CTR/ECB/XTS and > > Chacha20. > > If I understand correctly, the RISC-V kernel-mode vector support now seems to be > heading down the path of supporting softirq context, as I had suggested > originally. With patches 1-2 of Andy Chiu's latest patchset > "[v7, 00/10] riscv: support kernel-mode Vector" > (https://lore.kernel.org/linux-riscv/20231221134318.28105-1-andy.chiu@sifive.com). > applied, the kernel has basic support for kernel-mode vector, including in > softirq context. > > With that being the case, "skcipher" algorithms can just use the RISC-V vector > unit unconditionally, given that skcipher only supports task and softirq > context. Therefore, can you consider undoing your change that added fallbacks > using the simd helper (crypto/simd.c)? Thanks! > I had a go at incorporating my suggestions into your patchset, and rebasing the patchset onto riscv/for-next plus the first two patches of "[v9, 00/10] riscv: support kernel-mode Vector". You can get the result from branch "riscv-crypto" of https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git. Everything seems to work (tested in QEMU, as usual). Please consider using it when you send out v4; thanks! I can even send it out myself, if you want, but I assume you're still "owning" the patchset. - Eric
On Dec 30, 2023, at 11:51, Eric Biggers <ebiggers@kernel.org> wrote: > Hi Jerry, > On Thu, Dec 21, 2023 at 11:48:27PM -0600, Eric Biggers wrote: >> Hi Jerry, >> >> On Tue, Dec 05, 2023 at 05:27:49PM +0800, Jerry Shih wrote: >>> Changelog v2: >>> - Turn to use simd skcipher interface for AES-CBC/CTR/ECB/XTS and >>> Chacha20. >> >> If I understand correctly, the RISC-V kernel-mode vector support now seems to be >> heading down the path of supporting softirq context, as I had suggested >> originally. With patches 1-2 of Andy Chiu's latest patchset >> "[v7, 00/10] riscv: support kernel-mode Vector" >> (https://lore.kernel.org/linux-riscv/20231221134318.28105-1-andy.chiu@sifive.com). >> applied, the kernel has basic support for kernel-mode vector, including in >> softirq context. >> >> With that being the case, "skcipher" algorithms can just use the RISC-V vector >> unit unconditionally, given that skcipher only supports task and softirq >> context. Therefore, can you consider undoing your change that added fallbacks >> using the simd helper (crypto/simd.c)? Thanks! >> > > I had a go at incorporating my suggestions into your patchset, and rebasing the > patchset onto riscv/for-next plus the first two patches of "[v9, 00/10] riscv: > support kernel-mode Vector". You can get the result from branch "riscv-crypto" > of https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git. > Everything seems to work (tested in QEMU, as usual). > > Please consider using it when you send out v4; thanks! I can even send it out > myself, if you want, but I assume you're still "owning" the patchset. > > - Eric Thank you. I sent the v4 patch. Link: https://lore.kernel.org/all/20231231152743.6304-1-jerry.shih@sifive.com/ -Jerry
From: Jerry Shih <bignose1007@gmail.com> This series provides cryptographic implementations using the vector crypto extensions[1] including: 1. AES cipher 2. AES with CBC/CTR/ECB/XTS block modes 3. ChaCha20 stream cipher 4. GHASH for GCM 5. SHA-224/256 and SHA-384/512 hash 6. SM3 hash 7. SM4 cipher This patch set is based on Heiko Stuebner's work at: Link: https://lore.kernel.org/all/20230711153743.1970625-1-heiko@sntech.de/ The implementations reuse the perl-asm scripts from OpenSSL[2] with some changes adapting for the kernel crypto framework. The perl-asm scripts generate the RISC-V RVV 1.0 instructions and the opcodes of the vector crypto instructions into `.S` files. We will replace the vector crypto opcodes with asm mnemonics in the future. It needs lots of extensions checking for toolchains. All changes pass the kernel run-time crypto self tests and the extra tests with vector-crypto-enabled qemu. Link: https://lists.gnu.org/archive/html/qemu-devel/2023-11/msg00281.html This series depend on: 1. kernel 6.6-rc7 Link: https://github.com/torvalds/linux/commit/05d3ef8bba77c1b5f98d941d8b2d4aeab8118ef1 2. support kernel-mode vector Link: https://lore.kernel.org/all/20230721112855.1006-1-andy.chiu@sifive.com/ 3. vector crypto extensions detection Link: https://lore.kernel.org/lkml/20231017131456.2053396-1-cleger@rivosinc.com/ 4. fix the error message: alg: skcipher: skipping comparison tests for xts-aes-aesni because xts(ecb(aes-generic)) is unavailable Link: https://lore.kernel.org/linux-crypto/20231009023116.266210-1-ebiggers@kernel.org/ Here is a branch on github applying with all dependent patches: Link: https://github.com/JerryShih/linux/tree/dev/jerrys/vector-crypto-upstream-v3 [1] Link: https://github.com/riscv/riscv-crypto/blob/56ed7952d13eb5bdff92e2b522404668952f416d/doc/vector/riscv-crypto-spec-vector.adoc [2] Link: https://github.com/openssl/openssl/pull/21923 Updated patches (on current order): 3, 4, 6, 7, 8, 9, 10, 11, 12 New patch: - Unchanged patch: 1, 2, 5 Deleted patch: 6 in v2 Changelog v3: - Use asm mnemonics for the instructions in RVV 1.0 extension. - Use `SYM_TYPED_FUNC_START` for indirect-call asm symbols. - Update aes xts_crypt() implementation. - Update crypto function names with the prefix/suffix of `riscv64` or the specific extensions to avoid the collision with functions in `crypto/` or `lib/crypto/`. Changelog v2: - Do not turn on the RISC-V accelerated crypto kconfig options by default. - Assume RISC-V vector extension could support unaligned access in kernel. - Turn to use simd skcipher interface for AES-CBC/CTR/ECB/XTS and Chacha20. - Rename crypto file and driver names to make the most important extension at first place. Heiko Stuebner (2): RISC-V: add helper function to read the vector VLEN RISC-V: hook new crypto subdir into build-system Jerry Shih (10): RISC-V: crypto: add OpenSSL perl module for vector instructions RISC-V: crypto: add Zvkned accelerated AES implementation crypto: simd - Update `walksize` in simd skcipher RISC-V: crypto: add accelerated AES-CBC/CTR/ECB/XTS implementations RISC-V: crypto: add Zvkg accelerated GCM GHASH implementation RISC-V: crypto: add Zvknha/b accelerated SHA224/256 implementations RISC-V: crypto: add Zvknhb accelerated SHA384/512 implementations RISC-V: crypto: add Zvksed accelerated SM4 implementation RISC-V: crypto: add Zvksh accelerated SM3 implementation RISC-V: crypto: add Zvkb accelerated ChaCha20 implementation arch/riscv/Kbuild | 1 + arch/riscv/crypto/Kconfig | 110 ++ arch/riscv/crypto/Makefile | 68 + .../crypto/aes-riscv64-block-mode-glue.c | 494 +++++++ arch/riscv/crypto/aes-riscv64-glue.c | 137 ++ arch/riscv/crypto/aes-riscv64-glue.h | 18 + .../crypto/aes-riscv64-zvkned-zvbb-zvkg.pl | 949 +++++++++++++ arch/riscv/crypto/aes-riscv64-zvkned-zvkb.pl | 415 ++++++ arch/riscv/crypto/aes-riscv64-zvkned.pl | 1199 +++++++++++++++++ arch/riscv/crypto/chacha-riscv64-glue.c | 122 ++ arch/riscv/crypto/chacha-riscv64-zvkb.pl | 321 +++++ arch/riscv/crypto/ghash-riscv64-glue.c | 175 +++ arch/riscv/crypto/ghash-riscv64-zvkg.pl | 100 ++ arch/riscv/crypto/riscv.pm | 359 +++++ arch/riscv/crypto/sha256-riscv64-glue.c | 145 ++ .../sha256-riscv64-zvknha_or_zvknhb-zvkb.pl | 317 +++++ arch/riscv/crypto/sha512-riscv64-glue.c | 139 ++ .../crypto/sha512-riscv64-zvknhb-zvkb.pl | 265 ++++ arch/riscv/crypto/sm3-riscv64-glue.c | 124 ++ arch/riscv/crypto/sm3-riscv64-zvksh.pl | 227 ++++ arch/riscv/crypto/sm4-riscv64-glue.c | 121 ++ arch/riscv/crypto/sm4-riscv64-zvksed.pl | 268 ++++ arch/riscv/include/asm/vector.h | 11 + crypto/Kconfig | 3 + crypto/cryptd.c | 1 + crypto/simd.c | 1 + 26 files changed, 6090 insertions(+) create mode 100644 arch/riscv/crypto/Kconfig create mode 100644 arch/riscv/crypto/Makefile create mode 100644 arch/riscv/crypto/aes-riscv64-block-mode-glue.c create mode 100644 arch/riscv/crypto/aes-riscv64-glue.c create mode 100644 arch/riscv/crypto/aes-riscv64-glue.h create mode 100644 arch/riscv/crypto/aes-riscv64-zvkned-zvbb-zvkg.pl create mode 100644 arch/riscv/crypto/aes-riscv64-zvkned-zvkb.pl create mode 100644 arch/riscv/crypto/aes-riscv64-zvkned.pl create mode 100644 arch/riscv/crypto/chacha-riscv64-glue.c create mode 100644 arch/riscv/crypto/chacha-riscv64-zvkb.pl create mode 100644 arch/riscv/crypto/ghash-riscv64-glue.c create mode 100644 arch/riscv/crypto/ghash-riscv64-zvkg.pl create mode 100644 arch/riscv/crypto/riscv.pm create mode 100644 arch/riscv/crypto/sha256-riscv64-glue.c create mode 100644 arch/riscv/crypto/sha256-riscv64-zvknha_or_zvknhb-zvkb.pl create mode 100644 arch/riscv/crypto/sha512-riscv64-glue.c create mode 100644 arch/riscv/crypto/sha512-riscv64-zvknhb-zvkb.pl create mode 100644 arch/riscv/crypto/sm3-riscv64-glue.c create mode 100644 arch/riscv/crypto/sm3-riscv64-zvksh.pl create mode 100644 arch/riscv/crypto/sm4-riscv64-glue.c create mode 100644 arch/riscv/crypto/sm4-riscv64-zvksed.pl -- 2.28.0