nettle-bugs

nettle-bugs@lists.lysator.liu.se

2191 discussions

Start a nNew thread

[PATCH v2] powerpc64/sha256: fix loading overreads by loading less and shifting
by Eric Richter 13 Sep '24

13 Sep '24

2 2

[PATCH] Add support for elf_aux_info() on OpenBSD
by Brad Smith 09 Sep '24

09 Sep '24

Signed-off-by: Brad Smith <brad(a)comstyle.com> --- configure.ac | 2 +- fat-arm64.c | 11 ++++++++++- fat-ppc.c | 12 ++++++------ 3 files changed, 17 insertions(+), 8 deletions(-) diff --git a/configure.ac b/configure.ac index 4f27e663..1f53a890 100644 --- a/configure.ac +++ b/configure.ac @@ -212,7 +212,7 @@ LSH_FUNC_ALLOCA # getenv_secure is used for fat overrides, # getline is used in the testsuite -AC_CHECK_FUNCS(secure_getenv getline) +AC_CHECK_FUNCS(secure_getenv getline elf_aux_info) ASM_WORDS_BIGENDIAN=unknown AC_C_BIGENDIAN([AC_DEFINE([WORDS_BIGENDIAN], 1) diff --git a/fat-arm64.c b/fat-arm64.c index 45cce0cc..36136078 100644 --- a/fat-arm64.c +++ b/fat-arm64.c @@ -51,6 +51,8 @@ #if USE_GETAUXVAL # include <asm/hwcap.h> # include <sys/auxv.h> +#elif defined(HAVE_ELF_AUX_INFO) +# include <sys/auxv.h> #elif defined(__OpenBSD__) # include <sys/sysctl.h> # include <machine/cpu.h> @@ -133,8 +135,15 @@ get_arm64_features (struct arm64_features *features) } else { +#if USE_GETAUXVAL || defined(HAVE_ELF_AUX_INFO) + unsigned long hwcap = 0; + #if USE_GETAUXVAL - unsigned long hwcap = getauxval(AT_HWCAP); + hwcap = getauxval(AT_HWCAP); +#elif defined(HAVE_ELF_AUX_INFO) + elf_aux_info(AT_HWCAP, &hwcap, sizeof(hwcap)); +#endif + features->have_aes = ((hwcap & (HWCAP_ASIMD | HWCAP_AES)) == (HWCAP_ASIMD | HWCAP_AES)); features->have_pmull diff --git a/fat-ppc.c b/fat-ppc.c index aaccc116..c4dae3a1 100644 --- a/fat-ppc.c +++ b/fat-ppc.c @@ -48,14 +48,14 @@ # include <asm/cputable.h> # include <sys/auxv.h> # endif -#elif defined(__FreeBSD__) +#elif defined(__FreeBSD__) || defined(__OpenBSD__) # include <machine/cpu.h> # ifdef PPC_FEATURE2_HAS_VEC_CRYPTO # define PPC_FEATURE2_VEC_CRYPTO PPC_FEATURE2_HAS_VEC_CRYPTO # endif -# if __FreeBSD__ >= 12 +# ifdef HAVE_ELF_AUX_INFO # include <sys/auxv.h> -# else +# elif !defined(__OpenBSD__) # include <sys/sysctl.h> # endif #endif @@ -129,11 +129,11 @@ get_ppc_features (struct ppc_features *features) # if USE_GETAUXVAL hwcap = getauxval(AT_HWCAP); hwcap2 = getauxval(AT_HWCAP2); -# elif defined(__FreeBSD__) -# if __FreeBSD__ >= 12 +# elif defined(__FreeBSD__) || defined(__OpenBSD__) +# ifdef HAVE_ELF_AUX_INFO elf_aux_info(AT_HWCAP, &hwcap, sizeof(hwcap)); elf_aux_info(AT_HWCAP2, &hwcap2, sizeof(hwcap2)); -# else +# elif !defined(__OpenBSD__) size_t len; len = sizeof(hwcap); sysctlbyname("hw.cpu_features", &hwcap, &len, NULL, 0); -- 2.46.0

2 5

[PATCH] powerpc64/sha256: fix loading overreads by loading less and shifting
by Eric Richter 06 Sep '24

06 Sep '24

