search

anestisb / android-prepare-vendor

Set of scripts to automate AOSP compatible vendor blobs generation from factory images
348 stars 155 forks source link

Can someone explain why dm-verity does not work out of the box #138

Closed ardevd closed 5 years ago

ardevd commented 5 years ago

I'm building AOSP for a Pixel C (Dragon) and I'm struggling to with dm-verity and it refuses to boot if I compile the -eng build. Then I stumbled upon this repository. However, I am still a bit confused as to exactly why dm-verity wont work. I assumed the cryptographic hash tree would be generated after the different images were built?

Could someone please explain?

Thanks!

anestisb commented 5 years ago

Pixel C was never supported by this tool. I haven't personally worked with any Pixel C devices so I cannot help. But since it has an unlocked bootloader and is an AOSP supported device I can't see any reason not to boot as long as you have properly signed the images.

Maybe https://groups.google.com/forum/#!forum/android-building is a more appropriate place to ask.

ardevd commented 5 years ago

Thanks for responding. I am aware the Pixel C is not supported by this project but my question was more general in nature. When I build AOSP and flash it on the Pixel C it boots up just fine until I lock the bootloader. At that point, whenever i boot it will throw me to the bootloader screen and display an error saying "OS on your tablet is damaged. Needs recovery". My question here was whether this is related to dm-verity and the as an extension, the purpose of this project of it it might be something else?

Thanks.

thestinger commented 5 years ago

dm-verify is how the kernel verifies the system / vendor images. It isn't the mechanism used to verify the boot image. The bootloader on the Pixel C may not support locking the bootloader with an alternate OS at all, or you may just not be signing it with the appropriate tool. You would need to do that research yourself.

ardevd commented 5 years ago

Thanks. That all I needed to know. Cheers!

ardevd commented 5 years ago

@thestinger I'm still a bit confused about why this project exists though. If dm-verity works out of the box, what problem does this project solve? Is it just the ability to build the vendor.img with the correct fingerprint so that you get rid of the error message from the framework when booting? I've read the README but with all the status updates from the recent AOSP updates, I'm not entirely sure what's valid anymore.

thestinger commented 5 years ago

If dm-verity works out of the box

It doesn't work out of the box for vendor.img. It only works out of the box for system.img.

what problem does this project solve?

It regenerates vendor.img to have dm-verity and a proper fingerprint, along with being able to build components in it from source. A substantial portion of it is open source.

It also bundles all the necessary files for device support into system.img and sets up various resources / properties for device and carrier support. The device support packages from Google are very incomplete and this project is needed to have fully working builds.

I've read the README but with all the status updates from the recent AOSP updates, I'm not entirely sure what's valid anymore.

It's needed both to regenerate vendor.img and for proper device support in system.img.

ardevd commented 5 years ago

Thank you! It makes sense now. So in my case my only option is to disable dm-verity for the vendor partition?

thestinger commented 5 years ago

Compare https://github.com/anestisb/android-prepare-vendor/blob/master/blueline/config.json to the list of files in Google's device support packages for the Pixel 3, or do the same for another device. You can see that they're missing quite a bit. The bytecode packages (apk, jar) are also often only available in an optimized format which needs to be reversed back to dex bytecode to robustly include it.

Some work has also gone into replicating a subset of the properties and resource overlays missing from AOSP. For example, ro.control_privapp_permissions=enforce is a security feature missing in a build of AOSP for marlin or sailfish as it's set in Google's internal device support repository. There are also various resource overrides for frameworks/base, packages/apps/Settings, etc. which are not yet part of the project.

thestinger commented 5 years ago

Thank you! It makes sense now. So in my case my only option is to disable dm-verity for the vendor partition?

What makes you think that's the issue? I explained the likely problem above:

dm-verify is how the kernel verifies the system / vendor images. It isn't the mechanism used to verify the boot image. The bootloader on the Pixel C may not support locking the bootloader with an alternate OS at all, or you may just not be signing it with the appropriate tool. You would need to do that research yourself.

thestinger commented 5 years ago

The bootloader verifies the boot image (including the kernel) before the kernel is loaded. The kernel verifies system and vendor.

