Revert "Disable aws-lc-sys jitter entropy to avoid startup SIGABRT" - #6795
Merged
Conversation
This reverts commit 6e8ecec. The SIGABRT it targeted was not CPU jitter entropy. The crash is aws-lc aborting when the arm64 RNDR instruction fails: some hosts advertise FEAT_RNG via ID_AA64ISAR0_EL1.RNDR while the instruction never actually returns entropy, and aws-lc abort()s instead of falling back to a software source. Disabling jitter entropy does not avoid that. It only changes which callback the hardware RNG backs, and so which abort fires. With CPU jitter enabled, RNDR backs get_prediction_resistance and the process aborts in rand.c:259; with it disabled, RNDR backs get_extra_entropy and it aborts in rand.c:294. Both are fatal, and the crashes continued after this commit landed. The mitigation is OPENSSL_armcap=~0x20000, which clears ARMV8_RNG at runtime so aws-lc routes around RNDR. That belongs in the deployment rather than the build, and is applied there. Signed-off-by: Gerd Zellweger <mail@gerdzellweger.com>
gz
enabled auto-merge
August 3, 2026 23:16
blp
approved these changes
Aug 3, 2026
mythical-fred
approved these changes
Aug 4, 2026
mythical-fred
left a comment
There was a problem hiding this comment.
The commit-message writeup is the actual review here: RNDR failing is fatal in both entropy source configurations because have_hw_rng_aarch64() gates both callbacks, so the original AWS_LC_SYS_NO_JITTER_ENTROPY=1 only shifted which abort site fires. The mitigation belongs in the deployment (OPENSSL_armcap=~0x20000) rather than the build. Approving the revert.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Reverts the
AWS_LC_SYS_NO_JITTER_ENTROPY=1build setting. The diagnosis behindit was most likely wrong, and it does not prevent the crash it targeted.
What actually aborts
The silent
SIGABRTduring the first TLS handshake is aws-lc's entropy sourceaborting when the arm64
RNDRinstruction fails, not the CPU jitter entropyhealth check.
Some Google Cloud arm64 hosts advertise
FEAT_RNGviaID_AA64ISAR0_EL1.RNDRbut the instruction never returns entropy. Measured in-process on a GKE
n4a-highcpu-8(Axion) node:/proc/cpuinfoFeaturesrngOPENSSL_armcap_P0x3887d, soARMV8_RNG(bit 17) is setrndr_multiple8(buf, 8)CRYPTO_rndr_multiple8(buf, 48)aws-lc selects the hardware RNG because capability detection says it exists, then
abort()s when it fails, with no fallback and nothing written to stderr. Locatedby breakpointing every branch feeding the tail-merged
bl abortinrand_bytes_implon a live crashing process.This is per-instance rather than per-machine-type: a sibling node of the same
type ran the same binary and workload fine, and its
rndr_multiple8returns 1.Why disabling jitter entropy does not help
RNDRis fatal in both entropy source configurations. The flag only changeswhich callback the hardware RNG backs, and therefore which abort fires:
get_extra_entropyget_prediction_resistanceentropy_os_get_extra_entropyentropy_cpu_get_prediction_resistance(RNDR)rand.c:259NO_JITTER_ENTROPY=1entropy_cpu_get_extra_entropy(RNDR)NULLrand.c:294Both branch on the same
have_hw_rng_aarch64(). Consistent with this, thecrashes continued after the reverted commit landed.
The upstream issue the original commit matched against (aws/aws-lc-rs#1072) is a
different failure: it aborts in
tree_jitter_initialize_onceon Windows, whereasthese backtraces are in
rand_bytes_impl.Mitigation
OPENSSL_armcap=~0x20000clearsARMV8_RNGat runtime, after which bothconfigurations route around
RNDR. Verified against the pipeline binary:OPENSSL_armcap_PRAND_bytes0x3887dOPENSSL_armcap=~0x200000x1887dThat is a runtime setting and belongs in the deployment rather than the build, so
it is applied there instead of in this repo.
A bug report is going upstream to aws-lc asking it to fall back rather than abort
when a probed hardware RNG fails, and to retry
RNDRthe way the x86 path alreadyretries
RDRAND(rdrand_multiple8retries 10 times;rndr_multiple8does notretry at all, though Arm documents
RNDRas permitted to fail transiently).