kit/linux-gts6l
1
0
Fork 0
Code Issues 18 Pull requests Projects Releases Packages Wiki Activity Actions

Fingerprint: EgisTec ET713 (ET7XX) over non-secure SPI0 #11

New issue
Open
opened 2026-08-21 15:18:45 +00:00 by kit · 0 comments
kit commented 2026-08-21 15:18:45 +00:00
Owner
Copy link

Feasible — and, contrary to the usual "fingerprint is locked in TrustZone" assumption, this sensor's imaging path is non-secure AP-side SPI. The proprietary trustlets are the least necessary piece.

Hardware

  • EgisTec ET713 (ET7XX family), capacitive, from battery-data/fingerprint dtsi: compatible = "etspi,et7xx", etspi-chipid = "ET713", etspi-modelinfo = "T865".
  • Bus: SPI0 = qupv3_se0_spi = spi@880000 (QUP0/SE0) — a normal AP-side geni SPI controller. Mainline already has it as spi0: spi@880000 under geniqup@8c0000. Not the SSC island, not TZ-reserved.
  • GPIOs: reset/sleep = tlmm 7, LDO/power = tlmm 6. spi-max-frequency = 50 MHz.
  • Defconfig: CONFIG_SENSORS_ET7XX=y, CONFIG_SENSORS_FINGERPRINT=y.

Why it's not TZ-locked here (corrects an earlier assumption)

The GPL driver (drivers/fingerprint/et7xx-spi.c, et7xx-spi_data_transfer.c, in the Samsung tree — not confidential) does the imaging itself: ~182 spi_sync calls, etspi_io_read_register / etspi_io_burst_read_register reading image data directly.

The secure-vs-not choice is a build flag: et7xx-spi_data_transfer.c wraps every transfer in #ifdef ENABLE_SENSORS_FPRINT_SECURE → return 0 (TZ owns the bus) #else → real spi_sync. Production Android builds it secure; we build it non-secure and the AP reads raw images. This is the EgisTec capacitive path, unlike the Qualcomm ultrasonic QBT2000 (which genuinely uses TZ-owned SPI).

The CONFIDENTIAL trustlets (SecFinger, tigerfp, BioAuthDriver, ifbio) only do template matching/storage — which on a Linux phone is replaced by userspace. Not needed.

Plan

  1. Enable spi0 + pinctrl in our DTS; add an etspi,et7xx child at reg=<0>, with reset tlmm 7, LDO tlmm 6, 50 MHz.
  2. Port the GPL et7xx-spi.c to mainline, built non-secure (ENABLE_SENSORS_FPRINT_SECURE off) so the AP does the SPI. Reshape its ioctl/imaging surface toward something a userspace matcher can consume.
  3. Bring-up check: power the LDO, read the chip ID register over SPI — expect ET713. That alone proves the bus + driver.
  4. Userspace matching — the real risk. libfprint has EgisTec drivers but ET713/ET7XX support specifically is unverified. If unsupported, we can read the sensor but can't authenticate until a matcher exists. The matching algorithm is not in any GPL source we can use (the trustlet is a black box we won't lift).

Verdict

Kernel-side (sensor powers on, produces raw images): very doable, ~1 session. End-to-end auth: gated on libfprint ET713 support — needs checking before promising a working unlock. Not blocked on the CONFIDENTIAL source at all.

Feasible — and, contrary to the usual "fingerprint is locked in TrustZone" assumption, this sensor's imaging path is **non-secure AP-side SPI**. The proprietary trustlets are the *least* necessary piece. ## Hardware - **EgisTec ET713** (ET7XX family), capacitive, from `battery-data`/fingerprint dtsi: `compatible = "etspi,et7xx"`, `etspi-chipid = "ET713"`, `etspi-modelinfo = "T865"`. - Bus: **SPI0 = `qupv3_se0_spi` = `spi@880000` (QUP0/SE0)** — a normal AP-side geni SPI controller. **Mainline already has it** as `spi0: spi@880000` under `geniqup@8c0000`. Not the SSC island, not TZ-reserved. - GPIOs: reset/sleep = `tlmm 7`, LDO/power = `tlmm 6`. `spi-max-frequency = 50 MHz`. - Defconfig: `CONFIG_SENSORS_ET7XX=y`, `CONFIG_SENSORS_FINGERPRINT=y`. ## Why it's not TZ-locked here (corrects an earlier assumption) The GPL driver (`drivers/fingerprint/et7xx-spi.c`, `et7xx-spi_data_transfer.c`, in the Samsung tree — **not** confidential) does the imaging itself: ~182 `spi_sync` calls, `etspi_io_read_register` / `etspi_io_burst_read_register` reading image data directly. The secure-vs-not choice is a build flag: `et7xx-spi_data_transfer.c` wraps every transfer in `#ifdef ENABLE_SENSORS_FPRINT_SECURE` → `return 0` (TZ owns the bus) `#else` → real `spi_sync`. Production Android builds it secure; **we build it non-secure and the AP reads raw images.** This is the EgisTec capacitive path, unlike the Qualcomm ultrasonic QBT2000 (which genuinely uses TZ-owned SPI). The CONFIDENTIAL trustlets (`SecFinger`, `tigerfp`, `BioAuthDriver`, `ifbio`) only do template matching/storage — which on a Linux phone is replaced by userspace. Not needed. ## Plan 1. Enable `spi0` + pinctrl in our DTS; add an `etspi,et7xx` child at `reg=<0>`, with reset `tlmm 7`, LDO `tlmm 6`, 50 MHz. 2. Port the GPL `et7xx-spi.c` to mainline, built **non-secure** (`ENABLE_SENSORS_FPRINT_SECURE` off) so the AP does the SPI. Reshape its ioctl/imaging surface toward something a userspace matcher can consume. 3. Bring-up check: power the LDO, read the chip ID register over SPI — expect ET713. That alone proves the bus + driver. 4. Userspace matching — **the real risk.** libfprint has EgisTec drivers but ET713/ET7XX support specifically is unverified. If unsupported, we can *read* the sensor but can't authenticate until a matcher exists. The matching algorithm is not in any GPL source we can use (the trustlet is a black box we won't lift). ## Verdict Kernel-side (sensor powers on, produces raw images): very doable, ~1 session. End-to-end auth: gated on libfprint ET713 support — needs checking before promising a working unlock. Not blocked on the CONFIDENTIAL source at all.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
gts6l/6.17
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
kit/linux-gts6l#11
No description provided.