From a series of notes on bringing up our own OS on a Samsung Galaxy Tab S6 (SM‑T865, Snapdragon 855). The previous part — "The Parasite in the Tablet" — explained who the "Wi‑Fi chip" on this SoC really is and why it cannot be switched off, only isolated. This one is about a single episode from which it follows exactly what kind of isolation that must be.
1. What could be seen
Stage four: the modem is loaded and alive, the GLINK → QRTR → QMI transport is up, and on our side the servers the firmware expects to find on the host are running. One of them is rmtfs, the modem's "disk server". A few seconds after running, the modem was supposed to start the WLAN domain and announce the WLFW service. Instead — fatal.
The word fatal here is not a message and not a panic. It is bit 0 in the SMP2P word slave-kernel that the modem raises over our shared memory: 6 — healthy, 7 — died after having been ready. The modem usually leaves the reasons for its death in SMEM (SMEM_SSR_REASON_MSS0), but only if it managed to start its own error service. Here there were no words. A rule we had to learn earlier: "fatal without a reason" always means "early" — death before the modem learned to complain.
What the modem did before dying, our servers knew. ipc.hosts shows, for each host, what it was asked: for rmtfs — which files were opened, how many sectors were read and written, what was refused and why. The remoteproc state log gives the time of the running → crashed transition. Putting one together with the other, we got a timeline: the modem opened /boot/modem_fs1 — answered; /boot/modem_fs2 — answered; /boot/modem_fsg — refused, no such partition; 23 ms later — fatal. It reproduced every time.
2. Why this matters to the modem
EFS is the modem's file system: radio calibration, IMEI, carrier state. It lives on partitions of the application processor's disk — our disk, which the modem cannot reach on its own. So it reads and writes them through us, sector by sector: OPEN {path} → a caller number, ALLOC_BUFF → the address of a shared RAM region, RW_IOVEC → "move such‑and‑such sectors there". There are four partitions: modemst1 and modemst2 — two working copies, fsc — a cookie, fsg — the golden copy from which EFS is restored when both working copies fail verification.
Later, when the server was already working, it became visible how the modem uses them: one sector at offset 512 from each of fs1, fs2 and fsg — the headers — then a full read of the chosen copy. That is, it opens fsg and looks into it always, at every start, before it decides which one to use. This is not an emergency path — it is part of the regular check.
On this tablet there is no fsg partition. It simply does not exist in the GPT table; Samsung, by all appearances, keeps the golden copy some other way or does not keep it at all — we do not know this and do not claim it.
3. The wrong answer and the right one
The first implementation answered the way rmtfs from the qrtr utilities — the reference for Linux — answers: no partition — OPEN refused. That is honest, that is by the protocol, and that is exactly the answer the firmware does not survive. Why precisely a refusal on fsg is fatal while the absence of the server altogether is not (without rmtfs the modem lives another ~40 seconds and dies with efs sync failed), we do not know: the firmware code is closed. The observation is only timing and reproducibility.
The right answer came from the question "what does an erased golden copy read as?". Zeros. A partition that was never written or was erased returns zeros on read, and the modem's EFS knows this state — it knows how to recover from a zero fsg (we saw this from the other side, when because of a caching error the modem read empty headers of the working copies and restored EFS from scratch). So a missing partition must be opened empty: a shadow of zeros the size of modemst1 (or 2 MiB if there is nothing to take the size from), a caller number as usual, SUCCESS. The modem reads the header, sees an erased copy, picks a working one — and moves on.
Both answers remain in the code: Refusal::NoPartition — as Linux does, and the blank_missing flag, on by default. The comment at the flag says the same: a refusal produces fatal milliseconds after OPEN, before the modem reads its own copies — so, empty.
4. The pattern: the host is tested at every step
If fsg were the only such place, this would be a note about a quirk. But the same pattern repeats at every stage between "the modem is alive" and "Wi‑Fi works". The firmware does not just use the host — it tests it, and reacts to a failed answer not with an error but with a refusal to go further, or with death.
- The domain map. The modem firmware is split into protection domains, and before starting them the modem asks the host, via
pd-mapper, where the needed service lives. One of the questions iskernel/elf_loader: which domain loads user PDs. The tablet ships a single map file,modemr.jsn, and there is no answer to this question in it. Without an answer the WLAN domain does not start, and the WLFW service never appears. The answer had to be taken from the board table — the same one Linux keeps inqcom_pd_mapper.cfor SM8150. - Checking the file server. Before loading the WLAN firmware via
tqftp, the modem writes to/readwrite/server_check.txtand reads it back. If it does not match — it loads nothing. Only after that does it pullwlanmdsp.mbnitself. - The WLFW handshake. When the WLAN domain has started after all, its firmware expects a sequence of steps from the host: the MSA region, whose ownership the host transfers to it through the secure world and confirms with
MSA_READY; board data, loaded in segments (BDF_DOWNLOAD); the calibration report (CAL_REPORT). Only after that doesFW_READYcome. Without board data it never comes: the firmware waits forCAL_REPORT, and that comes after the download. A host that did not take a step gets no error — it gets nothing. - Unknown questions. Every server receives messages nobody serves. Staying silent is not allowed — the modem's client waits for an answer and times out; one must answer
NOT_SUPPORTED, like the reference. The same with GLINK channels: every remoteOPENis acknowledged, even ones we do not need, otherwise the modem waits forOPEN_ACK.
What these steps have in common: the modem checks the correctness of an answer by its form, not its content. It needs a caller number, not real sectors; a list of domains, not the vendor's file; the bytes of server_check.txt coming back the same, not a directory on disk; a QMI answer code, not an implementation. A refusal, silence and "no such thing" are the only answers it does not accept.
The same checks on one diagram. Red is the firmware in the role of a client, green are the servers it expects to find on the host; a bold frame is where the transparent answer is born: the shadow, scratch, the board table, NOT_SUPPORTED. A solid arrow is a mechanism; a dashed one is what happens if you answer honestly.
This is a fragment of the general map of the tablet's tenants; the whole of it, with the same node names, is in Whose Computer Is This?, § 2a.
5. The design that follows from this
Hence the principle called transparent isolation in the previous note: answer everything the modem asks with an answer correct in form — and hand over nothing real. Every server is built by this rule.
A shadow instead of the disk. The EFS partitions are the modem's property, not ours; the server gets them read‑only. On OPEN the partition is read into RAM once, and from then on all RW_IOVEC — reads and writes alike — go to this copy. The disk never changes; a reboot forgets. The modem sees that its writes "landed", and from its point of view they did. Dirty sectors are counted (dirty in ipc.hosts), but there is no policy for flushing them to disk — not as a flag but as code: the write path does not exist. Every transfer is checked twice: the sector and length against the shadow's size, the address in the shared region against its boundaries; otherwise OutOfRange. A missing partition is a shadow of zeros.
Scratch instead of files. tqftp translates the modem's paths into its own: everything under /readonly/... is only the firmware search path, a name with .. is dropped; everything under /readwrite/... is RAM scratch, 64 KiB and 16 files for everything together, old ones evicted. A write anywhere else is a TFTP ACCESS error. server_check.txt is written to scratch and read back from it: the server is "verified", not a byte went outside.
An empty list instead of a refusal. pd-mapper, asked about a service that is neither in the vendor files nor in the board table, answers with an empty list of domains — like the reference. That is an answer, not an error.
NOT_SUPPORTED instead of silence. Any unknown QMI message gets a correct reply with the NOT_SUPPORTED code; the identifier is recorded in unknown so that it can be seen what the modem wanted.
6. What it costs
The modem's writes to EFS are not saved. Everything it managed to write during a session — updated state, counters, whatever it is — is lost on reboot. On Linux and Android this does not happen: rmtfs from the qrtr utilities and the proprietary rmt_storage write to the real modemst1/modemst2, tqftpserv writes to a real host directory. The modem gets persistent storage on the host's disk — by design, EFS is supposed to survive a reboot, and in fact it survives even a factory reset: no OS reinstall touches the modem partitions.
For a cellular modem this is a price: without saved state part of its functions will not work. For now we pay it knowingly — Wi‑Fi through the modem works, and a disk‑write policy (if it is ever needed) is recorded as a debt and will require ownership of the partitions.
In the threat model the same price reads as a gain. Wi‑Fi firmware is compromised over the air regularly; a compromised firmware needs somewhere to write in order to persist, and on Linux/Android it has partitions that survive everything. On our side it has nowhere to write through the host: the shadow and scratch live in RAM, every boot is a clean slate. Persistence through the host is closed not by a prohibition that can be bypassed, but by the absence of a path. What remains is persistence by the modem's own means, outside our visibility, and that has to be kept on the "not closed" list rather than considered solved.
7. Summary
Twenty‑three milliseconds is the time in which the firmware decides whether the host is good enough for it. A refusal, however honest, is for it not information but a sign of a broken host. Hence the form of isolation: not to switch off and not to forbid, but at every step to give the answer the modem expects — syntactically correct and essentially empty. A shadow instead of the disk, scratch instead of files, an empty list instead of a refusal, NOT_SUPPORTED instead of silence. What this amounts to as a whole and what remains afterwards — in "The Parasite in the Tablet".
Sources in the repository: the EFS server and the empty‑shadow logic — crates/tools/src/rmtfs.rs (module documentation, Shadow, PATHS, Refusal::NoPartition, blank_missing, tests); the file server — crates/tools/src/tqftp.rs (Place::of, READWRITE, MAX_SCRATCH_BYTES, MAX_SCRATCH_FILES, the server_check test); the domain map — crates/tools/src/pdmapper.rs. Transport, servers, timings and the WLFW handshake — docs/wifi-sm8150.md § 4–6; the reset table — ibid. § 7, rows 5 and 6. What is neutralised and the comparison with Linux — docs/wifi-threat-model.md § 3, § 6.3, § 7. The stage record — TASKS.md, line 87.
VPN Chrome extension: what it protects and what it doesn'tA Chrome VPN extension is a proxy for browser traffic only. What it really protects, where it leaks, and when you need a full VPN app instead.
Turnkey smart homes on our own OS: 0xd-os and 0xd-uiWe build turnkey smart homes on components we designed ourselves. At the core is 0xd-os — one operating system that runs identically on a flagship tablet and on a device with 512 KB of memory.
Why security agents need a sandboxAn agent that can 'just run tools' on a security review is a second attacker — unless every call has a grant. AGI Core isolates tool execution; Forge keeps the skill list in UIDE.