utils: Fix CSPRNG build on macOS and Windows#6
Merged
Conversation
Two build failures in the recent rvvm_csprng_bytes addition, both turned up by ScalarEvolution2's CI matrix: macOS arm64 — getentropy(3) called but not declared. The Apple branch was folded in with OpenBSD under a single #include <unistd.h>. OpenBSD does declare getentropy there; macOS does not — since 10.12 Sierra it lives in <sys/random.h>. Split the Apple and OpenBSD branches so each pulls the header where the symbol actually is. Windows x86_64 — undefined reference to BCryptGenRandom. The Windows branch calls BCryptGenRandom but the Makefile never linked bcrypt on MinGW. Added -lbcrypt to the Windows LDFLAGS via the same check_cc_flags helper used for other Win32 libs, gated on OS=windows. Every Windows target we support (NT 6+ / Vista and later) ships bcrypt.dll, so the link is unconditional. Cross-validated both with zig cc: - target x86_64-windows-gnu: librvvm.dll links, bcrypt.dll imported. - target aarch64-macos: librvvm.dylib links, getentropy imported.
SolAstrius
added a commit
that referenced
this pull request
Apr 27, 2026
Four small, related fixes that retire every "real bug in handled code" left from the original audit. #5 CORB consumer — sound_hda_corb_wp_write previously fetched only the entry at the new WP and never advanced corb_rp. Linux happens to bump WP after every entry so it worked, but a guest that batches multiple commands before bumping WP (spec §4.4.1.4 says you can) silently dropped all but the last. Now walks RP+1..WP inclusive, dispatching each verb, advancing RP to match — the spec-conformant CORB consumer model. #6 SET_PIN_WIDGET_CTRL on NID 3 — the verb's macro existed but no case dispatched it, and GET hardcoded a constant OUT_ENABLE. So Linux's pin power-up sequence ("write OUT_ENABLE, read back to confirm") happened to round-trip correctly only by accident. Now stores a real per-pin control byte (hda->pin_ctrl, single pin today; multi-pin codecs would key by NID), and GET returns it. Initialised to OUT_ENABLE so probe-time GET behaviour is unchanged for guests that don't write the register first. #12 RUN/SRST ordering — spec §3.3.35 requires "the RUN bit must be cleared before SRST is asserted." We previously accepted both bits set in the same write without enforcement — the worker would keep running with zeroed BDL pointers, spinning against a freshly-reset stream until the guest re-asserted RUN. Now on the SRST 0→1 edge, force-stop the worker (running=0) and override the same write's RUN bit, matching real HW behaviour where SRST clears the engine as part of its "stream registers and FIFO are reset" effect. #14 spinlock-across-pci_send_irq — was flagged as a smell ("could self-deadlock if IRQ delivery is synchronous and re-enters MMIO"). Verified RVVM's pci_send_irq → rvvm_send_irq just queues into the interrupt controller; the vCPU is a separate thread that picks it up later and never re-enters our MMIO synchronously from the calling thread. Documented the safety reasoning at the call site so future readers don't have to re-investigate. Not a bug — just under-documented.
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
1 participant
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.
Two build failures in `rvvm_csprng_bytes`, both surfaced by ScalarEvolution2's CI matrix on the current staging pin:
macOS arm64 — `call to undeclared function 'getentropy'`
The Apple branch shared an `#include <unistd.h>` with OpenBSD. OpenBSD does declare `getentropy(3)` there; macOS does not — since 10.12 Sierra it lives in `<sys/random.h>`. Split the two branches so each pulls its correct header.
Windows x86_64 — `undefined reference to BCryptGenRandom`
The Windows branch calls `BCryptGenRandom` but the Makefile never linked bcrypt on MinGW. Added `-lbcrypt` to the Windows `LDFLAGS` block via the same `check_cc_flags` helper already used for other Win32 libs. Every Windows target we support (Vista / NT 6+) ships `bcrypt.dll`, so it's unconditional inside the existing `ifeq ($(OS),windows)`.
Cross-validated
Both targets cross-compiled from Linux via `zig cc` (0.15.2):
Test plan