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.
Jorijn van der Graaf
21d6aa448c