اطلاعات نسخه در ویژگی های AVB

برای پشتیبانی نسخه 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() بارگذاری کرد و در پارامتر خروجی AvbSlotVerifyData** out_data ذخیره می شود.

فرمت پیش فرض اطلاعات نسخه

به طور پیش فرض، سیستم ساخت اندروید از فرمت زیر به ترتیب برای نسخه سیستم عامل و وصله امنیتی استفاده می کند.

قالب com.android.build.${partition}.os_version A[.BC] است، به عنوان مثال، 12 یا 12.0.0 :

• A: نسخه اصلی
• ب: نسخه جزئی، در صورت عدم وجود آن به صورت پیش فرض صفر می شود
• ج: نسخه فرعی، در صورت وجود نداشتن، به طور پیش فرض صفر می شود

قالب 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)

اطلاعات نسخه سفارشی را مشخص کنید

با شروع اندروید 13، هر ساخت دستگاه می تواند یک مقدار سفارشی برای نسخه سیستم عامل داشته باشد که توسط بوت لودر دستگاه قابل تشخیص است. به عنوان مثال:

• 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'

اطلاعات نسخه منسوخ در هدر تصویر بوت

در اندروید 9 و بالاتر، نسخه Binding Keymaster 4 پیشنهاد می کند که os_version از هدر boot.img حذف کنید.

برای مقایسه، استفاده منسوخ از دریافت اطلاعات نسخه از هدر تصویر بوت نیز در اینجا توضیح داده شده است. توجه داشته باشید که فیلد os_version در هدر بوت هم نسخه سیستم عامل و هم سطح وصله امنیتی را در یک عدد صحیح بدون علامت 32 بیتی ترکیب می کند. و این مکانیسم فرض می کند که همه تصاویر با هم به روز می شوند، که پس از ماژولارسازی پارتیشن در 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;