Repository navigation
goodixtls5f10: optional Linux-side TLS-PSK provisioning (opt-in) - #6
Open
mounkastel wants to merge 4 commits into
Open
mounkastel wants to merge 4 commits into
mounkastel wants to merge 4 commits into
Conversation
The 5F10 only speaks TLS once the MCU carries a TLS-PSK, so far the driver could only read the chip-side hash of that key (0xE4). Add the matching write command 0xE0, mirroring goodix_send_preset_psk_read(): same production-layer send (calc-checksum, 1000 ms reply wait), reply body discarded.
Pack a host-generated 32-byte PSK into the TLV-1 body the MCU's preset-PSK slot hashes (AES-256-GCM + HMAC-SHA256 with static protocol material), and decide a 0xE4 read without touching hardware: match / mismatch / missing / invalid. Provisioning itself stays opt-in: only GOODIX5F10_AUTOPROVISION=1 acts on the decision; a missing or mismatching key fails the open otherwise. Unit tests cover the payload shape, the read decision and the env parsing.
During activation the driver reads the chip's preset-PSK hash with 0xE4 and compares it against SHA256 of the TLV-1 body of the loaded key: matching means go, missing/mismatching with provisioning opted in (GOODIX5F10_AUTOPROVISION=1) means generate/write 0xE0/read-back-verify, everything else fails the open with no write. The write is verified strictly before the key file is saved. load_secrets() only generates a fresh key when the file is absent; unreadable or wrong-length files fail the open so a recovered-from-Windows key is never silently replaced. save_psk() creates the key file O_CREAT|O_TRUNC|0600 in one open and the session key buffer is cleansed on close.
mounkastel
marked this pull request as ready for review
October 18, 2026 17:47
One neutral section next to the per-device PSK chapter: what the opt-in GOODIX5F10_AUTOPROVISION=1 path does (generate, write 0xE0, read back 0xE4, verify against SHA256 of the TLV-1 body, save 0600), that re-provisioning is covered by the same opt-in, and the dual-boot warning about the shared PSK slot. The read-only Windows-key recovery route is unchanged.
mounkastel
force-pushed
the
provisioning
branch
from
October 19, 2026 04:41
be6193d to
bda8c51
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds provisioning of the 5F10 TLS-PSK from Linux, without Windows. Off by default: nothing is written
to the sensor unless
GOODIX5F10_AUTOPROVISION=1is set.With the opt-in: if the key file is absent (
ENOENTonly), the driver generates a key, writes it with0xE0, reads it back with0xE4, checks it againstSHA256(TLV-1 body)and saves it (mode 0600).A stored key that no longer matches the chip is re-provisioned the same way. An unreadable or
wrong-length key file fails the open and is never replaced.
Without it, behaviour is unchanged, except that a key that does not match the sensor now fails the
open early with a clear message instead of a later handshake timeout.
Related: #5 (FMI-76 test report).
Testing
read-back matched, enroll/verify worked. See Testing report: FMI-76 (same model as #1), Arch Linux, PSK generated and provisioned on Linux with no Windows data #5.
load_secrets()) has not been run on hardware.tests/test-goodix5f10-config.cwere not run.Note: the key slot is shared with the Windows driver; on the one dual-boot machine I tried, each
side rewrote the key on mismatch (see #5).
Not included: the standalone pyusb tool,
.gitignorechanges.