Микроархитектурная безопасность AWS Firecracker VMM: анализ систем сдерживания фейерверка

Таблица ссылок

• Аннотация и введение
• Фон
• Модели угроз
• Анализ систем сдерживания фейерверков
• Анализ микроархитектурных атак и средств защиты в микроVM Firecracker
• Заключение, благодарности и ссылки

4. Анализ систем сдерживания петарды

На рис. 2 показана защита, предлагаемая Firecracker, представленная AWS. В этом разделе мы анализируем каждый изображенный компонент, а также их защиту от микроархитектурных атак и уязвимости к ним.

КВМ . Виртуальная машина на основе ядра Linux (KVM) — это гипервизор, реализованный в современных ядрах Linux и, следовательно, являющийся частью базы кода Linux. Он виртуализирует режимы супервизора и пользователя базового оборудования, управляет переключением контекста между виртуальными машинами и обрабатывает большинство причин выхода из виртуальной машины, если они не связаны с операциями ввода-вывода. Помимо этих механизмов архитектурной изоляции, KVM также реализует средства защиты от атак Spectre на выход виртуальной машины для защиты хостовой ОС или гипервизора от злоумышленников. Firecracker в значительной степени использует KVM в качестве своего гипервизора. Однако, поскольку KVM является частью исходного кода Linux и разработан сообществом Linux, мы определяем, что KVM не является частью Firecracker. Поэтому меры противодействия микроархитектурным атакам, реализованные в KVM, нельзя отнести к системе сдерживания Firecracker.

Метаданные, устройства и службы ввода-вывода. Метаданные, устройства и службы ввода-вывода — это части Firecracker VMM и API, которые напрямую взаимодействуют с виртуальной машиной, собирая и управляя метриками, а также обеспечивая подключение. AWS рекламирует простоту этих интерфейсов (для уменьшения поверхности атаки) и то, что они написаны с нуля для Firecracker на Rust, языке программирования, известном своими функциями безопасности [9]. Тем не менее, Rust, в первую очередь, обеспечивает внутрипроцессную защиту от недопустимого и внешнего доступа к памяти, но микроархитектурные атаки, такие как атаки кэша, Spectre и MDS, могут привести к утечке информации между процессами, а не к прямому захвату процесса жертвы.

Еще одно заметное отличие Firecracker от многих других VMM заключается в том, что все эти службы запускаются в том же хост-процессе, что и сама виртуальная машина, хотя и в другом потоке. Хотя виртуализация адресов памяти внутри виртуальной машины обеспечивает некоторую путаницу между гостевым кодом и службами ввода-вывода, некоторые атаки Spectre работают конкретно внутри одного процесса. Однако внутрипроцессные атаки могут представлять меньшую угрозу для реальных систем, поскольку каждый из двух гостей, работающих на одном и том же оборудовании, имеет свою собственную копию этих важных служб.

Тюремщик барьер. В случае взлома API или VMM тюремщик обеспечивает последний барьер защиты вокруг экземпляра Firecracker. Он защищает файлы и ресурсы хост-системы с помощью пространств имен и групп управления (cgroups) соответственно [7]. Микроархитектурные атаки не угрожают напрямую файлам, которые по определению находятся за пределами микроархитектурного состояния. Cgroups позволяют системному администратору назначать процессы группам, а затем распределять, ограничивать и контролировать использование системных ресурсов для каждой группы [17]. Вполне вероятно, что ограничения, применяемые к контрольным группам, могут помешать злоумышленнику выполнить определенные микроархитектурные атаки. Например, ограничения памяти могут затруднить проведение атак на основе вытеснения кэша, а ограничения времени ЦП могут помешать злоумышленнику эффективно использовать инструмент отказа в обслуживании ЦП, такой как HyperDegrade [2], который может замедлить работу жертвы. процесс, упрощающий выбор времени микроархитектурной эксфильтрации или инъекции по боковым каналам. На практике Firecracker не распространяется с какими-либо конкретными правилами cgroup [7]; Фактически, он специально разработан для эффективной работы многих виртуальных машин Firecracker при распределении ресурсов Linux по умолчанию [6].

Ни одна из систем изоляции и сдерживания в Firecracker, похоже, не защищает напрямую от атак «пользователь-пользователь» или «пользователь-хост». Поэтому мы приступили к тестированию различных концепций микроархитектурных атак внутри и снаружи виртуальных машин Firecracker.