Aby zapewnić obsługę powiązania wersji Keymaster, program ładujący urządzenia powinien podać wersję systemu operacyjnego (OS) i poziom poprawki zabezpieczeń dla każdej partycji. Wersja systemu operacyjnego i poziom poprawki zabezpieczeń to dwie oddzielne pary klucz -> wartość we właściwościach AVB . np,
-
com.android.build.system.os_version -> '12' -
com.android.build.system.security_patch -> '2022-02-05' -
com.android.build.vendor.os_version -> '12' -
com.android.build.vendor.security_patch -> '2022-02-05' -
com.android.build.boot.os_version -> '12' -
com.android.build.boot.security_patch -> '2022-02-05'
Program ładujący urządzenia może pobrać te właściwości AVB z obrazu vbmeta za pomocą avb_property_lookup() . Za pomocą avb_slot_verify() można załadować wiele obrazów vbmeta, które zostaną zapisane w parametrze wyjściowym out_data AvbSlotVerifyData** .
Domyślny format informacji o wersji
Domyślnie system kompilacji Androida użyje następującego formatu, odpowiednio dla wersji systemu operacyjnego i poprawki zabezpieczeń.
Format com.android.build.${partition}.os_version to A[.BC], np. „12” lub „12.0.0”:
- O: wersja główna
- B: wersja pomocnicza, domyślnie zero, gdy jest nieobecna
- C: wersja podrzędna, domyślnie zero, gdy jest nieobecna
Format com.android.build.${partition}.security_patch to RRRR-MM-DD.
Domyślnie system kompilacji wygeneruje tylko com.android.build.${partition}.security_patch dla partycji system , system_ext i partycji product . Oczekuje się, że producent urządzenia ustawi BOOT_SECURITY_PATCH , VENDOR_SECURITY_PATCH itp. dla partycji niesystemowych. np,
- Generuje
BOOT_SECURITY_PATCH := 2022-01-05-
com.android.build.boot.security_patch -> '2022-01-05'
-
-
VENDOR_SECURITY_PATCH := 2022-02-05-
com.android.build.vendor.security_patch -> '2022-02-05'
-
Producent urządzenia może ustawić *_SECURITY_PATCH na $(PLATFORM_SECURITY_PATCH) , jeśli zawsze będzie aktualizował wszystkie partycje do wersji z tym samym poziomem poprawek zabezpieczeń.
-
BOOT_SECURITY_PATCH := $(PLATFORM_SECURITY_PATCH) -
VENDOR_SECURITY_PATCH := $(PLATFORM_SECURITY_PATCH)
Określanie informacji o wersji niestandardowej
Począwszy od Androida 13, każda kompilacja urządzenia może mieć niestandardową wartość wersji systemu operacyjnego, która może zostać rozpoznana przez program ładujący urządzenia. np,
-
SYSTEM_OS_VERSION := 12.0.0-
com.android.build.system.os_version -> '12.0.0'
-
-
BOOT_OS_VERSION := abc-
com.android.build.boot.os_version -> 'abc'
-
-
VENDOR_OS_VERSION := 12.0.1-
com.android.build.vendor.os_version -> '12.0.1'
-
Informacje o przestarzałej wersji w nagłówku obrazu rozruchowego
Począwszy od Androida 9, powiązanie wersji Keymaster sugeruje usunięcie os_version z nagłówka boot.img .
Dla porównania opisano tutaj również przestarzałe wykorzystanie uzyskiwania informacji o wersji z nagłówka obrazu rozruchowego. Należy zauważyć, że pole os_version w nagłówku rozruchowym łączy wersję systemu operacyjnego i poziom poprawki zabezpieczeń w 32-bitową liczbę całkowitą bez znaku. I ten mechanizm zakłada, że wszystkie obrazy będą aktualizowane razem, co jest przestarzałe po modularyzacji partycji w Project Treble .
// Operating system version and security patch level.
// For version "A.B.C" and patch level "Y-M-D":
// (7 bits for each of A, B, C; 7 bits for (Y-2000), 4 bits for M)
// A = os_version[31:25]
// B = os_version[24:18]
// C = os_version[17:11]
// Y = 2000 + os_version[10:4]
// M = os-version[3:0]
uint32_t os_version;