The working principle of Android phone fingerprint driver

1 TrustZone
supports TrustZone's ARM with one more NS (Non-Secure) per peripheral control line. When the NS bit is 1, it means that it is non-secure world access (such as Android).
The method of TZ controlling peripherals is similar to x86 Pass-Through.

2 Principle
Question:
Why should fingerprint payment be driven in TZ?
Answer: The
TZ side that needs payment function, the AP side that does not require payment function.
TZ has its own protected dedicated memory area, which requires special permissions.

Question:
For example, as follows, I have recorded a lot of fingerprints in my phone through settings, and now I press my thumb on the sensor to unlock or pay. What is the process?
Answer:
1. The mobile phone stores fingerprint characteristic data, not in the fingerprint IC, but in the eMMC/UFS on the SoC side;
2. The stored data is encrypted and managed by TZ, so even if it is available on the Linux (Android) side It can’t be decrypted and used either;
3. The comparison process is roughly as follows: TZ collects the fingerprint from the fingerprint IC through SPI (here, dot matrix data, which is the image), and then calls the comparison function of the fingerprint comparison library in TZ, There are several important parameters in this function,
a. Fingerprint template pointer
b. Fingerprint template number
c. Fingerprint image Buffer pointer
comparison function that needs to be compared will return the sequence number and matching percentage of the fingerprint template with the best matching degree. Call the function to determine whether the comparison is done. The detailed comparison process is described below ;
4. So when there are multiple templates, you can call it only once, or call for(...), depending on your caller. Most implementations generally call it once.
5. Since SPI communication is the bottleneck in this process, Quick Match is to take 1/4 of the picture first. You can understand that it is similar to Thumbnail and then sent for comparison. If the result cannot be judged, then get back the whole picture. Figure, continue to compare.

The detailed comparison process is as follows:
Android has provided a part of the framework since MNC 6.0. General manufacturers can follow Google's Framework to implement the necessary functions. The final form is a .so file, which is loaded and executed by the Google Fingerprint framework.

A fingerprint template is generally 100~300K, so even if there are 10, about 3M RAM is enough. It is not very burdensome for mobile phones with a few G RAM now.

Android sends a comparison request --> SPI data under TZ, wait for the finger to press the interrupt --> Return to the Android side to run the

finger press to interrupt arrival (Android side) --> call the TZ side comparison process function (read the picture through SPI- ->Image preprocessing-->Call algorithm library comparison)-->Return the comparison result to Android.

If the comparison is correct, the Android side will unlock or perform other operations. Otherwise, it will generally vibrate, indicating a failure; if there is no vibration, it means that there is no finger or the finger left quickly, so no data is obtained.

The more expensive part is the system call, that is, from Android --> Tuning Linux Driver --> Tuning smc into TZ --> Execute --> Return.

3 URLs
MSM8998 (Qualcomm 835 processor) external fingerprint recognition sensor
http://www.seotest.cn/jishu/32751.html

adnanjee/Goodix-GF3208
https://github.com/adnanjee/Goodix-GF3208

4 Abbreviations
MISO: mi s əu
MOSI: m əu si
QUP: The SPI bus and I2C of the Qualcomm platform share the core and pins, called QUP (QCOM Universal Peripheral); and UART and QUP share pins, and are called BLSP
SerDes: sir-deez
USB overhead: overhead, packet header and packet end bytes added by the protocol layer instead of the application layer, that is, a USB packet The additional bytes (Token, ACK, CRC, etc.) in addition to the payload are called overhead