f1bdec37f0f97c0640667178b2ac152c54442dfc |
|
10-Mar-2017 |
David Zeuthen <zeuthen@google.com> |
libavb: Only print basename of file in avb_debug() and friends. In some setups where libavb is used, the macro __FILE__ evaluates to a really long strings such as /some_mount_point/path/to/something/and/then/libavb/avb_slot_verify.c /foo/bar/baz/foo/XyzComponent/../../libavb/avb_slot_verify.c meaning that debug output is cluttered to the point that it's not useful. Unfortunately there's no __FILENAME__ macro in C so instead figure out the basename at runtime. Bug: None Test: New unit tests and unit tests pass. Test: Tested on various boot loaders. Change-Id: Icb7d407bc0960d50ac069d3426a48531775dcf89
/external/avb/test/avb_util_unittest.cc
|
0f7de9479afef18835cdbfe3da07811a7993504e |
|
08-Mar-2017 |
David Zeuthen <zeuthen@google.com> |
Add memory leak tracing infrastructure and fix a memory leak. Do this by instrumenting the malloc()/free() routines used by the tests and have it record a stack trace for every allocation. Check at the end of each unit test that all memory has been freed. If not, print a list of all these stack traces. Re-organize all tests so they derive from BaseAvbtoolTest and make this super class do the requisite leak-reset and leak-check in Setup() and Teardown() methods. After doing this, the only leak identified in libavb (woot!) turned out to be in avb_slot_verify(). Fix this. Also fix some tests that knowingly leak memory. Bug: None Test: All unit tests pass. Change-Id: I54da00ef0cc840e390cad118888affe5a86b76e3
/external/avb/test/avb_util_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_util_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_util_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_util_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_util_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_util_unittest.cc
|
baf59e232e48d0111e4b38f74c60c89e6f8f0b14 |
|
14-Nov-2016 |
David Zeuthen <zeuthen@google.com> |
libavb: Move all A/B functionality into separate libavb_ab/ directory. This new libavb_ab "library" depends on libavb "library" insofar that it's using the same abstractions (system dependencies and operations). For easy integration the newly introduced AvbABOps struct extends the AvbOps struct so users can build just a single struct and use that for both. Also emphasize in README that libavb_ab usage is optional and that it's possible to integrate libavb with another A/B stack. (The quotes in use for "library" above is because these are not really libraries from a system-integration perspective. That is, 3rd party is expected to integrate this source-code with their own build-system and toolchain.) Since we now have multiple libraries - at least from the point of view of how it's used in unit tests - change Android.mk such that library users need to use libavb/libavb.h and libavb_ab/libavb_ab.h instead of just e.g. libavb.h. Test: Unit tests pass Test: Tested in UEFI-based bootloader in qemu. Test: Tested boot_control.avb.so in same UEFI-based system. Bug: None Change-Id: I19ea8f6bd1e63b2617b0e9fa9fc3b2a68ac4a92e
/external/avb/test/avb_util_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_util_unittest.cc
|
0b7f1d3aadf8fcc79fff914480c7efcc3cfa4008 |
|
25-Oct-2016 |
David Zeuthen <zeuthen@google.com> |
Add support for FEC in hashtrees. This change adds support for 'avbtool add_hashtree_footer' options --generate_fec and --fec_num_roots. If used, this generates FEC data on the given image. If used on the root filesystem, the kernel command-line will be set up to use it. For more information about FEC, see https://gitlab.com/cryptsetup/cryptsetup/wikis/DMVerity By default this feature is not turned on. It can be enabled for the root filesystem by adding this line BOARD_AVB_SYSTEM_ADD_HASHTREE_FOOTER_ARGS := --generate_fec to the build system files. Note that this change extends the AvbHashtreeDescriptor struct to carry FEC-related metadata. This change would normally be a no-no (since we're changing metadata stored on disk!) but since AVB isn't yet used in device firmware - or even undergone a release (see Issue 32414650) - this change is considered to be OK. Test: New unit tests + unit tests pass. Test: Manually tested in qemu using an UEFI-based bootloader. Bug: 31263832 Change-Id: I271956112c0fe52f57e3a66c0d0658e6b5266239
/external/avb/test/avb_util_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_util_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_util_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_util_unittest.cc
|