nettle-bugs

nettle-bugs@lists.lysator.liu.se

2 participants
2194 discussions

[PATCH] SLH-DSA
by Zoltan Fridrich 17 Feb '25

17 Feb '25

Hello, I would like to contribute an implementation of SLH-DSA to Nettle. The implementation is based off of the reference sphincs+ implementation and leancrypto slh-dsa implementation. Included tests contain test vectors from leancrypto slh-dsa tests. Could you please review the attached patch and give me your feedback? Kind regards, Zoltan

4 15

FOSDEM 2025
by Niels Möller 29 Jan '25

29 Jan '25

Hi, I just want to say that I'm going to FOSDEM this year. I will also do a talk in the security devroom on Saturday, https://fosdem.org/2025/schedule/event/fosdem-2025-5661-sigsum-detecting-ro… Regards, /Niels -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance.

1 0

ANNOUNCE: Nettle-3.10.1
by Niels Möller 30 Dec '24

30 Dec '24

I'm happy to announce a new release of GNU Nettle, a low-level cryptographics library. This release includes a few bug fixes and portability improvements. See NEWS entries below. Users of powerpc64 are adviced to upgrade; the bugs in the powerpc64 sha256 assembly of nettle-3.10 has the potential to cause crashes due to invalid memory read accesses. It's unclear if it could be exploitable, but it seems unlikely that any exploit could do worse than denial of service. 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.1.tar.gz https://www.lysator.liu.se/~nisse/archive/nettle-3.10.1.tar.gz Happy hacking, /Niels Möller NEWS for the Nettle 3.10.1 release This is a maintenance release, with only a few bugfixes and portability improvements. The new version is intended to be fully source and binary compatible with Nettle-3.6. The shared library names are libnettle.so.8.10 and libhogweed.so.6.10, with sonames libnettle.so.8 and libhogweed.so.6. Bug fixes: * Fix buffer overread in the new sha256 assembly for powerpc64, as well as a stack alignment issue. * Added missing nettle_mac structs for hmac-gosthash. * Fix configure test for valgrind, to not attempt to run valgrind on executables built using memory sanitizers. Optimizations: * Improved runtime detection of cpu features for OpenBSD and FreeBSD, using elf_aux_info when available. This also adds runtime detection for FreeBSD on arm64. Contributed by Brad Smith. -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance.

1 0

[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

Jump to page:

2025

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