Browser Extension Zone + Pi 4B Board Support + SRDX Security Fix

Three kernel commits push the 0.7.0 sprint forward. core/ext_zone.sg (sigil-kernel ae38f9a) implements the browser extension zone process with Manifest V2/V3 capability grants — a distinct slot pool from renderer processes, with user-approved caps (net/fs/cookie/history) brokered through the cap inspector. hal/aarch64/board_pi4.sg + pi4_init.sg (sigil-kernel 4f33127) deliver Pi 4B (BCM2711) board support and 4-step bring-up sequence. core/srdx_xport.sg (sigil-kernel f701583) gets user-pointer bounds checking on the EL0→EL1 boundary — a Code team security flag.

ext_zone.sg — extension process isolation (ae38f9a)

Extensions are neither renderers nor apps. They need a wider capability profile than a renderer (they can't function with just CAP_IPC), but a narrower one than the Browser process. ext_zone.sg defines the extension process as its own slot type, with its own slot pool (EXT_BASE 0xFF6000, 16 slots × 32B), separate from renderer slots.

Cap hierarchy — the three-tier process model

Process type	CAP_IPC	Net	FS read	Cookies	History	Display	Exec
Renderer	✅ (only cap held)	❌	❌	❌	❌	❌	❌
Extension zone	✅	user-approved	user-approved	user-approved	user-approved	❌	❌
Browser process	✅	✅	✅	✅	✅	✅	✅

Extensions can be granted up to 4 optional caps: CAP_NET(256) · CAP_FS_RD(512) · CAP_COOKIE(1024) · CAP_HISTORY(2048) — per the extension's Manifest declaration. All other caps are structurally absent (not policy-blocked; absent from the slot's capability register).

ext_install(id, manifest, cap_grant)

Allocates an extension slot. Sanitizes cap_grant to known bits only (unknown bits are cleared). Forces CAP_IPC. No cap can be granted that isn't in the known-bits mask — a malformed manifest cannot grant itself unexpected capabilities.

ext_revoke_cap(id, cap)

Removes a specific cap from the extension's profile. CAP_IPC is protected — it cannot be revoked (extensions communicate only via IPC; revoking IPC would make the extension unreachable and uncleanable). All other caps are revocable from the cap inspector at any time.

ext_crash(id)

Strips ALL caps from the slot (including CAP_IPC) on fault. The extension cannot reach any resource after crashing — the cap register is zero.

ext_kill(id)

Clean shutdown — cap strip + slot reuse.

PASS: EXT init=1 cap=1 rev=1 (allocate slot, grant caps, revoke one, verify remaining profile).

Three isolation guarantees

A compromised extension cannot escalate beyond its install-time cap grant (the kernel strips unknown bits at ext_install; ext_revoke_cap can only reduce, never add caps after install)
Renderer cannot gain extension caps (different slot pool; renderer slots and extension slots are non-overlapping address ranges)
Browser mediates all chrome.* API calls via IPC — extensions never call chrome APIs directly; they send IPC messages, the Browser process handles them and returns results. The extension never holds a capability for what the chrome API does; the Browser process holds it.

Pi 4B board support (4f33127)

board_pi4.sg defines the BCM2711 memory map: peripheral base PBASE = 0xFE000000 (vs Pi3's 0x3F000000), UART0, GPIO, VideoCore Mailbox, GIC-400 interrupt controller addresses. pi4_init.sg runs the 4-step Pi 4B bring-up at scratch address 0x4B9000.

4-step bring-up sequence

Step ①: GPIO 14/15 → ALT0

UART0 TXD/RXD — BCM2711 GPIO function select. GPIO pins 14 and 15 must be set to Alt Function 0 before PL011 UART0 can be used. On Pi 4B this is required before any serial output.

Step ②: PL011 UART0 init at 115200

Integer baud rate divisor IBRD=26, fractional FBRD=3 for 115200 baud at 48 MHz UART clock. (The real Pi 4B mailbox sets the UART clock before this step; in the HAL model, 48 MHz is the assumed clock after mailbox setup.)

Step ③: GENET NIC init → nic_init()

The Pi 4B uses the Broadcom GENET (Gigabit Ethernet) controller rather than the LAN9514 USB-Ethernet on Pi 3. nic_init() is called (currently routes to the loopback stub until real GENET HAL ships).

Step ④: VideoCore Mailbox framebuffer alloc

Request a 1280×720×32bpp framebuffer from the VideoCore GPU via the Pi mailbox property interface (tag 0x00048003: allocate buffer). In simulation, the mailbox response is synthetic; on real hardware, the VC returns a physical address.

pi4_bringup() returns a state bitmask: GPIO|UART|NIC|FB (bits 0–3). PASS: PI4 gpio=1 uart=1 nic=1 fb=1.

Why Pi 4B matters now

The Pi 4B (BCM2711) is the minimum-spec platform for the 0.7.0 browser sprint — the browser requires more RAM than Pi 3B's 1 GB (Pi 4B ships with 2/4/8 GB options). Board support landed before the browser chrome build so that the browser can target real hardware from day one, not just QEMU.

SRDX xport bounds check security fix (f701583)

Code team security flag: srdx_xport_dispatch was passing user-supplied buf/len arguments directly to nic_send, nic_recv, and nic_mac without bounds checking the EL0→EL1 boundary. This commit adds two guard functions:

xport_uptr_ok(ptr, len)

Checks (a) ptr is not null; (b) len is not negative; (c) len ≤ 1514 (raw NIC MTU, no single frame can exceed this); (d) ptr + len does not wrap (integer overflow guard).

xport_outbuf_ok(ptr)

Checks output buffer pointer is not null before writing to it (e.g., nic_mac output buffer).

Both guards are called at the entry of srdx_xport_dispatch before any call to nic_send / nic_recv / nic_mac. A failing guard returns an error code to EL0 — the dispatch does not proceed.

The commit message notes: "Full page-table isolation deferred to MMU Phase-2." This fix is an explicit defense-in-depth check at the syscall dispatch layer. The full isolation (where EL1 cannot reach EL0 memory at all without a validated pointer) requires the MMU to be fully active and enforcing page-table boundaries, which is a Phase-2 kernel item.

PASS: SRT send=1 recv=1 lnk=1 bnd=1 (existing tests still pass + new bounds-check test: null ptr rejected, negative len rejected, MTU overrun rejected, wrap detected).