ldls: a second driver, and everything it found

e1000 -- Linux's, unmodified -- probes, opens, gets an address by DHCP and
carries ping traffic in a SchOS process. The kernel was driving that NIC and
gave it up, which makes it the first real handover as well as the second
driver.

None of what it needed was a missing feature. Every one was a call that
succeeded, returned zero and did nothing:

  _find_next_bit          "bit 0 is set"          -- for_each_cpu never ended
  netif_carrier_off       carrier already up      -- TCTL.EN never set
  __x86_indirect_thunk_r8 the jump discarded      -- 255 rx buffers, none made
  dma_map_page_attrs      bus address 0           -- NIC aimed at physical 0

so the rule from memcpy is now general: a stub returning zero is unsafe
wherever zero is a meaningful answer.

The loader grew ko_fixup_percpu(). The stack guard turned out to be one
per-CPU variable among several; `current` cannot be defused because the driver
dereferences it. Taking the %gs off instead leaves the same opcode reading the
same width from storage the host supplies -- a per-CPU variable in a
single-threaded host is just a variable. Eight bytes become seven and a nop,
and the displacement is not always last, so there is now just enough of an x86
decoder in ko.c to know how long the instruction is.

ldls/kpi/thunk.c is fifteen lines of assembly and the highest-value file here:
retpolines are control flow, and a stub cannot stand in for a jump.

The kernel side:

  - ioperm.c, the TSS I/O permission bitmap. A driver's outl is an instruction,
    not a call, and e1000's reset path picks it deliberately. IOPL=3 would hand
    over the PIC and the disk with it, so it is per-port. Writing it found that
    the I/O map base had been written at offset 64 rather than 102, leaving the
    CPU checking ports 0-831 against the TSS's own RSP0.
  - claim masks the device's IRQ line: 450,000 a second, otherwise.
  - net_detach(), the missing half of net_attach_late(). An interface left in
    the stack keeps its route and sends every frame to a driver that refuses
    it, which looks exactly like a userspace driver that does not work.
  - e1000_release() gives up the interface, not just the hardware.

8139too still passes 4/4; ldls-check still passes 27; four CPUs, no panic.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VQ7Qx8E1q1M1bbCq8QLHS2

docs/architecture/devices.md

@@ -73,8 +73,9 @@ What a driver needs from a kernel, and all it needs:
 | reach its registers | `mmap`, where the offset is a BAR's physical address |
 | memory it can hand to the device | `PCIIOC_DMA` |
 | be told when the device wants attention | `PCIIOC_IRQ`, then `read()` |
+| use its ports, if it has an I/O BAR | nothing — `CLAIM` grants them |
 
-Three of those are worth expanding on, because each encodes a decision:
+Four of those are worth expanding on, because each encodes a decision:
 
 **`mmap` is checked against the caller's claims.** An offset that is not inside
 a BAR of a device this process holds is refused. That is the whole difference
@@ -105,6 +106,15 @@ happened here at 72,000 interrupts a second, and what it looked like from
 userspace was a clock running seven times slow. See §13 of
 [../history/kernel.md](../history/kernel.md).
 
+**Ports come with the claim, and only that device's.** There is no ioctl for
+this because there is no decision left to make: a process holding a device with
+an I/O BAR gets exactly the ports in that BAR, through the TSS I/O permission
+bitmap, and loses them when it releases or exits. Granting it is not optional —
+a driver's `outl` is an instruction compiled into it, not a call anything can
+intercept — and granting it *coarsely* is not acceptable, because `IOPL=3` is
+one flag that hands over the interrupt controller and the disk along with the
+NIC. See [../../include/ioperm.h](../../include/ioperm.h).
+
 ### Handing a device over
 
 `struct pci_driver` has a `release` hook. A driver that does not define one keeps
@@ -122,6 +132,18 @@ console falls back to the VBE framebuffer.
 **No syscall on that path knows it is talking about a GPU.** The kernel hands
 over a PCI device; the process decides what it is.
 
+Two things a release has to do beyond quiescing the hardware, both found by
+handing over a NIC the kernel was actively using:
+
+- **Mask the line.** The kernel's handler is gone and the incoming driver is
+  about to enable the device, so for a while nothing will acknowledge the
+  cause. Left unmasked that is an interrupt storm — 450,000 a second, measured.
+- **Give up the class device too.** A NIC's `release` calls `net_detach()`, the
+  missing half of `net_attach_late()`. An interface left in the stack keeps its
+  address and the route to its subnet, so the stack goes on choosing it and
+  every frame reaches a `transmit` that now correctly refuses. Nothing reports
+  an error. See [ldls.md](ldls.md).
+
 It also **changes the display mode**, on a control socket, with `schmode` as the
 client — and that is worth a sentence here because it is the thing the device
 model makes possible rather than the thing it does. A modeset is five commands