crypto: random APIs fail closed instead of falling back to the cycle counter #155

Open
nonos-sync wants to merge 3 commits from nonos-sync/gh-614 into main AGit
Member

@eKisNonos

The infallible random APIs fell back to cycle-counter-derived values when the DRBG wasn't up or a hardware source failed. Keys, nonces, seeds and canaries are drawn through them. They now fail closed: hardware entropy (get_entropy64_secure) stays as the second source, and with none the kernel halts through one entropy_unavailable() (crypto/util/rng/unavailable.rs) instead of returning predictable bytes.

Changed:

  • rng/global/generate.rs: random_u64 and fill_with_fallback_secure, which serves get_random_bytes and fill_random_bytes.
  • crypto/util/misc.rs: secure_random_u64.
  • core/api/random/platform.rs: random64_or_counter is renamed random64_or_halt (3 callers in keygen.rs).
  • rng/entropy/collect/get.rs: get_entropy64; its now-unused emergency_entropy_mix is removed.

The _secure / Result variants are unchanged.

Early boot (from reading the code): none of the changed APIs is called from src/boot or src/memory. KASLR, the canary and the allocator seeds use arch::cpu_random directly, and the DRBG init already stops boot on failure. On a machine with no RDRAND/RDSEED, a call before virtio-rng is up now panics, which is intended.

Not changed:

  • security/policy/advanced.rs:71 StackCanary::gen_canary still uses the TSC when RDRAND is missing (commented as deliberate).
  • Two secure_random_u64 variants spin forever instead of halting.

Verification: kernel cargo check (x86_64-nonos.json, microkernel-core and microkernel-core,nonos-smp) passes with only the 2 existing quirk_bits.rs warnings. Not yet boot-tested; a combined make dev-image / dev-boot of all seven fix branches is still to run.


Opened on GitHub by senseix21 as pull request 614. Review and merge happen there while this repository is kept in step from GitHub; this copy follows it, and is marked merged or closed when it is.

@eKisNonos The infallible random APIs fell back to cycle-counter-derived values when the DRBG wasn't up or a hardware source failed. Keys, nonces, seeds and canaries are drawn through them. They now fail closed: hardware entropy (`get_entropy64_secure`) stays as the second source, and with none the kernel halts through one `entropy_unavailable()` (`crypto/util/rng/unavailable.rs`) instead of returning predictable bytes. **Changed:** - `rng/global/generate.rs`: `random_u64` and `fill_with_fallback_secure`, which serves `get_random_bytes` and `fill_random_bytes`. - `crypto/util/misc.rs`: `secure_random_u64`. - `core/api/random/platform.rs`: `random64_or_counter` is renamed `random64_or_halt` (3 callers in `keygen.rs`). - `rng/entropy/collect/get.rs`: `get_entropy64`; its now-unused `emergency_entropy_mix` is removed. The `_secure` / `Result` variants are unchanged. **Early boot (from reading the code):** none of the changed APIs is called from `src/boot` or `src/memory`. KASLR, the canary and the allocator seeds use `arch::cpu_random` directly, and the DRBG init already stops boot on failure. On a machine with no RDRAND/RDSEED, a call before virtio-rng is up now panics, which is intended. **Not changed:** - `security/policy/advanced.rs:71` `StackCanary::gen_canary` still uses the TSC when RDRAND is missing (commented as deliberate). - Two `secure_random_u64` variants spin forever instead of halting. **Verification:** kernel `cargo check` (`x86_64-nonos.json`, `microkernel-core` and `microkernel-core,nonos-smp`) passes with only the 2 existing `quirk_bits.rs` warnings. Not yet boot-tested; a combined `make dev-image` / `dev-boot` of all seven fix branches is still to run. --- Opened on GitHub by senseix21 as [pull request 614](https://github.com/NON-OS/microkernel/pull/614). Review and merge happen there while this repository is kept in step from GitHub; this copy follows it, and is marked merged or closed when it is.
The infallible random APIs (get_random_bytes, fill_random_bytes,
random_u64, get_entropy64, util::misc::secure_random_u64 and the keygen
helper behind generate_secure_key) returned output derived from the cycle
counter whenever the DRBG or every hardware source was unavailable. Keys,
nonces, seeds and canaries are drawn through these functions, so that
output was predictable exactly where it mattered.

Hardware entropy (RDRAND/RDSEED, virtio-rng) stays the fallback when the
DRBG cannot serve. With none available the kernel now halts through a
single entropy_unavailable() terminal rather than producing predictable
bytes. The _secure and Result-returning variants are unchanged.
nonos-sync changed title from WIP: crypto: random APIs fail closed instead of falling back to the cycle counter to crypto: random APIs fail closed instead of falling back to the cycle counter 2026-10-10 05:09:39 -04:00
The production-source hygiene gate refuses panic! in kernel source. Stopping
through boot::stop does what the panic meant and is the kernel's own way to
halt: it names the step on serial as [FATAL], shows the notice band on the
panel, and halts.
This pull request can be merged automatically.
This branch is out-of-date with the base branch
You are not authorized to merge this pull request.
View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u origin +refs/pull/155/head:nonos-sync/gh-614
git switch nonos-sync/gh-614
Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
NON-OS/nonos-micro-kernel!155
No description provided.