| 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/libavb/avb_vbmeta_image.h
|
| b0f1787002898154e617db69393bed651970bc55 |
|
22-Mar-2017 |
David Zeuthen <zeuthen@google.com> |
Use Markdown in README file.
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
/external/avb/libavb/avb_vbmeta_image.h
|
| 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/libavb/avb_vbmeta_image.h
|
| 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/libavb/avb_vbmeta_image.h
|
| 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/libavb/avb_vbmeta_image.h
|
| 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/libavb/avb_vbmeta_image.h
|
| 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/libavb/avb_vbmeta_image.h
|
| c612e2e353444f6ad714e43702c2afd057516254 |
|
16-Sep-2016 |
David Zeuthen <zeuthen@google.com> |
Switch to MIT license.
BUG=31508897
TEST=Unit tests pass.
Change-Id: I790afce2889e3dfaf6a53c02ccaaec3544229a9c
/external/avb/libavb/avb_vbmeta_image.h
|
| 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/libavb/avb_vbmeta_image.h
|