ardevd commented 5 years ago

Thank you! I didnt mean to have you answer the same question twice I was just curious about the dm-verity part of this project.

As you say, the bootloader verifies the boot.img and for some reason it's not willing to boot my aosp build when the bootloader is locked. I've never encountered a device that refuses to do so, but as you say, this might be a limitation specific to the bootloader on the Pixel C. I tried reaching out to the appropriate google group but no response so far. I also havent been able to find anyone else with the same issue but given the limited nature of the Pixel C's distribution, I guess that's not too big of a surprise.

thestinger commented 5 years ago

I've never encountered a device that refuses to do so

Google introduced a full verified boot chain with the Nexus 5X, Nexus 6P and Pixel C. Earlier Nexus devices didn't verify the boot image when the bootloader was locked. It wasn't the same thing. It only prevented administration actions via fastboot like flashing and formatting partitions on previous generations.

The standardized support for verified boot has green, yellow, orange and red states. See https://source.android.com/security/verifiedboot/boot-flow. The Pixel C doesn't implement the standard verified boot. It has a custom implementation and may not have support for verifying an alternate operating system like the Nexus 5X, 6P and Pixel phones.

ardevd commented 5 years ago

Interesting. May I ask how you know the Pixel C does not implement the standard verified boot? Is the custom implementation detailed or documented anywhere?

thestinger commented 5 years ago

Interesting. May I ask how you know the Pixel C does not implement the standard verified boot? Is the custom implementation detailed or documented anywhere?

You can see that for yourself from the message it shows when the bootloader is unlocked.

I'm not aware of any phones or tablets with support for verified boot with an alternate OS other than the Nexus 5X, 6P, Pixel, Pixel XL, Pixel 2, Pixel 2 XL, Pixel 3 and Pixel 3 XL.

Modern Android devices are required to provide verified boot, so if they don't implement support for the optional yellow state they aren't going to support locking the bootloader with an alternate OS. Locking the bootloader with an alternate OS generally doesn't work anymore with the exception of Pixel phones and the last generation of Nexus phones since it does more than simply disabling flashing and formatting via fastboot.

thestinger commented 5 years ago

It would be news to me if the Pixel C or any other phones or tablets supported verified boot with an alternate OS. I'm not aware of any tablet supporting it. As far I know, it has never been implemented elsewhere or at least hasn't ever been publicly used / discussed.

Look at the sample screens at https://source.android.com/security/verifiedboot/boot-flow. If the Pixel C implemented this, you would have seen the orange (unlocked) and red (locked with corrupt OS) screens by now, with your goal being a successful yellow state. I don't think it has this. That's why I said above that if it does support verified boot with an alternate OS.

For the Pixel 2, we had to reverse engineer the bootloader to discover avb_custom_key and figure out how to use it, which I then documented and submitted for inclusion in the official AVB documentation in AOSP where it's now published.

The Pixel C boot chain firmware is open source, so you could easily figure out if verified boot for alternate operating systems is supported by looking into it. I seriously doubt that it's supported.

ardevd commented 5 years ago

@thestinger Very interesting! Do you have a link to the source for the Pixel C boot chain firmware?

ardevd commented 5 years ago

Also, is avb_custom_key used for the Pixel 3 as well? I dont see any reference to avb_custom_key in this repository.

thestinger commented 5 years ago

This repository doesn't handle that, since it's outside the scope of it. It's part of flashing AOSP onto a Pixel 2 or Pixel 2 XL (AVB 1.0). I assume they reused the same API on the Pixel 3 and Pixel 3 XL (AVB 1.1).

On the Nexus 5X, Nexus 6P, Pixel and Pixel XL, an earlier verified boot standard was used and it didn't have an explicit step for flashing the public key. It still had a mechanism to enforce it but it wasn't as good and relied on binding it to the TEE on first boot.

ardevd commented 5 years ago

Cool, learning a lot here. Did you have a link to the source for the Pixel C boot chain firmware though? I also tried extracting the bootloader using imgtool but it failed to extract.

thestinger commented 5 years ago

factory-ryu at https://chromium.googlesource.com/chromiumos/third_party/coreboot/+refs