Before a VM is started, the idsig file is created (or updated) by the
virtualization service. This is needed because the idsig file is usually
not available, especially when the APK is downloaded from the store.
Note that the generated idsig file is not a signed one. Therefore, the
APK is first verified using the APK signature scheme V3 (or V2) over a
dm-verity device backed by the APK and the merkle tree (and root hash)
from the idsig file. Only if the verification is successful, the root
hash stored to the instance.img and then used for the subsequent boots
of the VM.
Bug: 193504400
Test: atest MicrodroidHostTestCases
Test: run MicrodroidDemoApp without having the idsig file in
/data/local/tmp/virt.
Change-Id: I9fad05ca9562ae0666431102a8147d0f76f04e6a
This CL adds the `create` and `write_into` methods to `V4Signature` each
of which is used to construct V4Signature from an apk and to write it
into a file.
Next step will be modifying the virtualization service to create an
idsig file for a given apk, thus eliminating the need to provide the
idsig file separately.
Bug: 193504400
Test: m libidsig libidsig.test
Change-Id: I2be60fbb6ec40af12297e20b112318a032dd78f9
This change improves the merkle tree generation routine so that we don't
do unnecessary data copies. Previously, hashes for level N is written
to a temporary store and then copied into the tree. Even worse, the
hashes written to the tree is copied into another buffer when they are
used as the inputs for the next level.
With this CL, the hashes are directly written to and read from the tree.
This is done by having two (non-overlapping) slices on the hash tree.
Bug: N/A
Test: cargo test
Change-Id: I34be81ece6941eba78980c8bc4697ed5d523ed53
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
The idsig crate is for creating an idsig file from an apk. It will be
used by virtualization service when a VM is first created. From the
input APK, the corresponding idsig file is generated and passed to the
VM as a partition. Inside the VM, a dm-verity block device is created
for the APK whose merkle tree is backed by the idsig file.
If it's the VM's first boot, the APK (still on top of dm-verity) is
verified using the APK signature scheme V2 or V3. This involves a full
scanning of the APK. Therefore, a successful V2/V3 verification means
that the merkle tree and the root hash in the idsig file is also
trustful, because otherwise there must have been an I/O error during the
scanning, or the V2/V3 verification must has failed.
Subsequent boots don't involve the lengthy V2/V3 verification. Instead,
we use the root hash that is stored to the instance disk during the
first boot. We don't use the root hash read from the idsig file which
might have been compromised and therefore shouldn't be used without the
V2/V3 verification.
As the first step, the idsig crate is created. It currently has routines
for the generation of merkle tree. Later, apksigv4.rs which implements
the idsig file format will be moved from apkdmverity to here. Then
finally, virtualization service will use this to actually create an
idsig file when necessary.
Bug: 193504400
Test: cargo test
Change-Id: I242dd8c6d74fd3098831ce820dd989871939e911
Andrew Walbran
Joel Galenson
Jiyong Park