The daemon announces every matched finger on the system bus and stops there,
because root has no session bus, no display and no business starting your
applications. fingerprintd-agent is the other half: it runs as you, subscribes
properly rather than parsing gdbus monitor output, filters by uid because the
signal is visible to every local user, and maps fingers to commands from a file
you own and can edit without restarting anything.
It is a separate binary and a separate subpackage because it is a separate
trust domain. /etc/fingerprintd/actions.conf is a root shell and is guarded
like one; ~/.config/fingerprintd/fingers.conf runs your commands as you, so it
is an ordinary dotfile.
Demonstrated on the phone: one press of the unlock finger both unlocks it and
opens plasma-camera.
fingerprint-auth alone was not enough. /etc/pam.d/kde-fingerprint is written
for a Fedora/authselect layout and its auth stack is two lines: a substack of
fingerprint-auth followed by an include of postlogin. Alpine ships neither.
With only the first supplied, the fingerprint MATCHED and PAM still answered
Permission denied -- the include of a missing service failing after the match
had already succeeded, which is a confusing way to be told a file is absent.
The daemon's own log said MATCH while pamtester said no.
On Fedora postlogin does lastlog and umask bookkeeping. Nothing here needs
that; what is needed is that the seam exists and contributes nothing, so the
stack's result stays the one the fingerprint substack produced. Hence four
optional pam_permit lines and a comment explaining why it is deliberately
empty rather than merely unfinished.
Also observed while testing, and worth knowing before anyone calls this
broken: the lock screen arms fingerprint ONCE when it appears, waits 30
seconds -- pam_fprintd's own timeout -- and then cancels and falls back to a
password. Pressing outside that window reaches nothing at all, and the daemon
records it as `verify: cancelled over 0 press(es)`.
Jorijn caught both.
`session` declared nothing. The FingerMatched signal is emitted for every
matched finger unconditionally -- it never consulted the config -- so a
`session` line was a rule the format invited you to write that did exactly
nothing. Announcing every finger is the right default anyway: a session agent
should not need a root-owned file to declare its interest in a signal it is
free to ignore. The column is gone.
Which leaves the config for the two things that really do need the daemon, and
with `session` gone the verdict column had no partner left to vary against. It
read as a property of the finger while being a property of the attempt, so it
is now written as what it is:
<finger> [no-unlock] [absolute command...]
no-unlock says the finger never unlocks; a command is what root runs. At least
one is required, because a finger listed alone says nothing the signal does not
already say -- and that is a parse error rather than a silently useless line.
The example config now also states plainly what no-unlock is not. It is a panic
button, not deniability: the rejection it fabricates comes back in milliseconds
where a real one takes about three seconds, the journal records that the finger
actually matched, the file names the finger in plain text, and the finger still
shows as enrolled. Both of those weaknesses are real and neither is fixed here.
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.
Jorijn asked for the control that settles it -- a fresh template, tested with
learning off -- and ran it twice.
fresh template, 0 folds 30/30, two consecutive blocks of fifteen
same lineage, 40 folds 12/15
same lineage, 185 folds total failure, 108 consecutive rejections
Every one of those measured with learning switched off during the measurement
itself, so nothing moved underneath the numbers, and the fresh-template result is
replicated back to back. Three points, monotonic in fold count.
The mechanism has been visible since the 185-fold collapse: the frames one press
contributes are near-duplicates of a single image from one finger position, so
folding them spends the template's ninety-six slots on that position and evicts
the diversity a twenty-sample enrolment put there. Stock's updates are spread
across many separate presses hours apart, which is where diversity actually comes
from.
And there is nothing on the other side of the scale. A plain enrolment measures
thirty out of thirty, so learning has no headroom to improve anything, and it has
never once been observed to raise a rate under conditions worth defending -- the
run that once looked like proof was confounded by a freshly wiped sensor and a
user learning the technique, both of which Jorijn identified himself while the
numbers were still climbing.
The code stays behind --learn=1. The finding is about this trustlet's algorithm,
not about the idea.
Same reason as enrol. A wipe is the start of a controlled sequence, and bringing
the daemon back with learning enabled invites whatever verifies next to begin
folding before anyone intended it.
Enrolment does not use learning, but the enrol step left the daemon running with
it enabled, so the brand-new template started folding the moment anything
verified. That is precisely the contamination a fresh-template control is meant
to exclude, and the control is the next thing being run. trend turns it back on.
Jorijn asked whether the timeouts were the wrong-finger path or something to do
with learning. Neither. It is a deadlock between the press rule and the
instruction the user is given.
A press was judged only when the finger was released. The user is told to hold
until it answers. So a press whose frames keep rejecting is never released, the
daemon never judges it, and the client sits there until its own timeout expires.
The transcript shows exactly that: twenty-nine consecutive full-contact frames
rejected across twenty seconds with the finger down throughout, surfaced to the
user as a hang rather than as a failure.
Detection was fine, the settled gate was fine, the matcher was doing its job and
saying no. Nothing was ever going to tell the user so.
A press now answers no-match once it has accumulated five rejected frames,
without waiting for a release. At roughly seven hundred milliseconds a frame
that is about three and a half seconds -- long enough that the frame-3 and
frame-8 matches in this project's records still land, short enough to be an
answer instead of a wait. A phone tells you it did not recognise you while your
finger is still on it.
The paired test I built cannot exist on this hardware, and finding that out cost
Jorijn his enrolled finger.
Restoring an earlier container byte for byte made the trustlet read its header,
UNLINK it, look for a .bak and advance the RPMB counter -- for both containers.
QTEE binds every SFS object to a hardware anti-rollback counter, so an earlier
version is not stale to it, it is tampered, and the response to tampering is
deletion. No copy can undo that. The journal has warned about this counter since
August in the context of the group index; it applies to the template itself just
as hard, and I did not check before building a feature on the assumption that it
did not.
So restore refuses and explains, with the measurement in the message. Snapshots
stay: they are still forensic evidence of what a template looked like, they just
cannot be put back. Changing a template means enrolling again.
The daemon compounded it. The group-selection cache stored "0 templates loaded"
as a valid answer, so once the trustlet had unlinked everything, every later
claim answered "skipped (already active, 0 template(s))" and never tried again.
It now caches only a positive result, so a failed load is retried rather than
made permanent.
Four matches, each followed by a template save, then five consecutive failures.
Jorijn asked whether it was user error. It was not.
Over one evening the harvest folded 185 frames into a template whose
max_sub_template_num is 96, and the template went from matching ten presses out
of ten to failing five in a row. The frames one press contributes are
near-duplicates of a single image, so folding eight of them per press does not
add coverage: it spends the template's slots on one finger position and evicts
the diversity the enrolment put there. Stock's roughly forty-six updates in a
session are spread across many separate presses, which is where diversity
actually comes from.
So one fold per matched press, which also needs no extra capture at all because
the matching frame is already inside the trustlet. Eight remains available for a
deliberate experiment.
The snapshot directory was resolved from $HOME while the script is run under
sudo, so every snapshot landed in /root/fp6-backups and looked, from the user's
shell, like it had never been taken. That is the one thing that would have made
this unrecoverable, and it was caught only because the restore was needed. It
now resolves the invoking user's home.
Jorijn ran the same block twice, split five held and five released, and the held
half kept costing about 2.7 seconds more per press in the client while the
daemon's own decide time stayed at 36 to 334 milliseconds either way. The gap was
not the sensor and not the matcher. It was this daemon.
The save was deferred until after the verdict was posted, for exactly the right
reason. The harvest was not, and the harvest is up to eight capture-and-fold
round trips. Holding a finger through the verdict keeps it fed to its frame
limit, so a held press folded eight frames and a released press folded one --
and every one of those folds sat between the match and the client hearing about
it.
Both now run after the event is posted. A finger held through the verdict is
still there a millisecond later, so the harvest loses nothing by waiting, and
the frame that actually matters was already folded at the moment it matched.
Selecting a group makes the trustlet reload every template in it from storage,
and on this device that is 651276 bytes crossing the listener in chunks. Measured
over ten verifications: eleven claims, eleven reloads, fifty-four chunk reads,
twenty-six megabytes of round trips. All of it happens before the verify loop
starts, so all of it lands in the latency a user feels while being invisible to
the daemon's own timing -- which is how it survived this long.
It is also unnecessary. The trustlet holds templates in memory once loaded; a
successful authentication on stock produces no storage callbacks at all. A group
that is already active does not need selecting again, so a repeat claim now
answers from what the last real selection reported.
Enrolment forces a real selection, because it adds a template and the reload is
the point.
Measured after: two claims, one real selection, one skipped, and the chunk reads
drop from five per claim to two for the pair.
Jorijn: "response times this run tanked", and then, sharply, "are you sure its
back? or has it always been like this."
It has always been like this, and the number was never measuring the daemon. The
client's wall clock starts when the verify request starts, so it includes however
long the user takes to get a finger onto the sensor. In the run that prompted the
question the slow presses spent two seconds and more watching an EMPTY sensor --
ten consecutive frames at metric 129 to 142 against a 133 idle floor -- and then
matched on the very first frame that had contact in it.
Every matched press in that run reads "press 1: 1 frames -> MATCH". Not one
needed a retry. The presses that felt instant were the ones where a finger was
already down when the request started, and the presses that felt slow were the
ones where it was not.
So the loop now times from first contact as well as from the start, and says so
in as many words. A figure that silently includes human reaction time cannot be
compared between runs, between people, or against a phone.
CONFIG=<path> copied the file to /tmp under its own basename, while the remote
half installed /tmp/fingerprintd.json. A config named anything else therefore
left the PREVIOUS deploy's fingerprintd.json in place and installed that, while
printing ">> config installed" either way.
It went unnoticed until the printed config hash did not move after a deliberate
change, which is the only reason the hashes are printed at all. An experiment had
already been deployed against the wrong config by then.
The file now crosses under a fixed name, and a deploy with no CONFIG removes any
stale one on the phone rather than leaving something for a later run to pick up
by accident.
Jorijn worked out the technique and it changes what every number in this project
means: "press and LIFT (quick tap) is wrong, holding the sensor until it gives
the result is a 100% success rate."
The logs agree, on a properly controlled comparison. Same template, same
session, learning off for all four blocks, only the technique differing: tapped
4/15 and 3/15, held 15/15 and 15/15.
The frame data says why. Over every frame this project has a verdict for, split
at 2.5x the idle floor:
full contact, interrupt settled 78/175 = 45% match
full contact, interrupt asserted 28/142 = 20%
partial, interrupt settled 1/9 = 11%
partial, interrupt asserted 0/53 = 0%
A tap is caught while the finger is still arriving or already leaving. Such a
frame is not a hard verdict waiting to happen, it is a wasted one: with the
rescan budget at 0 every frame is terminal, so its rejection ends the press. 62
partial frames produced exactly one match between them.
So the tracker becomes a Schmitt trigger. A press now STARTS on settled contact
and ENDS on the finger leaving, which means a frame taken mid-landing produces
no event at all rather than a false rejection. A press that never settles simply
yields no verdict and the loop waits for the next one, which is an honest try
again. Enrolment is untouched: it passes one threshold for both and keeps its
own sample-quality gate inside the trustlet.
fptrial.sh now says hold, and defaults to fifteen presses. Instructing a tap for
its whole life is what quietly made every rate this project has quoted a worst
case, and a tap is not a case the product has -- nobody taps a phone sensor and
walks away, they rest a finger until it unlocks.
Learning rewrites the template in place, which means a rate that climbs over an
evening has three explanations and the numbers cannot tell them apart: the
template got better, the sensor got wiped clean, or the user learned where the
sensor likes to be pressed. Jorijn named the second and third while the numbers
were still going up. All three move the same way on the same time axis, and the
first trend run had no way to separate them because no earlier version of the
template survived.
A snapshot makes the paired test possible. Measure the learned template, restore
the older one, measure again within the same session -- the sensor is equally
clean and the user equally practised across both halves, so the only thing that
differs is the template. A rate that falls back on restore is learning. A rate
that stays up is not.
Restore stops the daemon before swapping the files and brings it back with
learning off, because the trustlet caches the template in memory once loaded and
because a restored template that immediately starts learning again is not a
control.
Two changes to the measurement, both about not wasting a finger.
The wrong-finger control is off by default now. Across every run this project
has made the wrong finger has matched zero times out of forty-odd taps; the
question that is still open is the false-negative rate, and each control tap
spends a press that could have measured it. Pass a count to put the control
back, and the summary says plainly when it was not run rather than printing a
zero that reads like a result.
And a trend run now reports how many frames learning folded, out of the daemon's
own transcript, alongside the container size. Without that a run cannot tell
"learning fired and did not help" from "learning never fired" -- which is exactly
the confusion that let the first trend run measure a static template three times
and look like a result.
Default trial length goes to fifteen taps, since dropping the control freed the
presses and ten was too few to separate three-in-ten from five-in-ten.
Template learning was doing nothing. Across three measured trials, six presses
matched and five of them folded zero frames: the harvest captured a NEW frame
before folding, and by the time it ran the finger was gone, so the capture read
the idle floor and the loop exited. Every press in those trials was exactly one
frame long -- a tap lasts 400 to 600 ms and a frame costs 200 to 300, so there
is never a second frame to harvest.
Stock does not capture first. In the reference trace UPDATE_TEMPLATE follows
do_authenticate directly -- auth success score, authenticated result is updated,
CANCEL, checking the template, UPDATE_TEMPLATE -- with no CAPTURE_IMAGE between
them. The trustlet still holds the image it just matched against, so the frame
that produced the verdict is the frame to fold, and it costs one command with
nothing on the sensor.
So the fold happens at the match site now, and the harvest continues from slot
one for as long as the finger actually stays down. A quick tap folds exactly one
frame instead of none, which is the case that matters: a quick tap is what a
user does.
The touch-frame flag follows the event that carried the verdict, so a match on
the rising edge sets bit 6 exactly as stock does.
Measured 2026-09-04: the trustlet's duplicated-finger check refuses to re-enrol
a finger it already has a template for -- 0 accepted of 7 presses, rc=0 on each,
while a never-enrolled finger progressed normally. Re-enrolment adds a template
and there is no trustlet-side remove, so a measured finger's old template has to
go before it can be enrolled again.
wipe does that the way it has been done by hand twice: backup first, daemon
stopped so the trustlet reloads from the store, only the template containers
removed, the group index kept because deleting it risks the RPMB anti-rollback
counters going stale, the name map cleared, then a restart and the sizes.
enrol checks the name map and refuses a finger that is already there, pointing
at wipe, so the refusal cannot be mistaken for bad pressing again.
A refused enrolment sample is one of two things: an image the algorithm saw and
turned down (rc=0, samples remaining unchanged) or an error the trustlet never
got past (a negative rc). The touch line printed the count and the fid but not
the rc, so a run of twenty-two refusals in a row said nothing about which it was.
It does now.
EXTRA=... on deploy-dev.sh appends daemon flags, so a diagnostic session can
come up with --ta-log without editing the script or the unit by hand.
Nothing is packaged yet, so the binary, the scripts, the module load, the
persist mount and the transient unit all live in places a reboot wipes. That is
deliberate -- a reboot leaves a stock phone rather than a half-installed daemon
-- but its cost was a list of manual steps in a journal handoff, and the second
reboot of the day showed what that costs. The list is now a script.
Two things it gets right that a first draft did not. The readiness check is
scoped to the current systemd invocation: the journal persists across restarts
and reboots, so grepping the whole unit history matches the previous run's ready
line and reports the daemon up while the session is still coming up on the
worker thread. And the binary is copied under a new name and swapped in with mv
after the unit stops, because a running executable cannot be overwritten and
scp reports that only as "dest open: Failure" -- which a retry loop turns into
six identical failures instead of one clear one.
Verified from a freshly rebooted phone and again over a running daemon.
Learning rewrites the template on every matched press, so run two is not a
repeat of run one and an A/B against a moving template is not an A/B. The order
is the measurement:
enrol a fresh template at 20 samples with no position prompts, which is also
the outstanding replication of the best result this lane has seen
base learning off: the clean number for that template, and the only figure
comparable to every rate already recorded
trend learning on, three times: the rate should climb, with the container
size as an independent witness that it is the template moving
A rate that climbs while the body grows is learning. A rate that moves while the
body does not is noise, and the daemon's own learn: lines say which. Run one of
the trend is not evidence that learning helped; it starts on the template the
baseline ended on.
One limit the script states rather than letting someone discover it: learning
only fires on a press that matched, so a template that never matches never
improves. That is why the protocol re-enrols instead of building on a template
already measured at 0 of 10.
The matcher has been a black box that answers yes or no, and that is why "the
matcher saw a full-contact image of the enrolled finger and rejected it" went a
whole session with no explanation.
There is no tzdbg on mainline -- /sys/kernel/debug/tzdbg does not exist on this
kernel -- so the /proc/tzdbg/qsee_log route that captured the Android reference
log is unavailable, and the qcomtee qseelog ring is on record as wedging TZ. But
focal64 writes its log into the response buffer, which is how the research
harness printed it all along. --ta-log scans it, so the matcher's own verdicts
are readable on pmOS: auth success score, identify fail with the
FtVerifyByTemplate return, and the per-frame image quality, coverage and
humidity.
Turning it on taught three things, all of which are configuration rather than
code.
A log level is not enough. The trustlet answered "no key named
diagnosis.enable_algorithm_log, use default value" -- that switch and two
siblings are separate on/off gates that stock sets on and we had never sent at
all, so the algorithm log level was being applied to a stream that was off.
Lower is more verbose and 6 is off: level 0 produced 244 lines where 5 produced
far fewer. That settles a direction the config generator explicitly left open,
and it means the old verbose setting of 5 was very nearly a quiet one.
The ring is the scarce resource. It is about 150 lines per session and is never
reset, so the config dump alone overflows it: at framework level 0 the dump
produced 244 lines and UPDATE_TEMPLATE's own lines never arrived. The shipped
verbose config now leaves the framework log off and the algorithm log at 0,
which cut the init ring to 38 lines and reserves it for the matcher. Framework
tracing is a separate run and cannot also have the matcher's lines, and the
level cannot be raised later because 6 is unrecoverable by a runtime SYNC_CONFIG.
Template learning, the half of the algorithm this daemon never ran. Every match
rate measured against this device -- 1/10, 2/10, 3/10, 7/10 -- was measured
against a day-zero template that no stock user lives with, because a stock
template is rewritten on every successful press and ours never moved a byte.
HarvestTemplate mirrors stock's post-match loop: while the finger is still on
the sensor, capture and fold, sending no event so the matcher cannot re-run and
revise a verdict the client already has. A quick tap pays almost nothing, since
the finger is gone by the time a verdict lands and the first capture reads the
idle floor; a held press contributes the frames it was actually held for.
That last property is why this subsumes the enrolment-tuning thread. The working
hypothesis after the strict-threshold and 30-sample failures was that enrolment
conditions have to resemble verification conditions. Learning is exactly that,
done by the algorithm from real unlock presses instead of by coaching a user
into positions they never use.
FlushTemplate issues the SAVE_DATA, and the worker calls it after the verdict is
posted rather than before. Persisting a learned template is roughly 350 ms of
gpfile and RPMB traffic and it does not belong on an unlock path; stock defers it
the same way, with a lazy-updater timer.
--learn=0 turns the whole thing off, which is the only way the comparison is
single-variable: learning is cumulative, so an A/B needs one binary and one
template lineage rather than two builds. --learn-frames bounds what one press may
contribute, because the template body moves as a single gpfile op against a
516084-byte listener buffer and a 30-sample body already measured 386402.
--probe-learn sends one UPDATE_TEMPLATE with no finger and then ENUMERATEs to
prove the trustlet survived it, which is the part a bare return code cannot say.
Stock rewrites the stored template on every successful press. Its post-match
loop is QUERY_FINGER_STATUS, CAPTURE_IMAGE, 0x1015 UPDATE_TEMPLATE while the
finger stays down, with no REPORT_EVENT in it -- so the matcher does not re-run
and the verdict cannot change. Forty-six of those against eighty-six captures in
one reference session, and the stored body measurably grows: 333278 bytes at
enrolment, 360822 at the next session's load, 371734 after one authentication
session. This daemon sent none of them.
The command shares REPORT_EVENT's event context. The stock wrapper memsets 732
bytes and writes six fields: a zero byte at +0x2a4, the scan-slot count, a zero
word, the count of frames folded so far in this press, a flags word of
0x00080000 with bit 6 set on the frame whose event was FingerTouched, and a zero
at +0x2d8. Declared length 0x2dc.
+0x2d8 is the one that matters, and it matters by staying zero. The dispatcher
stub reads it after the handler returns and only if it is non-zero does it read
+0x2dc and make that the response length. Every earlier attempt in this project
set both fields and varied the declared length across 0x2e0, 0x400 and 0x1000;
all of them answered -90, the trustlet gone, and the conclusion recorded was
"do not retry until a template is loaded". A loaded template was necessary but
not sufficient. The stock HAL sets neither field.
Measured on the device with two templates loaded and no finger: both branches
answer rc=0 and ENUMERATE still reports 2, so the app did not fault.
Those fields are little endian, assembled low-address-first by the handler. An
earlier reading called them big endian, off the bfi order, and was wrong.
Bit 6 selects which algorithm entry runs: clear takes libfp_template_x_update,
set takes the other, which also reads the scan-slot count.
pos() was eval'ing over the script's positional parameters from inside a
function, where $1 is the function's own argument. So `pos 3` printed "3" and
`pos 10` printed "100": every run this script has ever driven printed sample
numbers where positions should have been.
That rewrites an earlier conclusion rather than just fixing a bug. No enrolment
on this device had ever been guided, including the one that produced the best
template measured so far -- its spread came entirely from the config's overlap
band refusing near-duplicates, not from anything this script said. The
paired-test attribution drops a contributor, and the 30-sample run becomes
directly comparable to it because both were equally unguided.
Prompts are therefore opt-in now, behind FPENROL_GUIDE=1. The first run where
they actually fired steered the finger to edges, tips and hard rolls, needed 74
presses for 30 accepts, and produced a template that matched 0 of 10 taps.
Prompting a user toward positions they never use in a real tap builds a template
of positions they never use in a real tap. The default is the instruction that
worked: press as you would to unlock, and let the refusals move you.
The stage count comes from the daemon's num-enroll-stages property rather than a
second hardcoded 20.
Three fixes from the same session, all of which had been left uncommitted.
The tee_shm fd leak is the serious one. The per-frame capture region was
released only on the invoke-FAILURE path, on the belief that an invoke consumes
its input objects. That is libqcomtee's rule for callback objects, not memory
objects -- its own ta_load.c hands a memory object in exactly this way and
releases it unconditionally afterwards. So one fd leaked per captured frame, and
the first daemon instance to live through ~1000 frames hit the 1024 limit: every
capture then answered "memory region alloc failed" and an enrolment in progress
ran out of frames with nothing on the sensor to blame. Soak-proven fixed at 93
frames with the fd count flat at 2-3.
The enrolment sample count lived in two places, a hardcoded 20 here and
common.max_enrolling_samples in the trustlet config. When the config said 30 the
daemon still advertised 20 stages, so the progress counter froze at 20/20 and
the run looked clamped or hung when in fact all 30 samples were taken. It now
comes from the same JSON the trustlet is given, so the two cannot drift, with
--samples= as a deliberate override.
--probe-ta-load loads one TA image through the daemon's own loader and reports
the raw loader result. It brings up only what a load needs and unloads
afterwards, so a refusal is inert.
Jorijn asked whether re-enrolling a finger overwrites its template. It does
not. The trustlet stores a new one and keeps the old, because
FF_CMD_TA_REMOVE is not implemented -- the group on this device now holds six
templates, including one from the research harness and a pair from an
enrolment two configs ago.
The trustlet identifies against every template loaded in the group, and this
daemon reported verify-match for whatever fid came back. So a request naming
one finger was answered by any of them, including templates no name maps to
any more. That is wrong by fprintd's contract, and it also means the last
measurement was taken against the union of every template ever enrolled here
rather than against the one under test.
VerifyStart now computes which fids may answer -- the named finger's, or every
named finger's for "any" -- and a match on anything else is not a match for
that request. A fid that no name maps to answers for nothing at all.
This does not reclaim the slots. Five templates per group is the configured
limit and stale ones still occupy it; removing them needs FF_CMD_TA_REMOVE,
whose payload is not reverse-engineered.
The enrol callbacks emitted enroll-stage-passed and enroll-retry-scan as D-Bus
traffic and wrote nothing to the transcript. So a grep for refusals in the log
of the guided enrolment found none, and I recorded that the new coverage and
overlap thresholds might have refused nothing at all -- while Jorijn had been
watching the refusals scroll past on the client, which is where the signal
actually surfaced.
The conclusion was drawn from the absence of something never written. Both
outcomes are now logged with the running count, so a run's refusals can be
counted from its transcript instead of from whoever happened to be watching.
Jorijn asked whether the sample count is ours to control and whether more
samples would help. It is -- and the config dump says something more useful.
Stock enrols with 20 samples, not the 10 we had guessed, but it also sets six
keys we were leaving entirely to the trustlet's built-in defaults:
min_enrolling_coverage_threshold 70
min_enrolling_quality_threshold 20
enroll_overlap_min_area 60
enroll_overlap_max_area 80
enable_duplicated_finger_checking on
max_extral_enroll_low_quality 16
Those defaults accept anything, which is how ten quick taps in one position
became a stored template. The overlap bounds are the mechanism that matters:
a sample must overlap the previous one by 60 to 80 percent -- more means the
finger did not move, less means a gap -- so the algorithm now refuses the
same-spot sample instead of storing it. Sample count alone would have stored
twenty near-duplicates rather than ten.
Deliberately left out: min_identify_quality_threshold and
min_identify_coverage_threshold. Those gate matching rather than enrolment and
would reject exactly the landing frames the 1.5x detection threshold exists to
catch. One group of variables at a time.
fpenrol.sh grows to twenty positions, and its rejection message now says to
move rather than to press harder, because the enforcement and the guidance
finally agree on what a rejected sample means.
The threshold change is the first thing to move accuracy. Labelled protocol,
enrolled quick taps: 4 of 10, against 2 of 10 for every previous build. Seven
of fifteen presses now get two or more frames where none did before, and the
landing frames the old threshold discarded turn up in the transcript at 207,
213, 242 and 284. Wrong finger still 0 of 5.
It also explains the latency asymmetry Jorijn noticed. A match ends the loop
the moment it happens, mean 1317 ms. A no-match waits for the finger to lift,
mean 2190 ms, because a later frame in the same press may still match -- and
they do, at frames 3, 5 and 8. That is the press rule working, not a fault.
What the same run says about the template is worse than the loop ever was. One
press produced eight frames at full contact, 362 to 367, and every one
rejected; another produced six. Roughly one frame in seven matches, against the
47 to 75 percent the journal records for the template the research harness
enrolled. The first template here was ten quick taps in about one position, so
the algorithm was handed ten near-duplicate images of one spot.
fpenrol.sh enrols with a different contact position per ACCEPTED sample --
centre, left, right, tip, joint, rolled either way -- driven by
fprintd-enroll's own per-stage output rather than by counting presses. Enrol as
a SECOND finger so both templates coexist and the comparison holds the loop
constant; the trustlet reports which fid matched, and the daemon's map turns
that back into a name.
Three loop changes have now failed to move quick-tap accuracy: the frame gap
from 500 to 40 ms, the rising edge from two matcher runs to one (3x cheaper
frame), and waking on the touch edge instead of polling. All three left every
press at exactly one frame and the rate at 2 of 10. The transcript says why:
frame 20 @ 4005ms: metric=247 irq=1 finger landing, below threshold
frame 21 @ 4399ms: metric=366 FINGER rej detected; this frame costs ~400 ms
frame 22 @ 4562ms: metric=132 already gone
A frame that detects a finger takes 400-580 ms to process, of which the
trustlet's own REPORT_EVENT is about 300, and a quick tap lasts 400-600 ms.
There is no room for a second frame however early the loop wakes. Speed was
never the constraint.
But the landing frames are being thrown away. 209 and 247 against a 133 floor,
with the interrupt already asserted, discarded by a 2x threshold -- and they are
the only frames a quick tap has to spare. 1.5x puts the threshold at 200: above
the highest idle drift observed (147), below the lowest landing frame seen
(209). The tests pin it between those two measurements rather than to a
constant, and assert that 2x would have discarded both.
Single variable against the labelled 2-of-10 baseline.
The measurement that made this worth building: gpio75 is silent at idle under
WAIT_TOUCH -- zero edges in sixty seconds -- and bursts within milliseconds of
a finger landing. In the observed taps the burst appeared in the transcript
hundreds of milliseconds before the polled capture noticed the finger, which is
why a quick tap only ever produced one frame however cheap the frame became.
So the inter-frame wait is now a wait on the line rather than a sleep. At idle
it times out at the fallback cadence and costs nothing. At contact it returns
at once, so the first capture of a press happens when the finger lands. While
the finger stays down the sensor keeps pulsing, so the wait keeps returning
immediately and the loop runs as fast as QTEE allows -- which is what a press
wants and what stock's architecture does.
Queued edges are dropped when a session arms, or the previous press's burst
would wake the first wait instantly. --edge-wake gates it as a single variable
against the labelled 2-of-10 baseline; it and --irq-observe are mutually
exclusive because both would drain the same fd.
Taps are one frame at ~200 ms per frame just as they were at ~700, so the
polling cadence is what catches a tap once and the loop's cost is no longer the
limit. The remaining lever is the architecture stock uses: react to the touch
edge, then capture as fast as QTEE allows for the length of the press.
That rests on a prerequisite worth measuring before a line of it is written.
The IRQ line is requested with both edges enabled and an observer thread polls
it and logs every event with the kernel timestamp, the interval since the last,
and the pulse width. Pure observation -- the matching loop is untouched.
Two questions it answers. Whether edges are observable from userspace at all,
and how quiet the line is at idle under an armed session: the level poll caught
it high on 5 of 136 idle frames, so there are pulses at rest, and if they are
frequent a wake-on-edge is dead before it starts.
Labelled baseline on the proven loop, quick taps only: enrolled finger 2 of 10,
wrong finger 0 of 5. Every press was one frame.
The rising-edge frame costs ~700 ms because it runs the matcher twice -- event 5
and event 7 on the same image, two verdicts back. A human tap is over before a
second frame can exist at that cost. Keeping only the touch event keeps what
every recorded match followed, halves the rising frame, and may be the
difference between one frame per tap and two. It is a single variable against a
labelled baseline; if the rate drops, it comes out.
Also fixes fptrial.sh's latency column, which was all zero: busybox date has no
%N, so it reads /proc/uptime instead.
Thirteen real fprintd-verify runs produced four matches and nine misses and no
rate, because nothing recorded which finger each run used. This script runs the
protocol -- N quick taps with the enrolled finger, then N with a different one
-- tells the user which finger and which tap they are on, and records the label
and the wall-clock latency from prompt to client result per tap. The daemon's
transcript has the frames; this has the labels. A loop change is measured
against this, one variable at a time.
Two changes went in together and the next four runs matched nothing, including
a held press. They cannot be separated after the fact, so both come out and the
loop returns to the shape that has matched every time it was asked to.
One is definitely broken. The rising-edge recapture assumed a frame 50 ms after
detection would show a settled finger; on a quick tap the finger was already
gone, the recapture read the idle floor -- metric 133, still flagged FINGER
from the first capture -- and an empty image went to the matcher. A guaranteed
miss on exactly the case it was meant to fix.
The other is probably wrong. Dropping event 5 as a duplicate rested on
observing that event 7 alone produces a verdict -- but every such observation
was a held frame that followed an event 5 on the same press. Whether the touch
event initialises the press in the trustlet is not known, and five finger
frames with no match is not the evidence to remove it on.
The process error is the one worth writing down: two variables changed at
once, on a live user's finger, with no way to attribute the result. One at a
time from here.
Two changes to the verify loop, both from measurement on the daemon.
The rising edge sent events 5 and 7 from the same capture and got two verdicts
back from one image -- rej rej, -11 -11, MATCH MATCH. Event 5 reaches the
matcher here as well as event 7, so the second REPORT_EVENT was 250 to 300 ms
of redundant work on every press, on the frame where speed matters most.
Authentication now sends only event 7. Enrolment keeps event 5, where it is the
sample trigger rather than a duplicate.
And the frame that detects the finger is the finger landing: partial contact,
and the frame that rejects most often -- across the real runs matches came at
frame 3, 5 and 8 of a press, and a quick tap is one frame. So on the rising
edge the daemon captures once more, about 50 ms later, before reporting, and
the matcher's first look is at a settled finger.
The rescan-budget experiment is reverted. At the stock budget every
non-matching frame answered -11, for the enrolled finger and the wrong one
alike, while matches landed exactly where they did at rescan=0. The budget
relabels a non-match; it does not make the trustlet try harder. Under the press
rule the two are functionally identical, and rescan=0's terminal rejection is
the cleaner label.
rescan=0 made every frame terminal, which is what stopped a wrong finger from
hanging the client -- but it also disabled the trustlet's own "image not good
enough yet, try again" answer, so a marginal first frame became a hard
rejection. In real use that showed as a quick tap of the enrolled finger
answering verify-no-match: one frame, rejected. Matches land at frame 3, 5, 8
of a press; the first frame is the finger landing.
The alternative is to let the trustlet keep its rescan budget and handle the
wrong finger where it actually manifests, at the press level: a press that
lifts with no terminal verdict is reported as no-match. The trustlet then
answers -11 on marginal frames instead of rejecting them, and the press keeps
going until it matches or the finger lifts.
A knob rather than a decision, because the trade-off is measured, not assumed:
under the stock budget seven of nineteen correct presses ended undecided at the
old 500 ms frame rate, and whether the faster loop closes that gap is the
question the next runs answer.
A claim is held by a bus connection. If that connection goes away -- the client
crashed, was killed, or never called Release -- the claim has to go with it, or
the device is AlreadyInUse for everyone until the daemon restarts. fprintd
watches the claimant's name for exactly this reason.
Found the hard way: a Claim issued from one busctl invocation, which exits the
moment it returns, left the device permanently claimed by a connection that no
longer existed. The daemon now subscribes to NameOwnerChanged for the
claimant's unique name and, when it loses its owner, cancels any running
operation and clears the claim. Release goes through the same path so the
subscription is torn down either way.
Verified with the stock client killed mid-verify under timeout: the claim
dropped, the verify cancelled, and fprintd-list worked immediately after.
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.
A wrong finger against the daemon was a silent wait: the loop exited only on a
terminal verdict, and at the stock rescan budget a wrong finger never produces
one -- it answers "not identified yet" on every frame until the right finger
shows up. fprintd's PAM module needs a verify-no-match to deny or retry, so
that is a client that hangs.
The unit of decision is now a press. Within one press the matcher may reject
early frames and match a later one, so a press is judged when the finger lifts:
any match wins, only rejections is no-match, no terminal frame at all is
undecided and scanning continues. A press that matches is reported the moment
it does rather than making the user hold for a release.
Undecided presses are exactly why the rescan budget matters here. At 0 every
frame is terminal and every press decides; at the stock budget seven of
nineteen correct-finger presses ended undecided in the last measurement, which
under a press rule would read as rejections. So the daemon is being run with
rescan forced to 0 while that trade-off is measured on the new template rather
than assumed.
Every frame is logged under --verbose and every press always, so the next
wrong-finger control is visible in the transcript instead of absent from it.
fprintd's contract: a status with done=true means no more status is coming,
not that the operation is over. The client still calls EnrollStop or
VerifyStop, and until it does the device is busy with that operation. Clearing
the op on done made every stock client's Stop fail with NoActionInProgress --
seen on the first fprintd-enroll against this daemon, which otherwise succeeded
through all ten stages.
Clearing it from the worker was also a race: a client that cancels and
immediately starts a new operation would have had that new operation cleared by
the old one's completion event. The worker no longer touches the op state at
all; only Stop and Release do, on the main thread.
