AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Informational 16 Bitcoin

hashes: add SHA256 ARM hardware acceleration

Public commit record

What the developer wrote

Authored by jrakibi

76/100 · Adequate
hashes: add SHA256 ARM hardware acceleration

rust-bitcoin/rust-bitcoin#1962 added SIMD SHA256 intrinsics for x86 machines. However, for
ARM machines we're still falling back to software_process_block(),
which is ~4x slower.

This adds support for ARM SHA2 crypto extensions. The code is
inspired by https://github.com/noloader/SHA-Intrinsics/blob/4e754bec921a9f281b69bd681ca0065763aa911c/sha256-arm.c.
variable names are kept the same for easier review and comparison.

I did benchmarks on an AWS EC2 (t4g.small, Neoverse-N1):

for 65kb:
- without ARM: 266.71 µs
- with ARM: 55.956 µs

That's almost ~5x faster for larger blocks.
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
The short version

What changed, and why it matters

This commit adds a faster way to calculate SHA-256 hashes on modern 64-bit ARM processors (like Apple's M chips, AWS Graviton, and recent smartphones) by using built-in CPU instructions called ARM SHA2 crypto extensions. It mirrors an earlier change that did the same thing for x86 processors. There is no indication in the commit that this fixes a security bug; it is a performance improvement.

Recommended action

Treat as a routine performance optimization, not a security patch. If reviewing for security, verify that the unsafe block's preconditions (16-word state buffer, 64-byte input block, correct alignment) are upheld by the surrounding `HashEngine` code and that the runtime feature detection correctly prevents executing sha2 instructions on CPUs without the extension. Consider adding targeted test vectors that exercise both the ARM intrinsic and fallback paths on aarch64 CI runners.

Security signals we found

01

New unsafe code using architecture-specific intrinsics

02

Runtime CPU feature detection before executing target-feature-specific code

03

Translation of third-party cryptographic reference code into Rust

04

No bounds checking visible inside the unsafe intrinsic block (relies on caller invariants and fixed-size buffer)

Risk score

Why this scored 16/100

Our methodology →
Potential impact 0/30
Exploitability 0/25
Stealth signal 0/15
Affected reach 5/15
Confidence 8/10
Evidence quality 3/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.