The trustlet has always reported WHICH finger matched and the daemon only ever
used it to answer yes. A table in /etc/fingerprintd/actions.conf now gives each
finger a meaning: run a command as root, tell the user's session, or report
no-match while doing one of those anyway -- which is duress, where the phone
should look like it simply did not recognise the finger.
Two rules shaped the design.
Root does not launch applications. The daemon has no session bus, no display
and no user environment, so a `session` rule carries no command at all: the
daemon emits net.catcrafts.Fingerprintd1.FingerMatched(finger, uid) and an
agent in the user's own session decides what that means from the user's own
configuration. The only commands in the file are ones root is meant to run.
Which makes the file a root shell, and the parser treats it as one. It is
refused outright unless root owns it and nobody else can write it, group
included. A malformed line rejects the WHOLE file rather than being skipped:
applying the prefix would leave a policy nobody wrote, and the missing half
could be the one that mattered. That property is tested, and the test caught it
being false the first time -- rules accumulated before the bad line survived
the rejection.
A system command must be an absolute path, because resolving a bare name
through PATH makes what root runs depend on an environment this daemon does not
control. It is double-forked with a scrubbed environment so an action may
outlive the daemon (a reboot) without ever stalling the worker thread that is
the only thread allowed to touch the trustlet.
Ordering is deliberate: the verdict override happens before the client is told,
because that is the point of duress; the session signal and the root command
happen after, on the same principle that keeps the harvest and the save off the
unlock path.
No actions.conf ships. An example goes to /usr/share/doc, because shipping a
root shell nobody asked for is not a default.
Not yet exercised on hardware.
FF_CMD_TA_REMOVE, recovered the way AUTHENTICATE was: read the stub, read the
handler. The 0x2006 stub at 0xa15c is a bare `ldp w0, w1, [payload]`, so the
request is two u32s -- gid at +0, fid at +4 -- and the 0x2000 dispatcher
validates no length. Walking the jump table reproduces authenticate at 0xa180,
which is the address already on record, so the table read is sound.
Three preconditions, all the trustlet's own. The gid must be the ACTIVE group
(it compares against device+0x30, the field SET_ACTIVE_GROUP writes). The fid
must be non-zero: zero is not "remove all", it is an error the trustlet logs
and refuses. And the fid must be among the loaded templates, because it
removes by the SLOT INDEX it finds, not by id.
It persists: on a hit the trustlet formats ff_template_<gid>_<slot>.bin and
calls ff_file_delete, which arrives on our gpfile listener as an unlink -- so
this only works with the store served writable.
Proven harmlessly first. --probe-remove sends one command with no map
involvement, and a fid the group does not hold answers rc=-2 with the real
template untouched -- which is what established that both words are read where
we send them, before anything was deleted.
Then for real, through fprintd-delete: both 347202-byte containers and their
.bak companions unlinked, templates loaded 1 -> 0, and a re-enrolment
afterwards completed 20 stages with SAVE_DATA rc=0, so the store is consistent
after a removal rather than merely emptier.
The ordering the transcript shows is worth keeping: the group index is
rewritten and the RPMB anti-rollback counter bumped BEFORE each unlink. That
is precisely why an orderly removal leaves a valid store where restoring an
older container leaves a tampered one -- the counter has already moved past
it.
The delete reply now waits for the worker, because only that thread invokes
the trustlet and fprintd's Delete methods are synchronous. Names are dropped
before templates on purpose: a template that survives a failed removal is a
slot leak, while a name that survives a successful one keeps offering a finger
that can no longer match.
Two things the packaging left behind.
A verify that ran its 600-frame budget without the sensor being touched was
reported to the client as verify-unknown-error. Nothing had gone wrong: nobody
had pressed. It cost three verifications during packaging, each reading as a
broken daemon. fprintd's contract is that a verify runs until the client stops
it, so the frame cap bounds one trustlet scan session rather than the user's
patience, and a window with no press simply runs again. Verified across the
rollover: 600 frames untouched, "still waiting", then a press matching on its
first contact frame in 44 ms.
Presses that happen and never reach a verdict now report verify-retry-scan --
a bad scan, which fprintd has a word for, and not the matcher saying no.
The cost is that an unanswered verify polls every ~200 ms for as long as the
client holds it. The cure is measured and available -- gpio75 is silent at
idle and bursts on contact -- but it would make the IRQ the only way a press
is ever noticed, deleting the poll under every rate this daemon has been
measured at. Noted where the loop waits, not done.
And the trustlet: focal64.mbn is a proprietary OEM-signed blob, so the package
ships a fp6-vendor-blobs manifest fragment instead, the same mechanism
soc-fairphone-fp6-audio uses for the amp config. It needed a new directive
there -- a QTEE image is an ELF header file plus one payload per program
header, not one file -- and reassembly on the phone reproduces the image QTEE
has accepted since August, byte for byte.
An aport, the units, and everything a phone needs to come up with a working
sensor without a single command being run by hand. Verified on the dev phone
across two reboots: modules-load.d loads qcomtee, tmpfiles builds the SFS
root, the mount unit brings up persist, and the daemon is ready 51 seconds
into the boot, owning net.reactivated.Fprint with the enrolled finger
visible.
The packaging shape is the one imsd uses for 81voltd. A versioned
provides="fprintd=..." satisfies plasma-workspace -- its Users KCM is the
enrolment UI and speaks exactly this bus name -- and excludes the real
fprintd, which is not tidiness: fprintd is D-Bus-activatable, so a client
call would otherwise start it and fight us for the name. The cost is the
fprintd-* CLIs, which go with the package.
fprintd-pam is an install_if subpackage pinned to the exact fprintd version,
so the provides breaks its condition and apk purges it -- taking pam_fprintd,
which is the entire point of the daemon, with it. Depending on it explicitly
is what keeps it, and it has no dependency on fprintd itself.
Two things the packaging exposed in the daemon:
The transcript is for experiments, not for a shipped daemon. A file per start
in an unrotated directory, recording the time of every unlock, to say what
the journal already has. It is now opt-in behind --log-dir, which is what
deploy-dev.sh passes since fplearn.sh reads it.
Taking it off the daemon path also took away the setvbuf it was doing as a
side effect of dup2'ing fd 1, and under systemd stdout is a pipe, which means
full buffering: the daemon started, worked, answered D-Bus calls, and printed
nothing. A working daemon that looks hung. stdout is now line-buffered from
the first line of main.
The config ships as generated by fp6fpcfg.py --daemon --verbose, sha256
b205c756914a66f1, because that is the file every accuracy number was measured
on. The quieter variant is untested and switching is a measurement.
The trustlet is not here and never will be: focal64.mbn is a proprietary
OEM-signed blob, and the unit's ConditionPathExists is what keeps the package
inert without it -- as it does on a kernel with no CONFIG_QCOMTEE.
