Fimeg/SouveraineOS
Watch
1
0
Fork
You've already forked SouveraineOS
 0
Code Releases Activity

task-44: the TA clears the latch, and the sensor does not free-run

Browse source 
fpctzappfingerprint loads from cold boot and answers; init/idle/arm all 0x0.
gpio121 goes idle-low after the sequence - the latch that killed piece 1 is
cleared, so a rising edge is possible for the first time. init accounts for 68
of the edges; armed and untouched is a flat 0 over 15s, so the 1444-event run
was the re-arm loop. Open: whether a finger raises an edge.

Reconcile the file with the code it now contradicts (the sysfs is shipped on
purpose) and register arbitrary signed-TA loading as a new Tier-0 primitive.
This commit is contained in:
Fimeg 2026-08-01 19:01:42 -04:00
commit be4ceedbd1
2 changed files with 176 additions and 21 deletions
Download patch file Download diff file Expand all files Collapse all files

38
docs/SECURITY-AUDIT.md
View file

@ -136,9 +136,47 @@ Tracked gaps. Each has a status; none are silently accepted.
| SDDM-vs-greetd asymmetry (two greeters) | Deferred debt, not accepted | doctrine §12 |
| Autonomous invisible capability use | Open — P3 not yet enforced | P3 |
| Cross-machine user-data sync (contacts federation) | Parked — separate trust domain | `contacts-design.md` |
| **Arbitrary signed TA loading from the AP** | **New 2026-08-01 — ungated beyond file perms** | below; TASK-44 |
---
## New primitive 2026-08-01 — the AP can load trusted applications
Recorded deliberately, because it is a genuine widening of what the device can
do and it happened as a side effect of chasing a fingerprint sensor.
**What changed.** Until today the QSEECOM client could only *look up* apps
already resident in TrustZone (`GET_APP_ID`), and on a mainline userspace
nothing ever loads one — Android's `qseecomd` does that — so every lookup
returned `-ENOENT` and the surface was inert. The kernel now implements
`qcom_scm_qseecom_app_load()` and a `LOAD_APP` ioctl that reassembles a QSEE
image (`.mdt` + `.bNN`) and hands TZ its physical address. **Any signed TA
image placed in `/lib/firmware` can now be started and issued commands.**
Proven end-to-end: `fpctzappfingerprint` loads from cold boot and answers.
**What backstops it, and what does not.** TZ verifies the image signature, so
we cannot load our own code into the secure world — that check is Qualcomm's
and Google's, not ours, and it is the real boundary. What TZ does *not* decide
is **which** signed vendor TA gets started, **when**, or **on whose behalf**.
Today the only access control on that is file permissions:
`/dev/qseecom` is `crw------- root root`. So the primitive is
root-gated and nothing more.
**Why it matters to this threat model.** A TA is a privileged execution
context that outlives the process that started it and may hold keys or device
state. This sits **below the session authority entirely** — sessiond, the
capability tiers and the lock state have no visibility into it, so none of P2
(capability = live state), P3 (use is visible) or P6 (narrow granularity)
currently apply. It is Tier-0 surface reachable by any root-capable process,
including a compromised one, and a wedged or misdriven TA can take TZ or the
modem with it.
**Not yet decided, and the reason this is a watch-list row rather than a
finding:** whether TA loading should be a capability at all — gated per-app,
attested to a caller, and *visible* when used (P3) — or whether root-only is
the accepted answer for a single-user device. Do not let "the fingerprint
needed it" become the implicit policy for every TA on the device.
## Long-arc goal — process isolation + integrity monitoring
**Goal:** isolate every process into a known, gated section, with a Wazush-style