apkdmverity can attach a file to a loop device using LOOP_CONFIGURE
instead of LOOP_SET_FD/LOOP_SET_STATUS64 because it's more efficient.
The reason we used the latter was that LOOP_CONFIGURE didn't work then,
but the problem was only for the idsig file when it's attached to a loop
device using LO_FLAGS_DIRECT_IO.
I still don't know the reason, but at least we can use LOOP_CONFIGURE
and explicitly do not turn on Direct IO when attaching IDSIG file to a
loop device.
This is a partial revert of 7ce2e53528.
Bug: 191344832
Test: atest MicrodroidTestApp
Test: atest apkdmverity.test
Change-Id: I53a9da6d1d981b0d64a75bd362b09063570e7a68
virtualizationservice currently passes extra apks and corresponding
idsigs as block devices. microdroid_manager will read the payload config
and mount the apks to /mnt/extra-apk/{index} after verifying them.
Bug: 205224817
Test: atest ComposHostTestCases MicrodroidHostTestCases
Test: manually edit vm config and see apks mounted
Change-Id: I9afa03cb7fabe0ca16b7926c4480d0b32c8bcd04
For now, the command for apkdmverity and zipfuse is hard-coded in the
init script file. To support passing extra APKs, microdroid_manager
needs to parse the vm config, and then manually run apkdmverity and
zipfuse with appropriate parameters.
Bug: 205224817
Test: atest MicrodroidHostTestCases ComposHostTestCases
Change-Id: Ieef463a807db63c985b5088dcf609f29ddb3de84
Each tests in apkdmverity.test creates a device mapper block device
having a specific name. Since the name is a global resource, multiple
tests shouldn't share the same name, otherwise a run of a test might
affect a run of another test.
The newly added test `correct_custom_roothash` incorrectly used the name
'correct' which is already being used by `correct_inputs`. Use a
different name.
Bug: 199801708
Test: monitor TH
Change-Id: Ie2d297b817da7a2a8edd0b7e23c9b5ce4843d598
Upgrade to rustc 1.55.0 seems to have changed the error kind from Other
to Uncategorized. However, Uncategozied is a hidden error kind. Instead
of expecting a specific error kind, expect an error of any kind.
Bug: 199772260
Test: watch TH
Change-Id: Ia7066b0c06899cbaaf009bf7c4bcb3a4cc44121d
This CL completes the APK verification story in microdroid. Previously,
the roothash of an APK that apkdmverity uses came from the idsig file.
That file (and thus roothash in it) is untrusted because it's not signed
by anyone. It is generated by virtualization service when the VM is
created.
With this CL, the roothash becomes trustful. Specifically, the roothash
is from the instance disk which is encrypted and signed using the per-VM
secret key. When the roothash in the instance disk is none, which
could happen during the initial boot of the VM, we do the full APK verification (by
scanning every bits), and save the roothash in the instance disk. In the
subsequent boots, we skip the full APK verification, but instead compare
the roothash with the saved one. If they differ, the boot is halted.
1) The start of apkdmverity and zipfuse is controlled by
microdroid_manager. This is to NOT start them before the roothash is
read from the instance disk. Previously, this was impossible because
they are started by init while microdroid_manager is running in
background.
2) apkdmverity now uses the bootstrap bionic libraries, because it is
started far before APEXd activates APEXes.
3) microdroid_manager passes the roothash (read from instance disk) to
apkdmverity via a new system property `microdroid_manager.apk_roothash`.
This is preferred over to letting microdroid_manager directly execute
apkdmverity and pass the roothash as a commandline argument. We don't
want to allow microdroid_manager to fork/exec an executable other than
app payload; there already is a selinux neverallow rule for it.
4) microdroid_manager waits for a new sysprop `linkerconfig.ready` to
become `true` before it executes an app payload. Previously, this was
implied because microdroid_manager waits for /mnt/apk which is created
by zipfuse which in turn is executed after the linkerconfig is ready.
Since zipfuse now is started much earlier, we no longer can rely on the
implicit dependency.
Bug: 193504400
Test: atest MicrodroidHostTestCases
Test: run `adb shell /apex/com.android.virt/bin/vm run-app
/data/local/tmp/virt/MicrodroidDemoApp.apk
/data/local/tmp/virt/MicrodroidDemoApp.apk.idsig
/data/local/tmp/virt/instance.img assets/vm_config.json`
... two times.
In the first run:
microdroid_manager[128]: payload verification successful. took 85.705852ms
microdroid_manager[128]: Updating APK roothash: A4BC793C78E1A...
In the second run:
microdroid_manager[128]: payload verification successful. took 56.789795ms
microdroid_manager[128]: Saved roothash is trustful. Not updating
When the same command is invoked after the apk is intentionally
modified, it fails as expected:
init: Service 'microdroid_manager' (pid 128) exited with status 1
oneshot service took 0.202000 seconds in background
Bug: 193504400
Change-Id: I469116d806cf3dae66fe41c04fdfd6bdb843edab
The library is the place where everything about the handling of
idsig format is. Move apksiv4.rs from apkdmverity to the library.
The behavior remains the same.
Bug: 193504400
Test: m apkdmverity libidsig
Change-Id: I7994fee83f5a8fcd7e8988ceeb9bbfe7a47a684f
apkdmverity is added to microdroid as well.
Bug: 190343842
Test: MicrodroidHostTestCases (not changed)
Change-Id: If5d6608b52cc93cd13ace85c03b5b2891041b8b4
It was in the wrong directory: apkdmverity/apkverity. Changed it to
directly under apkdmverity.
Bug: N/A
Test: monitor TH
Change-Id: I47599ba5f2b4fb237c21a5ddc63fb3ce0bcf7349
Jooyung Han
Jiyong Park
Inseob Kim
Chris Wailes