Android文件系统保护——dmverity

    研究dmverity比较早了，从4.4的版本就开始。前期的版本由于文件系统限制，不能直接使用。手机的文件系统格式又比较多。jffs2和romfs,ramfs用的比较多。所以限制了这个技术的使用。随着版本一步一步升级。谷歌终于决定统一该技术了。

Android 5.x OTA Update官方文档（三、模块式OTA）

转自http://blog.csdn.net/huangyabin001/article/details/44871481

    若能直译，不会意译，意译不成，为了选择不误导他人也会漏译无伤大雅的部分，英语是硬伤，如果有误译，请路过的朋友帮忙指正，以免误导更多的朋友，这一篇我看得特别费劲，所以推荐大家直接看原版文档。

    OTA是原始制造商用来远程升级系统分区的一种机制，在Android5.0的设备上我们可以使用模块式OTA来更新我们的设备。

    Android5.x及其之后的版本都可以使用模块式OTA来保证每个设备使用相同的分区。模块式OTA把整个分区作为一个文件并且生成一个二进制补丁，而不是对比每个文件生成对应的很多个补丁。

    Android4.4及其早起的版本使用文件式OTA的方式来确保设备包含相同的文件内容、权限和模式。但是这种升级方法允许时间戳和潜在的布局等发生变化。

 

    由于block OTA允许每个设备之间必须使用相同的分区，因此它允许使用dm_verity方式来对系统分区进行加密。（dm_verity:device-mapper-verity数据映射真实性）。

 

    在Android5.x及其之后的版本我们可以通过在打包工具ota_from_target_files使用--block参数来生成一个基于模块式的OTA，从而实现模块式OTA实施方案。而由于搭载4.4及其早期的版本都是使用文件式的OTA，因此我们可以通过一个完整模块式OTA来及过渡我们当前的设备。

    DMVerity需要搭载了Android5.x系统的新的设备中bootloader的支持，因次我们不能在旧的设备上使用DMVerity。

    致力于维护Android OTA System的开发者们可以订阅[email protected] ，以便及时的了解最新的消息。

原文如下：

You can enable block-based over-the-air (OTA) updates for new devices running Android 5.0. OTA is the mechanism by which OEMs remotely update the system partition of a device:

• Android 5.0 and later versions use block OTA updates to ensure that each device uses the exact same partition. Instead of comparing individual files and computing binary patches, block OTA handles the entire partition as one file and computes a single binary patch, ensuring the resultant partition contains exactly the intended bits. This allows the device system image to achieve the same state via fastboot or OTA.
• Android 4.4 and earlier versions used file OTA updates, which ensured devices contained similar file contents, permissions, and modes, but allowed metadata such as timestamps and the layout of the underlying storage to vary between devices based on the update method.

Because block OTA ensures that each device uses the same partition, it enables the use of dm-verity to cryptographically sign the system partition. For details on dm-verity, see Verified Boot.

Note: You must have a working block OTA system before using dm-verity.

Recommendations

---

For devices launching with Android 5.0 or later, use block OTA updates in the factory ROM. To generate a block-based OTA for subsequent updates, pass the --block option to ota_from_target_files.

For devices that launched with Android 4.4 or earlier, use file OTA updates. While is it possible to transition devices by sending a full block OTA of Android 5.0 or later, it requires sending out a full OTA that is significantly larger than an incremental OTA (and is therefore discouraged).

Because dm-verity requires bootloader support found only in new devices shipping with Android 5.0 or later, youcannot enable dm-verity for existing devices.

Developers working on the Android OTA system (the recovery image and the scripts that generate OTAs) can keep up with changes by subscribing to the [email protected] mailing list.

File vs. Block OTAs

---

During a file-based OTA, Android attempts to change the contents of the system partition at the filesystem layer (on a file-by-file basis). The update is not guaranteed to write files in a consistent order, have a consistent last modified time or superblock, or even place the blocks in the same location on the block device. For this reason, file-based OTAs fail on a dm-verity-enabled device; after the OTA attempt, the device does not boot.

During a block-based OTA, Android serves the device the difference between the two block images (rather than two sets of files). The update checks a device build against the corresponding build server at the block level (below the filesystem) using one of the following methods:

• Full update. Copying the full system image is simple and makes patch generation easy but also generates large images that can make applying patches expensive.
• Incremental update. Using a binary differ tool generates smaller images and makes patch application easy, but is memory-intensive when generating the patch itself.

Note: adb fastboot places the exact same bits on the device as a full OTA, so flashing is compatible with block OTA.

Updating unmodified systems

For devices with unmodified system partitions running Android 5.0, the download and install process for a block OTA remains the same as for a file OTA. However, the OTA update itself might include one or more of the following differences:

• Download size. Full block OTA updates are approximately the same size as full file OTA updates, and incremental updates can be just a few megabytes larger.
• 
  

  Figure 1. Compare Nexus 6 OTA sizes between Android 5.0 and Android 5.1 releases (varying target build changes)

  In general, incremental block OTA updates are larger than incremental file OTA updates due to:

  • Data preservation. Block-based OTAs preserve more data (file metadata, dm-verity data, ext4 layout, etc.) than file-based OTA.
  • Computation algorithm differences. In a file OTA update, if a file path is identical in both builds, the OTA package contains no data for that file. In a block OTA update, determining little or no change in a file depends on the quality of the patch computation algorithm and layout of file data in both source and target system.
• Sensitivity to faulty flash and RAM. If a file is corrupted, a file OTA succeeds as long as it doesn't touch the corrupted file, but a block OTA fails if it detects any corruption on the system partition.

Updating modified systems

For devices with modified system partitions running Android 5.0:

• Incremental block OTA updates fail. A system partition might be modified during an adb remount or as a result of malware. File OTA tolerates some changes to the partition, such as the addition of files that are not part of the source or target build. However, block OTA does not tolerate additions to the partition, so users will need to install a full OTA overwriting any system partition modifications) or flash a new system image to enable future OTAs.
• Attempts to change modified files cause update failure. For both file and block OTA updates, if the OTA attempts to change a file that has been modified, the OTA update fails.
• Attempts to access modified files generate errors (dm-verity only). For both file and block OTA updates, if dm-verity is enabled and the OTA attempts to access modified parts of the system filesystem, the OTA generates an error.