OPENSSL_ARMCAP(3ossl)

📦
version 3.5.9 · 6 versions
, in fedora 43, fedora 44

🌸 OPENSSL_ARMCAP 🌸

okay so bestie, welcome to the OpenSSL manual, section 3ossl — this is the one about the Arm processor capabilities vector, and honestly? it's giving "your CPU has a whole secret menu and you can order off it" 💅

✨ NAME ✨

OPENSSL_armcap — the Arm processor capabilities vector 🦋

✨ SYNOPSIS ✨

env OPENSSL_armcap=... <application>

✨ DESCRIPTION ✨

so libcrypto supports a whole range of Arm instruction set extensions, right? and every one of those extensions gets represented by a bit in the Arm processor capabilities vector. when libcrypto initializes, it takes whatever the Arm CPU capabilities detection logic hands back and stores it in that vector. the detection methods are OS-dependent — they're a combo of info the kernel gathered during boot plus probe functions that literally try to execute instructions and catch the illegal instruction signals with a signal handler. iconic behaviour tbh 😭

if you wanna override the set of extensions available to an application, set the OPENSSL_armcap environment variable before you start the application. you assign it a numerical value that denotes the bits in the Arm processor capabilities vector. the arm_arch.h header file defines all the possible values, and they're explained in detail below 🫶

you turn on multiple extensions by logically OR-ing together the values for the extensions you want.

Notes: Attempting to executing an instruction from an extension that the target CPU does not support will result in an illegal instruction exception (SIGILL). 💀

also please note that not all possible values in the Arm processor capabilities vector are actual processor capabilities. some of them are OpenSSL performance preferences for certain implementations that only make sense on specific CPUs. so like, it's a vibe check, not a spec sheet 🌈

