Linux fingerprint sensor daemon for QTEE devices
  • C++ 88.6%
  • Shell 11.4%
Find a file
Repository files (latest commit first)
Filename Latest commit message Latest commit date
Jorijn van der Graaf 9fbf5e6c73 Run the frame loop at 40 ms, and time it
500 ms between frames was the research harness's pace, chosen so a person
could read the transcript as it scrolled. It became the daemon's pace by
inheritance, not by decision, and it is the root of both complaints from real
use: false negatives and a slow answer after lifting.

The matcher rejects the early frames of a correct press and matches several
frames in -- frames 3 and 8 in the acceptance run. So the number of frames a
press gets is what decides it, and at 500 ms a one-second press gets two. And a
lift is only noticed on the next frame, so the gap is also the latency a user
feels before verify-no-match.

A frame costs four QTEE round trips whatever the gap; the gap is pure delay on
top. 40 ms is a starting point, not a measurement: the loop now logs
milliseconds per frame so the real achievable rate is read rather than assumed,
and logs the IRQ line alongside the metric so it is visible whether gpio75
tracks the finger under an armed session -- if it does, lift detection can
become an edge wait instead of a poll. --frame-gap= overrides it.
2026-09-02 22:36:47 +02:00
implementations Run the frame loop at 40 ms, and time it 2026-09-02 22:36:47 +02:00
interfaces Guide the enrolment, and take the sample total from the config 2026-09-02 21:01:00 +02:00
packaging Become a daemon: a held session, a worker, and net.reactivated.Fprint 2026-09-02 22:10:51 +02:00
tests Guide the enrolment, and take the sample total from the config 2026-09-02 21:01:00 +02:00
.gitignore Initial commit: the gpfile wire format, pinned by two real containers 2026-09-02 16:02:46 +02:00
LICENSE Initial commit: the gpfile wire format, pinned by two real containers 2026-09-02 16:02:46 +02:00
lint-rules.h Initial commit: the gpfile wire format, pinned by two real containers 2026-09-02 16:02:46 +02:00
project.cpp Become a daemon: a held session, a worker, and net.reactivated.Fprint 2026-09-02 22:10:51 +02:00
README.md README: it works end to end through fprintd's own clients 2026-09-02 22:29:59 +02:00

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, so pam_fprintd, the Plasma fingerprint KCM and fprintd-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:

packaging/make-sysroot.sh                        # once; no root, no qemu, no device
crafter-build -- --target=aarch64-alpine-linux-musl \
  --sysroot=~/.cache/fingerprintd/sysroot-aarch64-alpine \
  --march=armv8-a --mtune=generic
crafter-build test --target=aarch64-alpine-linux-musl --sysroot=... \
  --march=armv8-a --mtune=generic                # runs the suites under qemu-aarch64

The result links dynamically against the phone's own musl and libc++ (libc++, libc++abi, libunwind, libgcc_s, all already present on pmOS). The research harness this replaces had to be built -static, but only because it was built with the host's glibc toolchain — that constraint does not apply to a real Alpine sysroot.

Verified on the device: all five suites pass cross-built and run on the phone itself, not only under emulation.

Status

It works end to end through fprintd's own clients. On the Fairphone 6, as a systemd unit owning net.reactivated.Fprint:

fprintd-enroll -f right-index-finger user   ten stages, enroll-completed
fprintd-list user                            - #0: right-index-finger
fprintd-verify user   (wrong finger)         verify-no-match, on the first press
fprintd-verify user   (enrolled finger)      verify-match,    on the first press

Nothing in fprintd was modified; the daemon speaks its interface.

module what it holds
:Sfs the gpfile frame — the read/write offset split, the O_TRUNC guard, root mapping, path-traversal rejection
:Rpmb request/reply framing, the bytes-transferred out-parameter, JEDEC result codes, chunking, the one-time-programmable key guard
:Ta command surface, the 740-byte event context, capture flags, save masks, enrol/auth payloads, the error table, the verdict rule
:Engine baseline calibration, touch edges, enrolment progress, the accounting
:Store the finger name map
:Tee QTEE service/op numbers, the listener table, the 13-byte CBOR credentials blob
:Sensor the pins, the timings, and the XPU guard

Every constant that was recovered by reverse-engineering carries where it came from, and the tests are written to fail if it is undone rather than to restate it. Several replay real captures off the phone.

Two policy decisions live in the daemon and both were forced by measurement. Verification is judged per press: any matching frame wins, only rejections is no-match — both correct presses in the acceptance run had rejected frames before the one that matched, so a first-frame rule would have failed them. And the shipped config sets max_authentication_rescan_times to 0, because at the stock budget a wrong finger never yields a terminal frame and a PAM client waits forever for the verify-no-match it needs.

Not done: packaging (provides="fprintd=…" so this replaces the fprintd daemon package while fprintd-pam stays), the shipped storage policy, polkit (a caller-uid rule stands in), trustlet-side template removal (deletes drop the name only), cleanup when a claiming client vanishes from the bus, and the kernel config change — CONFIG_QCOMTEE, which selects the SHM bridge — that gates any public image.

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.