platform_build/tools/releasetools/validate_target_files.py

510 lines
20 KiB
Python
Raw Normal View History

#!/usr/bin/env python
# Copyright (C) 2017 The Android Open Source Project
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
"""
Validate a given (signed) target_files.zip.
It performs the following checks to assert the integrity of the input zip.
- It verifies the file consistency between the ones in IMAGES/system.img (read
via IMAGES/system.map) and the ones under unpacked folder of SYSTEM/. The
same check also applies to the vendor image if present.
- It verifies the install-recovery script consistency, by comparing the
checksums in the script against the ones of IMAGES/{boot,recovery}.img.
- It verifies the signed Verified Boot related images, for both of Verified
Boot 1.0 and 2.0 (aka AVB).
"""
import argparse
import filecmp
import logging
import os.path
import re
import zipfile
from hashlib import sha1
releasetools: Make validate_target_files.py pylint clean. C: 73, 0: Wrong hanging indentation (add 4 spaces). file_name, actual_sha1, expected_sha1) ^ | (bad-continuation) C:171, 0: Wrong continued indentation (add 20 spaces). 'SYSTEM/etc/recovery.img', expected_recovery_sha1) ^ | (bad-continuation) C:185, 0: Wrong continued indentation (add 20 spaces). file_path='IMAGES/boot.img', expected_sha1=boot_info[3]) ^ | (bad-continuation) C:191, 0: Wrong continued indentation (add 20 spaces). file_path='IMAGES/recovery.img', ^ | (bad-continuation) C:192, 0: Wrong continued indentation (add 20 spaces). expected_sha1=expected_recovery_sha1) ^ | (bad-continuation) W: 67,15: Use % formatting in logging functions and pass the % parameters as arguments (logging-format-interpolation) W:150,17: Use % formatting in logging functions and pass the % parameters as arguments (logging-format-interpolation) W:153,15: Use % formatting in logging functions and pass the % parameters as arguments (logging-format-interpolation) W:194,15: Use % formatting in logging functions and pass the % parameters as arguments (logging-format-interpolation) C: 27, 0: standard import "import logging" comes before "import common" (wrong-import-order) C: 28, 0: standard import "import os.path" comes before "import common" (wrong-import-order) C: 29, 0: standard import "import re" comes before "import common" (wrong-import-order) C: 31, 0: standard import "import sys" comes before "import common" (wrong-import-order) Test: pylint --rcfile=pylintrc validate_target_files.py Test: Run validate_target_files.py with a target-files.zip. Change-Id: Ie64acdb4cee4326938c4ad5a34b575d7b82478c0
2018-02-01 21:00:19 +01:00
import common
import rangelib
def _ReadFile(file_name, unpacked_name, round_up=False):
"""Constructs and returns a File object. Rounds up its size if needed."""
assert os.path.exists(unpacked_name)
with open(unpacked_name, 'rb') as f:
file_data = f.read()
file_size = len(file_data)
if round_up:
file_size_rounded_up = common.RoundUpTo4K(file_size)
file_data += b'\0' * (file_size_rounded_up - file_size)
return common.File(file_name, file_data)
def ValidateFileAgainstSha1(input_tmp, file_name, file_path, expected_sha1):
"""Check if the file has the expected SHA-1."""
releasetools: Make validate_target_files.py pylint clean. C: 73, 0: Wrong hanging indentation (add 4 spaces). file_name, actual_sha1, expected_sha1) ^ | (bad-continuation) C:171, 0: Wrong continued indentation (add 20 spaces). 'SYSTEM/etc/recovery.img', expected_recovery_sha1) ^ | (bad-continuation) C:185, 0: Wrong continued indentation (add 20 spaces). file_path='IMAGES/boot.img', expected_sha1=boot_info[3]) ^ | (bad-continuation) C:191, 0: Wrong continued indentation (add 20 spaces). file_path='IMAGES/recovery.img', ^ | (bad-continuation) C:192, 0: Wrong continued indentation (add 20 spaces). expected_sha1=expected_recovery_sha1) ^ | (bad-continuation) W: 67,15: Use % formatting in logging functions and pass the % parameters as arguments (logging-format-interpolation) W:150,17: Use % formatting in logging functions and pass the % parameters as arguments (logging-format-interpolation) W:153,15: Use % formatting in logging functions and pass the % parameters as arguments (logging-format-interpolation) W:194,15: Use % formatting in logging functions and pass the % parameters as arguments (logging-format-interpolation) C: 27, 0: standard import "import logging" comes before "import common" (wrong-import-order) C: 28, 0: standard import "import os.path" comes before "import common" (wrong-import-order) C: 29, 0: standard import "import re" comes before "import common" (wrong-import-order) C: 31, 0: standard import "import sys" comes before "import common" (wrong-import-order) Test: pylint --rcfile=pylintrc validate_target_files.py Test: Run validate_target_files.py with a target-files.zip. Change-Id: Ie64acdb4cee4326938c4ad5a34b575d7b82478c0
2018-02-01 21:00:19 +01:00
logging.info('Validating the SHA-1 of %s', file_name)
unpacked_name = os.path.join(input_tmp, file_path)
assert os.path.exists(unpacked_name)
actual_sha1 = _ReadFile(file_name, unpacked_name, False).sha1
assert actual_sha1 == expected_sha1, \
'SHA-1 mismatches for {}. actual {}, expected {}'.format(
releasetools: Make validate_target_files.py pylint clean. C: 73, 0: Wrong hanging indentation (add 4 spaces). file_name, actual_sha1, expected_sha1) ^ | (bad-continuation) C:171, 0: Wrong continued indentation (add 20 spaces). 'SYSTEM/etc/recovery.img', expected_recovery_sha1) ^ | (bad-continuation) C:185, 0: Wrong continued indentation (add 20 spaces). file_path='IMAGES/boot.img', expected_sha1=boot_info[3]) ^ | (bad-continuation) C:191, 0: Wrong continued indentation (add 20 spaces). file_path='IMAGES/recovery.img', ^ | (bad-continuation) C:192, 0: Wrong continued indentation (add 20 spaces). expected_sha1=expected_recovery_sha1) ^ | (bad-continuation) W: 67,15: Use % formatting in logging functions and pass the % parameters as arguments (logging-format-interpolation) W:150,17: Use % formatting in logging functions and pass the % parameters as arguments (logging-format-interpolation) W:153,15: Use % formatting in logging functions and pass the % parameters as arguments (logging-format-interpolation) W:194,15: Use % formatting in logging functions and pass the % parameters as arguments (logging-format-interpolation) C: 27, 0: standard import "import logging" comes before "import common" (wrong-import-order) C: 28, 0: standard import "import os.path" comes before "import common" (wrong-import-order) C: 29, 0: standard import "import re" comes before "import common" (wrong-import-order) C: 31, 0: standard import "import sys" comes before "import common" (wrong-import-order) Test: pylint --rcfile=pylintrc validate_target_files.py Test: Run validate_target_files.py with a target-files.zip. Change-Id: Ie64acdb4cee4326938c4ad5a34b575d7b82478c0
2018-02-01 21:00:19 +01:00
file_name, actual_sha1, expected_sha1)
def ValidateFileConsistency(input_zip, input_tmp, info_dict):
"""Compare the files from image files and unpacked folders."""
def CheckAllFiles(which):
logging.info('Checking %s image.', which)
# Allow having shared blocks when loading the sparse image, because allowing
# that doesn't affect the checks below (we will have all the blocks on file,
# unless it's skipped due to the holes).
image = common.GetSparseImage(which, input_tmp, input_zip, True)
prefix = '/' + which
for entry in image.file_map:
# Skip entries like '__NONZERO-0'.
if not entry.startswith(prefix):
continue
# Read the blocks that the file resides. Note that it will contain the
# bytes past the file length, which is expected to be padded with '\0's.
ranges = image.file_map[entry]
# Use the original RangeSet if applicable, which includes the shared
# blocks. And this needs to happen before checking the monotonicity flag.
if ranges.extra.get('uses_shared_blocks'):
file_ranges = ranges.extra['uses_shared_blocks']
else:
file_ranges = ranges
incomplete = file_ranges.extra.get('incomplete', False)
if incomplete:
logging.warning('Skipping %s that has incomplete block list', entry)
continue
# If the file has non-monotonic ranges, read each range in order.
if not file_ranges.monotonic:
h = sha1()
for file_range in file_ranges.extra['text_str'].split(' '):
for data in image.ReadRangeSet(rangelib.RangeSet(file_range)):
h.update(data)
blocks_sha1 = h.hexdigest()
else:
blocks_sha1 = image.RangeSha1(file_ranges)
# The filename under unpacked directory, such as SYSTEM/bin/sh.
unpacked_name = os.path.join(
input_tmp, which.upper(), entry[(len(prefix) + 1):])
unpacked_file = _ReadFile(entry, unpacked_name, True)
file_sha1 = unpacked_file.sha1
assert blocks_sha1 == file_sha1, \
'file: %s, range: %s, blocks_sha1: %s, file_sha1: %s' % (
entry, file_ranges, blocks_sha1, file_sha1)
logging.info('Validating file consistency.')
# TODO(b/79617342): Validate non-sparse images.
if info_dict.get('extfs_sparse_flag') != '-s':
logging.warning('Skipped due to target using non-sparse images')
return
# Verify IMAGES/system.img.
CheckAllFiles('system')
# Verify IMAGES/vendor.img if applicable.
if 'VENDOR/' in input_zip.namelist():
CheckAllFiles('vendor')
# Not checking IMAGES/system_other.img since it doesn't have the map file.
def ValidateInstallRecoveryScript(input_tmp, info_dict):
"""Validate the SHA-1 embedded in install-recovery.sh.
install-recovery.sh is written in common.py and has the following format:
1. full recovery:
...
if ! applypatch --check type:device:size:sha1; then
Moving recovery resources from /system to /vendor This change is part of a topic that moves the recovery resources from the system partition to the vendor partition, if it exists, or the vendor directory on the system partition otherwise. The recovery resources are moving from the system image to the vendor partition so that a single system image may be used with either an A/B or a non-A/B vendor image. The topic removes a delta in the system image that prevented such reuse in the past. The recovery resources that are moving are involved with updating the recovery partition after an update. In a non-A/B configuration, the system boots from the recovery partition, updates the other partitions (system, vendor, etc.) Then, the next time the system boots normally, a script updates the recovery partition (if necessary). This script, the executables it invokes, and the data files that it uses were previously on the system partition. The resources that are moving include the following. * install-recovery.sh * applypatch * recovery-resource.dat (if present) * recovery-from-boot.p (if present) This change includes the platform build system and release tools changes to move the recovery resources from system to vendor (or /system/vendor). The release tools need to know where to generate the recovery patch, and they discover this from misc_info.txt variable board_uses_vendorimage, which the platform build system generates. We remove applypatch from PRODUCT_PACKAGES, but it is added back as a required module in target/product/base_vendor.mk. Several release tools rely on the misc_info.txt board_uses_vendorimage variable to know how to generate and detect the recovery patch. This change partially removes the --rebuild_recovery flag from the merge_target_files.py script. The flag will be fully removed in a follow-on change. Bug: 68319577 Test: Ensure that recovery partition is updated correctly. Change-Id: Ia4045bd67ffb3d899efa8d20dab4c4299b87ee5f
2019-09-18 02:06:47 +02:00
applypatch --flash /vendor/etc/recovery.img \\
type:device:size:sha1 && \\
...
2. recovery from boot:
...
if ! applypatch --check type:recovery_device:recovery_size:recovery_sha1; then
applypatch [--bonus bonus_args] \\
Moving recovery resources from /system to /vendor This change is part of a topic that moves the recovery resources from the system partition to the vendor partition, if it exists, or the vendor directory on the system partition otherwise. The recovery resources are moving from the system image to the vendor partition so that a single system image may be used with either an A/B or a non-A/B vendor image. The topic removes a delta in the system image that prevented such reuse in the past. The recovery resources that are moving are involved with updating the recovery partition after an update. In a non-A/B configuration, the system boots from the recovery partition, updates the other partitions (system, vendor, etc.) Then, the next time the system boots normally, a script updates the recovery partition (if necessary). This script, the executables it invokes, and the data files that it uses were previously on the system partition. The resources that are moving include the following. * install-recovery.sh * applypatch * recovery-resource.dat (if present) * recovery-from-boot.p (if present) This change includes the platform build system and release tools changes to move the recovery resources from system to vendor (or /system/vendor). The release tools need to know where to generate the recovery patch, and they discover this from misc_info.txt variable board_uses_vendorimage, which the platform build system generates. We remove applypatch from PRODUCT_PACKAGES, but it is added back as a required module in target/product/base_vendor.mk. Several release tools rely on the misc_info.txt board_uses_vendorimage variable to know how to generate and detect the recovery patch. This change partially removes the --rebuild_recovery flag from the merge_target_files.py script. The flag will be fully removed in a follow-on change. Bug: 68319577 Test: Ensure that recovery partition is updated correctly. Change-Id: Ia4045bd67ffb3d899efa8d20dab4c4299b87ee5f
2019-09-18 02:06:47 +02:00
--patch /vendor/recovery-from-boot.p \\
--source type:boot_device:boot_size:boot_sha1 \\
--target type:recovery_device:recovery_size:recovery_sha1 && \\
...
Moving recovery resources from /system to /vendor This change is part of a topic that moves the recovery resources from the system partition to the vendor partition, if it exists, or the vendor directory on the system partition otherwise. The recovery resources are moving from the system image to the vendor partition so that a single system image may be used with either an A/B or a non-A/B vendor image. The topic removes a delta in the system image that prevented such reuse in the past. The recovery resources that are moving are involved with updating the recovery partition after an update. In a non-A/B configuration, the system boots from the recovery partition, updates the other partitions (system, vendor, etc.) Then, the next time the system boots normally, a script updates the recovery partition (if necessary). This script, the executables it invokes, and the data files that it uses were previously on the system partition. The resources that are moving include the following. * install-recovery.sh * applypatch * recovery-resource.dat (if present) * recovery-from-boot.p (if present) This change includes the platform build system and release tools changes to move the recovery resources from system to vendor (or /system/vendor). The release tools need to know where to generate the recovery patch, and they discover this from misc_info.txt variable board_uses_vendorimage, which the platform build system generates. We remove applypatch from PRODUCT_PACKAGES, but it is added back as a required module in target/product/base_vendor.mk. Several release tools rely on the misc_info.txt board_uses_vendorimage variable to know how to generate and detect the recovery patch. This change partially removes the --rebuild_recovery flag from the merge_target_files.py script. The flag will be fully removed in a follow-on change. Bug: 68319577 Test: Ensure that recovery partition is updated correctly. Change-Id: Ia4045bd67ffb3d899efa8d20dab4c4299b87ee5f
2019-09-18 02:06:47 +02:00
For full recovery, we want to calculate the SHA-1 of /vendor/etc/recovery.img
and compare it against the one embedded in the script. While for recovery
from boot, we want to check the SHA-1 for both recovery.img and boot.img
under IMAGES/.
"""
Moving recovery resources from /system to /vendor This change is part of a topic that moves the recovery resources from the system partition to the vendor partition, if it exists, or the vendor directory on the system partition otherwise. The recovery resources are moving from the system image to the vendor partition so that a single system image may be used with either an A/B or a non-A/B vendor image. The topic removes a delta in the system image that prevented such reuse in the past. The recovery resources that are moving are involved with updating the recovery partition after an update. In a non-A/B configuration, the system boots from the recovery partition, updates the other partitions (system, vendor, etc.) Then, the next time the system boots normally, a script updates the recovery partition (if necessary). This script, the executables it invokes, and the data files that it uses were previously on the system partition. The resources that are moving include the following. * install-recovery.sh * applypatch * recovery-resource.dat (if present) * recovery-from-boot.p (if present) This change includes the platform build system and release tools changes to move the recovery resources from system to vendor (or /system/vendor). The release tools need to know where to generate the recovery patch, and they discover this from misc_info.txt variable board_uses_vendorimage, which the platform build system generates. We remove applypatch from PRODUCT_PACKAGES, but it is added back as a required module in target/product/base_vendor.mk. Several release tools rely on the misc_info.txt board_uses_vendorimage variable to know how to generate and detect the recovery patch. This change partially removes the --rebuild_recovery flag from the merge_target_files.py script. The flag will be fully removed in a follow-on change. Bug: 68319577 Test: Ensure that recovery partition is updated correctly. Change-Id: Ia4045bd67ffb3d899efa8d20dab4c4299b87ee5f
2019-09-18 02:06:47 +02:00
board_uses_vendorimage = info_dict.get("board_uses_vendorimage") == "true"
if board_uses_vendorimage:
script_path = 'VENDOR/bin/install-recovery.sh'
recovery_img = 'VENDOR/etc/recovery.img'
else:
script_path = 'SYSTEM/vendor/bin/install-recovery.sh'
recovery_img = 'SYSTEM/vendor/etc/recovery.img'
if not os.path.exists(os.path.join(input_tmp, script_path)):
releasetools: Make validate_target_files.py pylint clean. C: 73, 0: Wrong hanging indentation (add 4 spaces). file_name, actual_sha1, expected_sha1) ^ | (bad-continuation) C:171, 0: Wrong continued indentation (add 20 spaces). 'SYSTEM/etc/recovery.img', expected_recovery_sha1) ^ | (bad-continuation) C:185, 0: Wrong continued indentation (add 20 spaces). file_path='IMAGES/boot.img', expected_sha1=boot_info[3]) ^ | (bad-continuation) C:191, 0: Wrong continued indentation (add 20 spaces). file_path='IMAGES/recovery.img', ^ | (bad-continuation) C:192, 0: Wrong continued indentation (add 20 spaces). expected_sha1=expected_recovery_sha1) ^ | (bad-continuation) W: 67,15: Use % formatting in logging functions and pass the % parameters as arguments (logging-format-interpolation) W:150,17: Use % formatting in logging functions and pass the % parameters as arguments (logging-format-interpolation) W:153,15: Use % formatting in logging functions and pass the % parameters as arguments (logging-format-interpolation) W:194,15: Use % formatting in logging functions and pass the % parameters as arguments (logging-format-interpolation) C: 27, 0: standard import "import logging" comes before "import common" (wrong-import-order) C: 28, 0: standard import "import os.path" comes before "import common" (wrong-import-order) C: 29, 0: standard import "import re" comes before "import common" (wrong-import-order) C: 31, 0: standard import "import sys" comes before "import common" (wrong-import-order) Test: pylint --rcfile=pylintrc validate_target_files.py Test: Run validate_target_files.py with a target-files.zip. Change-Id: Ie64acdb4cee4326938c4ad5a34b575d7b82478c0
2018-02-01 21:00:19 +01:00
logging.info('%s does not exist in input_tmp', script_path)
return
releasetools: Make validate_target_files.py pylint clean. C: 73, 0: Wrong hanging indentation (add 4 spaces). file_name, actual_sha1, expected_sha1) ^ | (bad-continuation) C:171, 0: Wrong continued indentation (add 20 spaces). 'SYSTEM/etc/recovery.img', expected_recovery_sha1) ^ | (bad-continuation) C:185, 0: Wrong continued indentation (add 20 spaces). file_path='IMAGES/boot.img', expected_sha1=boot_info[3]) ^ | (bad-continuation) C:191, 0: Wrong continued indentation (add 20 spaces). file_path='IMAGES/recovery.img', ^ | (bad-continuation) C:192, 0: Wrong continued indentation (add 20 spaces). expected_sha1=expected_recovery_sha1) ^ | (bad-continuation) W: 67,15: Use % formatting in logging functions and pass the % parameters as arguments (logging-format-interpolation) W:150,17: Use % formatting in logging functions and pass the % parameters as arguments (logging-format-interpolation) W:153,15: Use % formatting in logging functions and pass the % parameters as arguments (logging-format-interpolation) W:194,15: Use % formatting in logging functions and pass the % parameters as arguments (logging-format-interpolation) C: 27, 0: standard import "import logging" comes before "import common" (wrong-import-order) C: 28, 0: standard import "import os.path" comes before "import common" (wrong-import-order) C: 29, 0: standard import "import re" comes before "import common" (wrong-import-order) C: 31, 0: standard import "import sys" comes before "import common" (wrong-import-order) Test: pylint --rcfile=pylintrc validate_target_files.py Test: Run validate_target_files.py with a target-files.zip. Change-Id: Ie64acdb4cee4326938c4ad5a34b575d7b82478c0
2018-02-01 21:00:19 +01:00
logging.info('Checking %s', script_path)
with open(os.path.join(input_tmp, script_path), 'r') as script:
lines = script.read().strip().split('\n')
assert len(lines) >= 10
check_cmd = re.search(r'if ! applypatch --check (\w+:.+:\w+:\w+);',
lines[1].strip())
check_partition = check_cmd.group(1)
assert len(check_partition.split(':')) == 4
full_recovery_image = info_dict.get("full_recovery_image") == "true"
if full_recovery_image:
assert len(lines) == 10, "Invalid line count: {}".format(lines)
# Expect something like "EMMC:/dev/block/recovery:28:5f9c..62e3".
target = re.search(r'--target (.+) &&', lines[4].strip())
assert target is not None, \
"Failed to parse target line \"{}\"".format(lines[4])
flash_partition = target.group(1)
# Check we have the same recovery target in the check and flash commands.
assert check_partition == flash_partition, \
"Mismatching targets: {} vs {}".format(check_partition, flash_partition)
# Validate the SHA-1 of the recovery image.
recovery_sha1 = flash_partition.split(':')[3]
ValidateFileAgainstSha1(
Moving recovery resources from /system to /vendor This change is part of a topic that moves the recovery resources from the system partition to the vendor partition, if it exists, or the vendor directory on the system partition otherwise. The recovery resources are moving from the system image to the vendor partition so that a single system image may be used with either an A/B or a non-A/B vendor image. The topic removes a delta in the system image that prevented such reuse in the past. The recovery resources that are moving are involved with updating the recovery partition after an update. In a non-A/B configuration, the system boots from the recovery partition, updates the other partitions (system, vendor, etc.) Then, the next time the system boots normally, a script updates the recovery partition (if necessary). This script, the executables it invokes, and the data files that it uses were previously on the system partition. The resources that are moving include the following. * install-recovery.sh * applypatch * recovery-resource.dat (if present) * recovery-from-boot.p (if present) This change includes the platform build system and release tools changes to move the recovery resources from system to vendor (or /system/vendor). The release tools need to know where to generate the recovery patch, and they discover this from misc_info.txt variable board_uses_vendorimage, which the platform build system generates. We remove applypatch from PRODUCT_PACKAGES, but it is added back as a required module in target/product/base_vendor.mk. Several release tools rely on the misc_info.txt board_uses_vendorimage variable to know how to generate and detect the recovery patch. This change partially removes the --rebuild_recovery flag from the merge_target_files.py script. The flag will be fully removed in a follow-on change. Bug: 68319577 Test: Ensure that recovery partition is updated correctly. Change-Id: Ia4045bd67ffb3d899efa8d20dab4c4299b87ee5f
2019-09-18 02:06:47 +02:00
input_tmp, 'recovery.img', recovery_img, recovery_sha1)
else:
assert len(lines) == 11, "Invalid line count: {}".format(lines)
# --source boot_type:boot_device:boot_size:boot_sha1
source = re.search(r'--source (\w+:.+:\w+:\w+) \\', lines[4].strip())
assert source is not None, \
"Failed to parse source line \"{}\"".format(lines[4])
source_partition = source.group(1)
source_info = source_partition.split(':')
assert len(source_info) == 4, \
"Invalid source partition: {}".format(source_partition)
ValidateFileAgainstSha1(input_tmp, file_name='boot.img',
releasetools: Make validate_target_files.py pylint clean. C: 73, 0: Wrong hanging indentation (add 4 spaces). file_name, actual_sha1, expected_sha1) ^ | (bad-continuation) C:171, 0: Wrong continued indentation (add 20 spaces). 'SYSTEM/etc/recovery.img', expected_recovery_sha1) ^ | (bad-continuation) C:185, 0: Wrong continued indentation (add 20 spaces). file_path='IMAGES/boot.img', expected_sha1=boot_info[3]) ^ | (bad-continuation) C:191, 0: Wrong continued indentation (add 20 spaces). file_path='IMAGES/recovery.img', ^ | (bad-continuation) C:192, 0: Wrong continued indentation (add 20 spaces). expected_sha1=expected_recovery_sha1) ^ | (bad-continuation) W: 67,15: Use % formatting in logging functions and pass the % parameters as arguments (logging-format-interpolation) W:150,17: Use % formatting in logging functions and pass the % parameters as arguments (logging-format-interpolation) W:153,15: Use % formatting in logging functions and pass the % parameters as arguments (logging-format-interpolation) W:194,15: Use % formatting in logging functions and pass the % parameters as arguments (logging-format-interpolation) C: 27, 0: standard import "import logging" comes before "import common" (wrong-import-order) C: 28, 0: standard import "import os.path" comes before "import common" (wrong-import-order) C: 29, 0: standard import "import re" comes before "import common" (wrong-import-order) C: 31, 0: standard import "import sys" comes before "import common" (wrong-import-order) Test: pylint --rcfile=pylintrc validate_target_files.py Test: Run validate_target_files.py with a target-files.zip. Change-Id: Ie64acdb4cee4326938c4ad5a34b575d7b82478c0
2018-02-01 21:00:19 +01:00
file_path='IMAGES/boot.img',
expected_sha1=source_info[3])
# --target recovery_type:recovery_device:recovery_size:recovery_sha1
target = re.search(r'--target (\w+:.+:\w+:\w+) && \\', lines[5].strip())
assert target is not None, \
"Failed to parse target line \"{}\"".format(lines[5])
target_partition = target.group(1)
# Check we have the same recovery target in the check and patch commands.
assert check_partition == target_partition, \
"Mismatching targets: {} vs {}".format(
check_partition, target_partition)
recovery_info = target_partition.split(':')
assert len(recovery_info) == 4, \
"Invalid target partition: {}".format(target_partition)
ValidateFileAgainstSha1(input_tmp, file_name='recovery.img',
releasetools: Make validate_target_files.py pylint clean. C: 73, 0: Wrong hanging indentation (add 4 spaces). file_name, actual_sha1, expected_sha1) ^ | (bad-continuation) C:171, 0: Wrong continued indentation (add 20 spaces). 'SYSTEM/etc/recovery.img', expected_recovery_sha1) ^ | (bad-continuation) C:185, 0: Wrong continued indentation (add 20 spaces). file_path='IMAGES/boot.img', expected_sha1=boot_info[3]) ^ | (bad-continuation) C:191, 0: Wrong continued indentation (add 20 spaces). file_path='IMAGES/recovery.img', ^ | (bad-continuation) C:192, 0: Wrong continued indentation (add 20 spaces). expected_sha1=expected_recovery_sha1) ^ | (bad-continuation) W: 67,15: Use % formatting in logging functions and pass the % parameters as arguments (logging-format-interpolation) W:150,17: Use % formatting in logging functions and pass the % parameters as arguments (logging-format-interpolation) W:153,15: Use % formatting in logging functions and pass the % parameters as arguments (logging-format-interpolation) W:194,15: Use % formatting in logging functions and pass the % parameters as arguments (logging-format-interpolation) C: 27, 0: standard import "import logging" comes before "import common" (wrong-import-order) C: 28, 0: standard import "import os.path" comes before "import common" (wrong-import-order) C: 29, 0: standard import "import re" comes before "import common" (wrong-import-order) C: 31, 0: standard import "import sys" comes before "import common" (wrong-import-order) Test: pylint --rcfile=pylintrc validate_target_files.py Test: Run validate_target_files.py with a target-files.zip. Change-Id: Ie64acdb4cee4326938c4ad5a34b575d7b82478c0
2018-02-01 21:00:19 +01:00
file_path='IMAGES/recovery.img',
expected_sha1=recovery_info[3])
releasetools: Make validate_target_files.py pylint clean. C: 73, 0: Wrong hanging indentation (add 4 spaces). file_name, actual_sha1, expected_sha1) ^ | (bad-continuation) C:171, 0: Wrong continued indentation (add 20 spaces). 'SYSTEM/etc/recovery.img', expected_recovery_sha1) ^ | (bad-continuation) C:185, 0: Wrong continued indentation (add 20 spaces). file_path='IMAGES/boot.img', expected_sha1=boot_info[3]) ^ | (bad-continuation) C:191, 0: Wrong continued indentation (add 20 spaces). file_path='IMAGES/recovery.img', ^ | (bad-continuation) C:192, 0: Wrong continued indentation (add 20 spaces). expected_sha1=expected_recovery_sha1) ^ | (bad-continuation) W: 67,15: Use % formatting in logging functions and pass the % parameters as arguments (logging-format-interpolation) W:150,17: Use % formatting in logging functions and pass the % parameters as arguments (logging-format-interpolation) W:153,15: Use % formatting in logging functions and pass the % parameters as arguments (logging-format-interpolation) W:194,15: Use % formatting in logging functions and pass the % parameters as arguments (logging-format-interpolation) C: 27, 0: standard import "import logging" comes before "import common" (wrong-import-order) C: 28, 0: standard import "import os.path" comes before "import common" (wrong-import-order) C: 29, 0: standard import "import re" comes before "import common" (wrong-import-order) C: 31, 0: standard import "import sys" comes before "import common" (wrong-import-order) Test: pylint --rcfile=pylintrc validate_target_files.py Test: Run validate_target_files.py with a target-files.zip. Change-Id: Ie64acdb4cee4326938c4ad5a34b575d7b82478c0
2018-02-01 21:00:19 +01:00
logging.info('Done checking %s', script_path)
# Symlink files in `src` to `dst`, if the files do not
# already exists in `dst` directory.
def symlinkIfNotExists(src, dst):
if not os.path.isdir(src):
return
for filename in os.listdir(src):
if os.path.exists(os.path.join(dst, filename)):
continue
os.symlink(os.path.join(src, filename), os.path.join(dst, filename))
def ValidateVerifiedBootImages(input_tmp, info_dict, options):
"""Validates the Verified Boot related images.
For Verified Boot 1.0, it verifies the signatures of the bootable images
(boot/recovery etc), as well as the dm-verity metadata in system images
(system/vendor/product). For Verified Boot 2.0, it calls avbtool to verify
vbmeta.img, which in turn verifies all the descriptors listed in vbmeta.
Args:
input_tmp: The top-level directory of unpacked target-files.zip.
info_dict: The loaded info dict.
options: A dict that contains the user-supplied public keys to be used for
image verification. In particular, 'verity_key' is used to verify the
bootable images in VB 1.0, and the vbmeta image in VB 2.0, where
applicable. 'verity_key_mincrypt' will be used to verify the system
images in VB 1.0.
Raises:
AssertionError: On any verification failure.
"""
# See bug 159299583
# After commit 5277d1015, some images (e.g. acpio.img and tos.img) are no
# longer copied from RADIO to the IMAGES folder. But avbtool assumes that
# images are in IMAGES folder. So we symlink them.
symlinkIfNotExists(os.path.join(input_tmp, "RADIO"),
os.path.join(input_tmp, "IMAGES"))
# Verified boot 1.0 (images signed with boot_signer and verity_signer).
if info_dict.get('boot_signer') == 'true':
logging.info('Verifying Verified Boot images...')
# Verify the boot/recovery images (signed with boot_signer), against the
# given X.509 encoded pubkey (or falling back to the one in the info_dict if
# none given).
verity_key = options['verity_key']
if verity_key is None:
verity_key = info_dict['verity_key'] + '.x509.pem'
for image in ('boot.img', 'recovery.img', 'recovery-two-step.img'):
if image == 'recovery-two-step.img':
image_path = os.path.join(input_tmp, 'OTA', image)
else:
image_path = os.path.join(input_tmp, 'IMAGES', image)
if not os.path.exists(image_path):
continue
cmd = ['boot_signer', '-verify', image_path, '-certificate', verity_key]
proc = common.Run(cmd)
stdoutdata, _ = proc.communicate()
assert proc.returncode == 0, \
'Failed to verify {} with boot_signer:\n{}'.format(image, stdoutdata)
logging.info(
'Verified %s with boot_signer (key: %s):\n%s', image, verity_key,
stdoutdata.rstrip())
# Verify verity signed system images in Verified Boot 1.0. Note that not using
# 'elif' here, since 'boot_signer' and 'verity' are not bundled in VB 1.0.
if info_dict.get('verity') == 'true':
Also install verity_key to ramdisk for non-system-as-root target. The commit in d14b895665f9fb122f93edb16655fd3a49510032 (https://android-review.googlesource.com/c/platform/build/+/728287) changed partition layout, to always build the root dir into system.img, even for devices not using system-as-root (i.e. the ones with separate boot ramdisk). With the new layout, there will be two root dirs for non-system-as-root targets during the boot. If such a device uses Verified Boot 1.0, /verity_key needs to be available in both roots, to establish the chain of trust. - bootloader uses the baked-in key to verify boot.img; it then loads the ramdisk from the verified boot.img - First stage init uses /verity_key (in ramdisk) to verify and mount system.img at /system, then chroot's to it - Second stage init uses /verity_key (in system.img) to verify and mount other partitions This CL adds rules to additionally install verity_key into ramdisk for such targets. Bug: 139770257 Test: Set up a target to use non-system-as-root (BOARD_BUILD_SYSTEM_ROOT_IMAGE != true). `m dist`. Test: Check that both ROOT/verity_key and BOOT/RAMDISK/verity_key exist in the built target_files.zip. Test: Run validate_target_files to validate the above target_files.zip. $ validate_target_files \ --verity_key_mincrypt /path/to/verity_key \ target_files.zip Test: Run sign_target_files_apks to sign the above target. Re-run validate_target_files on the signed target_files.zip. Test: python -m unittest test_validate_target_files Change-Id: Ibe7e771c8c376429add85851ac86055564765d3c
2019-09-16 21:10:43 +02:00
# First verify that the verity key is built into the root image (regardless
# of system-as-root).
verity_key_mincrypt = os.path.join(input_tmp, 'ROOT', 'verity_key')
assert os.path.exists(verity_key_mincrypt), 'Missing verity_key'
Also install verity_key to ramdisk for non-system-as-root target. The commit in d14b895665f9fb122f93edb16655fd3a49510032 (https://android-review.googlesource.com/c/platform/build/+/728287) changed partition layout, to always build the root dir into system.img, even for devices not using system-as-root (i.e. the ones with separate boot ramdisk). With the new layout, there will be two root dirs for non-system-as-root targets during the boot. If such a device uses Verified Boot 1.0, /verity_key needs to be available in both roots, to establish the chain of trust. - bootloader uses the baked-in key to verify boot.img; it then loads the ramdisk from the verified boot.img - First stage init uses /verity_key (in ramdisk) to verify and mount system.img at /system, then chroot's to it - Second stage init uses /verity_key (in system.img) to verify and mount other partitions This CL adds rules to additionally install verity_key into ramdisk for such targets. Bug: 139770257 Test: Set up a target to use non-system-as-root (BOARD_BUILD_SYSTEM_ROOT_IMAGE != true). `m dist`. Test: Check that both ROOT/verity_key and BOOT/RAMDISK/verity_key exist in the built target_files.zip. Test: Run validate_target_files to validate the above target_files.zip. $ validate_target_files \ --verity_key_mincrypt /path/to/verity_key \ target_files.zip Test: Run sign_target_files_apks to sign the above target. Re-run validate_target_files on the signed target_files.zip. Test: python -m unittest test_validate_target_files Change-Id: Ibe7e771c8c376429add85851ac86055564765d3c
2019-09-16 21:10:43 +02:00
# Verify /verity_key matches the one given via command line, if any.
if options['verity_key_mincrypt'] is None:
logging.warn(
'Skipped checking the content of /verity_key, as the key file not '
'provided. Use --verity_key_mincrypt to specify.')
else:
expected_key = options['verity_key_mincrypt']
assert filecmp.cmp(expected_key, verity_key_mincrypt, shallow=False), \
"Mismatching mincrypt verity key files"
logging.info('Verified the content of /verity_key')
Also install verity_key to ramdisk for non-system-as-root target. The commit in d14b895665f9fb122f93edb16655fd3a49510032 (https://android-review.googlesource.com/c/platform/build/+/728287) changed partition layout, to always build the root dir into system.img, even for devices not using system-as-root (i.e. the ones with separate boot ramdisk). With the new layout, there will be two root dirs for non-system-as-root targets during the boot. If such a device uses Verified Boot 1.0, /verity_key needs to be available in both roots, to establish the chain of trust. - bootloader uses the baked-in key to verify boot.img; it then loads the ramdisk from the verified boot.img - First stage init uses /verity_key (in ramdisk) to verify and mount system.img at /system, then chroot's to it - Second stage init uses /verity_key (in system.img) to verify and mount other partitions This CL adds rules to additionally install verity_key into ramdisk for such targets. Bug: 139770257 Test: Set up a target to use non-system-as-root (BOARD_BUILD_SYSTEM_ROOT_IMAGE != true). `m dist`. Test: Check that both ROOT/verity_key and BOOT/RAMDISK/verity_key exist in the built target_files.zip. Test: Run validate_target_files to validate the above target_files.zip. $ validate_target_files \ --verity_key_mincrypt /path/to/verity_key \ target_files.zip Test: Run sign_target_files_apks to sign the above target. Re-run validate_target_files on the signed target_files.zip. Test: python -m unittest test_validate_target_files Change-Id: Ibe7e771c8c376429add85851ac86055564765d3c
2019-09-16 21:10:43 +02:00
# For devices with a separate ramdisk (i.e. non-system-as-root), there must
# be a copy in ramdisk.
if info_dict.get("system_root_image") != "true":
verity_key_ramdisk = os.path.join(
input_tmp, 'BOOT', 'RAMDISK', 'verity_key')
assert os.path.exists(verity_key_ramdisk), 'Missing verity_key in ramdisk'
assert filecmp.cmp(
verity_key_mincrypt, verity_key_ramdisk, shallow=False), \
'Mismatching verity_key files in root and ramdisk'
logging.info('Verified the content of /verity_key in ramdisk')
# Then verify the verity signed system/vendor/product images, against the
# verity pubkey in mincrypt format.
for image in ('system.img', 'vendor.img', 'product.img'):
image_path = os.path.join(input_tmp, 'IMAGES', image)
# We are not checking if the image is actually enabled via info_dict (e.g.
# 'system_verity_block_device=...'). Because it's most likely a bug that
# skips signing some of the images in signed target-files.zip, while
# having the top-level verity flag enabled.
if not os.path.exists(image_path):
continue
cmd = ['verity_verifier', image_path, '-mincrypt', verity_key_mincrypt]
proc = common.Run(cmd)
stdoutdata, _ = proc.communicate()
assert proc.returncode == 0, \
'Failed to verify {} with verity_verifier (key: {}):\n{}'.format(
image, verity_key_mincrypt, stdoutdata)
logging.info(
'Verified %s with verity_verifier (key: %s):\n%s', image,
verity_key_mincrypt, stdoutdata.rstrip())
# Handle the case of Verified Boot 2.0 (AVB).
if info_dict.get("avb_enable") == "true":
logging.info('Verifying Verified Boot 2.0 (AVB) images...')
key = options['verity_key']
if key is None:
key = info_dict['avb_vbmeta_key_path']
# avbtool verifies all the images that have descriptors listed in vbmeta.
AVB: decouple vbmeta.img from recovery.img for non-A/B devices For following cases: Case 1: A/B devices: no change Case 2: non-A/B devices, with unsigned recovery image: not allowed anymore by mandating BOARD_AVB_RECOVERY_KEY_PATH Case 3: non-A/B devices, with signed recovery image: vbmeta.img should not include ChainPartitionDescriptor of recovery.img, otherwise device can not even boot into normal mode if recovery partition is damaged This CL will cause a build break if BOARD_AVB_RECOVERY_KEY_PATH is not set for non-A/B targets with recovery.img The following is an example to fix the build break by specifying AVB signing configs for the recovery.img. BOARD_AVB_RECOVERY_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem BOARD_AVB_RECOVERY_ALGORITHM := SHA256_RSA2048 BOARD_AVB_RECOVERY_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP) BOARD_AVB_RECOVERY_ROLLBACK_INDEX_LOCATION := 2 Also note that libavb in bootloader needs an update to include this commit Iaa886037edb18c2ff6c60fa2a7f883ab7303ba1a, to support verifying recovery.img independently (not through vbmeta.img). Bug: 130351427 Test (Case 3): normal mode: avb_slot_verify(flags=AVB_SLOT_VERIFY_FLAGS_NONE) recovery mode: avb_slot_verify(flags=AVB_SLOT_VERIFY_FLAGS_NO_VBMETA_PARTITION) Test: PYTHONPATH=build/make/tools/releasetools \ python -m unittest test_validate_target_files Test: Use a lunch'd target. `atest --host releasetools_test releasetools_py3_test` Test: validate_target_files.py with Case-3 target files Change-Id: I2a73252b385fa463b4abd444923a8acc473df0b4
2019-09-20 16:45:06 +02:00
# Using `--follow_chain_partitions` so it would additionally verify chained
# vbmeta partitions (e.g. vbmeta_system).
image = os.path.join(input_tmp, 'IMAGES', 'vbmeta.img')
cmd = [info_dict['avb_avbtool'], 'verify_image', '--image', image,
'--follow_chain_partitions']
Add options to sign the prebuilt custom images. The custom images are any images owned by OEMs and SoCs, oem images mounted on /oem is an example. The oem images can be used to customize devices for different carriers, like wallpaper, ringtones, and carrier-specific apks. OEMs can generate multiple oem images, like oem.img, oem-carrier1.img and oem-carrier2.img and flash different oem images for different carriers. The oem images are only one case, OEMs and SoCs can add more custom images and mount them to custom partitions. This change enables custom images to be vbmeta.img chained partitions. The following configuration in BoardConfig.mk is an exmaple. It has two custom partitions: oem and test. They will be signed by different keys. And they will be chained by vbmeta.img. The custom images here are prebuilts, which can be built by `make custom_images` separately. BOARD_AVB_<CUSTOM_PARTITION>_IMAGE_LIST should include all custom images to apply AVB signing. And to every custom partition, one image whose name is partition name must be added in its BOARD_AVB_<CUSTOM_PARTITION>_IMAGE_LIST. BOARD_CUSTOMIMAGES_PARTITION_LIST := oem test BOARD_AVB_OEM_KEY_PATH := external/avb/test/data/testkey_rsa4096.pem BOARD_AVB_OEM_ALGORITHM := SHA256_RSA4096 BOARD_AVB_OEM_ADD_HASHTREE_FOOTER_ARGS := BOARD_AVB_OEM_ROLLBACK_INDEX_LOCATION := 1 BOARD_AVB_OEM_PARTITION_SIZE := 5242880 BOARD_AVB_OEM_IMAGE_LIST := \ device/xxxx/yyyy/oem/oem.img \ device/xxxx/yyyy/oem/oem1.img BOARD_AVB_TEST_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem BOARD_AVB_TEST_ALGORITHM := SHA256_RSA2048 BOARD_AVB_TEST_ADD_HASHTREE_FOOTER_ARGS := BOARD_AVB_TEST_ROLLBACK_INDEX_LOCATION := 2 BOARD_AVB_TEST_PARTITION_SIZE := 10485760 BOARD_AVB_TEST_IMAGE_LIST := \ device/xxxx/yyyy/test/test.img \ device/xxxx/yyyy/test/test1.img To resign the custom images in the target zip file, the avb_extra_custom_image_key, avb_extra_custom_image_algorithms and avb_extra_custom_image_extra_args options are added to the sign_target_files_apks tool too. The following test cases list some examples about how to use them. BUG: 154171021 Test: 1) "atest --host releasetools_test releasetools_py3_test -c" 2) Build images by 'make dist', sign and validate target files. a) Test on dist w/ chained vbmeta_system and ome custom images sign_target_files_apks -d certs \ --avb_extra_custom_image_key oem=oem_rsa4096.pem \ --avb_extra_custom_image_algorithm oem=SHA256_RSA4096 \ xxx-target_xxx.zip signed.zip validate_target_files.py signed.zip Flash image and boot up. Verify the oem images and vbmeta images in OUT and target zips by avbtool. b) Test on dist w/ chained vbmeta_system and oem and test custom images sign_target_files_apks -d certs \ --avb_extra_custom_image_key oem=oem_rsa4096.pem \ --avb_extra_custom_image_algorithm oem=SHA256_RSA4096 \ --avb_extra_custom_image_extra_args oem=--do_not_generate_fec \ --avb_extra_custom_image_key test=test_rsa4096.pem \ --avb_extra_custom_image_algorithm test=SHA256_RSA4096 \ xxx-target_xxx.zip signed.zip validate_target_files.py signed.zip Verify the oem, test images and vbmeta images in OUT and target zips by avbtool. c) Test on dist w/o chained partition. sign_target_files_apks -d certs xxx-target_xxx.zip signed.zip validate_target_files.py signed.zip Flash image and boot up. Verify the vbmeta images in OUT and target zips by avbtool. Change-Id: Ifccfee5e8909697eef6ccda0cc352fa16a9f6db6
2020-04-28 03:36:36 +02:00
# Custom images.
custom_partitions = info_dict.get(
"avb_custom_images_partition_list", "").strip().split()
# Append the args for chained partitions if any.
Add options to sign the prebuilt custom images. The custom images are any images owned by OEMs and SoCs, oem images mounted on /oem is an example. The oem images can be used to customize devices for different carriers, like wallpaper, ringtones, and carrier-specific apks. OEMs can generate multiple oem images, like oem.img, oem-carrier1.img and oem-carrier2.img and flash different oem images for different carriers. The oem images are only one case, OEMs and SoCs can add more custom images and mount them to custom partitions. This change enables custom images to be vbmeta.img chained partitions. The following configuration in BoardConfig.mk is an exmaple. It has two custom partitions: oem and test. They will be signed by different keys. And they will be chained by vbmeta.img. The custom images here are prebuilts, which can be built by `make custom_images` separately. BOARD_AVB_<CUSTOM_PARTITION>_IMAGE_LIST should include all custom images to apply AVB signing. And to every custom partition, one image whose name is partition name must be added in its BOARD_AVB_<CUSTOM_PARTITION>_IMAGE_LIST. BOARD_CUSTOMIMAGES_PARTITION_LIST := oem test BOARD_AVB_OEM_KEY_PATH := external/avb/test/data/testkey_rsa4096.pem BOARD_AVB_OEM_ALGORITHM := SHA256_RSA4096 BOARD_AVB_OEM_ADD_HASHTREE_FOOTER_ARGS := BOARD_AVB_OEM_ROLLBACK_INDEX_LOCATION := 1 BOARD_AVB_OEM_PARTITION_SIZE := 5242880 BOARD_AVB_OEM_IMAGE_LIST := \ device/xxxx/yyyy/oem/oem.img \ device/xxxx/yyyy/oem/oem1.img BOARD_AVB_TEST_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem BOARD_AVB_TEST_ALGORITHM := SHA256_RSA2048 BOARD_AVB_TEST_ADD_HASHTREE_FOOTER_ARGS := BOARD_AVB_TEST_ROLLBACK_INDEX_LOCATION := 2 BOARD_AVB_TEST_PARTITION_SIZE := 10485760 BOARD_AVB_TEST_IMAGE_LIST := \ device/xxxx/yyyy/test/test.img \ device/xxxx/yyyy/test/test1.img To resign the custom images in the target zip file, the avb_extra_custom_image_key, avb_extra_custom_image_algorithms and avb_extra_custom_image_extra_args options are added to the sign_target_files_apks tool too. The following test cases list some examples about how to use them. BUG: 154171021 Test: 1) "atest --host releasetools_test releasetools_py3_test -c" 2) Build images by 'make dist', sign and validate target files. a) Test on dist w/ chained vbmeta_system and ome custom images sign_target_files_apks -d certs \ --avb_extra_custom_image_key oem=oem_rsa4096.pem \ --avb_extra_custom_image_algorithm oem=SHA256_RSA4096 \ xxx-target_xxx.zip signed.zip validate_target_files.py signed.zip Flash image and boot up. Verify the oem images and vbmeta images in OUT and target zips by avbtool. b) Test on dist w/ chained vbmeta_system and oem and test custom images sign_target_files_apks -d certs \ --avb_extra_custom_image_key oem=oem_rsa4096.pem \ --avb_extra_custom_image_algorithm oem=SHA256_RSA4096 \ --avb_extra_custom_image_extra_args oem=--do_not_generate_fec \ --avb_extra_custom_image_key test=test_rsa4096.pem \ --avb_extra_custom_image_algorithm test=SHA256_RSA4096 \ xxx-target_xxx.zip signed.zip validate_target_files.py signed.zip Verify the oem, test images and vbmeta images in OUT and target zips by avbtool. c) Test on dist w/o chained partition. sign_target_files_apks -d certs xxx-target_xxx.zip signed.zip validate_target_files.py signed.zip Flash image and boot up. Verify the vbmeta images in OUT and target zips by avbtool. Change-Id: Ifccfee5e8909697eef6ccda0cc352fa16a9f6db6
2020-04-28 03:36:36 +02:00
for partition in (common.AVB_PARTITIONS + common.AVB_VBMETA_PARTITIONS +
tuple(custom_partitions)):
key_name = 'avb_' + partition + '_key_path'
if info_dict.get(key_name) is not None:
AVB: decouple vbmeta.img from recovery.img for non-A/B devices For following cases: Case 1: A/B devices: no change Case 2: non-A/B devices, with unsigned recovery image: not allowed anymore by mandating BOARD_AVB_RECOVERY_KEY_PATH Case 3: non-A/B devices, with signed recovery image: vbmeta.img should not include ChainPartitionDescriptor of recovery.img, otherwise device can not even boot into normal mode if recovery partition is damaged This CL will cause a build break if BOARD_AVB_RECOVERY_KEY_PATH is not set for non-A/B targets with recovery.img The following is an example to fix the build break by specifying AVB signing configs for the recovery.img. BOARD_AVB_RECOVERY_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem BOARD_AVB_RECOVERY_ALGORITHM := SHA256_RSA2048 BOARD_AVB_RECOVERY_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP) BOARD_AVB_RECOVERY_ROLLBACK_INDEX_LOCATION := 2 Also note that libavb in bootloader needs an update to include this commit Iaa886037edb18c2ff6c60fa2a7f883ab7303ba1a, to support verifying recovery.img independently (not through vbmeta.img). Bug: 130351427 Test (Case 3): normal mode: avb_slot_verify(flags=AVB_SLOT_VERIFY_FLAGS_NONE) recovery mode: avb_slot_verify(flags=AVB_SLOT_VERIFY_FLAGS_NO_VBMETA_PARTITION) Test: PYTHONPATH=build/make/tools/releasetools \ python -m unittest test_validate_target_files Test: Use a lunch'd target. `atest --host releasetools_test releasetools_py3_test` Test: validate_target_files.py with Case-3 target files Change-Id: I2a73252b385fa463b4abd444923a8acc473df0b4
2019-09-20 16:45:06 +02:00
if info_dict.get('ab_update') != 'true' and partition == 'recovery':
continue
# Use the key file from command line if specified; otherwise fall back
# to the one in info dict.
key_file = options.get(key_name, info_dict[key_name])
chained_partition_arg = common.GetAvbChainedPartitionArg(
partition, info_dict, key_file)
AVB: decouple vbmeta.img from recovery.img for non-A/B devices For following cases: Case 1: A/B devices: no change Case 2: non-A/B devices, with unsigned recovery image: not allowed anymore by mandating BOARD_AVB_RECOVERY_KEY_PATH Case 3: non-A/B devices, with signed recovery image: vbmeta.img should not include ChainPartitionDescriptor of recovery.img, otherwise device can not even boot into normal mode if recovery partition is damaged This CL will cause a build break if BOARD_AVB_RECOVERY_KEY_PATH is not set for non-A/B targets with recovery.img The following is an example to fix the build break by specifying AVB signing configs for the recovery.img. BOARD_AVB_RECOVERY_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem BOARD_AVB_RECOVERY_ALGORITHM := SHA256_RSA2048 BOARD_AVB_RECOVERY_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP) BOARD_AVB_RECOVERY_ROLLBACK_INDEX_LOCATION := 2 Also note that libavb in bootloader needs an update to include this commit Iaa886037edb18c2ff6c60fa2a7f883ab7303ba1a, to support verifying recovery.img independently (not through vbmeta.img). Bug: 130351427 Test (Case 3): normal mode: avb_slot_verify(flags=AVB_SLOT_VERIFY_FLAGS_NONE) recovery mode: avb_slot_verify(flags=AVB_SLOT_VERIFY_FLAGS_NO_VBMETA_PARTITION) Test: PYTHONPATH=build/make/tools/releasetools \ python -m unittest test_validate_target_files Test: Use a lunch'd target. `atest --host releasetools_test releasetools_py3_test` Test: validate_target_files.py with Case-3 target files Change-Id: I2a73252b385fa463b4abd444923a8acc473df0b4
2019-09-20 16:45:06 +02:00
cmd.extend(['--expected_chain_partition', chained_partition_arg])
# Handle the boot image with a non-default name, e.g. boot-5.4.img
boot_images = info_dict.get("boot_images")
if boot_images:
# we used the 1st boot image to generate the vbmeta. Rename the filename
# to boot.img so that avbtool can find it correctly.
first_image_name = boot_images.split()[0]
first_image_path = os.path.join(input_tmp, 'IMAGES', first_image_name)
assert os.path.isfile(first_image_path)
renamed_boot_image_path = os.path.join(input_tmp, 'IMAGES', 'boot.img')
os.rename(first_image_path, renamed_boot_image_path)
proc = common.Run(cmd)
stdoutdata, _ = proc.communicate()
assert proc.returncode == 0, \
'Failed to verify {} with avbtool (key: {}):\n{}'.format(
image, key, stdoutdata)
logging.info(
'Verified %s with avbtool (key: %s):\n%s', image, key,
stdoutdata.rstrip())
AVB: decouple vbmeta.img from recovery.img for non-A/B devices For following cases: Case 1: A/B devices: no change Case 2: non-A/B devices, with unsigned recovery image: not allowed anymore by mandating BOARD_AVB_RECOVERY_KEY_PATH Case 3: non-A/B devices, with signed recovery image: vbmeta.img should not include ChainPartitionDescriptor of recovery.img, otherwise device can not even boot into normal mode if recovery partition is damaged This CL will cause a build break if BOARD_AVB_RECOVERY_KEY_PATH is not set for non-A/B targets with recovery.img The following is an example to fix the build break by specifying AVB signing configs for the recovery.img. BOARD_AVB_RECOVERY_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem BOARD_AVB_RECOVERY_ALGORITHM := SHA256_RSA2048 BOARD_AVB_RECOVERY_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP) BOARD_AVB_RECOVERY_ROLLBACK_INDEX_LOCATION := 2 Also note that libavb in bootloader needs an update to include this commit Iaa886037edb18c2ff6c60fa2a7f883ab7303ba1a, to support verifying recovery.img independently (not through vbmeta.img). Bug: 130351427 Test (Case 3): normal mode: avb_slot_verify(flags=AVB_SLOT_VERIFY_FLAGS_NONE) recovery mode: avb_slot_verify(flags=AVB_SLOT_VERIFY_FLAGS_NO_VBMETA_PARTITION) Test: PYTHONPATH=build/make/tools/releasetools \ python -m unittest test_validate_target_files Test: Use a lunch'd target. `atest --host releasetools_test releasetools_py3_test` Test: validate_target_files.py with Case-3 target files Change-Id: I2a73252b385fa463b4abd444923a8acc473df0b4
2019-09-20 16:45:06 +02:00
# avbtool verifies recovery image for non-A/B devices.
if (info_dict.get('ab_update') != 'true' and
info_dict.get('no_recovery') != 'true'):
image = os.path.join(input_tmp, 'IMAGES', 'recovery.img')
key = info_dict['avb_recovery_key_path']
cmd = [info_dict['avb_avbtool'], 'verify_image', '--image', image,
'--key', key]
proc = common.Run(cmd)
stdoutdata, _ = proc.communicate()
assert proc.returncode == 0, \
'Failed to verify {} with avbtool (key: {}):\n{}'.format(
image, key, stdoutdata)
logging.info(
'Verified %s with avbtool (key: %s):\n%s', image, key,
stdoutdata.rstrip())
def CheckDataDuplicity(lines):
build_prop = {}
for line in lines:
if line.startswith("import") or line.startswith("#"):
continue
key, value = line.split("=", 1)
if key in build_prop:
return key
build_prop[key] = value
def CheckBuildPropDuplicity(input_tmp):
"""Check all buld.prop files inside directory input_tmp, raise error
if they contain duplicates"""
if not os.path.isdir(input_tmp):
raise ValueError("Expect {} to be a directory".format(input_tmp))
for name in os.listdir(input_tmp):
if not name.isupper():
continue
for prop_file in ['build.prop', 'etc/build.prop']:
path = os.path.join(input_tmp, name, prop_file)
if not os.path.exists(path):
continue
logging.info("Checking {}".format(path))
with open(path, 'r') as fp:
dupKey = CheckDataDuplicity(fp.readlines())
if dupKey:
raise ValueError("{} contains duplicate keys for {}", path, dupKey)
def main():
parser = argparse.ArgumentParser(
description=__doc__,
formatter_class=argparse.RawDescriptionHelpFormatter)
parser.add_argument(
'target_files',
help='the input target_files.zip to be validated')
parser.add_argument(
'--verity_key',
help='the verity public key to verify the bootable images (Verified '
'Boot 1.0), or the vbmeta image (Verified Boot 2.0, aka AVB), where '
'applicable')
for partition in common.AVB_PARTITIONS + common.AVB_VBMETA_PARTITIONS:
parser.add_argument(
'--avb_' + partition + '_key_path',
help='the public or private key in PEM format to verify AVB chained '
'partition of {}'.format(partition))
parser.add_argument(
'--verity_key_mincrypt',
help='the verity public key in mincrypt format to verify the system '
'images, if target using Verified Boot 1.0')
args = parser.parse_args()
# Unprovided args will have 'None' as the value.
options = vars(args)
logging_format = '%(asctime)s - %(filename)s - %(levelname)-8s: %(message)s'
date_format = '%Y/%m/%d %H:%M:%S'
logging.basicConfig(level=logging.INFO, format=logging_format,
datefmt=date_format)
logging.info("Unzipping the input target_files.zip: %s", args.target_files)
input_tmp = common.UnzipTemp(args.target_files)
info_dict = common.LoadInfoDict(input_tmp)
with zipfile.ZipFile(args.target_files, 'r', allowZip64=True) as input_zip:
ValidateFileConsistency(input_zip, input_tmp, info_dict)
CheckBuildPropDuplicity(input_tmp)
ValidateInstallRecoveryScript(input_tmp, info_dict)
ValidateVerifiedBootImages(input_tmp, info_dict, options)
# TODO: Check if the OTA keys have been properly updated (the ones on /system,
# in recovery image).
logging.info("Done.")
if __name__ == '__main__':
try:
main()
finally:
common.Cleanup()