WikiDer > Ленивое восстановление состояния FP

Lazy FP state restore

Ленивая утечка состояния FPU (CVE-2018-3665), также называемый Ленивое восстановление состояния FP[1] или же LazyFP,[2][3] это уязвимость безопасности влияющий Intel Core ЦП.[1][4] Уязвимость вызвана сочетанием недостатков в спекулятивное исполнение технология, присутствующая в затронутых ЦП [1] и как определенные операционные системы обрабатывают переключение контекста на блок с плавающей запятой (FPU).[2] Используя эту уязвимость, местный процесс может вызвать утечку содержимого регистров FPU, принадлежащих другому процессу. Эта уязвимость связана с Призрак и Meltdown уязвимости, публично раскрытые в январе 2018 года.

Об этом сообщил Intel 13 июня 2018 г., после того как сотрудники Amazon, Cyberus Technology и SYSGO.[1][а]

Помимо использования для арифметика с плавающей запятой, регистры FPU также используются для других целей, в том числе для хранения криптографических данных при использовании Набор инструкций AES, присутствует во многих процессорах Intel.[3] Это означает, что эта уязвимость может позволить ключевой материал быть скомпрометированным.[3]

Механизм

Плавающая точка и SIMD регистры имеют большой размер и не используются каждой задачей (или потоком) в системе. Чтобы ускорить переключение контекста, наиболее распространенные микропроцессоры поддерживают ленивое переключение состояний. Вместо того, чтобы сохранять полное состояние во время переключения контекста, операционная система может просто пометить FPU как «недоступный» в надежде, что переключенной задаче он не понадобится. Если операционная система угадала правильно, время экономится. Если предположение неверно, первая инструкция FPU или SIMD вызовет ловушку для операционной системы, которая затем может сохранить состояние предыдущей задачи и загрузить правильное состояние для текущей задачи.

В вышедшие из строя процессоры, условие «FPU недоступно» обнаруживается не сразу. (Фактически, это почти не можешь обнаруживаться немедленно, так как может одновременно выполняться несколько инструкций, вызывающих сбой, и процессор должен первый обнаруженная ошибка, чтобы сохранить иллюзию упорядоченного исполнения. Информация о том, что является первым, недоступна до этапа вывода из эксплуатации по порядку.) Процессор предположительно выполняет инструкцию. используя содержимое реестра предыдущей задачи, и некоторые следующие инструкции, и только позже обнаруживает состояние недоступности FPU. Хотя все архитектурное состояние возвращается к началу ошибочной инструкции, можно использовать часть состояния FPU в качестве адреса при загрузке памяти, инициируя загрузку в кэш процессора. Затем эксплуатация происходит по той же схеме, что и все уязвимости семейства Spectre: поскольку состояние кеша нет архитектурное состояние (кэш влияет только на скорость, а не на правильность), загрузка кеша нет отменено, и адрес, включая часть состояния регистра предыдущей задачи, может быть позже обнаружен путем измерения времени, необходимого для доступа к различным адресам памяти.

Эту ошибку можно использовать, фактически не вызывая ловушек операционной системы. Поместив доступ к FPU в тень принудительного неверное предсказание ветки (например, используя ретполин) процессор по-прежнему будет спекулятивно выполнять код, но вернется к неверно предсказанной ветви и никогда не выполнит ловушку операционной системы. Это позволяет быстро повторить атаку, быстро считывая все состояние регистров FPU и SIMD.

Смягчение

Есть возможность уменьшить уязвимость в операционной системе и гипервизор уровни, всегда восстанавливая состояние FPU при переключении контекстов процесса.[6] С таким фиксом нет прошивка требуется обновление. Некоторые операционные системы уже не лениво восстанавливали регистры FPU по умолчанию, защищая эти операционные системы на затронутых аппаратных платформах, даже если существовала проблема с основным оборудованием.[6] В операционной системе Linux, использующей ядро ​​3.7 или выше, можно заставить ядро ​​быстро восстанавливать регистры FPU с помощью eagerfpu = on параметр ядра.[3] Также многие программное обеспечение поставщики и проекты, в том числе Дистрибутивы Linux,[7] OpenBSD,[8] и Xen[4] выпустили исправления для устранения уязвимости.

Примечания

  1. ^ В OpenBSD Проект утверждает, что обнаружил уязвимость самостоятельно.[5]

Смотрите также

Рекомендации

  1. ^ а б c d «Ленивое восстановление состояния FP». Intel. 2018-06-13. Получено 2018-06-18.
  2. ^ а б Стеклина, Юлиан; Прешер, Томас (2018-06-19). «LazyFP: утечка состояния реестра FPU с использованием побочных каналов микроархитектуры». arXiv:1806.07480 [cs.OS].
  3. ^ а б c d Прешер, Томас; Стеклина, Юлиан; Галович, Яцек. «Уязвимость Intel LazyFP: использование ленивого переключения состояния FPU». Cyberus Technology. Получено 2018-06-18.
  4. ^ а б «Xen Security Advisory CVE-2018-3665 / XSA-267, версия 3». 2018-06-13. Получено 2018-06-18.
  5. ^ де Раадт, Тео (2018-06-14). "Воспаление Брайана Кантрилла". openbsd-tech (Список рассылки). Получено 2018-06-18 - через marc.info.
  6. ^ а б «Ленивое сохранение / восстановление FPU (CVE-2018-3665)». Красная шляпа. 2018-06-14. Получено 2018-06-18.
  7. ^ "CVE-2018-3665". Debian. Получено 2018-06-17.
  8. ^ "Ошибки OpenBSD 6.3". OpenBSD. Получено 2018-06-18.

внешняя ссылка