* Refactor hash tree computation to work on a preallocated hash tree
buffer. This makes it possible to partially update a hash tree, which
is now supported.
* Add new subcommands for working with hash trees. There's no standard
header format for dm-verity information, so these commands write hash
tree files with a custom header. The commands are not really useful
outside of debugging avbroot's hash tree implementation.
Using AVB was considered, but it has no support for the hash tree data
living in a separate file from the input. If other parties agree on a
standard header in the future, avbroot will switch to that format.
* Add tests for the hash tree implementation.
Signed-off-by: Andrew Gunnerson <accounts+github@chiller3.com>
FEC data can be updated efficiently with "round" granularity when the
regions where the input file was modified are known.
Signed-off-by: Andrew Gunnerson <accounts+github@chiller3.com>
Previously, when running `avbroot ota verify`, only the payload chunk
hashes were verified.
Signed-off-by: Andrew Gunnerson <accounts+github@chiller3.com>
Previously, all replacement partition images (those that have been
patched or `--replace`d) were compressed as a whole, which would be very
slow for larger images. Instead, we'll split the images into 2 MiB
chunks and compress them in parallel. This more closely matches what
AOSP's payload_generator does and scales linearly with the number of CPU
cores. The compression is less efficient, but the file size generally
only increases by 10s of KiB.
This commit also reworks the implementation so that patched images are
stored in temp files instead of in memory again. In hindsight, doing
everything in memory only made things more complex and causes the memory
usage to blow up when doing things like `--replace system <path>`.
Signed-off-by: Andrew Gunnerson <accounts+github@chiller3.com>
dm-verity partitions don't necessarily have AVB descriptors inside the
root vbmeta images. The fstab might verify them against a public key on
disk using the `avb_keys` fs_mgr option. We have no way to statically
check for this scenario and it's becoming increasingly common on newer
OnePlus devices. Instead, we'll just limit the checks to partitions that
are verified by the bootloader.
Fixes: #223
Signed-off-by: Andrew Gunnerson <accounts+github@chiller3.com>
This way, the precompiled executables can run on distros that ship an
older version of glibc or don't use glibc at all.
Fixes: #222
Signed-off-by: Andrew Gunnerson <accounts+github@chiller3.com>
The autodetection logic for `@otacerts` is based on the presence of the
`recovery`, `vendor_boot`, and `boot` partitions (in that order). Some
devices have `vendor_boot`, but put `system/etc/security/otacerts.zip`
inside `boot`.
With the way things are written now, we don't have the ability to
inspect the actual partition images for the autodetection. It is based
on the name only. So, for now, we'll just allow the user to override the
autodetected partition similar to what we already do with the
`--boot-partition` option.
Issue: #218
Signed-off-by: Andrew Gunnerson <accounts+github@chiller3.com>
AOSP primarily cares about `odm` and `odm_dlkm`, so update the logic to
check for that specifically. This fixes patching some OTAs that include
an unprotected OEM-specific `odm_ext` image.
Issue: #218
Signed-off-by: Andrew Gunnerson <accounts+github@chiller3.com>
This does the reverse of `avbroot key extract-avb`. It's useful for
reconstructing a PKCS8-encoded RSA public key when working with the
`public_key` fields in `avb.toml`.
Signed-off-by: Andrew Gunnerson <accounts+github@chiller3.com>
https://rustsec.org/advisories/RUSTSEC-2023-0071
This is a side-channel vulnerability where secrets can be leaked to an
attacker that is able to measure the timing of a large number of RSA
operations. As of 2023-12-03, there is no released version of the rsa
crate that contains a fix.
For avbroot specifically, this vulnerability is not too critical for a
couple reasons:
1. avbroot performs RSA signing only at the end of lengthy processes
that involve a lot of disk I/O. It's very expensive to run avbroot
the millions of times needed to capture a sufficient amount of timing
data.
2. During a single run of avbroot, it will only perform RSA signing a
handful of times. To get sufficient measurements, the attacker would
need to rerun avbroot. If they are able to rerun avbroot, then they
are also able to just read and steal the private key directly.
avbroot has no network capabilities, so this is not inherently remotely
exploitable.
Signed-off-by: Andrew Gunnerson <accounts+github@chiller3.com>
Andrew Gunnerson