OPENSSL_ARMCAP(3SSL)

📦
version 4.0.3 · 3 versions
, in ubuntu stonking

💅 OPENSSL_ARMCAP 💅

okay bestie, welcome to OPENSSL_ARMCAP(3SSL) — yes that's the real manual page name, and yes we're gonna make it cute. This is the whole tea on the Arm processor capabilities vector. Sit down, grab a boba, let's go. 🧋✨

✨ 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, and each one of those extensions is literally just a bit in the Arm processor capabilities vector. That's it. That's the vibe. 👑

When libcrypto initializes, it takes the results that came back from the Arm CPU capabilities detection logic and stores them right into the Arm processor capabilities vector. The CPU capabilities detection methods are OS-dependent, bestie — they use a combo of info the kernel gathered during boot plus probe functions that attempt to execute instructions and trap the illegal instruction signals with a signal handler. Sneaky but iconic. 😭

Wanna override the set of extensions available to an application? Easy. Set the OPENSSL_armcap environment variable before starting 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. 🫶

Multiple extensions get enabled by logically OR-ing the values that represent the desired extensions.

Notes: Attempting to execute an instruction from an extension that the target CPU does not support will result in an illegal instruction exception (SIGILL). 💀
Also please note: not all possible values in the Arm processor capabilities vector are actual processor capabilities. Some values represent OpenSSL performance preferences for some implementations which only make sense on specific CPUs. So like, read the labels, bestie, don't just yolo it. 🙈

The following extensions are defined:

🌈 The extensions 🌈

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. (the way that "supported but not worth it" is a whole mood 😭)

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. That's it. Nothing to report, bestie. 🫥

⭐ EXAMPLES ⭐

Wanna check the capabilities currently detected? Run this:

$ 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. 👑

Wanna disable all instruction set extensions instead? Say less:

export OPENSSL_armcap=0x00

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>.

k that's the whole page, no cap. This was OPENSSL_ARMCAP from version 4.0.3, dated 2026-09-29 — literally iconic behavior, slay, and go check your OPENSSL_armcap before you go 💅💖✨

📦 where this page comes from