-
Notifications
You must be signed in to change notification settings - Fork 0
arc4random_buf() error path silently swallowed on macOS #49
Copy link
Copy link
Open
Labels
area/platformTile topology, shared-memory flow, supervisor processes, crash-only isolationTile topology, shared-memory flow, supervisor processes, crash-only isolationarea/securityCapability envelopes, deny-by-default, policy model, scope dimensions, sandbox isolationCapability envelopes, deny-by-default, policy model, scope dimensions, sandbox isolationpriority/P1-highBroken, no workaround, urgentBroken, no workaround, urgenttype/bugSomething isn't workingSomething isn't working
Milestone
Description
Metadata
Metadata
Assignees
Labels
area/platformTile topology, shared-memory flow, supervisor processes, crash-only isolationTile topology, shared-memory flow, supervisor processes, crash-only isolationarea/securityCapability envelopes, deny-by-default, policy model, scope dimensions, sandbox isolationCapability envelopes, deny-by-default, policy model, scope dimensions, sandbox isolationpriority/P1-highBroken, no workaround, urgentBroken, no workaround, urgenttype/bugSomething isn't workingSomething isn't working
Bug Description
`ulong*` → `uint64_t*` casts on fiat-crypto function calls violate strict aliasing rules. When struct fields of type `ulong*` (defined as `typedef unsigned long` in `src/util/fd_util_base.h:325`) are cast to `uint64_t*` and passed to `fiat_` functions, the compiler assumes the `uint64_t` pointer only aliases `uint64_t` data. Under `-O3 -ffast-math`, the compiler may reorder or deduplicate loads, silently corrupting cryptographic arithmetic.
Affected Files
Call Sites
All call `fiat_bn254_`, `fiat_bn254_scalar_`, and `fiat_25519_` with `(uint64_t)r->limbs` or `(uint64_t*)r->el` casts:
The struct members `limbs` and `el` are `ulong*`, not `uint64_t*`.
Impact
Historical Context
This exact issue caused a regression that was reverted in PR #801 (`uint64_t*` → `ulong*` strict aliasing regression). The revert suggests the correct fix was not found — the casts remain and the underlying aliasing problem persists.
Proposed Fix Direction
Use `(void*)(uintptr_t)` cast as an intermediate step, or restructure types to use `uint64_t*` consistently, or add `attribute((may_alias))` to the type definition. The key is that the cast must not create an intermediate typed pointer that the compiler can reason about for aliasing purposes.
Source
Reviewed from `doc/execution/testing/audit-macos.md` (audit of V2.22.S1 platform port PR).
Migrated from deeprnd/tickoni-archive#803