Skip to content

cpu_arm_linux.c and cpu_aarch64_linux.c unconditionally require getauxval / <sys/auxv.h> #3188

@justsmth

Description

@justsmth

Problem:

crypto/fipsmodule/cpucap/cpu_arm_linux.c and crypto/fipsmodule/cpucap/cpu_aarch64_linux.c unconditionally #include <sys/auxv.h> and call getauxval. These are glibc extensions also provided by musl and recent uclibc-ng, but not by older uclibc/uclibc-ng, which causes a hard build failure:

.../cpu_arm_linux.c:10:10: fatal error: sys/auxv.h: No such file or directory
   10 | #include <sys/auxv.h>
      |          ^~~~~~~~~~~~

Reported downstream for a uclibc-based armv7-unknown-linux-uclibceabihf target: aws/aws-lc-rs#1108

Users can work around this by defining OPENSSL_STATIC_ARMCAP, but that isn't easily discoverable and users hit the build failure first.

There's already precedent for gating getauxval behind a feature macro in crypto/rand_extra/urandom.c (OPENSSL_HAS_GETAUXVAL), but it's keyed only off __GLIBC_PREREQ and so doesn't help non-glibc libcs that might lack getauxval. Generalizing that pattern (e.g. via a CMake build-time probe) and applying it to the ARM/AArch64 cpucap sources with a fallback to /proc/self/auxv or /proc/cpuinfo when getauxval is unavailable would let these targets build out of the box while preserving runtime detection where possible.

Related Issues:

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions