Файлы System/bin Android 12. Справочник.


  Все     Команда     Скрипт     Служба     Приложение  

update_verifier
Проверка целостность разделов после OTA-обновления

Тип файла: команда
  Рус  
update_verifier verifies the integrity of the partitions after an A/B OTA update. It gets invoked
 by init, and will only perform the verification if it's the first boot post an A/B OTA update
 (https://source.android.com/devices/tech/ota/ab/#after_reboot).

 update_verifier relies on device-mapper-verity (dm-verity) to capture any corruption on the
 partitions being verified (https://source.android.com/security/verifiedboot). The verification
 will be skipped, if dm-verity is not enabled on the device.

 Upon detecting verification failures, the device will be rebooted, although the trigger of the
 reboot depends on the dm-verity mode.
   enforcing mode: dm-verity reboots the device
   eio mode: dm-verity fails the read and update_verifier reboots the device
   other mode: not supported and update_verifier reboots the device

 All these reboots prevent the device from booting into a known corrupt state. If the device
 continuously fails to boot into the new slot, the bootloader should mark the slot as unbootable
 and trigger a fallback to the old slot.

 The current slot will be marked as having booted successfully if the verifier reaches the end
 after the verification.
   

Комментарии
Компоненты для работы с бесшовным (seamless) OTA-обновлением A/B.

update_verifier вызывается init и будет выполнять проверку только в том случае, если это первая загрузка после
OTA-обновления A/B
(https://source.android.com/devices/tech/ota/ab/#after_reboot).

update_verifier полагается на device-mapper-verity (dm-verity) для обнаружения любых повреждений на проверяемые разделы
(https://source.android.com/security/verifiedboot).

Проверка будет пропущена, если на устройстве не включена функция dm-verity.

При обнаружении сбоев проверки устройство будет перезагружено, хотя триггер перезагрузка зависит от режима dm-verity:

enforcing mode: dm-verity перезагружает устройство

eio mode: dm-verity не читает, а update_verifier перезагружает устройство

other mode: не поддерживается и update_verifier перезагружает устройство

Все эти перезагрузки предотвращают загрузку устройства в известном
поврежденном состоянии. Если устройство постоянно не загружается в новый слот, загрузчик должен пометить слот как незагружаемый и вызвать откат к старому слоту.

Текущий слот будет помечен как успешно загруженный, если верификатор
дойдет до конца после проверки.

---------------------------------------
https://source.android.com/devices/tech/ota/ab

После установки

Для каждого раздела, для которого определен шаг после установки, update_engine монтирует новый раздел в определенное место и выполняет программу, указанную в OTA, относительно смонтированного раздела. Например, если постустановочная программа определена как usr/bin/postinstall в системном разделе, этот раздел из неиспользуемого слота будет смонтирован в фиксированном месте (например, /postinstall_mount ), а /postinstall_mount/usr/bin/postinstallвыполняется /postinstall_mount/usr/bin/postinstall команда.

Чтобы постустановка прошла успешно, старое ядро ??должно уметь:

Смонтировать новый формат файловой системы. Тип файловой системы не может измениться, если в старом ядре его не поддерживает, включая такие детали, как алгоритм сжатия, используемый при использовании сжатой файловой системы (например, SquashFS).

Разобраться с форматом программы после установки нового раздела. Если используется исполняемый и компонуемый формат (ELF), он должен быть совместим со старым ядром (например, 64-битная новая программа, работающая на старом 32-битном ядре, если архитектура переключилась с 32-битной на 64-битную сборку).

Если загрузчику ( ld ) не будет дано указание использовать другие пути или создать статический двоичный файл, библиотеки будут загружаться из старого образа системы, а не из нового.

Например, вы можете использовать сценарий оболочки в качестве постустановочной программы, интерпретируемой двоичным файлом оболочки старой системы с символом #! вверху), затем настроить пути к библиотекам из новой среды для выполнения более сложной двоичной программы после установки.

В качестве альтернативы вы можете запустить этап после установки из выделенного раздела меньшего размера, чтобы разрешить обновление формата файловой системы в основном системном разделе без проблем обратной совместимости или промежуточных обновлений. Это позволит пользователям обновляться до последней версии непосредственно из заводского образа.

Новая постустановочная программа ограничена политиками SELinux, определенными в старой системе.

Таким образом, этап после установки подходит для выполнения задач, предусмотренных конструкцией на данном устройстве, или других задач с максимальной эффективностью.

Ннапример, обновление прошивки или загрузчика с поддержкой A/B, подготовка копий баз данных для новой версии и т.д.

Этап после установки не подходит для разовых исправлений ошибок перед перезагрузкой, требующих непредвиденных разрешений.

Выбранная постустановочная программа запускается в postinstall контексте SELinux.
Все файлы в новом смонтированном разделе будут помечены postinstall_file независимо от их атрибутов после перезагрузки в эту новую систему.

Изменения атрибутов SELinux в новой системе не повлияют на этап после установки. Если постустановочной программе требуются дополнительные разрешения, их необходимо добавить в постустановочный контекст.

После перезагрузки

После перезагрузки update_verifier запускает проверку целостности с помощью dm-verity.

Эта проверка начинается до zygote, чтобы службы Java не вносили какие-либо необратимые изменения, которые могли бы помешать безопасному откату.

Во время этого процесса загрузчик и ядро также могут вызвать перезагрузку, если проверенная загрузка или dm-verity обнаружат какое-либо повреждение. После завершения проверки update_verifier помечает загрузку как успешную.

update_verifier будет читать только блоки, перечисленные в /data/ota_package/care_map.txt , который включен в пакет A/B OTA при использовании кода AOSP.

Клиент обновления системы Java, такой как GmsCore, извлекает care_map.txt , устанавливает разрешение на доступ перед перезагрузкой устройства и удаляет извлеченный файл после того, как система успешно загрузится в новую версию.