Currently system_other AVB public key is placed in system.img.
However, this makes it's harder to have a *generic* system.img
across different product configs. Moving the key to /product
partition to allow more product-specific AVB keys.
Device board config can add /product/etc/fstab.postinstall,
to mount system_other with this key in /product. It can specify
different mount options, file systems, verity settings, etc., in
this product-specific fstab as well.
Bug: 123611926
Test: `make productimage` checks the following is generated.
$OUT/product/etc/security/avb/system_other.avbpubkey
Also checks it's included in $OUT/installed-files-product.{json, txt}
Test: run the following command and checks that
PRODUCT/etc/security/avb/system_other.avbpubkey is updated:
./build/tools/releasetools/sign_target_files_apks \
--avb_system_other_algorithm SHA256_RSA2048 \
--avb_system_other_key external/avb/test/data/testkey_rsa2048.pem \
out/dist/*-target_files-*.zip signed-target_files.zip
Change-Id: I6804f29941bec54375d80bd68a5aedb5c23b842e
This commit updates how `check_elf_file.py` parses the symbol name
because the `llvm-readobj` (from clang-r353983) does not print "@" if
the symbol is not versioned.
See also. https://reviews.llvm.org/D56319
Bug: 128959554
Test: CHECK_ELF_FILES=true make check-elf-files
Change-Id: I0dee5e505225e57750a2c86cf0d25a151c218eb1
This CL adds support that allows treating an APEX as pre-signed. We can
skip signing an APEX with `-e <apex-name>=` and
`--extra_apex_payload_key <apex-name>=`. Note that the payload_key and
container_key must be in consistent state - either they're both
PRESIGNED or none of them is. CheckApkAndApexKeysAvailable() has been
updated to perform the sanity check.
Bug: 123716522
Test: Run sign_target_files_apks.py with the above flags.
Test: python -m unittest test_sign_target_files_apks
Change-Id: Id1e2f3f2facd4a97a385983cc9b78c028f7e7e73
This validation is to help ensure that any usage of custom merge config
files does not accidentally exclude any item that has been added to the
default config lists.
Bug: 124197349
Test: Run merge_target_files with custom merge config files.
Change-Id: I34c51cb75212368146a2944d37621f311060d24d
This reverts commit d8469727bc. The script
is broken on target_files.zip that don't contain any APEX.
Bug: 128848294
Test: Run check_target_files_signatures.py on target_files.zip w/o APEX.
OTA tools should pick up the avbtool, as listed in dict['avb_avbtool'],
from the current PATH (plus bin/ under the dir specified via `--path`),
the same way as handling all other host tools.
Test: `m dist`
Change-Id: I3eb4d2c61979b03d9c23b2403d9a38cf052d87ea
Also makes AddSystem check that an output_zip exists before attempting
to add the recovery patch to the output zip.
Bug: 128838154
Test: Running merge_target_files with --rebuild_recovery and verifying
it passes --rebuild_recovery to add_img_to_target_files.
Change-Id: I19347b2c0dabf29b7196045b18551b5d0687df2c
The keys_info in the touched code is a tuple, which is immutable.
Bug: 123716522
Test: Run sign_target_files_apks.py with '-e foo.apex=bar' that replaces
the APEX container key.
Change-Id: I4e57e46c93a56b7f6646764d021ebb42c19bf7f5
A few tweaks to make it easier to extend to generating RROs in
multiple partitions:
- deduce the module name inside generate_enforce_rro
- dedup rule definition
- tweak framework-res check to use source module name instead
Bug: 127758779
Test: verify noop on presubmit targets
Change-Id: I2f0d6270b21f5427c372c04a5c6e7fb712e72a9a
Bug: 123716522
Test: Run sign_target_files_apks.py to sign a target_files with APEXes.
Test: Run check_target_files_signatures.py on signed artifact.
Test: python -m unittest test_sign_target_files_apks
Change-Id: I3fa13e3d9461cf5e0838e0572d436e218164fe41
(cherry picked from commit aa7e993a22)
Only the container certs will be checked and reported. For the payload
within an APEX, we can't easily extract the cert info.
It needs to go along a longer path, if ever needed, by:
- extracting public keys from all the available certs;
- using each of them to verify against an APEX payload to find a match
(`avbtool verify_image --image payload --key public_key`).
Bug: 123716522
Test: Run check_target_files_signatures.py on target_files with APEXes.
Change-Id: I2ef318e05433d2d65ab84e2dff9e01fb6ee3373d
(cherry picked from commit d8469727bc)
Bug: 123716522
Test: Run sign_target_files_apks.py to sign a target_files with APEXes.
Test: Run check_target_files_signatures.py on signed artifact.
Test: python -m unittest test_sign_target_files_apks
Change-Id: I3fa13e3d9461cf5e0838e0572d436e218164fe41
Only the container certs will be checked and reported. For the payload
within an APEX, we can't easily extract the cert info.
It needs to go along a longer path, if ever needed, by:
- extracting public keys from all the available certs;
- using each of them to verify against an APEX payload to find a match
(`avbtool verify_image --image payload --key public_key`).
Bug: 123716522
Test: Run check_target_files_signatures.py on target_files with APEXes.
Change-Id: I2ef318e05433d2d65ab84e2dff9e01fb6ee3373d
Other modules have switched to logging module. sign_target_files_apks.py
needs to init the logger to get the logs.
Test: Run `sign_target_files_apks.py -v`. Check outputs.
Test: Run `check_target_files_signatures.py -v`.
Change-Id: Ic68c019f6fb14840561885f1194ad6efdfdb7d82
superimage-nodeps and supernod depends
on images from $(ANDROID_PRODUCT_OUT) (not from
target files package). It doesn't rebuild source
images if they are present.
A typical workflow is:
m -j
# change code in system
m snod -j
m supernod -j
Test: For non retrofit, run:
`m snod -j; m supernod -j`
Fixes: 128321505
Change-Id: Ib8c011cadb9c0cd334234aef39f19be6a48fee62
A followup change will make it not always equal TARGET_DEVICE,
so that name is unsuitable. Make its name follow the other product
variables.
Bug: 110206836
Test: presubmit
Change-Id: Icb1422ec5e7af658c5cc3070993c472e99805c6b
