elf_aux_info() returns an errno value (0 on success) rather than -1 with errno set. Ignoring the return value means the result is unreliable on failure. Treat a failure as "no features reported" so the generic code is used.
Signed-off-by: Brad Smith brad@comstyle.com --- fat-arm64.c | 3 ++- fat-ppc.c | 6 ++++-- 2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/fat-arm64.c b/fat-arm64.c index 36136078..e5b8a93b 100644 --- a/fat-arm64.c +++ b/fat-arm64.c @@ -141,7 +141,8 @@ get_arm64_features (struct arm64_features *features) #if USE_GETAUXVAL hwcap = getauxval(AT_HWCAP); #elif defined(HAVE_ELF_AUX_INFO) - elf_aux_info(AT_HWCAP, &hwcap, sizeof(hwcap)); + if (elf_aux_info(AT_HWCAP, &hwcap, sizeof(hwcap)) != 0) + hwcap = 0; #endif
features->have_aes diff --git a/fat-ppc.c b/fat-ppc.c index 39ba6a3d..52514e0a 100644 --- a/fat-ppc.c +++ b/fat-ppc.c @@ -130,8 +130,10 @@ get_ppc_features (struct ppc_features *features) hwcap = getauxval(AT_HWCAP); hwcap2 = getauxval(AT_HWCAP2); # elif defined(HAVE_ELF_AUX_INFO) - elf_aux_info(AT_HWCAP, &hwcap, sizeof(hwcap)); - elf_aux_info(AT_HWCAP2, &hwcap2, sizeof(hwcap2)); + if (elf_aux_info(AT_HWCAP, &hwcap, sizeof(hwcap)) != 0) + hwcap = 0; + if (elf_aux_info(AT_HWCAP2, &hwcap2, sizeof(hwcap2)) != 0) + hwcap2 = 0; # elif defined(__FreeBSD__) size_t len; len = sizeof(hwcap);
On Sun, Oct 4, 2026, 10:16 AM Brad Smith brad@comstyle.com wrote:
elf_aux_info() returns an errno value (0 on success) rather than -1 with errno set. Ignoring the return value means the result is unreliable on failure. Treat a failure as "no features reported" so the generic code is used.
I agree this bug should be fixed as soon as possible so one can take advantage of high performance path on supported hardware.
best regards, Mamone
Signed-off-by: Brad Smith brad@comstyle.com
fat-arm64.c | 3 ++- fat-ppc.c | 6 ++++-- 2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/fat-arm64.c b/fat-arm64.c index 36136078..e5b8a93b 100644 --- a/fat-arm64.c +++ b/fat-arm64.c @@ -141,7 +141,8 @@ get_arm64_features (struct arm64_features *features) #if USE_GETAUXVAL hwcap = getauxval(AT_HWCAP); #elif defined(HAVE_ELF_AUX_INFO)
elf_aux_info(AT_HWCAP, &hwcap, sizeof(hwcap));
if (elf_aux_info(AT_HWCAP, &hwcap, sizeof(hwcap)) != 0)hwcap = 0;#endif
features->have_aesdiff --git a/fat-ppc.c b/fat-ppc.c index 39ba6a3d..52514e0a 100644 --- a/fat-ppc.c +++ b/fat-ppc.c @@ -130,8 +130,10 @@ get_ppc_features (struct ppc_features *features) hwcap = getauxval(AT_HWCAP); hwcap2 = getauxval(AT_HWCAP2); # elif defined(HAVE_ELF_AUX_INFO)
elf_aux_info(AT_HWCAP, &hwcap, sizeof(hwcap));elf_aux_info(AT_HWCAP2, &hwcap2, sizeof(hwcap2));
if (elf_aux_info(AT_HWCAP, &hwcap, sizeof(hwcap)) != 0)hwcap = 0;if (elf_aux_info(AT_HWCAP2, &hwcap2, sizeof(hwcap2)) != 0)hwcap2 = 0;# elif defined(__FreeBSD__) size_t len; len = sizeof(hwcap); -- 2.55.0
nettle-bugs mailing list -- nettle-bugs@lists.lysator.liu.se To unsubscribe send an email to nettle-bugs-leave@lists.lysator.liu.se
Brad Smith brad@comstyle.com writes:
elf_aux_info() returns an errno value (0 on success) rather than -1 with errno set. Ignoring the return value means the result is unreliable on failure. Treat a failure as "no features reported" so the generic code is used.
The variables are explicitly initialized to zero. I would expected that elf_aux_info leaves them unchanged on failure, i.e., they stay zero.
So I'm curious both on the conditions that might make an elf_aux_info call for AT_HWCAP or AT_HWCAP2 fail, and if it really clobbers the output buffer on failure (which seems like a rather rude api to me)?
Regards, /Niels
On Mon, Oct 5, 2026 at 11:58 AM Niels Möller nisse@lysator.liu.se wrote:
Brad Smith brad@comstyle.com writes:
elf_aux_info() returns an errno value (0 on success) rather than -1 with errno set. Ignoring the return value means the result is unreliable on failure. Treat a failure as "no features reported" so the generic code is used.
The variables are explicitly initialized to zero. I would expected that elf_aux_info leaves them unchanged on failure, i.e., they stay zero.
the variables were never initialized to zero. I believe there's a paper on iacr ePrint that describes this function, but it's temporarily unavailable because the author requested a metadata change and iacr only processes these requests via email.
So I'm curious both on the conditions that might make an elf_aux_info call for AT_HWCAP or AT_HWCAP2 fail, and if it really clobbers the output buffer on failure (which seems like a rather rude api to me)?
Regards, /Niels
-- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance. _______________________________________________ nettle-bugs mailing list -- nettle-bugs@lists.lysator.liu.se To unsubscribe send an email to nettle-bugs-leave@lists.lysator.liu.se
Maamoun TK maamoun.tk@googlemail.com writes:
the variables were never initialized to zero.
Current code:
fat-arm64.c:
--> unsigned long hwcap = 0;
#if USE_GETAUXVAL hwcap = getauxval(AT_HWCAP); #elif defined(HAVE_ELF_AUX_INFO) elf_aux_info(AT_HWCAP, &hwcap, sizeof(hwcap)); #endif
fat-ppc.c:
--> unsigned long hwcap = 0; --> unsigned long hwcap2 = 0; # if USE_GETAUXVAL hwcap = getauxval(AT_HWCAP); hwcap2 = getauxval(AT_HWCAP2); # elif defined(HAVE_ELF_AUX_INFO) elf_aux_info(AT_HWCAP, &hwcap, sizeof(hwcap)); elf_aux_info(AT_HWCAP2, &hwcap2, sizeof(hwcap2)); # elif defined(__FreeBSD__) size_t len; len = sizeof(hwcap); sysctlbyname("hw.cpu_features", &hwcap, &len, NULL, 0); len = sizeof(hwcap2); sysctlbyname("hw.cpu_features2", &hwcap2, &len, NULL, 0);
So I think this should work, under the assumption that elf_aux_info and sysctlbyname don't clobber their output buffers on error. Am I missing something?
Regards, /Niels
Hi Niels,
I ran into this bug when I deployed the library on ARM environment, have you got the chance to debug the issue? I also wonder if my design proposal fixes it properly.
best regards, Mamone
On Mon, Oct 5, 2026, 1:39 PM Niels Möller nisse@lysator.liu.se wrote:
Maamoun TK maamoun.tk@googlemail.com writes:
the variables were never initialized to zero.
Current code:
fat-arm64.c:
--> unsigned long hwcap = 0;
#if USE_GETAUXVAL hwcap = getauxval(AT_HWCAP); #elif defined(HAVE_ELF_AUX_INFO) elf_aux_info(AT_HWCAP, &hwcap, sizeof(hwcap)); #endif
fat-ppc.c:
--> unsigned long hwcap = 0; --> unsigned long hwcap2 = 0; # if USE_GETAUXVAL hwcap = getauxval(AT_HWCAP); hwcap2 = getauxval(AT_HWCAP2); # elif defined(HAVE_ELF_AUX_INFO) elf_aux_info(AT_HWCAP, &hwcap, sizeof(hwcap)); elf_aux_info(AT_HWCAP2, &hwcap2, sizeof(hwcap2)); # elif defined(__FreeBSD__) size_t len; len = sizeof(hwcap); sysctlbyname("hw.cpu_features", &hwcap, &len, NULL, 0); len = sizeof(hwcap2); sysctlbyname("hw.cpu_features2", &hwcap2, &len, NULL, 0);
So I think this should work, under the assumption that elf_aux_info and sysctlbyname don't clobber their output buffers on error. Am I missing something?
Regards, /Niels
-- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance.
Maamoun TK maamoun.tk@googlemail.com writes:
I ran into this bug when I deployed the library on ARM environment, have you got the chance to debug the issue?
I would like to understand what the problem is. Can you confirm that elf_aux_val clobbers its output on error, or otherwise explain why hwcap doesn't stay zero?
To repeat, it is initialized to zero, and my expectation is that it is changed to non-zero only when elf_aux_info (or getauxval or sysctlbyname) successfully retrieves the attribute.
Regards, /Niels
On Tue, Oct 13, 2026 at 7:52 AM Niels Möller nisse@lysator.liu.se wrote:
Maamoun TK maamoun.tk@googlemail.com writes:
I ran into this bug when I deployed the library on ARM environment, have you got the chance to debug the issue?
I would like to understand what the problem is. Can you confirm that elf_aux_val clobbers its output on error, or otherwise explain why hwcap doesn't stay zero?
To repeat, it is initialized to zero, and my expectation is that it is changed to non-zero only when elf_aux_info (or getauxval or sysctlbyname) successfully retrieves the attribute.
Just so I understand, you want to implement a helper function that directly calls elf_aux_info and temporarily holds hwcap value?
Regards, /Niels
-- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance.
On 10/13/26 3:29 AM, Maamoun TK wrote:
On Tue, Oct 13, 2026 at 7:52 AM Niels Möller nisse@lysator.liu.se wrote:
Maamoun TK maamoun.tk@googlemail.com writes:
I ran into this bug when I deployed the library on ARM environment, have you got the chance to debug the issue?
I would like to understand what the problem is. Can you confirm that elf_aux_val clobbers its output on error, or otherwise explain why hwcap doesn't stay zero?
To repeat, it is initialized to zero, and my expectation is that it is changed to non-zero only when elf_aux_info (or getauxval or sysctlbyname) successfully retrieves the attribute.
Just so I understand, you want to implement a helper function that directly calls elf_aux_info and temporarily holds hwcap value?
What's the actual bug here? Looking at FreeBSD it appears to be implemented to only modify the input buffer on success and return the direct "errno" as the functions return value.
Code: - https://github.com/freebsd/freebsd-src/blob/main/lib/libsys/auxv.c#L276
man: - https://man.openbsd.org/elf_aux_info.3
Regards, /Niels
-- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance.
nettle-bugs mailing list -- nettle-bugs@lists.lysator.liu.se To unsubscribe send an email to nettle-bugs-leave@lists.lysator.liu.se
Bill Roberts bill.roberts@foss.arm.com writes:
What's the actual bug here? Looking at FreeBSD it appears to be implemented to only modify the input buffer on success and return the direct "errno" as the functions return value.
I'm also puzzled. I'm not opposed to making changes to Nettle's logic here, as proposed in the original patch, but I would like to understand how things go wrong, to be able to fix it with confidence.
Code: - https://github.com/freebsd/freebsd-src/blob/main/lib/libsys/auxv.c#L276
I actually see one case where buffer is modified also on failure, but that is for the handling of AT_EXECPATH (unrelated to Nettle's usage), if its strlcpy call detects that the provided buffer is too small.
Regards, /Niels
On 2026-10-05 5:58 a.m., Niels Möller wrote:
Brad Smithbrad@comstyle.com writes:
elf_aux_info() returns an errno value (0 on success) rather than -1 with errno set. Ignoring the return value means the result is unreliable on failure. Treat a failure as "no features reported" so the generic code is used.
The variables are explicitly initialized to zero. I would expected that elf_aux_info leaves them unchanged on failure, i.e., they stay zero.
So I'm curious both on the conditions that might make an elf_aux_info call for AT_HWCAP or AT_HWCAP2 fail, and if it really clobbers the output buffer on failure (which seems like a rather rude api to me)?
I was specifically asked by another FreeBSD/OpenBSD developer to instate the error checking as the contract with the API does not guarantee not writing to the buffer.
I specifically made a comment along the lines you did and was told..
"That's an implementation detail, not an API guarantee."
On 10/14/26 2:32 PM, Brad Smith wrote:
On 2026-10-05 5:58 a.m., Niels Möller wrote:
Brad Smithbrad@comstyle.com writes:
elf_aux_info() returns an errno value (0 on success) rather than -1 with errno set. Ignoring the return value means the result is unreliable on failure. Treat a failure as "no features reported" so the generic code is used.
The variables are explicitly initialized to zero. I would expected that elf_aux_info leaves them unchanged on failure, i.e., they stay zero.
So I'm curious both on the conditions that might make an elf_aux_info call for AT_HWCAP or AT_HWCAP2 fail, and if it really clobbers the output buffer on failure (which seems like a rather rude api to me)?
I was specifically asked by another FreeBSD/OpenBSD developer to instate the error checking as the contract with the API does not guarantee not writing to the buffer.
I specifically made a comment along the lines you did and was told..
"That's an implementation detail, not an API guarantee."
That makes more sense. The initial "patch" came through with a description and just some ASCII art arrows, not really a patch, and that was a bit vague for me.
Are there three discrete things going on here? 1. The possibility of the output buffer for elf_aux_info being clobbered on error 2. The lack of error checking on the return value for elf_aux_info 3. The need for hwcaps2
Is that right?
It's also not clear what they need from hwcaps2 to enable what feature.
Anyway to just clear this up and get a patch series for this?
Thanks, Bill
<snip>
That makes more sense. The initial "patch" came through with a description and just some ASCII art arrows, not really a patch, and that was a bit vague for me.
Are there three discrete things going on here?
- The possibility of the output buffer for elf_aux_info being
clobbered on error 2. The lack of error checking on the return value for elf_aux_info 3. The need for hwcaps2
Is that right?
It's also not clear what they need from hwcaps2 to enable what feature.
Anyway to just clear this up and get a patch series for this?
Sorry Brad, I see the patch now. I didn't go back in time far enough. This does make sense to me. I don't have a test machine with this environment at the moment, but LGTM FWIW.
Thanks, Bill
On 2026-10-14 3:32 p.m., Brad Smith wrote:
On 2026-10-05 5:58 a.m., Niels Möller wrote:
Brad Smithbrad@comstyle.com writes:
elf_aux_info() returns an errno value (0 on success) rather than -1 with errno set. Ignoring the return value means the result is unreliable on failure. Treat a failure as "no features reported" so the generic code is used.
The variables are explicitly initialized to zero. I would expected that elf_aux_info leaves them unchanged on failure, i.e., they stay zero.
So I'm curious both on the conditions that might make an elf_aux_info call for AT_HWCAP or AT_HWCAP2 fail, and if it really clobbers the output buffer on failure (which seems like a rather rude api to me)?
I was specifically asked by another FreeBSD/OpenBSD developer to instate the error checking as the contract with the API does not guarantee not writing to the buffer.
I specifically made a comment along the lines you did and was told..
"That's an implementation detail, not an API guarantee."
Also I wrote the code the way I did as it mimics the behavior of getauxval().
nettle-bugs@lists.lysator.liu.se
-
Bill Roberts -
Brad Smith -
Maamoun TK -
Niels Möller