fix(krun): air-gap guests by default; opt-in TSI inet hijack#53
Merged
toksdotdev merged 1 commit intokrunfrom Apr 30, 2026
Merged
fix(krun): air-gap guests by default; opt-in TSI inet hijack#53toksdotdev merged 1 commit intokrunfrom
toksdotdev merged 1 commit intokrunfrom
Conversation
when no virtio-net device was configured, configure_vsock auto-enabled TsiFlags::HIJACK_INET so the guest's inet socket calls were transparently bridged to the host through vsock. that silently defeated air-gap setups: the guest had no network interface, yet its tcp/udp traffic still reached the outside world. flipped the default so guests with no virtio-net are air-gapped, and added MachineBuilder::enable_inet_hijack(bool) for callers that still want the TSI fallback. reported in superradcompany/microsandbox#645. BREAKING CHANGE: callers that previously relied on the implicit TSI fallback (no virtio-net configured) must now call .machine(|m| m.enable_inet_hijack(true)) to keep that behavior.
35a199f to
35be9f4
Compare
1 task
4 tasks
appcypher
pushed a commit
that referenced
this pull request
Apr 30, 2026
bumped all msb_krun_* workspace crates and their internal path-dependency version refs from 0.1.11 to 0.1.12, and refreshed both lockfiles. the libkrun C-API crate (1.17.3) and the example crates are unchanged. changes since 0.1.11: - fix(krun): air-gap guests by default; opt-in TSI inet hijack (#53)
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
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.
problem
when no virtio-net device was configured,
configure_vsockauto-enabledTsiFlags::HIJACK_INETso the guest's inet socket calls were transparently bridged to the host through vsock. that's a sensible default for "no network attached, give me something usable," but it silently defeated true air-gap setups: the guest had no network interface, yet its tcp/udp traffic still reached the outside world.reported downstream in superradcompany/microsandbox#645 where
msb run --no-net ... nc 1.1.1.1 80returned a cloudflare 301 even thoughip ashowed onlylo.fix
flipped the default so guests with no virtio-net are air-gapped, and added
MachineBuilder::enable_inet_hijack(bool)for callers that still want the TSI fallback. covered by unit tests.breaking: callers that previously relied on the implicit TSI fallback (no virtio-net configured) must now call
.machine(|m| m.enable_inet_hijack(true))to keep that behavior.test plan
cargo build -p msb_krun(no features)cargo build -p msb_krun --features netcargo test -p msb_kruncargo test -p msb_krun --features net api::vmcargo clippy -p msb_krun --features net --tests -- -D warningscargo fmt -p msb_krun --check