Repository navigation
libevdev 1.14.0 reviewed, and the roadmap gives ADR-011's reason for the zone cookies - #250
Merged
Merged
Conversation
… sends datagrams to the bridge from its own address and, with IPV6_FREEBIND, from untrusted's, and counters in the net zone say which arrived
…ource, and counts before and after the net zone's chains The probe's control sent with no bound source while personal's fd19:: address was still tentative, so its datagrams left from the link-local address and matched no counter: run 37352305190 read "own datagrams did not reach the net zone" and could say nothing about the spoofed ones. Now personal waits until eth0 has no tentative address and binds each source, so a send that cannot use its address says so (OWN6-REFUSED EADDRNOTAVAIL). It sends over IPv4 too, where the kernel refuses a source the zone does not hold without IP_TRANSPARENT. The net zone counts each source at prerouting -350, ahead of its own chains, and again at input, after them, and the verdict prints every count.
…kryptikd sets on its eth0 IPV6_FREEBIND needs no capability and IPv6 checks no source on the way out, so a routed zone could send as fd19::<k> of another zone: personal as untrusted, whose address the forward chain lets onto the uplink's own network, or any zone to the resolver with the answer going to another. The design said a zone cannot send from another address; for IPv6 it could. kryptikd now creates each routed zone's eth0 with the MAC 02:19:00:00:00:<k>, which the zone can neither change nor forge (no CAP_NET_ADMIN, no CAP_NET_RAW, no packet sockets). The net zone's ruleset pairs 10.19.0.<k> and fd19::<k> with that MAC for every host number and drops, at prerouting ahead of conntrack, a packet from the bridge whose source and MAC are not a pair; from a link-local address only neighbour discovery passes. It is the inet table the net zone already loads, so the kernel gains nothing (no NF_TABLES_BRIDGE), and the read-back after loading now looks for the pin too. netzone-uplink.sh checks every host's pair, the order of the prerouting rules, and that netlink.rs gives the MAC the script expects; the kernel-backed veth tests read the MAC back inside the zone's namespace; zone-source-pinned counts what reaches the net zone ahead of the pin and what it takes in.
…he gateway again, and the uplink coming back to zone 0 under its own name reattach-after-restart pinged the bridge once #213 refused personal the VM gateway, so nothing showed a reattached zone going out through the net zone's forwarding and NAT any more. personal keeps that check, worded as what it shows. untrusted, which its definition lets reach the gateway, now runs across a second restart and must reach 10.0.2.2 before it, have no eth0 and no path while the net zone is down, and reach it again once reattached. While the net zone is down the uplink must be back in zone 0 as eth0, down, with no address, and the next start must take it again. A review read the uplink as renamed by the net zone and every later start failing on "create bridge kryptik0: File exists"; nothing renames it, and the kernel names a returning interface dev<N> only when zone 0 already has one by its name. The design doc says so.
…ridge, so no zone reaches it on its uplink addresses A zone's packet to the net zone's own address on an uplink (10.0.2.15 under QEMU, a café's 192.168.x.y on a real one) is local delivery, so the forward chain's rule on the uplinks' networks never saw it, and the input chain accepted it: every zone, local or not, reached whatever the net zone listens on there, such as dhcpcd. The input chain now drops what comes in from kryptik0 unless it is addressed to 10.19.0.1, fd19::1, a link-local or a link-scope multicast address. The guest check uplink-address-refused has untrusted reach the VM gateway and be refused the net zone's addresses beside it; netzone-uplink.sh checks the input rules. A review asked the same of a router's admin page on its WAN address. The net zone cannot know that address, so no rule can refuse it; the design doc says so where it lists what the rule does not cover.
…e list's first line stays as main has it and the PR merges clean GitHub runs no CI for a pull request that conflicts with main, and this one did, on the verdict list's first line, which main and the DNS branch also change.
…ation cannot undo a count of READY lines or hide the newest one s6-log moves /run/uncaught-logs/current aside at about 100 KB. The restart checks counted READY lines in current alone, so a rotation during their wait made the count fall below the one taken before and the check fail with nothing wrong; and the newest READY line was read from current first and the archives after, so tail -1 gave an archived line once one existed. One set of helpers now reads the archives, previous and current, oldest first, and every count, newest line and diagnostic in the suite goes through it. Found by linux-distro-a2's read of #230.
…g, whose raw socket root may use there Run 37570910486 failed reattach-egress with "gateway before no" while a fresh untrusted reached the gateway: icmp-echo.py opens only an ICMP datagram socket, and kryptikd sets the zone's ping_group_range to the zone's own gid, so root entering the namespace with nsenter was refused before anything was sent. The checks that already ping from a zone's namespace use ping, which falls back to a raw socket as root; this one does too. uplink-returned and uplink-retaken passed in that run.
The one conflict is the zones suite's verdict list: main's line, with this branch's three restart verdicts after reattach-after-restart.
The one conflict is the zones suite's verdict list: main's line, with uplink-address-refused after uplink-refused.
…y control, and says why the control failed Run 37571430413 refused both of the net zone's uplink addresses as it should (UPLINK4-REFUSED UPLINK6-REFUSED) but failed on its control: the echo to the VM gateway, the fresh zone's first packet, got no answer within 3 s, while routed-egress and egress-after-restart reached the same gateway in that run. The zone now echoes the bridge first, as routed-egress does, gives the gateway 5 s, and on a miss the verdict carries icmp-echo.py's NOPONG reason, the zone's exit status and the end of its stderr.
Conflicts: create_veth's doc comment, now one line in main's style with the peer MAC added; and the design doc's zone bullets, where main's plainer loopback bullet stands beside the MAC pin and the corrected claim that a zone cannot send from another address. The pin's comment in netzone-init.sh is cut to two lines.
…ne's address only with that zone's MAC
…s kept: cleanup-held's cut of build/recipes/services.sh and five service scripts, redone on main by hand, comments only From 65a6fbb, taken where the comment it shortens is still main's and the reason survives. Changed from it: boot-success's header names the slot booted from outside (#226), esp_committed is read at every boot with no trial on record, not only on a degraded state, and forget_entries keeps that the committed slot's own entry is a second way to it; testctl keeps why a control disk is read only on a medium and only when signed, and its key list is the thirteen keys main reads; time-floor keeps the newest committed release (#181); sysinit keeps a one-line list of the state's three kinds and why the consent directory is setgid. Dropped: the shortened section rulers (churn) and installer-run's shellcheck line, which predates slot_arg and kbd_arg.
…tikd replaces the port that run left in the net zone Run 37593717720 showed why uplink-address-refused's control failed: its untrusted started seconds after the one before it exited, and attach failed with "create veth kv-untrusted/eth0: File exists". A zone's port outlives it until the kernel has torn its network namespace down, so the new run started with loopback only, its ICMP socket got EACCES, and everything it tried was refused for want of a path. The same race let zone-separation pass with no path at all: an echo that cannot leave is never answered. registry::claim lets one instance of a zone run, so a port by its name is stale when the next one attaches: attach deletes it and retries for up to 5 s. zone-separation now needs the bridge to answer as well, and routed-restart-path starts untrusted again as its last run ends and needs its path to the bridge.
…tart goes out through the gateway again, and the uplink comes back to zone 0 under its own name # Conflicts: # docs/design/net-zone.md
Both change attach_v4's veth creation: this branch retries it over a stale port, and zone-source-probe gives eth0 the MAC the net zone pins. The loop keeps the retry and passes the MAC, so neither is lost whichever lands first. The suite keeps both sets of checks and the doc both changes.
Main now holds the update, recovery and clock changes; none touches this branch's files.
…mments are shorter, with their reasons kept
…their reasons kept: cleanup-held's cut of tools/kryptik, tools/provenance-inventory.sh, tools/verify-signatures.sh and three of their tests, redone on main by hand, comments only Only comment regions are taken from 65a6fbb; its message, help-range and test-label changes are left out. Where the cut dropped a reason, a shorter one is kept: kryptik has no transfer, clipboard or mount command because from zone 0 those would bypass the chrome, --ask passes the passphrase never as an argument, a Wi-Fi passphrase goes on stdin; the inventory's || true and its passthrough of publisher-named classes; the GNU keyring vouches only for whoever it names until checked out of band, a pinned key is one its project publishes on its own origin, which CPython releases the python key signs, netfilter's confirmation of its current key, anchored_import's return codes and kernel.org's signed projects. tools/key-provenance.tsv is left as it is: its header says what each confirmation route establishes and where it stops, which a summary loses.
…-held's cut of install-test, state-test, update-test, suite-lib and vm-drive.py, redone on main by hand, comments only Only comment regions are taken from 65a6fbb. Kept where it corrects main: suite-lib's header names what install_disk reads. Changed from it: update-test's header keeps the broken trial, and its channel comment keeps what the not-a-pointer control is; suite-lib keeps the production pair's testctl key. Dropped with the cut, as untrue or repeated: update-test's 'plain http is for development images only' (the suite writes an http channel on either role) and the request-order comment its own pass and fail lines state.
…sons kept: cleanup-held's cut of tools/desktop/kryptik-launch.c and kryptik-session, redone on main by hand, comments only Only comment regions are taken from 65a6fbb. Changed from it: the launcher's header keeps that it is the daemon's one client for the keys and the menu, and that the proxy socket is bound into the zone so a zone never sees the compositor's own; its update verbs keep that apply answers once the slot is written; the session keeps that anything needing root goes to the launch daemon.
…re shorter, with their reasons kept: cleanup-held's cut of kryptikd's sources, probes and cli suite, redone on main by hand, comments only Only comment regions are taken from 65a6fbb. Where the cut dropped a reason a shorter one is kept: the broker's peer uid is the kernel's, a zone reaches only its own clipboard and a move crosses once, None refuses every transfer, the destination is looked up again as it may have restarted, the identity switch is restored on every path; update.rs never resolves under what the net zone reports, never stages past the signed size, and its channel file is the image's; serve.rs's socket directory admits the group alone; stop signals a launcher only while its pid and start time match; and the suites' charters and orderings. Kept where the cut corrects main: the broker's request table gains transfer and clipboard-move, cli.sh's header its exit codes.
…zone tools' comments are shorter, with their reasons kept
… with their reasons kept
… comments are shorter, with their reasons kept
…e shorter, with their claims kept: cleanup-held's cut of docs/decisions.md, docs/design/broker.md and docs/supply-chain.md, redone on main by hand Where main changed a passage after the cut, main's text stands: the records include proposed ones, nosmt's cookies stay because root can turn SMT back on, the root image is about 1.7 GB, fuzz.yml exists, and the signature gate reads key-provenance.tsv. supply-chain.md carries two corrections the cut made: Intel's microcode comes from Intel's own unsigned archive, not linux-firmware, and cmake-bin is held to Kitware's signed SHA-256 list like the source tarball.
… their reasons kept
… comments are shorter, with their reasons kept: cleanup-held's cut of time.rs, docs/design/time.md, boot-check.sh, integrity-test.sh and tests/installer.sh, redone on main by hand, comments only Only comment regions are taken from 65a6fbb. Main's text stays wherever the cut would drop what main now relies on: the floor may be a later committed release; integrity-test.sh's header is its --help text, step 5 points at sysinit.sh's trust boundary and says why the attacker's payload is signed; the regulatory database is compressed like all of /lib/firmware. time.rs's module doc keeps why the time is a claim: only zone 0 sets the clock, and it has no network.
…nd the supply-chain notes are shorter, with their claims kept
…the integrity and installer suites' comments are shorter, with their reasons kept
…kes in only what is addressed to the bridge, and a zone started again at once keeps its path # Conflicts: # docs/design/net-zone.md # tools/image/zones-test.sh
…ntation fixes, nothing libinput calls; and the roadmap's core-scheduling row gives ADR-011's reason for the cookies, that root can turn SMT back on
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.
Main's pin gate went red on 2026-10-07 when libevdev tagged 1.14.0. Its four commits since 1.13.7 add libevdev_upload_ff_effect and libevdev_remove_ff_effect and fix documentation; libinput calls neither, and nothing is a security fix, so a review row rather than a bump. The roadmap's core-scheduling row still gave the old reason for the cookies (a machine whose SMT cannot be turned off); ADR-011's reason is that root can turn SMT back on through /sys/devices/system/cpu/smt/control, and the row now says so. Based on the batch so it goes in with it; CI's gate is the proof.