| Age | Commit message (Collapse) | Author |
|---|
|
This feature allows digests from on-device persistent storage to be used
in place of digests embedded in descriptors. This allows verification of
partitions which hold per-device configuration data set during a factory
or provisioning stage and expected to remain unchanged from that point
forward.
Support is added for both 'hash' and 'hashtree' descriptors. In the case
of hashtree descriptors, the verity root digest needs to be added to the
kernel command line so this can be configured later without access to
AVB persistent storage. This is accomplished by supporting substitutions
of the form $(AVB_<part_name>_ROOT_DIGEST) where <part_name> is the
uppercase partition name. For example, if the partition name was
'factory' the kernel command line descriptor would hold:
"androidboot.vbmeta.root_digest.factory=$(AVB_FACTORY_ROOT_DIGEST)"
The persistent value ops are designed to be reusable. Persistent values
are expected to be tamper-proof, similar to rollback indexes, and are
not expected to be available outside of the boot code running AVB.
Using persistent digests also requires that the partition not use A/B.
A new flag has been added to avbtool to support this as well as a
'flags' field in hash and hashtree descriptors.
This CL bumps the AVB version to 1.1 and any use of persistent digests
(or the --do_not_use_ab flag) will set the minimum libavb version in
vbmeta to 1.1. If these features are not used, the minimum remains 1.0.
Bug: 73020477
Test: Unit
Change-Id: Iffef31b232492bc8700ab8496c5da2ccfb49be44
|
|
Add information about how the custom key can be set on Pixel 2.
Bug: None.
Test: No code changes.
Change-Id: I84b5fd12b8a4db01ac1d132129351d49a75cc958
|
|
Bug: 65385915
Test: Unit tests
Change-Id: I7cc24f02bd4df1b810f3d8b12a3251981fe504f6
|
|
This code was already marked as experimental in anticipation of being
removed in the future. Officially deprecate it and set Jun 1 2018 as
the date it will be removed. This should give users of the code ample
time to fork/migrate.
To keep using the code AVB_AB_I_UNDERSTAND_LIBAVB_AB_IS_DEPRECATED
must be defined.
The reason for deprecating this code is twofold:
- Its policy was optimized for devices without a display with
e.g. automatic fallback to the other slot if a slot fails to
boot. Since most A/B stacks in Android devices don't work this
way this code is confusing.
- There are no known active users, no good test coverage for the
bootctrl.avb code, and no plans to use it.
When the code is removed we'll provide an easy transition path by
keeping (but renaming) the |ab_ops| member in AvbOps.
Bug: 64140612
Test: All unit tests pass.
Test: UEFI-based boot loader compiles.
Change-Id: Id5e090a2048076d36ccca2e1c4cb55e226b8b43d
|
|
Includes the needed kernel patches for AVB under the new folder contrib/* and
updates README.md for this info. Also adds a link for A/B related build system
variables.
The two patches are generated by `git format-patch` from android common
kernel 4.4:
https://android.googlesource.com/kernel/common/+/android-4.4
The 0002-*.patch is generated by merging four commits:
1. git rebase -i 8d6f006d608c3b03652fb919e496945f2d4d4f1d
2. Removes unrelated commits, and s/pick/squash for the following
commits:
2.1 squash e5272d4c20b3 ANDROID: AVB: Only invalidate vbmeta when told to do so.
2.2 squash 815c6db10b07 ANDROID: AVB: Fix invalidate_vbmeta_submit().
2.3 squash f0893c7ddba2 ANDROID: AVB: Fix linter errors.
3. Updates commit message.
Bug: None
Test: None
Change-Id: Icb007769db4b7454d98cd49a9827e0ad5820fd31
|
|
This is useful in situations where the signing helper - or one of its
libraries - is printing debug / information messages on STDOUT instead
of STDERR (as it should).
Bug: 36590704
Test: New unit tests and all unit tests pass.
Change-Id: I0258131e483ea447d383958708952036ada95875
|
|
This can be used with make_vbmeta_image, add_hash_footer, and
add_hashtree_footer to figure out what will be put in the
required_libavb_version_{major, minor} fields in the VBMeta
struct. This is useful if you also want to store this value in a file
inside system.img before adding a hashtree and integrity data to it.
Right now "1.0" will be printed out since we're still at 1.0. In the
future this may get more complicated.
As with --calc_max_image_size the caller is supposed to pass all the
same options (except --output and --image) that they would pass when
not using the option. This is because options will influence what
minimum libavb version will be required - for example, if using an
algorithm introduced post-1.0 this would be expressed with the
--algorithm option.
Bug: 62077941
Test: New unit test and all unit tests pass.
Change-Id: I97a26f5b51eb4a8c63ca7903a406b174eb88bacb
|
|
Up until now 'avbtool verify_image' only checks that the vbmeta struct
is signed with the embedded public key. While this is useful it would
be more useful if we also checked that the digests in the hash- and
hashtree descriptors are correct.
The complication with this is that we need to load other image files
and we don't really know what file to look for - all we have is a
partition name. The way we solve this is to look in the same directory
as the given image and also use the file extension of the given
image. E.g. if you use --image /path/to/vbmeta.img and we process a
hash descriptor for 'boot' it will make us look for /path/to/boot.img.
Here's an example of a garden-vanilla setup where all integrity-data
is stored in vbmeta.img:
$ ./avbtool verify_image --image ${ANDROID_PRODUCT_OUT}/vbmeta.img
Verifying image /ssd/android/aosp/out/target/product/uefi_x86_64/vbmeta.img using embedded public key
vbmeta: Successfully verified SHA256_RSA4096 vbmeta struct in /ssd/android/aosp/out/target/product/uefi_x86_64/vbmeta.img
boot: Successfully verified sha256 hash of /ssd/android/aosp/out/target/product/uefi_x86_64/boot.img for image of 10543104 bytes
system: Successfully verified sha1 hashtree of /ssd/android/aosp/out/target/product/uefi_x86_64/system.img for image of 1065213952 bytes
vendor: Successfully verified sha1 hashtree of /ssd/android/aosp/out/target/product/uefi_x86_64/vendor.img for image of 264114176 bytes
$ echo $?
0
Here's an example where we want to ensure vbmeta.img is signed with a
given key. It fails because it's signed by the default test key which
is test/data/testkey_rsa4096.pem
$ ./avbtool verify_image --image ${ANDROID_PRODUCT_OUT}/vbmeta.img --key test/data/testkey_rsa2048.pem
Verifying image /ssd/android/aosp/out/target/product/uefi_x86_64/vbmeta.img using key at test/data/testkey_rsa2048.pem
./avbtool: Embedded public key does not match given key.
$ echo $?
1
If we pass that key verification succeeds
$ ./avbtool verify_image --image ${ANDROID_PRODUCT_OUT}/vbmeta.img --key test/data/testkey_rsa4096.pem
Verifying image /ssd/android/aosp/out/target/product/uefi_x86_64/vbmeta.img using key at test/data/testkey_rsa4096.pem
vbmeta: Successfully verified SHA256_RSA4096 vbmeta struct in /ssd/android/aosp/out/target/product/uefi_x86_64/vbmeta.img
boot: Successfully verified sha256 hash of /ssd/android/aosp/out/target/product/uefi_x86_64/boot.img for image of 10543104 bytes
system: Successfully verified sha1 hashtree of /ssd/android/aosp/out/target/product/uefi_x86_64/system.img for image of 1065213952 bytes
vendor: Successfully verified sha1 hashtree of /ssd/android/aosp/out/target/product/uefi_x86_64/vendor.img for image of 264114176 bytes
$ echo $?
0
Also, verification still work for chained partitions and provided the
filename matches the partition name (modulo extension) then
hash/hashtree verification machinery also kicks in:
$ ./avbtool verify_image --image ${ANDROID_PRODUCT_OUT}/system.img
Verifying image /ssd/android/aosp/out/target/product/uefi_x86_64/system.img using embedded public key
vbmeta: Successfully verified footer and SHA256_RSA4096 vbmeta struct in /ssd/android/aosp/out/target/product/uefi_x86_64/system.img
system: Successfully verified sha1 hashtree of /ssd/android/aosp/out/target/product/uefi_x86_64/system.img for image of 1065213952 bytes
$ echo $?
0
Also make it such that for each chain partition descriptor a
corresponding --expected_chain_partition option must also be
given. The format of this is exactly the same as the --chain_partition
option. The intent of this option is to verify that the image is
indeed using the correct rollback index location and public key for
chain partitions.
Also make 'avbtool verify_image' a lot more verbose so it's easier to
see what's going on.
Bug: 62038348
Test: New unit tests and all unit tests pass.
Change-Id: Ic6cd48c9ef9c8d97f6427104466bdc1822fc54aa
|
|
Test: Build, boot bullhead
Test: libavb_host_unittest, image_handler_unittest.py, libavb_symbols_test
Change-Id: I86b0176f4c3f64a15a18e2c0f44fccfb64cedeb9
|
|
This is useful for rejecting images that are too big for a given
partition size.
Bug: 38304476
Test: New unit tests + all unit tests pass.
Change-Id: I09facd11c4d79291073ecdf5cbaec4e0058d19de
|
|
This option makes it possible to generate system.img with kernel
command-line descriptors for setting up the partition with dm-verity
as the root filesystem. This is different from the existing option
--setup_rootfs_from_kernel which takes a path to system.img and adds
the kernel command-line descriptors to e.g. vbmeta.img.
This option can be used when using chained partitions for system.img.
Also fix README.md to use --include_descriptors_from_image and not
--include_descriptors_from_footer.
Bug: 38304536
Test: New unit tests + all unit tests pass.
Change-Id: I6285877cdb3b63a7c9117c270459d1fbb93e3309
|
|
It was pointed out "Additionally, the rollback indexes in the verified
image must not exceed those stored on the device" was ambigious so
rephrase for clarification.
Bug: None
Test: All unit tests pass.
Change-Id: I2f8e89beef4aa42f4b844390c8053f6f775fec2b
|
|
The overhead of FEC is tiny and data shows that it help a lot. So just
enable it by default to avoid everybody having to manually turn it on.
Technically this is a breaking change (insofar hashtree images will
now have FEC on when avbtool is updated) but since we haven't actually
released 1.0.0 and it's still early days for AVB, do it anyway. Do
warn on stderr that the --generate_fec option is now deprecated.
Bug: None
Test: All unit tests pass
Test: Manually tested on UEFI-based bootloader.
Change-Id: I4eb5cca25bb1ca08f0e80ca033dc037fc4379104
|
|
Currently AVB only supports one error mode for handling dm-verity
errors which is to invalidate the slot in question and restart the
device. On the next reboot the bootloader is expected to boot the
other slot or enter some kind of repair state.
While this may be suitable for some devices / form-factors it doesn't
allow for the workflow described in "Recovering from dm-verity errors"
as described in
https://source.android.com/security/verifiedboot/verified-boot
This CL adds support for specifying the error mode by allowing passing
through the verity error handling mode to avb_slot_verify(). Initially
four error handling modes are supported
* AVB_HASHTREE_ERROR_MODE_RESTART_AND_INVALIDATE means that the HLOS
will invalidate the current slot and restart (current behavior).
* AVB_HASHTREE_ERROR_MODE_RESTART means that the OS will restart
(without the current slot being invalidated).
* AVB_HASHTREE_ERROR_MODE_EIO means that an EIO error will be
returned to the application.
* AVB_HASHTREE_ERROR_MODE_LOGGING means that errors will be logged
and corrupt data may be returned to applications. This mode should
be used ONLY for diagnostics and debugging. It cannot be used
unless also allow verification errors (e.g. only UNLOCKED mode).
The passed-in value combined with whether dm-verity is disabled in the
top-level vbmeta maps to androidboot.veritymode being either
'enforcing', 'eio', or 'logging' and
androidboot.vbmeta.invalidate_on_error maybe being set to 'yes'.
In a nutshell this CL simply sets androidboot.veritymode and
androidboot.vbmeta.invalidate_on_error based on whatever hashtree
error mode is passed by the caller of avb_slot_verify().
This CL also introduces $(ANDROID_VERITY_MODE) which is now used by
avbtool in the dm="..." string and libavb will replace this with
'restart_on_corruption', 'ignore_corruption', etc. depending on the
error handling mode passed to avb_slot_verity().
A related CL for drivers/md/dm-verity-avb.c will support
androidboot.vbmeta.invalidate_on_error to only invalidate if this is
set to 'yes'.
The README.md file has been updated with a section to discuss
dm-verity error handling and what it entails.
Since we're changing avb_slot_verify() with this CL also use this
opportunity to change the |allow_verification_mode| boolean parameter
into a flag. This will make it easier to add features to libavb in the
future without breaking API again.
Also update the toy UEFI bootloader in examples/uefi to use this new
API and make it use AVB_HASHTREE_ERROR_MODE_RESTART_AND_INVALIDATE.
Bug: 38157502
Test: New unit tests and all unit tests pass.
Test: Manually tested all dm-verity error modes on UEFI-based bootloader.
Change-Id: I0e6639839ce696e815ac6e8fad8dfb2212390ddd
|
|
This information is currently in a separate document which is
confusing when things get out of sync, leading to bitrot and
worse. Instead, just include this information in README.md - this way
it's easy to point to and things don't bitrot!
Emphasize that recommendations and best practices are just that and
the word 'must' should be taken with a grain of salt. It is done this
way such that requirement docs for specific devices can point to a
specific version of README.md and say "the device MUST implementation
all recommendations (except X, Y, and Z) in this particular version of
external/avb/README.md".
Test: Renders fine in Markdown editor.
Test: All unit tests pass.
Bug: None
Change-Id: Iaae80e021180c1a18db8cdbd479e04c98f4c7d33
|
|
The Android build system recently gained support for using AVB for
vendor.img. Mention this in the "Build system integration notes"
section. Also fix a couple of typos and mention more typical options
that can be used in various variables.
Bug: None
Test: All unit tests pass.
Change-Id: I567a36af66a7ffef2c5c7267d057a2e8bfe7d058
|
|
This only works on images with AVB footers. This feature is needed for
some Treble use-cases where a "golden" system.img is used across
devices with varying 'system' partition sizes.
Bug: 36029318
Test: New unit tests and all unit tests pass.
Change-Id: Idc0c31a79157c52249b3ebcd02c1c3bc5228de7f
|
|
This can be used to verify that a custom signer works correctly.
Since this is only expected to be used on developer machines (e.g. not
in the build system), just use PyCrypto instead of shelling out to
openssl(1).
Bug: 36590704
Test: New unit tests and unit tests pass
Change-Id: Ifd26c7fe0e06cff102d35a46399f9d251cd779c6
|
|
This new tool can be used at runtime to control AVB behavior on the
device. Initially it can be used to enable/disable dm-verity.
Also move boot_control/avb_ops_device.[ch] into a new libavb_user
library since this code is now shared between avbctl and
boot_control.avb. Also use fs_mgr_read_fstab() instead of
fs_mgr_read_fstab_with_dt() to read /fstab.device since this is
legacy and will never have fstab entries in the device tree.
Bug: 34124301
Test: All unit tests pass
Test: Manually tested on UEFI-based bootloader with vbmeta partitions.
Test: Manually tested on UEFI-based bootloader without vbmeta partitions.
Change-Id: I1f2f9ce245ae1a5bea75994d5a53f7d64872936f
|
|
This makes it a lot easier to read (most editors has syntax Markdown
highlighting) and things like
https://android.googlesource.com/platform/external/avb/+/master/
will automatically display the README.md file.
Bug: None
Test: No code changes. All unit tests pass.
Change-Id: Ie25d5e0366712856c8f2c088015aacf1976171f3
|