the following extensions are defined:

  • 0x0001
    • Name: ARMV7_NEON
    • Meaning: Indicates support for the Armv7 Neon SIMD extensions on the processor.
    • Effect: Enables various Armv7 Neon SIMD implementations.
  • 0x00002
    • Name: ARMV7_TICK
    • Meaning: Indicates support for the Armv7 system timer on the processor.
    • Effect: This is used as a seed for some random number generators.
  • 0x00004
    • Name: ARMV8_AES
    • Meaning: Indicates support for the Armv8.0 AES hardware-acceleration extensions on the processor.
    • Effect: Enables various Armv8.0 AES hardware-accelerated implementations.
  • 0x00008
    • Name: ARMV8_SHA1
    • Meaning: Indicates support for the Armv8.0 SHA1 hardware-acceleration extensions on the processor.
    • Effect: Enables various Armv8.0 SHA1 hardware-accelerated implementations.
  • 0x00010
    • Name: ARMV8_SHA256
    • Meaning: Indicates support for the Armv8.0 SHA256 hardware-acceleration extensions on the processor.
    • Effect: Enables various Armv8.0 SHA256 hardware-accelerated implementations.
  • 0x00020
    • Name: ARMV8_PMULL
    • Meaning: Indicates support for the Armv8.0 polynomial multiplication hardware-acceleration extensions on the processor.
    • Effect: Used to hardware-accelerate polynomial multiplication, for example in AES-GCM.
  • 0x00040
    • Name: ARMV8_SHA512
    • Meaning: Indicates support for the Armv8.2 SHA512 hardware-acceleration extensions on the processor.
    • Effect: Enables Armv8.2 SHA512 hardware-accelerated implementations.
  • 0x00080
    • Name: ARMV8_CPUID
    • Meaning: Indicates support for the Armv8.0 hardware identification extensions on the processor.
    • Effect: Allows implementations to change their behaviour, dependant on the processor platform in order to achieve better performance.
  • 0x00100
    • Name: ARMV8_RNG
    • Meaning: Indicates support for the Armv8.5 hardware random number generation extensions on the processor.
    • Effect: Enables hardware random number generation on supported AArch64 processors.
  • 0x00200
    • Name: ARMV8_SM3
    • Meaning: Indicates support for the Armv8.2 SM3 hardware-acceleration extensions on the processor.
    • Effect: Enables Armv8.2 SM3 hardware-accelerated implementations.
  • 0x00400
    • Name: ARMV8_SM4
    • Meaning: Indicates support for the Armv8.2 SM4 hardware-acceleration extensions on the processor.
    • Effect: Enables Armv8.2 SM4 hardware-accelerated implementations.
  • 0x00800
    • Name: ARMV8_SHA3
    • Meaning: Indicates support for the Armv8.2 SHA3 hardware-acceleration extensions on the processor.
    • Effect: Enables SHA3 hardware-accelerated implementations (see also ARMV8_HAVE_SHA3_AND_WORTH_USING).
  • 0x01000
    • Name: ARMV8_UNROLL8_EOR3
    • Meaning: Indicates support for the Arm EOR3 instruction, which is a part of the Armv8.2 SHA3 extensions, and enables 8x Loop unrolling in the AES-CTR implementation.
    • Effect: Enables the 8x loop unrolling utilising EOR3 implementation of AES-CTR on platforms that support the SHA3 extension and have enough vector bandwidth.
  • 0x02000
    • Name: ARMV8_SVE
    • Meaning: Indicates support for the Armv8.2 SVE hardware extension on the processor.
    • Effect: Enables various Armv8.2 SVE implementations.
  • 0x04000
    • Name: ARMV9_SVE2
    • Meaning: Indicates support for the Armv9.0 SVE2 hardware extension on the processor.
    • Effect: Enables various Armv9.0 SVE2 implementations.
  • 0x08000
    • Name: ARMV8_HAVE_SHA3_AND_WORTH_USING
    • Meaning: Indicates support for the Armv8.2 SHA3 hardware-acceleration extensions on the processor, and that the hardware bandwidth is sufficient for it to be worth using.
    • Effect: On certain Apple platforms, although the SHA3 extension is supported, it is actually slower than other implementations. This flag disables the hardware-accelerated SHA3 implementations on these platforms.
  • 0x10000
    • Name: ARMV8_UNROLL12_EOR3
    • Meaning: Indicates support for the Arm EOR3 instruction, which is a part of the Armv8.2 SHA3 extensions, and enables 12x loop unrolling in the AES-CTR implementation.
    • Effect: Enables the 12x loop unrolling utilising EOR3 implementation of AES-CTR on platforms that support the extension and have enough vector bandwidth.
  • 0x20000
    • Name: ARMV9_SVE2_POLY1305
    • Meaning: Indicates support for the Armv9.0 SVE2 hardware extension, and enables its use in the Poly1305 implementation.
    • Effect: Enables the Armv9.0 SVE2 Poly1305 implementation if SVE2 is enabled, the vector length is greater than 128 bits, and the vector length is a power of 2.

✨ RETURN VALUES ✨

Not available. 🙈 (it's a manpage about an env var bestie, there's nothing to return, we're just vibing)

✨ EXAMPLES ✨

wanna check the capabilities that are currently detected? say less 👑

$ openssl info -cpusettings
OPENSSL_armcap=0x987d

the detected capabilities in the above example indicate that ARMV7_NEON, ARMV8_AES, ARMV8_SHA1, ARMV8_SHA256, ARMV8_PMULL, ARMV8_SHA512, ARMV8_SHA3, ARMV8_UNROLL8_EOR3, and ARMV8_HAVE_SHA3_AND_WORTH_USING are enabled. look at her go ✨

and if you wanna disable all the instruction set extensions:

export OPENSSL_armcap=0x00

nuclear option fr fr 💀

Copyright 2026 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the "License"). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

okay that's the whole page bestie 🎀 this was version 3.5.9, dated 2026-09-29, and it's the OPENSSL_ARMCAP page from the OpenSSL 3ossl manual. go forth and probe your CPU's capabilities responsibly, mwah 💖🦋

📦 where this page comes from