Утечка состояния ленивого FPU ( CVE - 2018-3665), также называемая ленивым восстановлением состояния FP [1] или LazyFP [2] [3] — уязвимость безопасности, затрагивающая процессоры Intel Core . [1] [4] Уязвимость вызвана сочетанием недостатков в технологии спекулятивного выполнения , присутствующей в затронутых процессорах [1] , и тем, как некоторые операционные системы обрабатывают переключение контекста в блоке с плавающей точкой (FPU). [2] Эксплуатируя эту уязвимость, локальный процесс может получить утечку содержимого регистров FPU, принадлежащих другому процессу. Эта уязвимость связана с уязвимостями Spectre и Meltdown , которые были публично раскрыты в январе 2018 года.
Intel объявила об этом 13 июня 2018 года после того, как об этом узнали сотрудники Amazon , Cyberus Technology и SYSGO . [1] [a]
Помимо использования для арифметики с плавающей точкой , регистры FPU также используются для других целей, в том числе для хранения криптографических данных при использовании набора инструкций AES , присутствующего во многих процессорах Intel. [3] Это означает, что эта уязвимость может привести к компрометации ключевого материала . [3]
Регистры с плавающей точкой и SIMD большие и не используются каждой задачей (или потоком) в системе. Чтобы ускорить переключение контекста, большинство распространенных микропроцессоров поддерживают ленивое переключение состояний. Вместо того чтобы сохранять полное состояние во время переключения контекста, операционная система может просто пометить FPU как «недоступный» в надежде, что переключенная задача не будет в нем нуждаться. Если операционная система угадала правильно, время экономится. Если угадала неправильно, первая инструкция FPU или SIMD вызовет ловушку для операционной системы, которая затем может сохранить состояние для предыдущей задачи и загрузить правильное состояние для текущей задачи.
В процессорах с неупорядоченным выполнением состояние «FPU not available» обнаруживается не сразу. (На самом деле, его почти невозможно обнаружить сразу, так как может быть несколько инструкций, вызывающих сбой, выполняемых одновременно, и процессор должен принять первую обнаруженную ошибку, чтобы сохранить иллюзию упорядоченного выполнения. Информация о том, какая из них первая, недоступна до этапа упорядоченного завершения.) Процессор спекулятивно выполняет инструкцию , используя содержимое регистра предыдущей задачи и некоторые последующие инструкции, и только позже обнаруживает состояние «FPU not available». Хотя все архитектурное состояние возвращается к началу инструкции, вызывающей сбой, можно использовать часть состояния FPU в качестве адреса в загрузке памяти, вызывая загрузку в кэш процессора. Эксплуатация затем происходит по той же схеме, что и все уязвимости семейства Spectre: поскольку состояние кэша не является архитектурным состоянием (кэш влияет только на скорость, а не на корректность), загрузка кэша не отменяется, а адрес, включая часть состояния регистра предыдущей задачи, может быть впоследствии обнаружен путем измерения времени, необходимого для доступа к различным адресам памяти.
Эту ошибку можно эксплуатировать, фактически не вызывая никаких ловушек операционной системы. Поместив доступ FPU в тень принудительного неверного предсказания ветвления (например, с помощью retpoline ), процессор все равно спекулятивно выполнит код, но вернется к неверно предсказанной ветви и никогда фактически не выполнит ловушку операционной системы. Это позволяет быстро повторять атаку, быстро считывая все состояние регистра FPU и SIMD.
Можно смягчить уязвимость на уровне операционной системы и гипервизора , всегда восстанавливая состояние FPU при переключении контекстов процесса. [6] При таком исправлении не требуется обновление прошивки . Некоторые операционные системы уже не лениво восстанавливают регистры FPU по умолчанию, защищая эти операционные системы на затронутых аппаратных платформах, даже если существовала базовая проблема с оборудованием. [6] В операционной системе Linux с ядром 3.7 или выше можно заставить ядро быстро восстановить регистры FPU, используя eagerfpu=onпараметр ядра. [3] Кроме того, многие поставщики и проекты системного программного обеспечения , включая дистрибутивы Linux , [7] OpenBSD , [8] и Xen [4], выпустили исправления для устранения уязвимости.