Originally, the 16 input words were loaded with 16 individual vector load instructions. This has a side effect where the last three loads would overread 1/2/3 extra words. Fix the overread by replacing unnecessary overlapped reads with shifts. As a consequence, the constant registers for 4,8,12 can be removed, and also gain about 1~2% in performance. Signed-off-by: Eric Richter <erichte(a)linux.ibm.com> --- Some additional comments, since I agree that the loads should be fixed, but a bit of a performance anomaly appeared: I thought I had tested this exact method in a previous iteration of the patches, and saw either no change or a minor performance hit. This time around I am seeing a slight performance improvement: (This is output from a script that compares 10-iteration benchmark runs, the values in parens are the difference from just changing the loads to shifts) alg/mode min avg max ====================== ============== ============== ============== sha256 update 460.64 (+2.45) 467.99 (+6.63) 468.89 (+7.13) hmac-sha256 64 bytes 126.39 (+0.94) 126.86 (+0.14) 127.42 (+0.08) hmac-sha256 256 bytes 272.14 (+2.97) 273.07 (+2.07) 273.60 (+1.44) hmac-sha256 1024 bytes 391.52 (+2.00) 393.17 (+2.03) 395.58 (+3.13) hmac-sha256 4096 bytes 440.61 (+3.22) 442.46 (+4.50) 444.15 (+5.73) hmac-sha256 single msg 454.75 (+1.23) 457.51 (+3.85) 459.70 (+5.91) However, removing the loads for the now unused TC registers now hurts performance by about the amount gained from using the shifts: Adding this change: - li TC4, 4 - li TC8, 8 - li TC12, 12 li TC16, 16 yields the following performance values (parens are difference against the code that did not remove the li's but did use shifts): alg/mode min avg max ====================== ============== ============== ============== sha256 update 462.47 (+1.83) 462.75 (-5.24) 462.87 (-6.02) hmac-sha256 64 bytes 126.01 (-0.38) 126.69 (-0.17) 127.00 (-0.42) hmac-sha256 256 bytes 270.13 (-2.01) 271.62 (-1.44) 272.99 (-0.61) hmac-sha256 1024 bytes 390.79 (-0.73) 391.84 (-1.33) 393.04 (-2.54) hmac-sha256 4096 bytes 438.60 (-2.01) 438.83 (-3.63) 439.30 (-4.85) hmac-sha256 single msg 454.52 (-0.23) 454.63 (-2.88) 454.76 (-4.94) If I add an align after the TC16 load: li TC16, 16 + .align 4 C Load state values lxvw4x VSR(VSA), 0, STATE C VSA contains A,B,C,D lxvw4x VSR(VSE), TC16, STATE C VSE contains E,F,G,H performance comes back to about where it was before removing the TC loads (parens are compared against the previous run): alg/mode min avg max ====================== ============== ============== ============== sha256 update 468.29 (+5.82) 468.74 (+5.99) 468.86 (+5.99) hmac-sha256 64 bytes 126.51 (+0.50) 127.26 (+0.57) 127.78 (+0.78) hmac-sha256 256 bytes 273.17 (+3.04) 274.51 (+2.89) 276.24 (+3.25) hmac-sha256 1024 bytes 393.27 (+2.48) 395.18 (+3.34) 397.87 (+4.83) hmac-sha256 4096 bytes 441.08 (+2.48) 443.21 (+4.38) 445.09 (+5.79) hmac-sha256 single msg 454.41 (-0.11) 458.30 (+3.67) 460.82 (+6.06) I suspect with four li instructions, those are issued 4x in parallel, and then the subsequent (slower) lxvw4x instructions are queued 2x. By removing the other three li instructions, that li is queued with the first lxvw4x, but not the second -- causing a stall as the second lxv has to wait for the parallel queue of the li + lxv before, as it depends on the li completing first. This is only my running theory, but unfortunately I don't currently have the bandwidth to do a deep dive for a <2% performance mystery (that said, I do intend to return to this when I get the chance, I suspect other areas of the code could also use a similar level of scrutiny). Do you have any thoughts or advice on this, or is the proposed approach acceptable for now? Additional note: I did also try rearranging the LOAD macros with the shifts, as well as moving around the requisite byte-swap vperms, but did not receive any performance benefits. It appears doing the load, vperm, shift, addi in that order appears to be the fastest order. powerpc64/p8/sha256-compress-n.asm | 33 +++++++++++++----------------- 1 file changed, 14 insertions(+), 19 deletions(-) diff --git a/powerpc64/p8/sha256-compress-n.asm b/powerpc64/p8/sha256-compress-n.asm index e08ae132..d3416e2a 100644 --- a/powerpc64/p8/sha256-compress-n.asm +++ b/powerpc64/p8/sha256-compress-n.asm @@ -44,10 +44,7 @@ define(`T1', `r8') define(`TK', `r9') define(`COUNT', `r10') define(`TC0', `0') C Index instructions allow literal 0 instead of a GPR -define(`TC4', `r11') -define(`TC8', `r12') -define(`TC12', `r14') -define(`TC16', `r15') +define(`TC16', `r11') C State registers define(`VSA', `v0') @@ -187,24 +184,24 @@ define(`LOAD', ` define(`DOLOADS', ` IF_LE(`DATA_LOAD_VEC(VT0, .load_swap, T1)') LOAD(0, TC0) - LOAD(1, TC4) - LOAD(2, TC8) - LOAD(3, TC12) + vsldoi IV(1), IV(0), IV(0), 4 + vsldoi IV(2), IV(0), IV(0), 8 + vsldoi IV(3), IV(0), IV(0), 12 addi INPUT, INPUT, 16 LOAD(4, TC0) - LOAD(5, TC4) - LOAD(6, TC8) - LOAD(7, TC12) + vsldoi IV(5), IV(4), IV(4), 4 + vsldoi IV(6), IV(4), IV(4), 8 + vsldoi IV(7), IV(4), IV(4), 12 addi INPUT, INPUT, 16 LOAD(8, TC0) - LOAD(9, TC4) - LOAD(10, TC8) - LOAD(11, TC12) + vsldoi IV(9), IV(8), IV(8), 4 + vsldoi IV(10), IV(8), IV(8), 8 + vsldoi IV(11), IV(8), IV(8), 12 addi INPUT, INPUT, 16 LOAD(12, TC0) - LOAD(13, TC4) - LOAD(14, TC8) - LOAD(15, TC12) + vsldoi IV(13), IV(12), IV(12), 4 + vsldoi IV(14), IV(12), IV(12), 8 + vsldoi IV(15), IV(12), IV(12), 12 addi INPUT, INPUT, 16 ') @@ -245,10 +242,8 @@ PROLOGUE(_nettle_sha256_compress_n) stdx r14, T0, SP stdx r15, T1, SP - li TC4, 4 - li TC8, 8 - li TC12, 12 li TC16, 16 + .align 4 C Load state values lxvw4x VSR(VSA), 0, STATE C VSA contains A,B,C,D -- 2.46.0

2 2

[PATCH] powerpc64/sha256: adjust stack offset for storing non-volatile registers
by Eric Richter 30 Aug '24

30 Aug '24

According to the ABI, the stack pointer is quadword aligned, so starting the stack storage at offset -8, may cause the return address to be stepped on. Adjusting to use -16 as the starting point, which also matches other POWER assembly code. Signed-off-by: Eric Richter <erichte(a)linux.ibm.com> --- powerpc64/p8/sha256-compress-n.asm | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/powerpc64/p8/sha256-compress-n.asm b/powerpc64/p8/sha256-compress-n.asm index 309db1fa..e08ae132 100644 --- a/powerpc64/p8/sha256-compress-n.asm +++ b/powerpc64/p8/sha256-compress-n.asm @@ -216,8 +216,8 @@ PROLOGUE(_nettle_sha256_compress_n) C Store non-volatile registers - li T0, -8 - li T1, -24 + li T0, -16 + li T1, -32 stvx v20, T0, SP stvx v21, T1, SP subi T0, T0, 32 @@ -321,8 +321,8 @@ PROLOGUE(_nettle_sha256_compress_n) C Restore nonvolatile registers - li T0, -8 - li T1, -24 + li T0, -16 + li T1, -32 lvx v20, T0, SP lvx v21, T1, SP subi T0, T0, 32 -- 2.46.0

2 2

[PATCH 1/2] powerpc64: remove use of m4_unquote in the load step for sha256
by Eric Richter 25 Aug '24

25 Aug '24

By passing in the constant offset value into the LOAD macro, the use of m4_unquote to calculate the correct constant GPR can be avoided, improving readability. Signed-off-by: Eric Richter <erichte(a)linux.ibm.com> --- powerpc64/p8/sha256-compress-n.asm | 36 +++++++++++++++--------------- 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/powerpc64/p8/sha256-compress-n.asm b/powerpc64/p8/sha256-compress-n.asm index 4848461e..309db1fa 100644 --- a/powerpc64/p8/sha256-compress-n.asm +++ b/powerpc64/p8/sha256-compress-n.asm @@ -177,34 +177,34 @@ define(`EXTENDROUNDS', ` ') define(`LOAD', ` - IF_BE(`lxvw4x VSR(IV($1)), m4_unquote(TC`'eval(($1 % 4) * 4)), INPUT') + IF_BE(`lxvw4x VSR(IV($1)), $2, INPUT') IF_LE(` - lxvd2x VSR(IV($1)), m4_unquote(TC`'eval(($1 % 4) * 4)), INPUT + lxvd2x VSR(IV($1)), $2, INPUT vperm IV($1), IV($1), IV($1), VT0 ') ') define(`DOLOADS', ` IF_LE(`DATA_LOAD_VEC(VT0, .load_swap, T1)') - LOAD(0) - LOAD(1) - LOAD(2) - LOAD(3) + LOAD(0, TC0) + LOAD(1, TC4) + LOAD(2, TC8) + LOAD(3, TC12) addi INPUT, INPUT, 16 - LOAD(4) - LOAD(5) - LOAD(6) - LOAD(7) + LOAD(4, TC0) + LOAD(5, TC4) + LOAD(6, TC8) + LOAD(7, TC12) addi INPUT, INPUT, 16 - LOAD(8) - LOAD(9) - LOAD(10) - LOAD(11) + LOAD(8, TC0) + LOAD(9, TC4) + LOAD(10, TC8) + LOAD(11, TC12) addi INPUT, INPUT, 16 - LOAD(12) - LOAD(13) - LOAD(14) - LOAD(15) + LOAD(12, TC0) + LOAD(13, TC4) + LOAD(14, TC8) + LOAD(15, TC12) addi INPUT, INPUT, 16 ') -- 2.45.2

2 4

[PATCH 0/2] AARCH64 Enable PAC and BTI
by Bill Roberts 13 Aug '24

13 Aug '24

This patchset enables PAC and BTI for nettle. Daiki has a patch here that I gave commented on: - https://git.lysator.liu.se/nettle/nettle/-/merge_requests/65 I also have an open public github with these changes at: https://github.com/billatarm/nettle/pull/1 Overally the patches are very similair, I just chose a different construct in how the various things are propgrated from configure to m4 which I think is a better seperation of duties. I wanted to share these over the mailing list as I am unable to create a fork on the GitLab instance and send a PR that way. Bill Roberts (2): x68_64: move machine specific asm to arch asm.m4 aarch64: enable PAC/BTI arm64/machine.m4 | 57 +++++++++++++++++++++++++++++++++++++++++++++++ asm.m4 | 2 +- config.m4.in | 4 ++++ configure.ac | 43 +++++++++++++++++++++++++++++++++++ x86_64/machine.m4 | 5 +++++ 5 files changed, 110 insertions(+), 1 deletion(-) -- 2.45.2

1 2

nettle: PACBTI for arm64 assembly
by Daiki Ueno 22 Jul '24

22 Jul '24

Hello, The attached is my attempt to enable PAC/BTI[1] support for AArch64. As the Nettle assembly files only define leaf functions (i.e., no subroutine calls with LR/SP save/restore), PAC is not applicable and thus only BTI is enabled for now. To test, I used the mock[2] environment with the fedora-40-aarch64 configuration: $ mock -r fedora-40-aarch64 --init <mock-chroot> sh-5.2# ./.bootstrap <mock-chroot> sh-5.2# ./configure --disable-documentation CFLAGS="-mbranch-protection=standard" <mock-chroot> sh-5.2# make -j$(nproc) <mock-chroot> sh-5.2# readelf -n libnettle.so Displaying notes found in: .note.gnu.property Owner Data size Description GNU 0x00000010 NT_GNU_PROPERTY_TYPE_0 Properties: AArch64 feature: BTI, PAC ... Regards, Footnotes: [1] https://wiki.debian.org/ToolChain/PACBTI [2] https://fedoraproject.org/wiki/Using_Mock_to_test_package_builds -- Daiki Ueno

3 7

[PATCH v3] powerpc64: Add optimized assembly for sha256-compress-n
by Eric Richter 18 Jun '24

18 Jun '24

This patch introduces an optimized powerpc64 assembly implementation for sha256-compress-n. This takes advantage of the vshasigma instruction, as well as unrolling loops to best take advantage of running instructions in parallel. The following data was captured on a POWER 10 LPAR @ ~3.896GHz Current C implementation: Algorithm mode Mbyte/s sha256 update 280.97 hmac-sha256 64 bytes 80.81 hmac-sha256 256 bytes 170.50 hmac-sha256 1024 bytes 241.92 hmac-sha256 4096 bytes 268.54 hmac-sha256 single msg 276.16 With optimized assembly: Algorithm mode Mbyte/s sha256 update 461.45 hmac-sha256 64 bytes 123.88 hmac-sha256 256 bytes 268.81 hmac-sha256 1024 bytes 390.91 hmac-sha256 4096 bytes 438.02 hmac-sha256 single msg 453.83 Signed-off-by: Eric Richter <erichte(a)linux.ibm.com> --- I split this patch to be standalone, rather than delay even further trying to update SHA512 -- I will update the SHA512 implementation when this one stabilizes. Regarding the load vperm needed for little endian: unfortunately we don't have a spare vector register to store the mask between rounds, so the best that can be done while maintaining p8 support will be to store the mask in a VSX register like the state values, and avoid the load. This is a negligible performance change however, yielding around +1MB/s on larger block counts (update, hmac 1024/4096/single msg) and -1MB/s on smaller (hmac 64/256). Dropping p8 support allows the use of the lxvb16x instruction, which does not need to be permuted, however that is as well a negligible performance improvement at the cost of dropping a whole cpu set. So I see a few options: A) leave as-is, consider storing the mask in a VSX register B) drop p8 support, use lxvb16x C) have a compile-time switch to use permute on p8, and use the single instruction for p9 an up. v3: - use protected zone instead of allocating stack space - add GPRs constants for multiples of 4 for loads - around +3.4 MB/s for sha256 update - move extend logic to its own macro called by EXTENDROUND - use 8 VSX registers to store previous state instead of the stack - around +11.0 MB/s for sha256 update fat-ppc.c | 12 + powerpc64/fat/sha256-compress-n-2.asm | 36 +++ powerpc64/p8/sha256-compress-n.asm | 364 ++++++++++++++++++++++++++ 3 files changed, 412 insertions(+) create mode 100644 powerpc64/fat/sha256-compress-n-2.asm create mode 100644 powerpc64/p8/sha256-compress-n.asm diff --git a/fat-ppc.c b/fat-ppc.c index cd76f7a1..efbeb2ec 100644 --- a/fat-ppc.c +++ b/fat-ppc.c @@ -203,6 +203,10 @@ DECLARE_FAT_FUNC(_nettle_poly1305_blocks, poly1305_blocks_func) DECLARE_FAT_FUNC_VAR(poly1305_blocks, poly1305_blocks_func, c) DECLARE_FAT_FUNC_VAR(poly1305_blocks, poly1305_blocks_func, ppc64) +DECLARE_FAT_FUNC(_nettle_sha256_compress_n, sha256_compress_n_func) +DECLARE_FAT_FUNC_VAR(sha256_compress_n, sha256_compress_n_func, c) +DECLARE_FAT_FUNC_VAR(sha256_compress_n, sha256_compress_n_func, ppc64) + static void CONSTRUCTOR fat_init (void) @@ -231,6 +235,8 @@ fat_init (void) _nettle_ghash_update_arm64() */ _nettle_ghash_set_key_vec = _nettle_ghash_set_key_ppc64; _nettle_ghash_update_vec = _nettle_ghash_update_ppc64; + + _nettle_sha256_compress_n_vec = _nettle_sha256_compress_n_ppc64; } else { @@ -239,6 +245,7 @@ fat_init (void) _nettle_aes_invert_vec = _nettle_aes_invert_c; _nettle_ghash_set_key_vec = _nettle_ghash_set_key_c; _nettle_ghash_update_vec = _nettle_ghash_update_c; + _nettle_sha256_compress_n_vec = _nettle_sha256_compress_n_c; } if (features.have_altivec) { @@ -338,3 +345,8 @@ DEFINE_FAT_FUNC(_nettle_poly1305_blocks, const uint8_t *, size_t blocks, const uint8_t *m), (ctx, blocks, m)) + +DEFINE_FAT_FUNC(_nettle_sha256_compress_n, const uint8_t *, + (uint32_t *state, const uint32_t *k, + size_t blocks, const uint8_t *input), + (state, k, blocks, input)) diff --git a/powerpc64/fat/sha256-compress-n-2.asm b/powerpc64/fat/sha256-compress-n-2.asm new file mode 100644 index 00000000..4f4eee9d --- /dev/null +++ b/powerpc64/fat/sha256-compress-n-2.asm @@ -0,0 +1,36 @@ +C powerpc64/fat/sha256-compress-n-2.asm + +ifelse(` + Copyright (C) 2024 Eric Richter, IBM Corporation + + This file is part of GNU Nettle. + + GNU Nettle is free software: you can redistribute it and/or + modify it under the terms of either: + + * the GNU Lesser General Public License as published by the Free + Software Foundation; either version 3 of the License, or (at your + option) any later version. + + or + + * the GNU General Public License as published by the Free + Software Foundation; either version 2 of the License, or (at your + option) any later version. + + or both in parallel, as here. + + GNU Nettle is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + General Public License for more details. + + You should have received copies of the GNU General Public License and + the GNU Lesser General Public License along with this program. If + not, see http://www.gnu.org/licenses/. +') + +dnl PROLOGUE(_nettle_sha256_compress_n) picked up by configure + +define(`fat_transform', `$1_ppc64') +include_src(`powerpc64/p8/sha256-compress-n.asm') diff --git a/powerpc64/p8/sha256-compress-n.asm b/powerpc64/p8/sha256-compress-n.asm new file mode 100644 index 00000000..c1ce0e8f --- /dev/null +++ b/powerpc64/p8/sha256-compress-n.asm @@ -0,0 +1,364 @@ +C x86_64/sha256-compress-n.asm + +ifelse(` + Copyright (C) 2024 Eric Richter, IBM Corporation + + This file is part of GNU Nettle. + + GNU Nettle is free software: you can redistribute it and/or + modify it under the terms of either: + + * the GNU Lesser General Public License as published by the Free + Software Foundation; either version 3 of the License, or (at your + option) any later version. + + or + + * the GNU General Public License as published by the Free + Software Foundation; either version 2 of the License, or (at your + option) any later version. + + or both in parallel, as here. + + GNU Nettle is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + General Public License for more details. + + You should have received copies of the GNU General Public License and + the GNU Lesser General Public License along with this program. If + not, see http://www.gnu.org/licenses/. +') + +.file "sha256-compress-n.asm" + +C Parameters in +define(`SP', `r1') +define(`STATE', `r3') +define(`K', `r4') +define(`NUMBLOCKS', `r5') +define(`INPUT', `r6') + +define(`T0', `r7') +define(`T1', `r8') +define(`TK', `r9') +define(`COUNT', `r10') +define(`TC0', `0') C Index instructions allow literal 0 instead of a GPR +define(`TC4', `r11') +define(`TC8', `r12') +define(`TC12', `r14') +define(`TC16', `r15') + +C State registers +define(`VSA', `v0') +define(`VSB', `v1') +define(`VSC', `v2') +define(`VSD', `v3') +define(`VSE', `v4') +define(`VSF', `v5') +define(`VSG', `v6') +define(`VSH', `v7') + +C Previous state value registers stored in VSX +define(`VSXA', `vs0') +define(`VSXB', `vs1') +define(`VSXC', `vs2') +define(`VSXD', `vs3') +define(`VSXE', `vs4') +define(`VSXF', `vs5') +define(`VSXG', `vs6') +define(`VSXH', `vs7') + +C Current K values +define(`VK', `v8') + +C Temp registers for math +define(`VT0', `v9') +define(`VT1', `v10') +define(`VT2', `v11') +define(`VT3', `v12') +define(`VT4', `v13') + +C Convenience named registers for sigma(a) and sigma(e) +define(`SIGA', `v14') +define(`SIGE', `v15') + +C Registers v16-v31 are used for input words W[0] through W[15] + +C Convert an index for W[i] to the corresponding vector register v[16 + i] +define(`IV', `m4_unquote(v`'eval((($1) % 16) + 16))') + +C ROUND(A B C D E F G H R EXT) +define(`ROUND', ` + + vadduwm VT1, VK, IV($9) C VT1: k+W + vadduwm VT4, $8, VT1 C VT4: H+k+W + + lxvw4x VSR(VK), TK, K C Load Key + addi TK, TK, 4 C Increment Pointer to next key + + vadduwm VT2, $4, $8 C VT2: H+D + vadduwm VT2, VT2, VT1 C VT2: H+D+k+W + + vshasigmaw SIGE, $5, 1, 0b1111 C Sigma(E) Se + vshasigmaw SIGA, $1, 1, 0 C Sigma(A) Sa + + vxor VT3, $2, $3 C VT3: b^c + vsel VT0, $7, $6, $5 C VT0: Ch. + vsel VT3, $3, $1, VT3 C VT3: Maj(a,b,c) + + vadduwm VT4, VT4, VT0 C VT4: Hkw + Ch. + vadduwm VT3, VT3, VT4 C VT3: HkW + Ch. + Maj. + + vadduwm VT0, VT0, VT2 C VT0: Ch. + DHKW + vadduwm $8, SIGE, SIGA C Anext: Se + Sa + vadduwm $4, VT0, SIGE C Dnext: Ch. + DHKW + Se + vadduwm $8, $8, VT3 C Anext: Se+Sa+HkW+Ch.+Maj. +') + +C Extend W[i] +define(`EXTEND', ` + vshasigmaw SIGE, IV($1 + 14), 0, 0b1111 + vshasigmaw SIGA, IV($1 + 1), 0, 0b0000 + vadduwm IV($1), IV($1), SIGE + vadduwm IV($1), IV($1), SIGA + vadduwm IV($1), IV($1), IV($1 + 9) +') + +define(`EXTENDROUND', ` + ROUND($1, $2, $3, $4, $5, $6, $7, $8, $9) + C Schedule (data) for 16th round in future + EXTEND($9) +') +define(`NOEXTENDROUND', `ROUND($1, $2, $3, $4, $5, $6, $7, $8, $9)') + +define(`NOEXTENDROUNDS', ` + NOEXTENDROUND(VSA, VSB, VSC, VSD, VSE, VSF, VSG, VSH, 0) + NOEXTENDROUND(VSH, VSA, VSB, VSC, VSD, VSE, VSF, VSG, 1) + NOEXTENDROUND(VSG, VSH, VSA, VSB, VSC, VSD, VSE, VSF, 2) + NOEXTENDROUND(VSF, VSG, VSH, VSA, VSB, VSC, VSD, VSE, 3) + + NOEXTENDROUND(VSE, VSF, VSG, VSH, VSA, VSB, VSC, VSD, 4) + NOEXTENDROUND(VSD, VSE, VSF, VSG, VSH, VSA, VSB, VSC, 5) + NOEXTENDROUND(VSC, VSD, VSE, VSF, VSG, VSH, VSA, VSB, 6) + NOEXTENDROUND(VSB, VSC, VSD, VSE, VSF, VSG, VSH, VSA, 7) + + NOEXTENDROUND(VSA, VSB, VSC, VSD, VSE, VSF, VSG, VSH, 8) + NOEXTENDROUND(VSH, VSA, VSB, VSC, VSD, VSE, VSF, VSG, 9) + NOEXTENDROUND(VSG, VSH, VSA, VSB, VSC, VSD, VSE, VSF, 10) + NOEXTENDROUND(VSF, VSG, VSH, VSA, VSB, VSC, VSD, VSE, 11) + + NOEXTENDROUND(VSE, VSF, VSG, VSH, VSA, VSB, VSC, VSD, 12) + NOEXTENDROUND(VSD, VSE, VSF, VSG, VSH, VSA, VSB, VSC, 13) + NOEXTENDROUND(VSC, VSD, VSE, VSF, VSG, VSH, VSA, VSB, 14) + NOEXTENDROUND(VSB, VSC, VSD, VSE, VSF, VSG, VSH, VSA, 15) +') + +define(`EXTENDROUNDS', ` + EXTENDROUND(VSA, VSB, VSC, VSD, VSE, VSF, VSG, VSH, 0) + EXTENDROUND(VSH, VSA, VSB, VSC, VSD, VSE, VSF, VSG, 1) + EXTENDROUND(VSG, VSH, VSA, VSB, VSC, VSD, VSE, VSF, 2) + EXTENDROUND(VSF, VSG, VSH, VSA, VSB, VSC, VSD, VSE, 3) + + EXTENDROUND(VSE, VSF, VSG, VSH, VSA, VSB, VSC, VSD, 4) + EXTENDROUND(VSD, VSE, VSF, VSG, VSH, VSA, VSB, VSC, 5) + EXTENDROUND(VSC, VSD, VSE, VSF, VSG, VSH, VSA, VSB, 6) + EXTENDROUND(VSB, VSC, VSD, VSE, VSF, VSG, VSH, VSA, 7) + + EXTENDROUND(VSA, VSB, VSC, VSD, VSE, VSF, VSG, VSH, 8) + EXTENDROUND(VSH, VSA, VSB, VSC, VSD, VSE, VSF, VSG, 9) + EXTENDROUND(VSG, VSH, VSA, VSB, VSC, VSD, VSE, VSF, 10) + EXTENDROUND(VSF, VSG, VSH, VSA, VSB, VSC, VSD, VSE, 11) + + EXTENDROUND(VSE, VSF, VSG, VSH, VSA, VSB, VSC, VSD, 12) + EXTENDROUND(VSD, VSE, VSF, VSG, VSH, VSA, VSB, VSC, 13) + EXTENDROUND(VSC, VSD, VSE, VSF, VSG, VSH, VSA, VSB, 14) + EXTENDROUND(VSB, VSC, VSD, VSE, VSF, VSG, VSH, VSA, 15) +') + +define(`LOAD', ` + IF_BE(`lxvw4x VSR(IV($1)), m4_unquote(TC`'eval(($1 % 4) * 4)), INPUT') + IF_LE(` + lxvd2x VSR(IV($1)), m4_unquote(TC`'eval(($1 % 4) * 4)), INPUT + vperm IV($1), IV($1), IV($1), VT0 + ') +') + +define(`DOLOADS', ` + IF_LE(`DATA_LOAD_VEC(VT0, .load_swap, T1)') + LOAD(0) + LOAD(1) + LOAD(2) + LOAD(3) + addi INPUT, INPUT, 16 + LOAD(4) + LOAD(5) + LOAD(6) + LOAD(7) + addi INPUT, INPUT, 16 + LOAD(8) + LOAD(9) + LOAD(10) + LOAD(11) + addi INPUT, INPUT, 16 + LOAD(12) + LOAD(13) + LOAD(14) + LOAD(15) + addi INPUT, INPUT, 16 +') + +.text +PROLOGUE(_nettle_sha256_compress_n) + cmpwi 0, NUMBLOCKS, 0 + ble 0, .done + mtctr NUMBLOCKS + + C Store non-volatile registers + + li T0, -8 + li T1, -24 + stvx v20, T0, SP + stvx v21, T1, SP + subi T0, T0, 32 + subi T1, T1, 32 + stvx v22, T0, SP + stvx v23, T1, SP + subi T0, T0, 32 + subi T1, T1, 32 + stvx v24, T0, SP + stvx v25, T1, SP + subi T0, T0, 32 + subi T1, T1, 32 + stvx v26, T0, SP + stvx v27, T1, SP + subi T0, T0, 32 + subi T1, T1, 32 + stvx v28, T0, SP + stvx v29, T1, SP + subi T0, T0, 32 + subi T1, T1, 32 + stvx v30, T0, SP + stvx v31, T1, SP + subi T0, T0, 32 + subi T1, T1, 32 + stdx r14, T0, SP + stdx r15, T1, SP + + li TC4, 4 + li TC8, 8 + li TC12, 12 + li TC16, 16 + + C Load state values + lxvw4x VSR(VSA), 0, STATE C VSA contains A,B,C,D + lxvw4x VSR(VSE), TC16, STATE C VSE contains E,F,G,H + + vsldoi VSB, VSA, VSA, 4 + vsldoi VSF, VSE, VSE, 4 + + vsldoi VSC, VSA, VSA, 8 + vsldoi VSG, VSE, VSE, 8 + + vsldoi VSD, VSA, VSA, 12 + vsldoi VSH, VSE, VSE, 12 + +.loop: + xxlor VSXA, VSR(VSA), VSR(VSA) + xxlor VSXB, VSR(VSB), VSR(VSB) + xxlor VSXC, VSR(VSC), VSR(VSC) + xxlor VSXD, VSR(VSD), VSR(VSD) + xxlor VSXE, VSR(VSE), VSR(VSE) + xxlor VSXF, VSR(VSF), VSR(VSF) + xxlor VSXG, VSR(VSG), VSR(VSG) + xxlor VSXH, VSR(VSH), VSR(VSH) + + li TK, 0 + lxvw4x VSR(VK), TK, K + addi TK, TK, 4 + + DOLOADS + + C "permute" state from VSA containing A,B,C,D into VSA,VSB,VSC,VSD + + EXTENDROUNDS + EXTENDROUNDS + EXTENDROUNDS + NOEXTENDROUNDS + + C Reload initial state from VSX registers + xxlor VSR(VT0), VSXA, VSXA + xxlor VSR(VT1), VSXB, VSXB + xxlor VSR(VT2), VSXC, VSXC + xxlor VSR(VT3), VSXD, VSXD + xxlor VSR(VT4), VSXE, VSXE + xxlor VSR(SIGA), VSXF, VSXF + xxlor VSR(SIGE), VSXG, VSXG + xxlor VSR(VK), VSXH, VSXH + + vadduwm VSA, VSA, VT0 + vadduwm VSB, VSB, VT1 + vadduwm VSC, VSC, VT2 + vadduwm VSD, VSD, VT3 + vadduwm VSE, VSE, VT4 + vadduwm VSF, VSF, SIGA + vadduwm VSG, VSG, SIGE + vadduwm VSH, VSH, VK + + bdnz .loop + + C Repack VSA,VSB,VSC,VSD into VSA,VSE for storing + vmrghw VSA, VSA, VSB + vmrghw VSC, VSC, VSD + vmrghw VSE, VSE, VSF + vmrghw VSG, VSG, VSH + + xxmrghd VSR(VSA), VSR(VSA), VSR(VSC) + xxmrghd VSR(VSE), VSR(VSE), VSR(VSG) + + stxvw4x VSR(VSA), 0, STATE + stxvw4x VSR(VSE), TC16, STATE + + + C Restore nonvolatile registers + li T0, -8 + li T1, -24 + lvx v20, T0, SP + lvx v21, T1, SP + subi T0, T0, 32 + subi T1, T1, 32 + lvx v22, T0, SP + lvx v23, T1, SP + subi T0, T0, 32 + subi T1, T1, 32 + lvx v24, T0, SP + lvx v25, T1, SP + subi T0, T0, 32 + subi T1, T1, 32 + lvx v26, T0, SP + lvx v27, T1, SP + subi T0, T0, 32 + subi T1, T1, 32 + lvx v28, T0, SP + lvx v29, T1, SP + subi T0, T0, 32 + subi T1, T1, 32 + lvx v30, T0, SP + lvx v31, T1, SP + subi T0, T0, 32 + subi T1, T1, 32 + ldx r14, T0, SP + ldx r15, T1, SP + +.done: + mr r3, INPUT + + blr +EPILOGUE(_nettle_sha256_compress_n) + +IF_LE(` +.data +.align 4 +.load_swap: + .byte 8,9,10,11, 12,13,14,15, 0,1,2,3, 4,5,6,7 +') -- 2.45.0

2 4

ANNOUNCE: Nettle-3.10
by Niels Möller 16 Jun '24

16 Jun '24

I'm happy to announce a new release of GNU Nettle, a low-level cryptographics library. This release adds support for RSA-OAEP, and improves performance mainly for powerpc64. See NEWS entries below. The Nettle home page can be found at https://www.lysator.liu.se/~nisse/nettle/, and the manual at https://www.lysator.liu.se/~nisse/nettle/nettle.html. The release can be downloaded from https://ftp.gnu.org/gnu/nettle/nettle-3.10.tar.gz https://www.lysator.liu.se/~nisse/archive/nettle-3.10.tar.gz Happy hacking, /Niels Möller NEWS for the Nettle 3.10 release This is a maintenance release, including a few each of bug fixes, new features and optimizations. The new version is intended to be fully source and binary compatible with Nettle-3.6. The shared library names are libnettle.so.8.9 and libhogweed.so.6.9, with sonames libnettle.so.8 and libhogweed.so.6. Bug fixes: * Add missing hash functions sha512_224 and sha512_256 to the nettle_get_hashes() list. The name values in the corresponding nettle_hash structs also changed to use underscore instead of dash, for consistency. * Fix a few cases of formally undefined calls to memcpy(dst, NULL, 0), resulting from valid calls to, e.g., sha256_update(ctx, 0, NULL). New features: * Support RSA-OAEP encryption. Contributed by Nicolas Mora and Daiki Ueno. * New function sha3_256_shake_output, new functions sha3_128_init, sha3_128_update, sha3_128_shake, sha3_128_shake_output. Contributed by Daiki Ueno. * Added DRBG-CTR with AES256, contributed by Simon Josefsson. Optimizations: * New combined gcm-aes assembly for powerpc64, contributed by Danny Tsen. * New sha256 assembly for powerpc64, contributed by Eric Richter. * Improved performance for powerpc64 AES decrypt, by skipping subkey transformations that don't suit the vncipher instructions. * Add arm64 CPU feature detection for Android and for Apple systems, contributed by Foolbar and Tim Kosse, prespectively. Miscellaneous: * New tests for side-channel silence, based on valgrind. * Delete all md5 assembly code. Delete all sparc32 assembly code. -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance.

1 0

Nettle release plans
by Niels Möller 16 Jun '24

16 Jun '24

I'm thinking about Nettle releases. I think it would be nice to get out a maintenance 3.10 release before summer vacations. (current NEWS file at https://git.lysator.liu.se/nettle/nettle/-/blob/master/NEWS is fairly accurate). After that, there are two different directions: * Try to clean up some of the API issues. This will break the API (and like for previous changes, it could make sense to add foo-compat.h include files that supports old API, to make it easy to upgrade an application to work with the new nettle version, while incrementally adjusting to the new api). It may also break ABI and imply an soname change, or we could keep old symbols working for the case of old applications linking to new libnettle.so (but not the other way round, as documented at https://www.lysator.liu.se/~nisse/nettle/nettle.html#Compatibility). If we go this way, that would be a Nettle-4.0, and it would make sense to me to try to get that done without much new features, and without making it a huge long-term project. * Focus on getting post-quantum algorithms into Nettle. What do you think? Regards, /Niels -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance.

3 6

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

nettle-bugs