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