Усі пристрої, які запускаються з Android Pie (Android 9), повинні підтримувати перевірене завантаження (Android Verified Boot 2.0), що забезпечує захист від відкату.
Android Pie (Android 9) тільки сьогодні вийшов у прямому ефірі для Google Pixel, Google Pixel 2 і навіть Основний телефон. Ми дізнаємося якомога більше про реліз з інтерв’ю (Google Pixel 3 матиме лише навігацію жестами!), the Відкидання коду AOSPі, нарешті, документ визначення сумісності (CDD). Ми писали про а нова функція для "важкоатлетичних" програм раніше сьогодні, але тепер ми виявили, що Google змінив своє формулювання щодо функції, представленої в Android Oreo: захист від відкату. Ця функція стала можливою завдяки Android Verified Boot 2.0 (також відомий просто як Verified Boot), проте виробникам оригінального обладнання не потрібно було впроваджувати AVB 2.0 у випуск Oreo. Тепер Google зобов’язує всі пристрої, які запускаються з Android Pie, підтримувати Verified Boot і, відповідно, захист від відкату.
Захист від відкату в Android Oreo
Суть функції полягає в тому, що вона запобігає завантаженню вашого телефону, якщо виявить, що пристрій перейшов на старішу версію до попередньої, наразі не схваленої версії програмного забезпечення, яке було визнано небезпечним через безпеку вразливість. Трохи більш технічне пояснення полягає в тому, що структура даних VBMeta, яка містить хеш для завантажувального розділу та метадані хеш-дерева для розділів системи та постачальника, використовує індекс відкату для відхилення зображень, які мають старіший відкат індекс.
Ця функція присутня на таких пристроях, як Google Pixel 2, Razer Phone і OnePlus 6, але не присутня на багатьох інших пристроях, таких як Samsung Galaxy S9 (хоча Samsung пропонує власну форму захист від відкату в Knox.) Тепер Google робить цю функцію обов’язковою для всіх пристроїв, які запускаються з Android Pie.
Перевірене завантаження в Android Pie
Згідно з оновленим формулюванням у розділі «Цілісність пристрою» в документі визначення сумісності, пристрої, які запускаються з Android 9, повинні підтримувати перевірене завантаження.
9.10. Цілісність пристрою
Наступні вимоги забезпечують прозорість статусу цілісності пристрою. Впровадження пристроїв:
- [C-0-1] ПОВИНЕН правильно повідомляти за допомогою методу System API PersistentDataBlockManager.getFlashLockState(), чи дозволяє стан завантажувача спалахувати образ системи. Стан FLASH_LOCK_UNKNOWN зарезервовано для реалізацій пристроїв, які оновлюються з попередньої версії Android, де не існувало цього нового системного методу API.
- [C-0-2] ПОВИНЕН підтримувати перевірене завантаження для цілісності пристрою.
Якщо впровадження пристрою вже запущено без підтримки перевіреного завантаження на попередній версії Android і не можуть додати підтримку цієї функції за допомогою оновлення системного програмного забезпечення, вони МОЖУТЬ бути звільнені від вимога.
...
- [C-1-10] ПОВИНЕН реалізувати захист від відкату для розділів, які використовуються Android (наприклад, завантажувальний, системний розділи) і використовуйте захищене від втручання сховище для зберігання метаданих, які використовуються для визначення мінімально допустимої ОС версія.
- СЛІД запровадити захист від відкату для будь-якого компонента з постійним мікропрограмним забезпеченням (наприклад, модем, камера) і СЛІД використовувати захищене від втручання сховище для зберігання метаданих, які використовуються для визначення мінімально допустимого версія.
Як ви можете бачити в останніх двох наборах пунктів, є одне застереження, на яке слід звернути увагу. Захист від повернення потрібен для розділів, які використовуються Android (завантажувальний, системний, постачальник тощо), але не для розділів із постійним мікропрограмним забезпеченням (модем, камера тощо). У попередньому наборі розділів виявляється та виправляється більшість вразливостей системи безпеки, тому приємно бачити, що захист цих розділів обов’язковий. Однак були виявлені експлойти, націлені на розділи з постійним мікропрограмним забезпеченням, тому ми не впевнені, чому Google не встановлює для них обов’язковий захист від відкату.
Старший член XDA npjohnson, член команди LineageOS, припускає, що вимога захисту від відкату на розділах із постійною мікропрограмою вимагають підключення вторинного завантажувача (SBL) і розширюваного завантажувача (XBL), оскільки ці розділи монтуються раніше в завантажувальній системі процес. Для менших виробників обладнання було б дорого впроваджувати налаштовані XBL, щоб відповідати налаштованим модемам та іншим постійним розділам, тому, можливо, Google не робить це вимогою, щоб полегшити виробникам пристроїв відповідність останнім вимогам CDD.
Як перевірити, чи підтримує ваш телефон AVB 2.0
Є дві команди оболонки ADB, за допомогою яких можна перевірити, чи підтримує ваш телефон AVB 2.0.
adb shell
dumpsys package | grep "verified_boot"АБО
adb shell
getprop | grep "avb"Якщо результатом першої команди є «android.software.verified_boot», то AVB 2.0 підтримується. Якщо вихідні дані другої команди показують «[ro.boot.avb_version]» і «[ro.boot.vbmeta.avb_version]» і вказують номер версії для кожної, це означає, що вона підтримується.
Перевірене завантаження та індивідуальна розробка
Android Verified Boot насправді не впливає на більшість користувачів користувацьких ПЗУ, хоча додає додатковий рівень безпеки, який у деяких випадках потрібно обійти. Наприклад, миготіння загального образу системи вимагає відключення AVB. Щоб змінити певні розділи, як-от постачальника на OnePlus 6, також потрібно вимкнути AVB, як я недавно дізнався. Відповідно до npjohnson, належним чином реалізований AVB 2.0 дає змогу користувацьким образам завантаження працювати із заблокованим завантажувачем. Ми побачимо, як включення AVB 2.0 на пристрої з Android Pie вплине на ландшафт, але ми сподіваємося, що це не призведе до ситуацій, подібних до останній переляк у спільноті Xiaomi Redmi Note 5 Pro. Обов’язковий AVB 2.0 – це ще один спосіб для Google покращити безпеку платформи Android, але найбільшою зміною, на нашу думку, є переробка угод OEM для обов’язкових регулярних виправлень безпеки.