برای پشتیبانی از اتصال نسخه KeyMint (که قبلاً Keymaster نام داشت)، انتظار میرود بوتلودر دستگاه، نسخه سیستم عامل (OS) و سطح وصله امنیتی را برای هر پارتیشن ارائه دهد. نسخه سیستم عامل و سطح وصله امنیتی دو جفت کلید-مقدار جداگانه در ویژگیهای AVB هستند. برای مثال:
-
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'
بوت لودر دستگاه میتواند آن ویژگیهای AVB را از یک تصویر vbmeta با استفاده از avb_property_lookup() دریافت کند. چندین تصویر vbmeta میتوانند توسط avb_slot_verify() بارگذاری شوند و در پارامتر خروجی out_data AvbSlotVerifyData** ذخیره شوند.
قالب پیشفرض اطلاعات نسخه
به طور پیشفرض، سیستم ساخت اندروید از فرمت زیر به ترتیب برای نسخه سیستم عامل و پچ امنیتی استفاده میکند.
فرمت com.android.build.${partition}.os_version به صورت A[.BC] است، برای مثال، 12 یا 12.0.0 :
- الف: نسخه اصلی
- ب: نسخه فرعی، در صورت عدم وجود، به طور پیشفرض روی صفر تنظیم میشود
- C: نسخه فرعی، در صورت عدم وجود، به طور پیشفرض روی صفر تنظیم میشود.
فرمت فایل com.android.build.${partition}.security_patch برابر با YYYY-MM-DD است.
به طور پیشفرض، سیستم ساخت com.android.build.${partition}.security_patch را برای پارتیشنهای system ، system_ext و product تولید میکند. انتظار میرود سازنده دستگاه BOOT_SECURITY_PATCH ، VENDOR_SECURITY_PATCH و سایر وصلهها را برای پارتیشنهای غیرسیستمی تنظیم کند. به عنوان مثال:
-
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'
-
سازنده دستگاه میتواند *_SECURITY_PATCH روی $(PLATFORM_SECURITY_PATCH) تنظیم کند اگر همیشه همه پارتیشنها را به نسخهای با سطح وصله امنیتی یکسان بهروزرسانی کند.
-
BOOT_SECURITY_PATCH := $(PLATFORM_SECURITY_PATCH) -
VENDOR_SECURITY_PATCH := $(PLATFORM_SECURITY_PATCH)
اطلاعات نسخه سفارشی را مشخص کنید
با شروع از اندروید ۱۳، هر دستگاه میتواند یک مقدار سفارشی برای نسخه سیستم عامل داشته باشد که توسط بوت لودر دستگاه قابل شناسایی است. به عنوان مثال:
-
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'
-
اطلاعات نسخه منسوخ شده در هدر تصویر بوت
در اندروید ۹ و بالاتر، اتصال نسخه Keymaster 4 پیشنهاد میدهد که os_version از هدر boot.img حذف شود.
برای مقایسه، روش منسوخشدهی دریافت اطلاعات نسخه از هدر تصویر بوت نیز در اینجا شرح داده شده است. توجه داشته باشید که فیلد os_version در هدر بوت، هم نسخه سیستم عامل و هم سطح وصله امنیتی را در یک عدد صحیح بدون علامت ۳۲ بیتی ترکیب میکند. و این مکانیسم فرض میکند که همه تصاویر با هم بهروزرسانی میشوند، که پس از ماژولارسازی پارتیشن در پروژه 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;