security: explicitly erase kernel RNG secrets on amd64 and arm64 - #219
medvednikov wants to merge 1 commit into
Conversation
medvednikov
left a comment
There was a problem hiding this comment.
Reviewed c1275f520298b980db092a9fea60c300ce30a730. No actionable regression identified in the explicit-erasure implementation and examined RNG call sites.
The volatile byte-store helper does not dereference the buffer for a zero length. The changed calls retire scratch/seed memory rather than changing the generator's output, readiness or rekey policy. The documented limitation to specified memory locations, not registers or every compiler-created copy, remains important.
Independent validation performed: copied the eraser C source and verified its Git blob hash (47b6b495de3f542b0872a1df21aac332b7d451e1), then compiled it in an isolated host harness. Lengths 0–256, surrounding canaries, full-buffer erasure, and null-with-zero-length passed with GCC 14.2 and Clang 17 at O0/O2/O3, plus GCC O3+LTO. Optimized freestanding x86-64 and AArch64 assembly both retained zero stores for an otherwise-dead local buffer.
Those checks execute the C eraser, not the V wrapper or kernel RNG lifecycle. I did not run the full repository V/kernel builds, boot/getrandom tests, or VirtIO DMA shutdown on hardware. CI results were not considered; the draft's kernel-validation limitations remain.
Feature 1: non-elidable kernel secret erasure
Adapt OpenBSD
explicit_bzerosemantics to Vinix with an original volatile-store implementation shared by amd64 and arm64. This is intentionally independent of the existing usercopy/SMAP/PAN PR series (#212, #214–#218).Changes
vinix_explicit_bzero()plus thesecuremem.zero()V wrapper. Zero-length calls do not access the pointer; this is for valid kernel memory, not usercopy.Validation performed
python3 tests/security/securemem_test.pypassed locally:git diff --checkpassed. The original edited source files were verified against their Git blob SHAs before editing.Merge gate / limitations
Draft: full V kernel compilation and QEMU/hardware boot/getrandom validation have not been completed in this environment. The local environment has no V compiler or QEMU and cannot clone network dependencies. The workflow requests both kernel builds; its results must be checked before merge.
This only erases the specified memory locations; it does not promise register wiping, elimination of all compiler-created copies, wiping SHA-256 internal state, or disposal of the original device-tree/firmware boot-seed copies. Those need a separate lifecycle audit.
OpenBSD references
Design and limits:
docs/security/explicit-erasure.md. No claim of overall OpenBSD security parity.