tequilaOS/platform_build
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
platform_build/target/product/security/Android.mk

83 lines
2.7 KiB
Makefile
Raw Normal View History

Add support for verity builds to the build system. Change-Id: I3ef908d8d52ec88de453b161bbc3f198517a72f1
2013-06-17 02:26:08 +02:00
LOCAL_PATH:= $(call my-dir)
#######################################
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
# verity_key (installed to /, i.e. part of system.img)
Add support for verity builds to the build system. Change-Id: I3ef908d8d52ec88de453b161bbc3f198517a72f1
2013-06-17 02:26:08 +02:00
include $(CLEAR_VARS)
LOCAL_MODULE := verity_key
LOCAL_SRC_FILES := $(LOCAL_MODULE)
LOCAL_MODULE_CLASS := ETC
LOCAL_MODULE_PATH := $(TARGET_ROOT_OUT)
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 using a separate ramdisk, we need a copy there to establish the chain of trust.
ifneq ($(BOARD_BUILD_SYSTEM_ROOT_IMAGE),true)
LOCAL_REQUIRED_MODULES := verity_key_ramdisk
endif
Add support for verity builds to the build system. Change-Id: I3ef908d8d52ec88de453b161bbc3f198517a72f1
2013-06-17 02:26:08 +02:00
include $(BUILD_PREBUILT)
Add PRODUCT_ADB_KEYS This easily allow products to add custom adb keys for debuggable builds. To use, provide a public key created by `adb keygen` to PRODUCT_ADB_KEYS. This way automated test farms don't need manual intervention to authenticate to the device over adb, but we don't disable security for everyone else. Add an inherit-product-if-exists hook to aosp_* targets so that our build servers can add a key for our test farms. Bug: 32891559 Test: lunch aosp_marlin-userdebug; m bootimage Test: lunch aosp_marlin-user; m bootimage Change-Id: I1720644d89ec5289fbe99f95ebcdfbb3f3b20e67
2017-11-03 23:53:52 +01:00
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
#######################################
# verity_key (installed to ramdisk)
#
# Enabling the target when using system-as-root would cause build failure, as TARGET_RAMDISK_OUT
# points to the same location as TARGET_ROOT_OUT.
ifneq ($(BOARD_BUILD_SYSTEM_ROOT_IMAGE),true)
include $(CLEAR_VARS)
LOCAL_MODULE := verity_key_ramdisk
LOCAL_MODULE_CLASS := ETC
LOCAL_SRC_FILES := verity_key
LOCAL_MODULE_STEM := verity_key
LOCAL_MODULE_PATH := $(TARGET_RAMDISK_OUT)
include $(BUILD_PREBUILT)
endif
Add PRODUCT_ADB_KEYS This easily allow products to add custom adb keys for debuggable builds. To use, provide a public key created by `adb keygen` to PRODUCT_ADB_KEYS. This way automated test farms don't need manual intervention to authenticate to the device over adb, but we don't disable security for everyone else. Add an inherit-product-if-exists hook to aosp_* targets so that our build servers can add a key for our test farms. Bug: 32891559 Test: lunch aosp_marlin-userdebug; m bootimage Test: lunch aosp_marlin-user; m bootimage Change-Id: I1720644d89ec5289fbe99f95ebcdfbb3f3b20e67
2017-11-03 23:53:52 +01:00
#######################################
# adb key, if configured via PRODUCT_ADB_KEYS
ifdef PRODUCT_ADB_KEYS
ifneq ($(filter eng userdebug,$(TARGET_BUILD_VARIANT)),)
include $(CLEAR_VARS)
LOCAL_MODULE := adb_keys
LOCAL_MODULE_CLASS := ETC
LOCAL_MODULE_PATH := $(TARGET_ROOT_OUT)
LOCAL_PREBUILT_MODULE_FILE := $(PRODUCT_ADB_KEYS)
include $(BUILD_PREBUILT)
endif
endif
Build otacerts as a module. Bug: 30414428 Test: `m -j dist` with aosp_taimen-userdebug. Check /system/etc/security/otacerts.zip available under system and recovery images. Change-Id: I5abeb2da441fb3e3231e094063c2383eb3807852 Merged-In: I5abeb2da441fb3e3231e094063c2383eb3807852
2019-04-19 03:37:32 +02:00
#######################################
# otacerts: A keystore with the authorized keys in it, which is used to verify the authenticity of
# downloaded OTA packages.
include $(CLEAR_VARS)
LOCAL_MODULE := otacerts
LOCAL_MODULE_CLASS := ETC
LOCAL_MODULE_STEM := otacerts.zip
LOCAL_MODULE_PATH := $(TARGET_OUT_ETC)/security
include $(BUILD_SYSTEM)/base_rules.mk
$(LOCAL_BUILT_MODULE): PRIVATE_CERT := $(DEFAULT_SYSTEM_DEV_CERTIFICATE).x509.pem
$(LOCAL_BUILT_MODULE): $(SOONG_ZIP) $(DEFAULT_SYSTEM_DEV_CERTIFICATE).x509.pem
$(SOONG_ZIP) -o $@ -j -f $(PRIVATE_CERT)
#######################################
# otacerts for recovery image.
include $(CLEAR_VARS)
LOCAL_MODULE := otacerts.recovery
LOCAL_MODULE_CLASS := ETC
LOCAL_MODULE_STEM := otacerts.zip
LOCAL_MODULE_PATH := $(TARGET_RECOVERY_ROOT_OUT)/system/etc/security
include $(BUILD_SYSTEM)/base_rules.mk
extra_recovery_keys := $(patsubst %,%.x509.pem,$(PRODUCT_EXTRA_RECOVERY_KEYS))
$(LOCAL_BUILT_MODULE): PRIVATE_CERT := $(DEFAULT_SYSTEM_DEV_CERTIFICATE).x509.pem
$(LOCAL_BUILT_MODULE): PRIVATE_EXTRA_RECOVERY_KEYS := $(extra_recovery_keys)
$(LOCAL_BUILT_MODULE): \
$(SOONG_ZIP) \
$(DEFAULT_SYSTEM_DEV_CERTIFICATE).x509.pem \
$(extra_recovery_keys)
$(SOONG_ZIP) -o $@ -j \
$(foreach key_file, $(PRIVATE_CERT) $(PRIVATE_EXTRA_RECOVERY_KEYS), -f $(key_file))
Reference in a new issue Copy permalink