- C++ 88.6%
- Shell 11.4%
| Filename | Latest commit message | Latest commit date |
|---|---|---|
Jorijn van der Graaf
80ff09b4ce
Fingerprintd:Store holds the correspondence between two vocabularies that know
nothing about each other: the trustlet identifies a finger by an opaque 32-bit
id it chose, and fprintd speaks users and names like "right-index-finger".
Nothing else can hold it -- the trustlet has no field for a name.
No biometric data passes through here. A template is a ~252 KB container the
trustlet encrypts and QTEE anti-rollback protects; this is a table of {name ->
the id the trustlet reported}, worth about as much as a username. It is stored
as one "name fid" per line, deliberately boring and greppable, because losing
it costs names rather than templates and it should be repairable by hand.
Two properties are load-bearing. fid 0 is never storable or matchable: 0 is
what the trustlet writes into the fid field when authentication FAILS, so a
stored 0 would turn every rejection into a match. And a damaged map degrades to
"fewer names known" rather than to a daemon that will not start -- unknown
names, missing ids, partly-numeric ids and zero fids are all skipped, since the
daemon that fails to start is the one that unlocks the phone.
The gid is the caller's Linux uid. SET_ACTIVE_GROUP and AUTHENTICATE only have
to agree with each other, so the value is ours to choose, and the uid makes the
mapping total with no allocation table. The dev phone's gid 60 is recorded as a
legacy group -- it was never a decision, just the ENROLL token's timeout field
read as a gid and then made self-consistent.
Verified by mutation: storing fid 0 and accepting a partly-numeric id both fail
the suite. A third mutation did not: Lookup's own zero guard is unreachable
because Add is the only way an entry is created and it already refuses 0. The
guard stays as defence in depth for a future writer, and the test now asserts
the invariant that makes it unreachable -- no entry holds fid 0 however it was
created -- rather than leaving a branch that no test can reach.
|
||
| implementations | ||
| interfaces | ||
| tests | ||
| .gitignore | ||
| LICENSE | ||
| lint-rules.h | ||
| project.cpp | ||
| README.md | ||
fingerprintd
Fingerprint daemon for the Fairphone 6 (milos, SM7635) on mainline Linux.
Why a daemon
The sensor is a FocalTech FT9391 on a TrustZone-owned SPI bus. spi@a88000 is
disabled in both the mainline and the stock Android device tree, and the pads
are XPU-protected — touching them from the normal world is an instant SError
reboot. Every pixel the sensor produces stays inside the TEE: capture,
preprocessing, the classifier, enrolment and matching all run in the focal64
trustlet, which reports a matched finger id and nothing else. A libfprint-style
driver cannot exist on this device.
So the normal world's job is narrower than usual, and none of it is per-request work:
- Power the sensor. Rail on gpio29, reset on gpio74, interrupt on gpio75 — the same division of labour the downstream driver uses. One sensor reset buys exactly one trustlet init, so whatever powers the sensor must also hold the session open.
- Be QTEE's filesystem. QTEE cannot reach storage. When the trustlet saves
or loads a template it calls back into the normal world through the
gpfile(0x7000) and RPMB (0x2000) listeners, and expects them served. QTEE does the crypto and the anti-rollback; this side moves opaque bytes and performs the authenticated RPMB transactions against the UFS device. - Speak a biometrics API. The daemon owns
net.reactivated.Fprint, sopam_fprintd, the Plasma fingerprint KCM andfprintd-enroll(1)work against it unmodified.
A listener registration is held for as long as the process lives and QTEE's listener table is global to the boot, so this has to be one long-lived process rather than a tool spawned per request.
Layout
interfaces/ Fingerprintd{,-Sfs}.cppm the core: pure C++ modules
implementations/main.cpp the daemon shell
tests/ one suite per core module
fingerprintd-core is a static library with no GLib, no libqcomtee and no
system headers. Everything in it is a wire format or a state machine that was
recovered by reverse-engineering, so all of it is pinned by tests that run on a
dev box with no phone, no TEE and no sensor. The daemon shell holds everything
that touches hardware.
Build
crafter-build # bin/fingerprintd-<target>-<march>/fingerprintd
crafter-build test # the unit suites
Cross-compiling for the phone:
crafter-build -- --target=aarch64-alpine-linux-musl \
--sysroot=<alpine-aarch64-sysroot> --march=armv8-a --mtune=generic
crafter-build test --target=aarch64-alpine-linux-musl
Status
Early. The core is being ported one wire format at a time out of the research
harness that first made the sensor work (utilities/fpta.c in the fp6 repo),
each piece landing with tests before the next starts. Fingerprintd:Sfs — the
gpfile frame — is done. The daemon itself does not run yet.
The working reference enrols a finger, keeps it across a reboot, and matches it with zero false accepts; the port exists to turn that into a service rather than to rediscover it.
Runtime dependencies, not carried here
The focal64 trustlet is proprietary and is not in this repo. It is
extracted from the device's own stock Android partition on first boot by the
fp6-vendor-blobs mechanism, the same way the audio firmware is.