Verified Boot требует криптографической проверки всего исполняемого кода и данных, которые являются частью загружаемой версии Android, перед ее использованием. Сюда входит ядро (загружаемое из раздела boot ), дерево устройств (загружаемое из раздела dtbo ), system раздел, раздел vendor и т. д.
Небольшие разделы, такие как boot и dtbo , которые считываются только один раз, обычно проверяются путем загрузки всего содержимого в память и последующего вычисления его хэша. Затем это вычисленное значение хэша сравнивается с ожидаемым значением хэша . Если значение не совпадает, Android не загрузится. Для получения более подробной информации см. Boot Flow .
Большие разделы, которые не помещаются в память (например, файловые системы), могут использовать хэш-дерево, где проверка является непрерывным процессом, происходящим по мере загрузки данных в память. В этом случае корневой хэш хэш-дерева вычисляется во время выполнения и сверяется с ожидаемым корневым хэш-значением . Android включает драйвер dm-verity для проверки больших разделов. Если в какой-то момент вычисленный корневой хэш не соответствует ожидаемому корневому хэш-значению , данные не используются, и Android переходит в состояние ошибки. Для получения более подробной информации см. повреждение dm-verity .
Ожидаемые хэши обычно хранятся либо в конце, либо в начале каждого проверенного раздела, либо в выделенном разделе, либо в обоих. Важно, что эти хэши подписаны (прямо или косвенно) корнем доверия. Например, реализация AVB поддерживает оба подхода, подробности см. в разделе Android Verified Boot .
Защита от отката
Даже при полностью безопасном процессе обновления существует возможность, что непостоянный эксплойт ядра Android вручную установит более старую, более уязвимую версию Android, перезагрузится в уязвимую версию, а затем использует эту версию Android для установки постоянного эксплойта. Оттуда злоумышленник навсегда владеет устройством и может делать все, что угодно, включая отключение обновлений.
Защита от этого класса атак называется Rollback Protection . Защита от отката обычно реализуется с помощью защищенного от несанкционированного доступа хранилища для записи последней версии Android и отказа от загрузки Android, если она ниже записанной версии. Версии обычно отслеживаются по разделам.
Более подробную информацию о том, как AVB обрабатывает защиту от отката, см. в файле AVB README .
Обработка ошибок проверки
Проверка может завершиться неудачей либо во время загрузки (например, если вычисленный хэш на boot разделе не соответствует ожидаемому хешу), либо во время выполнения (например, если dm-verity обнаруживает ошибку проверки на system разделе). Если проверка завершается неудачей во время загрузки, устройство не может загрузиться, и конечному пользователю необходимо выполнить шаги по восстановлению устройства.
Если проверка не проходит во время выполнения, поток немного сложнее. Если устройство использует dm-verity, его следует настроить в режиме restart . В режиме restart , если обнаружена ошибка проверки, устройство немедленно перезапускается с установленным специальным флагом, указывающим на причину. Загрузчик должен заметить этот флаг и переключить dm-verity в режим использования ошибки ввода-вывода ( eio ) и оставаться в этом режиме до тех пор, пока не будет установлено новое обновление.
При загрузке в режиме eio устройство показывает экран ошибки, информирующий пользователя об обнаружении повреждения и о том, что устройство может работать некорректно. Экран отображается до тех пор, пока пользователь его не закроет. В режиме eio драйвер dm-verity не перезапустит устройство, если возникнет ошибка проверки, вместо этого возвращается ошибка EIO, и приложению необходимо обработать ее.
Цель состоит в том, чтобы либо запустить системное обновление (чтобы можно было установить новую ОС без ошибок повреждения), либо чтобы пользователь мог получить как можно больше своих данных с устройства. После установки новой ОС загрузчик замечает недавно установленную ОС и переключается обратно в режим restart .