Skip to content

Pre-key locks on 64 KiB pages: per-target block alignment; open 0.9.0-rc.14 - #266

Merged
Slurp9187 merged 1 commit into
mainfrom
prekey-page-align
Oct 19, 2026
Merged

Slurp9187 merged 1 commit into
mainfrom
prekey-page-align

Conversation

@Slurp9187

Copy link
Copy Markdown
Owner

Follow-up to #265 (sealed memory, shipped in 0.9.0-rc.13), from the review of that release.

The pre-key block was aligned to 16 KiB everywhere, and on a page larger than that the lock was refused (Prekey::lock_status() reported it). It now takes its alignment from a per-target table after the secrets crate (1.3.0, src/secret.rs; added there after its own unlock-a-neighbour bug, #109), with the pre-key's 16 KiB as the floor:

Target Alignment
x86, x86_64 16 KiB
aarch64 Apple 16 KiB
aarch64 other 64 KiB
anything else 64 KiB (ppc64le's default page is 64 KiB)

The block owns every page it touches, so locking it locks nothing else and unlocking it on drop cannot release a neighbour's lock. On 64 KiB-aligned targets a Prekey takes 64 KiB, all locked; only the first 16 KiB hold the pre-key. The page-size refusal stays as the fallback for any target the table gets wrong. Compile-time assertions pin that the block holds the pre-key and fills whole aligned units; the tests now use the block's alignment instead of a hard-coded 16 KiB.

Also opens 0.9.0-rc.14 (manifest, lockfile, README pins, CHANGELOG Unreleased section) and updates SECURITY.md §3, the sealed module docs and the design note.

Checked

  • Local gate script, 40/40 green (-D warnings, stable 1.98.1; trybuild on 1.85; rustdoc stable, nightly docsrs and --features=full; thumbv7em; residue-probe).
  • Cross-compiled the library with sealed for x86_64 Windows / Linux / macOS, aarch64 Linux / macOS and ppc64le Linux, each with a scratch compile-time assertion of that target's promised alignment and block size; flipping aarch64 Linux's expectation fails the build.

Not checked

  • No 64 KiB-page hardware was available, so the 64 KiB path is verified by compilation, not by running.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Jd6eJgv7urGn4rvMcVASo2

…s; open 0.9.0-rc.14

The block was aligned to 16 KiB everywhere and a larger page was refused. It now takes its
alignment from a per-target table after the secrets crate (1.3.0, src/secret.rs): 16 KiB on
x86, x86_64 and Apple aarch64, 64 KiB on other aarch64 and any unlisted target, with the
pre-key's 16 KiB as the floor. The block owns every page it touches, so the lock and the
unlock reach nothing else. The page-size refusal stays as the fallback. Cross-compiled for
six targets with each alignment asserted at compile time; not run on 64 KiB-page hardware.

Suggested by the sealed-memory review.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jd6eJgv7urGn4rvMcVASo2
@Slurp9187
Slurp9187 merged commit 792c151 into main Oct 19, 2026
49 checks passed
@Slurp9187
Slurp9187 deleted the prekey-page-align branch October 19, 2026 06:53
Slurp9187 added a commit that referenced this pull request Oct 19, 2026
- LockError::page_too_large says the bound is the block's alignment, not the pre-key.
- Prekey::new documents that an unoptimized build stages the block on the stack.
- Drop a const assertion that cannot fail (size is always a multiple of alignment).
- The lock-success unit test skips a host whose page exceeds the block's alignment
  instead of clamping the size and locking a page it shares.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jd6eJgv7urGn4rvMcVASo2
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant