f35dd0322a
Remove ~400KB of compiled-in .inc blob files and replace with a runtime data loader that reads HMAC-SHA256 verified .bin files from disk at device open time. New components: - validity_data.h/c: Runtime data file loader with HMAC-SHA256 integrity verification. Searches /usr/share/libfprint/validity/ and /usr/local/share/libfprint/validity/ for per-device and common data files. Skipped entirely in emulation mode. Changes to existing code: - validity.c: New OPEN_LOAD_DATA SSM state loads device and common data files between firmware info reception and init sequence. Populates TLS key pointers from loaded data. Frees data stores on close. - validity_hal.h/c: Simplified device_table to vid/pid/flash_layout only (all blob pointers and partition_sig removed from structs). - validity_pair.c/h: Updated make_cert, build_partition_flash_cmd, build_tls_flash to take data parameters instead of using compiled-in arrays. Reset/DBE blob accessors use data store. - validity_tls.c/h: Removed 4 static key arrays, added pointer fields to ValidityTlsState populated from loaded data. - validity_db.c/h, validity_fwext.c/h: Updated get_write_enable_blob to take FpiDeviceValidity* and access data store. - validity_enroll.c: Updated all 5 callers for new signatures. Deleted files: - validity_blobs_0090.inc, validity_blobs_0097.inc, validity_blobs_009a.inc, validity_blobs_009d.inc (~400KB) - validity_pair_constants.inc (~6KB) Tests (171 total, all passing): - 15 data loader tests covering: empty store, double-free safety, valid/corrupt/too-small/nonexistent file loading, tag enum, load_device with missing dir/missing mandatory file/valid files/ corrupt HMAC, load_common with missing/valid files, enroll db_write_enable accessor with empty and populated stores. - All existing unit and integration tests updated and passing. The data files are distributed separately via the libfprint-validity-data package. |
||
|---|---|---|
| .. | ||
| aes2501 | ||
| aes3500 | ||
| egis0570 | ||
| egismoc | ||
| egismoc-05a1 | ||
| egismoc-0586 | ||
| egismoc-0587 | ||
| elan | ||
| elan-cobo | ||
| elanmoc | ||
| elanspi | ||
| focaltech_moc | ||
| fpcmoc | ||
| goodixmoc | ||
| nb1010 | ||
| realtek | ||
| realtek-5816 | ||
| synaptics | ||
| upektc_img | ||
| upektc_img-tcs1s | ||
| uru4000-4500 | ||
| uru4000-msv2 | ||
| validity | ||
| vfs0050 | ||
| vfs301 | ||
| vfs5011 | ||
| vfs7552 | ||
| capture.py | ||
| create-driver-test.py.in | ||
| driver.test.in | ||
| hwdb-check-unsupported.py | ||
| libfprint.supp | ||
| meson.build | ||
| README.md | ||
| test-device-fake.c | ||
| test-device-fake.h | ||
| test-fp-context.c | ||
| test-fp-device.c | ||
| test-fpi-assembling.c | ||
| test-fpi-device.c | ||
| test-fpi-ssm.c | ||
| test-generated-hwdb.sh | ||
| test-utils.c | ||
| test-utils.h | ||
| test-validity.c | ||
| test.in | ||
| umockdev-test.py | ||
| unittest_inspector.py | ||
| valgrind-python.supp | ||
| virtual-device.py | ||
| virtual-image.py | ||
umockdev Tests
umockdev tests use fingerprint devices mocked by umockdev
toolchain.
This document describes how to create test cases (for USB devices). Many of these tests are tests for image devices, where a single image is captured and stored.
Other kinds of umockdev tests can be created in a similar manner. For
match-on-chip devices you would instead create a test specific custom.py
script, capture it and store the capture to custom.pcapng.
'capture' and 'custom' Test Creation
For image devices the capture.py script will be used to capture one reference
image. If the driver is a non-image driver, then a custom.py script should be
created in advance, which will be run instead.
-
Make sure that libfprint is built with support for the device driver that you want to create a test case for.
-
From the build directory, run tests/create-driver-test.py as root. Note that if you're capturing data for a driver which already has a test case but the hardware is slightly different, you might want to pass a variant name as a command-line options, for example:
$ sudo tests/create-driver-test.py driver [variant]
-
If the capture is not successful, run the tool again to start another capture.
-
Add driver test name to
drivers_testsin themeson.build, as instructed, and change the ownership of the just-created test directory in the source. -
Check whether
meson testpasses with this new test.
Note. To avoid submitting a real fingerprint when creating a 'capture' test, the side of finger, arm, or anything else producing an image with the device can be used.
Possible Issues
Other changes may be needed to get everything working. For example the
elan driver relies on a timeout that is not reported correctly. In
this case the driver works around it by interpreting the protocol
error differently in the virtual environment (by means of
FP_DEVICE_EMULATION environment variable).