| fd0ba0d49101461dbb493cfb28c3a0a2158559b9 |
|
02-Feb-2018 |
Darren Krahn <dkrahn@google.com> |
Implement support for on-device persistent digests.
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
/external/avb/test/avb_slot_verify_unittest.cc
|
| fcadbf1d1a71406caa5ecb09a27cf635b9f2d842 |
|
27-Oct-2017 |
Lonnie Liu <lonliu@google.com> |
Support (boot) partition preloading.
Add a get_preloaded_partition() function in AvbOps. It provides an
alternative way to read a full parition (for checking its hash) without
performing a full memory copy. This also makes it possible to directly
boot the preloaded partition, rather than having to relocate the
loaded boot partition after avb_slot_verify().
TEST=Unit tests.
BUG=67854557
Change-Id: I062343dc68b6f2f48745a58ce04f0abca5e2e7e9
/external/avb/test/avb_slot_verify_unittest.cc
|
| 0922bf8970fd2a61b9053a6fca81d8165cc0af67 |
|
19-Jun-2017 |
David Zeuthen <zeuthen@google.com> |
Make it possible to disable verification.
Introduce a new AVB_VBMETA_IMAGE_FLAGS_VERIFICATION_DISABLED flag
which can be set in the top-level vbmeta struct. Also add {get,
enable, disable}-verification sub-commands to avbctl to read/write
this flag.
This flag acts much in the same way as the HASTREE_DISABLED flag
insofar that it's usually unset on images so setting it on a slot
means that the slot will only work in UNLOCKED mode (because the
signature on the top-level vbmeta struct will no longer verify).
If this flag is set, then
- only the top-level vbmeta struct is read; and
- descriptors are not processed; and
- all requested partitions are loaded without verification; and
- the |cmdline| field in the returned AvbSlotVerifyData object
will be set to "root=PARTUUID=$(ANDROID_SYSTEM_PARTUUID)"
and the GUID substitutions are performed. No androidboot.*
options are set in the returned command-line.
In effect this should allow booting the OS in the slot without any
modifications to the bootloader as if verified boot is not in use at
all. This is useful in some use-cases for example if using a
system.img image without any verification metadata at all.
Test: New unit tests + all unit tests pass.
Test: Manually tested on UEIF-based boot loader.
Bug: 62523303
Change-Id: Ib85539433c39691e407009dc8d66d94dc3ec5b09
/external/avb/test/avb_slot_verify_unittest.cc
|
| 01ca9962bd0d18d0a958b289fe481cdab7c072ca |
|
23-May-2017 |
David Zeuthen <zeuthen@google.com> |
libavb: Only load and verify hash partition if requested.
Currently avb_slot_verify() will load _and_ verify all hash partitions
mentioned in vbmeta structus even if a partition isn't in the
|requested_partitions| parameter.
The current behavior is not useful because verification of a hash
partition only works if you keep the loaded data around. If you don't
keep it around, you set yourself up for a time-of-check-to-time-of-use
(TOCTTOU) attack insofar that an attacker can change the partition
contents in the window between it was checked and until you load it
again.
This should save ~400ms (the cost of sha256'ing ~32 MiB of data) in
fs_mgr / early-mount. This is because fs_mgr requests no partitions to
be loaded since it is only interested in the vbmeta structs.
Bug: None
Test: New unit test + all unit tests pass.
Test: Manually tested on UEFI-based boot loader.
Change-Id: I3e60d6c01e431c43ee2c629ed84318cbeac44347
/external/avb/test/avb_slot_verify_unittest.cc
|
| a47b0a1074cca351c77d1aee326b979c393dde6f |
|
23-May-2017 |
David Zeuthen <zeuthen@google.com> |
libavb: Add test for verifying veritymode is set to 'disabled'.
If the HASHTREE_DISABLED flag is set in the top-level vbmeta struct we
should set androidboot.veritymode=disabled no matter what is passed as
the AvbHashtreeErrorMode. Add unit test for checking this.
Bug: None
Test: New unit tests + all unit tests pass.
Test: Manually tested on UEFI-based boot loader.
Change-Id: I87c42b494562033954060fb270c064509beebc01
/external/avb/test/avb_slot_verify_unittest.cc
|
| 73f2afadf9ecc1b08968952606ced50b0e8b6515 |
|
17-May-2017 |
David Zeuthen <zeuthen@google.com> |
avbtool: add_hashtree_footer: Add --setup_as_rootfs_from_kernel option.
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
/external/avb/test/avb_slot_verify_unittest.cc
|
| 02c550f85abc41491756495b9ea33d966e6e9585 |
|
10-May-2017 |
David Zeuthen <zeuthen@google.com> |
avbtool: Generate forward-error-correcting codes for hashtree by default.
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
/external/avb/test/avb_slot_verify_unittest.cc
|
| 8221811c5da1127d9e63558d1bb7100233efc0e9 |
|
09-May-2017 |
David Zeuthen <zeuthen@google.com> |
libavb: Allow specifying dm-verity error handling.
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
/external/avb/test/avb_slot_verify_unittest.cc
|
| 27a291fcc1948ca8309b307c34d3eb229c5d208d |
|
28-Apr-2017 |
David Zeuthen <zeuthen@google.com> |
libavb: Load entire partition if |allow_verification_error| is true.
This is needed to make the common workflow of
$ fastboot flash boot /path/to/boot.img
work. To do this we need to introduce a new AvbOps operation to get
the partition size. Note that libavb integrators had already had to do
this to implement read_from_partition() when a negative offset is
passed... so this shouldn't be a lot of extra work.
Also note that since libavb has no stable API this is not a breaking
change so there is no need to bump any version numbers (version
numbers are mostly for on-disk formats) ... in other words, libavb
integrators are expected to re-integrate and re-test their bootloader
code every time they uprev to a newer libavb. In this case they need
to implement a new AvbOps operation.
Add some extra docs to AvbOps to spell out that the struct should be
zeroed before being populated with function pointers. This is to
ensure unimplemented operations are always set to NULL.
For now handle the case where the newly operation is NULL (e.g. not
implemented) and just warn using avb_error() that it should be
implemented.
Add pre-condition checks to avb_slot_verify() to check that all
required operations at least are set.
Add a new unit test for this and also implement it in the
examples/uefi boot loader and libavb_user.
Bug: 37709309
Test: New unit test + all unit tests pass.
Test: Manually tested on UEFI-based bootloader.
Change-Id: Id225af91add2e52167994e80b5b3a788c6909c15
/external/avb/test/avb_slot_verify_unittest.cc
|
| fd9c18d298af8ffef64d736bf7f0900196af9b7a |
|
20-Mar-2017 |
David Zeuthen <zeuthen@google.com> |
avbtool: Use root=/dev/dm-0 instead of root=0xfd00.
It was pointed out that major/minor numbers could be dynamically
allocated. While this is unlikely, just use /dev/dm-0 which is
guaranteed to always refer to the first mapped device.
Bug: 36444660
Test: All unit tests pass.
Test: Manually tested on UEFI based bootloader.
Change-Id: If591fae1ee657ab6da0ab9b140e45965104da3fd
/external/avb/test/avb_slot_verify_unittest.cc
|
| a5fd3a4b5617b75ce5666e1bfd38be578e865e1f |
|
27-Feb-2017 |
David Zeuthen <zeuthen@google.com> |
Allow top-level vbmeta struct to be in 'boot' partition.
If there is no 'vbmeta' partition try to load the top-level vbmeta
struct from the end of 'boot' via a footer.
Two use-cases come to mind
- bring-up when the partition table doesn't yet mention vbmeta; and
- upgrades where it's not feasible to change the partition table
Bug: None
Test: New unit tests and all unit tests pass.
Change-Id: Id0c6c0f95ce157ffbeb0692d3c9547f49ab58640
/external/avb/test/avb_slot_verify_unittest.cc
|
| e3cadcacd798effe83b1593dba1ee0e3d84cf6e4 |
|
23-Feb-2017 |
David Zeuthen <zeuthen@google.com> |
Rework how versioning work.
Instead of listing the version of avbtool that generated the struct
(which is not very useful), convey the minimum required libavb version
needed to parse the structure. This is a lot more useful as it can be
used at runtime to reject updates requiring a newer libavb than what
is on the device (conveyed via androidboot.vbmeta.avb_version).
Also add a human-readable release-string field that describes what
tool (typically avbtool) was used to generate the data. Emphasize that
one cannot make assumptions about the format and it's only there to
aid in debugging. Also make it possible to easily append
build-specific information to this string.
Add a third version number field that can be bumped when doing bug-fix
releases that don't add any new features. This is groundwork needed
for a release process.
Document all this in the README file.
Also rename androidboot.vbmeta.version to androidboot.vbmeta.avb_version
since it conveys the version of libavb used in the bootloader.
Add avb_version_string() and suggest that this should be used in
bootloaders to convey what version of libavb is being used on the
device in debug/diagnostics output. Update examples/uefi to use this.
Bug: 35322304
Bug: 32414650
Test: New unit tests and all unit tests pass.
Test: Manually tested on UEFI based bootloader.
Change-Id: Iae52a751c84fe4ea4473803d6f4e978720737511
/external/avb/test/avb_slot_verify_unittest.cc
|
| bc41cead048a90f63e3dd4335097c5588ec09345 |
|
16-Feb-2017 |
David Zeuthen <zeuthen@google.com> |
libavb: Include androidboot.vbmeta.version in the generated command-line.
This version number represents the version of the libavb embedded in
the bootloader. This can be used at run-time to reject updates that
would write a vbmeta partition with a newer version than what the
bootloader supports.
(Also include some fixes for the previous CL which didn't make the cut
before Treehugger merged it.)
Bug: 35416772
Test: New unit tests and all unit tests pass.
Test: Manually tested on UEFI based bootloader.
Change-Id: Ie6aea68d0d5154be64cb1fff0699d16a0b123d39
/external/avb/test/avb_slot_verify_unittest.cc
|
| 19c38437eb77101ac30b29135cca58fbc684eace |
|
16-Feb-2017 |
David Zeuthen <zeuthen@google.com> |
libavb: Don't pass androidboot.slot_suffix in generated kernel command-line.
It's not appropriate to do this since the boot loader's A/B stack will
likely do this. Also add new avb_strdupv() utility function so it's
easy to do this yourself and update UEFI example bootloader to use
this.
Bug: None
Test: New unit tests + all unit tests pass.
Test: Manually tested on UEFI based bootloader.
Change-Id: I9f9596b1f273330e80a38d857233167fefcce01b
/external/avb/test/avb_slot_verify_unittest.cc
|
| a01e32f1513aa7a93bb8816c4bb853c941d99dae |
|
24-Jan-2017 |
David Zeuthen <zeuthen@google.com> |
avbtool: Use 'restart_on_corruption' when setting up dm-verity.
This is needed for the AVB error handler in the kernel which will only
be invoked when this option is used.
Bug: None
Test: Unit tests pass.
Change-Id: Id6ba4562ca973df2ef0425484eb9f1df22f2d7d0
/external/avb/test/avb_slot_verify_unittest.cc
|
| d5db21df02c9c89472cf2b189361392a2b0ef151 |
|
24-Jan-2017 |
David Zeuthen <zeuthen@google.com> |
avbtool: Fix overallocation for Authentication Data block.
It was reported by Esun Kim that avbtool allocated too much space for
the authentication data block which resulted in vbmeta.img being
bigger than it needed to be. Better to only allocate the amount of
space of we need.
Bug: None
Test: Unit tests pass.
Test: Manually tested on UEFI based bootloader.
Change-Id: Id34ded854d0ee0d35f51122b9b20a3939a4cbc7f
/external/avb/test/avb_slot_verify_unittest.cc
|
| 5d4f4f21a42debbcd9c9a784f90327bd91e49aac |
|
11-Jan-2017 |
David Zeuthen <zeuthen@google.com> |
Rename --generate_dm_verity_cmdline_from_hashtree to --setup_rootfs_from_kernel
This is more accurate especially in light of the HASHTREE_DISABLE flag.
Bug: None
Test: Unit tests pass.
Test: Manually tested on UEFI based bootloader.
Change-Id: I0123b7b0bdb7c0f92835022d403ed3228f250047
/external/avb/test/avb_slot_verify_unittest.cc
|
| 57ac06e6e4fae29eb616613eb2e2623d79230290 |
|
10-Jan-2017 |
David Zeuthen <zeuthen@google.com> |
Set androidboot.vbmeta.device from libavb instead of descriptor.
When using an initrd --generate_dm_verity_cmdline_from_hashtree is not
set because the initrd is expected to set up the root filesystem. In
this case androidboot.vbmeta.device still needs to be set but right
now this is not how things work. Fix this by setting this kernel
command-line parameter from within libavb instead of in a descriptor.
Bug: 33590159
Test: Unit tests pass.
Test: Manually tested on UEFI based bootloader.
Change-Id: I093c1b1f670082ca998f0a97a215676371ac0be2
/external/avb/test/avb_slot_verify_unittest.cc
|
| 4b6a634e48353da1e119ebe0287299f7b919d778 |
|
03-Jan-2017 |
David Zeuthen <zeuthen@google.com> |
Fix-up coding style and add PREUPLOAD.cfg file.
Previous commits broke the style specified our .clang-format file -
fixed this by running it through clang-format(1). During this process
discovered that I've been invoking clang-format(1) without the
--style=file option meaning that our .clang-format file actually
hadn't been used at all. So there's a rather big amount of formatting
changes in this CL.
Also replaced the .clang-format symlink target to
../../build/tools/brillo-clang-format with our own file since the
brillo one may go away in the future or not exist at all.
Finally, added a PREULOAD.cfg file to do this on every commit. See
https://android.googlesource.com/platform/tools/repohooks/
for more information about how this works.
Bug: None
Test: Manually tested.
Test: All unit tests pass.
Change-Id: I6461478a62efd81689bc4316c22f758e7f98f59f
/external/avb/test/avb_slot_verify_unittest.cc
|
| 72d5790de1e0e6ee5e8b185e59d102cbb46a986a |
|
13-Dec-2016 |
Darren Krahn <dkrahn@google.com> |
test: Add abstract delegate and better rollback indexes to FakeAvbOps
The abstract delegate allows tests to override and set their own
delegate, effectively customizing the fake behavior with minimal fuss. A
test could even use gmock to implement a delegate.
Rollback indexes will not necessarily be contiguous (0, 1, 2, ...) going
forward so handling them via a index-to-value map is better than a
strict vector.
Also, this CL moves C++ code, including tests, into a namespace.
Bug: 33553097
Test: unit
Change-Id: Ib53637c8b9320d9847b079aad79ce4fbd8ffc701
/external/avb/test/avb_slot_verify_unittest.cc
|
| 9744c202babdaf440a845ed5f5ad9234aff4680c |
|
16-Dec-2016 |
David Zeuthen <zeuthen@google.com> |
Make 32-bit version of the unit tests pass.
With corrupt_data being
uint8_t corrupt_data[4] = {0xff, 0xff, 0xff, 0xff};
then "-sizeof corrupt_data" when passed as a int64_t will be passed as
4294967292 instead of -4. I'm not entirely sure why this is but
passing the literal value -4 fixes it. This was discovered while
reviewing https://android-review.googlesource.com/#/c/315014/
Test: All unit tests pass on 64- and 32-bit.
Bug: None.
Change-Id: Ifdd440a45926284d9e9cdb8d4013887143aebc4a
/external/avb/test/avb_slot_verify_unittest.cc
|
| 40ee1da883c634ce94bb69e97a52598f8fbc151d |
|
23-Nov-2016 |
David Zeuthen <zeuthen@google.com> |
Rename "rollback index slot" to "rollback index location".
This is because the word slot is already used in the context of
A/B. Less confusing this way.
Bug: 33100927
Test: New unit tests and all unit tests pass.
Test: Manually tested on UEFI based bootloader.
Change-Id: Ic611b02dc18e7dd9f14c2c87b247be3cd8f4aaf2
/external/avb/test/avb_slot_verify_unittest.cc
|
| 8681a33e249cb68c5159ebccb50b55c56867fcdf |
|
23-Nov-2016 |
David Zeuthen <zeuthen@google.com> |
libavb: Pass all vbmeta images in AvbSlotVerifyData, not just 'vbmeta'.
Right now AvbSlotVerifyData only exposes the vbmeta struct from the
'vbmeta' partition and not from any chained partition. This is
problematic as applications (bootloader, fs_mgr, etc.) may need to
access descriptors no matter where they are stored. Of course such
applications could just reimplement avb_slot_verify() themselves but
this is error-prone and unnecessary. Instead, just make
avb_slot_verify() export what is needed.
Additionally, make androidboot.vbmeta.{hash_alg, size, digest} be a
digest of all these images, not just the root.
Before this change, user-space actually had no way to properly verify
vbmeta images in non-vbmeta partitions because it lacks access to
stored_rollback_indexes[] for comparison. Now, however, user-space can
use avb_slot_verify() for verification with an AvbOps struct where
validate_vbmeta_public_key() and read_rollback_index() will pass any
image. After this, all that is needed is comparing
androidboot.vbmeta.{hash_alg, size, digest} against the value computed
over vbmeta_images[] in AvbSlotVerifyData.
Additionally, all descriptors from all vbmeta images are now easily
available which is a feature which is needed in fs_mgr to set up
non-rootfs dm-verity partitions.
Bug: 31264231
Test: New unit tests + unit tests pass.
Test: Manually tested on UEFI based bootloader.
Change-Id: I8df1de246dba0b41cb3c9a7bfc93587bb55a666c
/external/avb/test/avb_slot_verify_unittest.cc
|
| bc8f647d58db7490caef46c3d7ac85e4f481c389 |
|
21-Nov-2016 |
David Zeuthen <zeuthen@google.com> |
Pass androidboot.vbmeta.device option on the kernel cmdline.
With these changes, avbtool and libavb will set this new option to the
partition GUID of the 'vbmeta' partition for the booted slot. This can
be used by an AVB-specific error handler to clear the 'vbmeta'
partition in question thereby forcing the bootloader to fall back to
another slot. Here's the debug output when manually tested with my toy
UEFI bootloader and a custom hacked up dm-verity error handler:
[ 0.000000] Kernel command line: rootfstype=ext4 init=/init console=ttyS0,115200 androidboot.console=ttyS0 androidboot.hardware=uefi_x86_64 enforcing=0 androidboot.selinux=permissive androidboot.debuggable=1 buildvariant=eng dm="1 vroot none ro 1,0 2080496 verity 1 PARTUUID=c2531a08-1ff2-4c3e-9d9d-a50e5abd02c8 PARTUUID=c2531a08-1ff2-4c3e-9d9d-a50e5abd02c8 4096 4096 260062 260062 sha1 e4806bc79e0d292901d10087d6e98dc70d8acca1 43f92ecfd184583d79f6ae8618559ca9b24c51d8 1 ignore_zero_blocks" root=0xfd00 androidboot.vbmeta.device=PARTUUID=b0868553-57db-4047-94fc-3673070128e2 androidboot.slot_suffix=_a androidboot.vbmeta.device_state=unlocked androidboot.vbmeta.hash_alg=sha256 androidboot.vbmeta.size=3264 androidboot.vbmeta.digest=739a4c9ad3e034ac483614ced4083a2caad246387ce7fed8bd8eb92a2d08486e
[...]
[ 1.215488] device-mapper: init: attempting early device configuration.
[ 1.216648] device-mapper: init: adding target '0 2080496 verity 1 PARTUUID=c2531a08-1ff2-4c3e-9d9d-a50e5abd02c8 PARTUUID=c2531a08-1ff2-4c3e-9d9d-a50e5abd02c8 4096 4096 260062 260062 sha1 e4806bc79e0d292901d10087d6e98dc70d8acca1 43f92ecfd184583d79f6ae8618559ca9b24c51d8 1 ignore_zero_blocks'
[ 1.221667] device-mapper: init: dm-0 is ready
[ 1.230688] device-mapper: verity: 8:6: data block 0 is corrupted
[ 1.231567] device-mapper: verity-avb: AVB error handler called!
[ 1.238727] device-mapper: verity-avb: invalidate_vbmeta: found AVB0 vbmeta partition
[ 1.241937] device-mapper: verity-avb: invalidate_vbmeta: completed.
[ 1.244188] EXT4-fs (dm-0): unable to read superblock
[...]
where invalidate_vbmeta() replaces the AVB0 magic with AVE0 to signal
the error. On the reboot, the bootloader immediately selects slot '_b'
because 'vbmeta_a' fails to validate
UEFI AVB-based boot loader
../../../../external/avb/libavb/avb_vbmeta_image.c:388: ERROR: Magic is incorrect.
../../../../external/avb/libavb/avb_slot_verify.c:331: ERROR: vbmeta_a: Error verifying vbmeta image: invalid vbmeta header
../../../../external/avb/libavb_ab/avb_ab_flow.c:268: ERROR: Error verifying slot _a with result ERROR_INVALID_METADATA - setting unbootable.
[...]
[ 0.000000] Kernel command line: rootfstype=ext4 init=/init console=ttyS0,115200 androidboot.console=ttyS0 androidboot.hardware=uefi_x86_64 enforcing=0 androidboot.selinux=permissive androidboot.debuggable=1 buildvariant=eng dm="1 vroot none ro 1,0 2080496 verity 1 PARTUUID=62b098aa-dcf3-494f-8656-2aad5d0963a2 PARTUUID=62b098aa-dcf3-494f-8656-2aad5d0963a2 4096 4096 260062 260062 sha1 e4806bc79e0d292901d10087d6e98dc70d8acca1 43f92ecfd184583d79f6ae8618559ca9b24c51d8 1 ignore_zero_blocks" root=0xfd00 androidboot.vbmeta.device=PARTUUID=c386b78f-39cd-4cb8-9fc9-ab1023de5beb androidboot.slot_suffix=_b androidboot.vbmeta.device_state=unlocked androidboot.vbmeta.hash_alg=sha256 androidboot.vbmeta.size=3264 androidboot.vbmeta.digest=739a4c9ad3e034ac483614ced4083a2caad246387ce7fed8bd8eb92a2d08486e
[...]
# bootctl get-current-slot
1
as expected.
The AVB error handler featured above will be in a separate CL since
it's against the Linux kernel.
Bug: 31622239
Test: Updated unit tests and unit tests pass.
Test: Manually tested on UEFI based bootloader, see above.
Change-Id: I57e0b7876f02b2484188a2624420085ced3fbdbc
/external/avb/test/avb_slot_verify_unittest.cc
|
| fd41eb9a7848ad8d2ae0a80186e461741bf134f1 |
|
17-Nov-2016 |
David Zeuthen <zeuthen@google.com> |
Add way to disable dm-verity allowing rootfs to be writable.
This feature already exist in Android's current verified boot
implementation and can be enabled by running 'adb disable-verity'. As
it's very useful for developers (it allows replacing e.g. binaries on
the root filesystem) we want AVB to have this feature as well.
First, add a 'flags' field in the VBMeta struct with a single possible
flag value HASHTREE_DISABLED (we can add more flags in the future).
Second, to enable the feature we essentially need to pass
root=PARTUUID=$(ANDROID_SYSTEM_PARTUUID)
instead of
dm="1 vroot ... PARTUUID=$(ANDROID_SYSTEM_PARTUUID) ... " root=0xfd00
To do this cleanly and keep all the details about dm-verity setup
outside the bootloader binary, introduce a flags field to the
command-line descriptor allowing the bootloader to skip the
command-line snippet depending on whether HASHTREE_DISABLED is set or
not. With this in place, modify avbtool to generate two kernel
command-line descriptors - one if HASHTREE_DISABLED is set and one if
it's not.
One note is that the VBMeta flag HASHTREE_DISABLED will never be used
at image build time. Instead, it's expected that 'adb disable-verity'
will set the flag by writing to vbmeta_a or vbmeta_b directly. This
will of course cause the image to not be verified but if the device is
unlocked the bootloader will boot it anyway .. this is because of the
previous CL with subject "Enable operations on unlocked devices."
I tried all this using my toy UEFI-based bootloader using libavb and
here's the result. First the bootloader output when processing a
freshly built image (with lots of thing deleted for brevity):
ab_result=OK,
slot_suffix=_a,
command-line='dm="1 vroot none ro 1,0 [...]" root=0xfd00
androidboot.slot_suffix=_a
androidboot.vbmeta.device_state=unlocked [...]'
and once we've get a shell remounting rootfs rw fails:
$ su
# mount -orw,remount /
'/dev/root' is read-only
It's possible however to set the new HASHTREE_DISABLED flag by writing
to vbmeta_a:
# echo -n -e \\x01 | dd bs=1 oseek=123 count=1 \
of=/dev/block/pci/pci0000\:00/0000\:00\:01.1/by-name/vbmeta_a
1+0 records in
1+0 records out
1 bytes transferred in 0.001 secs (1000 bytes/sec)
When rebooting the bootloader now outputs the following:
ab_result=OK_WITH_VERIFICATION_ERROR,
slot_suffix=_a,
command-line='root=PARTUUID=c2531a08-1ff2-4c3e-9d9d-a50e5abd02c8
androidboot.slot_suffix=_a
androidboot.vbmeta.device_state=unlocked [...]'
and it's now possible to remount the root filesystem and write to it:
$ su
# mount -orw,remount /
# echo foo > /bar
# cat /bar
foo
with changes persisting across reboots.
Needless to say, disabling hashtree verification like this will ONLY
work if the device is unlocked. This is because the HASHTREE_DISABLED
flag is in the verified data.
Test: New unit tests and unit tests pass.
Test: Manually tested on UEFI based bootloader, see above.
Bug: 32949911
Change-Id: I9474ddd5f442be369cb0a551f03ac181cc41a265
/external/avb/test/avb_slot_verify_unittest.cc
|
| 0155e6b158bdc5b3a442f16a5dc124d5dee9c71c |
|
16-Nov-2016 |
David Zeuthen <zeuthen@google.com> |
Enable operations on unlocked devices.
If a device is unlocked the expected behavior is that slots are
rejected if, and only if, they are invalid, not if they fail
verification.
Verification failure includes rollback index comparison failures,
signature mismatch, signature made by an unknown key, vbmeta structs
without any signature, and so on. Basically the spirit here is that an
unlocked device should be able to boot an image built on your local
workstation and e.g. signed with your own keys.
To easily enable such operations with avb_slot_verify() and
avb_ab_flow(), we introduce a boolean |allow_verification_error|
parameter in each function. If this is false everything is as before
and we'll abort verification as soon as something doesn't verify.
On the other hand, if |allow_verification_error| is true then we'll
keep going and only bail if e.g. the AVB metadata is invalid, _not_ if
it fails verification.
This is designed so callers can set |allow_verification_error| to true
exactly if the device is unlocked.
Callers of avb_slot_verify() where |allow_verification_error| is set
to true are guaranteed that AVB_SLOT_VERIFY_RESULT_OK is returned if,
and only if, the slot verified correctly.
Introduce AVB_AB_FLOW_RESULT_OK_WITH_VERIFICATION_ERROR in addition to
AVB_AB_FLOW_RESULT_OK so avb_ab_flow() users can make a distinction
whether the image verified or not. The new value can only returned if
|allow_verification_error| is set to true.
In both cases - avb_slot_verify() and avb_ab_flow() - the bootloader
has enough information to determine if the slot to boot cannot be
verified. For example, the device can convey to the user that the OS
it's about to boot is unverified and request the user to click
through. On the other hand if the slot did verify (despite the device
being unlocked) the bootloader can nicely avoid such a kludge.
Add some new test cases to verify correct operation both if
|allow_verification_error| is true or false.
Test: New unit tests and all unit tests pass.
Test: Tested in UEFI-based bootloader in qemu.
Bug: 32949911
Change-Id: I218c8761c201d2e8e4dc73eaebfb1ac2742e0726
/external/avb/test/avb_slot_verify_unittest.cc
|
| 18666abc5d8276a743111e6c3608e66f6c85fb51 |
|
15-Nov-2016 |
David Zeuthen <zeuthen@google.com> |
Make it possible to include public key metadata.
A new option --public_key_metadata can be used at image build time to
include a "public key metadata" blob in the vbmeta struct and this
data is passed to the validate_vbmeta_public_key() AvbOps operation
along with the public key.
The use-case for this option is a device where the root-of-trust
embedded in the device is different from the key used to sign AVB
metadata. Specifically, the public key metadata blob can be data
signed by the device root-of-trust and the data could assert the trust
chain between this root-of-trust and the AVB public key used to sign
the AVB metadata.
(This change breaks the on-disk image format but that's OK because
we're still pre-1.0 with respect to image format stability
guarantees.)
Bug: 32736356
Test: New unit tests and all unit tests pass.
Test: Tested in UEFI-based bootloader in qemu.
Change-Id: I7b9c3bf2f9326b5bb5659b2a431a59a5c9016aff
/external/avb/test/avb_slot_verify_unittest.cc
|
| a8bb9a0e8635e3562367ebfe89b1870b4e2cc8e2 |
|
28-Oct-2016 |
David Zeuthen <zeuthen@google.com> |
libavb: Make it possible to load other partitions than 'boot'.
Boot loaders may need to load other partitions than just 'boot'. For
example in a setup where both the Secure OS and Android is managed and
updated under the same A/B regime, the boot loader needs to load and
verify both of these and start both of them.
Concretely, make avb_slot_verify() and avb_ab_flow() take a list of
partition name to load and extend AvbSlotVerifyData to contain an array
of the partitions that were loaded.
Bug: None
Test: New unit tests and unit tests pass.
Test: Tested in UEFI-based bootloader and qemu.
Change-Id: I5c369faebf707f87df41418223ce94506d86058e
/external/avb/test/avb_slot_verify_unittest.cc
|
| 5cb2db99e2bd7ea889a91f22d3c104118ff199b7 |
|
27-Oct-2016 |
David Zeuthen <zeuthen@google.com> |
Add room for expansion in descriptors.
As seen in the previous CL adding FEC data to the Hashtree descriptor,
it's not inconceivable that we'll need additional fields in the
future. Therefore add a reserved field of 64 bytes for each descriptor
type. This way we can add fields in the future without breaking forwards
or backwards compability.
Don't do this for Property or KernelCmdline descriptors since these are
already free-form data.
Bug: None
Test: Unit tests pass.
Change-Id: I4a277546fd48e83f861ab5484f7e18524b7b0117
/external/avb/test/avb_slot_verify_unittest.cc
|
| 88b13e12a0ebe3c5195dbb5f48ba00ec896d1517 |
|
03-Oct-2016 |
David Zeuthen <zeuthen@google.com> |
Include full vbmeta digest on the kernel cmdline.
While manually sanity-checking the androidboot.vbmeta.digest value (by
running sha256sum on the DUT) I discovered that only half the digest was
appended to the kernel command-line. While we already had unit tests for
checking this, the data hardcoded in the unit tests was also half the
size.
Here's the output from the DUT for manually testing the fix:
# getprop |grep vbmeta
[ro.boot.vbmeta.device_state]: [unlocked]
[ro.boot.vbmeta.digest]: [f75dc1643b48d19696d001b0f6ef90440ef2df43253c00c4675f53fa70b3ab64]
[ro.boot.vbmeta.hash_alg]: [sha256]
[ro.boot.vbmeta.size]: [2944]
# dd if=/dev/block/pci/pci0000\:00/0000\:00\:01.1/by-name/vbmeta_a bs=1 count=2944 |sha256sum
f75dc1643b48d19696d001b0f6ef90440ef2df43253c00c4675f53fa70b3ab64 -
Bug: None
Change-Id: I60ad123b9abaa5f271ffd256964eb63acfb3807d
Test: Manually tested on DUT, see above
Test: Updated unit tests and all unit tests pass.
/external/avb/test/avb_slot_verify_unittest.cc
|
| 8b6973be7468f5c0db42ff8fcd91f8e97a345a27 |
|
20-Sep-2016 |
David Zeuthen <zeuthen@google.com> |
Add A/B implementation.
This CL add routines for working with A/B metadata, including A/B
selection and managing rollback indexes.
A/B metadata is stored in the 'misc' partition in the |slot_suffix|
field using a format private to libavb - see bootable/recovery/bootloader.h
for more details. A new set_ab_metadata sub-command has been added to
avbtool for initializing A/B metadata at build time.
A/B metadata integrity is provided by a simple magic marker and a CRC-32
checksum. If invalid A/B metadata is detected, the behavior is to reset
the A/B metadata to a known state where both slots are given seven boot
tries.
An implementation of the boot_control HAL using AVB-specific A/B
metadata is also provided.
Also factored out the test-side AvbOps into a FakeAvbOps class and put
it in its own file.
Saw a couple of references to things like "Brillo Boot Image" and the
like. Fixed these up.
This CL is based on work done by Kevin Chavez - see b/29072323 - during
his internship at Google.
BUG=31264229
TEST=New unit tests + all unit tests pass.
TEST=Manual testing of boot_control HAL using the bootctl command.
Change-Id: I594ea4173a051ecb72636058440372ff1ca5855b
/external/avb/test/avb_slot_verify_unittest.cc
|
| c612e2e353444f6ad714e43702c2afd057516254 |
|
16-Sep-2016 |
David Zeuthen <zeuthen@google.com> |
Switch to MIT license.
BUG=31508897
TEST=Unit tests pass.
Change-Id: I790afce2889e3dfaf6a53c02ccaaec3544229a9c
/external/avb/test/avb_slot_verify_unittest.cc
|
| 21e95266704e572ced1c633bbc4aea9f42afa0a5 |
|
27-Jul-2016 |
David Zeuthen <zeuthen@google.com> |
Add common verified boot tools and library.
This code is originally from the Brillo project but has been adapted for
use in all of Android. It consists of a tool - avbtool - for working
with images (e.g. boot.img, system.img). See the README file for how
it's integrated into the Android build system and how to enable it.
The main job of avbtool is to create vbmeta.img which is the
top-level object for verified boot. This image is designed to go into
the vbmeta partition (or, if using A/B, the slot in question
e.g. vbmeta_a or vbmeta_b) and be of minimal size (for out-of-band
updates). The vbmeta image is cryptographically signed and contains
verification data (e.g. cryptographic digests) for verifying boot.img,
system.img, and other partitions/images.
The vbmeta image can also contain references to other partitions where
verification data is stored as well as a public key indicating who
should sign the verification data. This indirection provides
delegation, that is, it allows a 3rd party to control content on a given
partition by including the public key said 3rd party is using to sign
the data with, in vbmeta.img. By design, this authority can be easily
revoked by simply updating vbmeta.img with new descriptors for the
partition in question.
Storing signed verification data on other images - for example
boot.img and system.img - is also done with avbtool.
In addition to avbtool, a library - libavb - is provided. This library
performs all verification on the device side e.g. it starts by loading
the vbmeta partition, checks the signature, and then goes on to load
the boot partition for verification.
The libavb library is intended to be used in both boot loaders and
inside Android. It has a simple abstraction for system dependencies
(see libavb/avb_sysdeps.h) as well as operations that the boot loader
or OS is expected to implement (see libavb/avb_ops.h).
In addition to handling verified boot, libavb will in the future be
extended to handle A/B selection in a way that can be used in the
device's fastboot implementation, its boot loader, and its
boot_control HAL implementation. This will be implemented in a future
CL.
BUG=29414516
TEST=Unit tests for avbtool and libavb + unit tests pass.
Change-Id: I69ee86878e21fa718faccfc56eb0b1f40707d847
/external/avb/test/avb_slot_verify_unittest.cc
|