Микроархитектурная безопасность AWS Firecracker VMM: анализ микроархитектурных атак и защиты

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

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

5. АНАЛИЗ МИКРОАРХИТЕКТУРНЫХ АТАКИ И ЗАЩИТЫ В МИКРОВМАХ ФЕЙРЕКЕРА

В этом разделе мы представляем наш анализ ряда микроархитектурных побочных каналов и спекулятивных PoC-атак на микроVM Firecracker. Мы тестируем эти PoC на «голом железе» и в экземплярах Firecracker, а также тестируем соответствующую защиту микрокода в различных сценариях. Мы запускаем наши тесты на сервере с процессором Intel Skylake 4114.

который имеет аппаратные расширения виртуализации и включен SMT. ЦП работает на микрокоде версии 0x2006b06[2]. Хост-операционная система — Ubuntu 20.04 с ядром Linux 5.10. Мы использовали Firecracker v1.0.0 и v1.4.0, последнюю версию по состоянию на июль 2023 года, для запуска гостевой системы Ubuntu 18.04 с ядром Linux 5.4, которое предоставляется Amazon при следовании краткому руководству[3].

Таким образом, рекомендуемая настройка производственного хоста, предоставляемая AWS Firecracker, недостаточна, когда речь идет о защите арендаторов от злонамеренных соседей. Таким образом, Firecracker не может обеспечить заявленные гарантии изоляции. Это потому что

(1) мы идентифицируем вариант Medusa, который становится пригодным для использования только тогда, когда он запускается на микроVM. Кроме того, рекомендуемые контрмеры не содержат необходимых шагов по смягчению последствий побочного канала или большинства других вариантов Medusa.

(2) мы показываем, что арендаторы не защищены должным образом от утечек информации, вызванных Spectre-PHT или Spectre-BTB при применении рекомендуемых контрмер. Варианты Spectre-PHT остаются проблемой даже при отключении SMT.

(3) мы не заметили различий в производительности PoC между Firecracker v1.0.0 и v1.4.0.

Мы пришли к выводу, что уровень виртуализации, обеспечиваемый Firecracker, мало влияет на микроархитектурные атаки, а рекомендации Firecracker по безопасности системы недостаточны.

5.1 Медуза

Мы оценивали PoC Могими [35] для побочных каналов Medusa [37] (классифицируемых Intel как MLPDS-варианты MDS [25]) на «голом железе» нашей тестовой системы и на виртуальных машинах Firecracker. Для каждого из трех известных вариантов, описанных в разделе 2.4.2, существует один PoC с утечкой. Мы использовали две программы-жертвы из библиотеки PoC:

• Программа «Блочная запись» записывает большой объем последовательных данных в цикле (так что процессор идентифицирует повторяющиеся записи и объединяет их).

• Программа «REP MOV» выполняет аналогичную операцию, но с помощью инструкции REP MOV вместо множества инструкций, перемещающих меньшие блоки данных в цикле.

5.1.1 Результаты. В таблице 1 показаны случаи успешной утечки данных при отключении всех микроархитектурных защит ядра. В двух левых столбцах показаны возможные комбинации трех PoC Medusa и двух включенных программ-жертв. В правых столбцах указано, какие конфигурации работают на «голом железе», а также с секретной и протекающей программой, работающей в параллельных экземплярах Firecracker. В частности, в варианте индексирования кэша секрет блокировки записи работает только с Firecracker. Вероятно, это связано с виртуализацией адресов памяти, которую обеспечивает виртуальная машина: гость видит только области виртуальной памяти, сопоставленные KVM, а KVM перехватывает инструкции по доступу к памяти и обрабатывает транзакции от имени гостя.

Мы протестировали эффективность защиты mds и nosmt против каждой комбинации PoC злоумышленника и жертвы на «голом железе» и в виртуальных машинах Firecracker. В Таблице 2 перечислены средства защиты, необходимые для предотвращения атак Medusa в сценариях «голое железо» и «Фейерверк». Из четырех уязвимостей в Firecracker только одна устраняется с помощью nosmt, и AWS явно не рекомендует включать защиту mds, хотя большинство дистрибутивов Linux поставляются с включенной ею по умолчанию. То есть многопользовательская облачная платформа может использовать Firecracker таким образом, чтобы это соответствовало рекомендуемым мерам безопасности AWS, и при этом оставаться уязвимой для большинства вариантов Medusa, включая тот, в котором сам Firecracker VMM сливает данные пользователя, что может привести к утечке данных пользователя. в противном случае не будет утечки.

5.2 RIDL и многое другое

В этом разделе мы представляем оценку программ RIDL PoC [51], представленную вместе с статьей ван Шайка и др. 2019 года [50]. RIDL — это класс MDS-атак, который использует спекулятивную загрузку из буферов внутри ЦП (а не из кеша или памяти). Репозиторий RIDL PoC также включает примеры атак, опубликованных в более поздних дополнениях к документу, а также один вариант атаки Fallout MDS.

5.2.1 Результаты. В таблице 3 представлена основная информация о протестированных нами PoC RIDL и эффективности соответствующих контрмер для предотвращения атак. Мы сравнили атаки на «голое железо» и в Firecracker, чтобы оценить заявления Amazon о повышенной аппаратной безопасности системы Firecracker microVM. Для тестов в системе Firecracker мы различаем флаги контрмер, включенные в хост-системе (H) и гостевом ядре Firecracker (VM). Помимо флагов ядра nosmt и mds, мы протестировали другие соответствующие флаги (см. раздел 2.4.4, [21]), включая kaslr, pti и l1tf, но не обнаружили, что они оказали влияние на какую-либо из этих программ. Мы исключили защиту tsx_async_abort, поскольку процессор, на котором мы тестировали, включает защиту mds, что делает флаг ядра tsx_async_abort избыточным [20].

В целом мы обнаружили, что защита mds не обеспечивает адекватной защиты от большинства атак RIDL. Однако отключение SMT смягчает большинство этих эксплойтов. Это согласуется с заявлениями Intel [25] и разработчиков Linux [21] о том, что SMT необходимо отключить, чтобы предотвратить атаки MDS через гиперпотоки. Двумя исключениями среди этих PoC являются выравнивание_write, для которого требуются как nosmt, так и mds на хосте, и pgtable_leak_notsx, который устраняется только контрмерами mds. Утечка, основанная на Alignment_write, использует ошибку выравнивания, а не утечку ошибки таблицы страниц, чтобы вызвать спекуляции [50]. В документе RIDL [50] и документации Intel по соответствующему эксплойту VRS [26] неясно, что именно отличает эту атаку от атак MFBDS на основе ошибок страниц, обнаруженных в других PoC, но наши экспериментальные результаты показывают, что микроархитектурный механизм утечки отчетливый. Существует простое и разумное объяснение поведения pgtable_leak_notsx, которое является уникальным среди этих PoC по одной ключевой причине: это единственный эксплойт, который пересекает границы безопасности (утечка значений таблицы страниц из ядра) в пределах одного потока, а не утечка из другая ветка. Само собой разумеется, что отключение многопоточности мало повлияет на этот однопоточный эксплойт. Однако контрмера mds очищает микроархитектурные буферы перед переключением с выполнения с привилегиями ядра на выполнение с привилегиями пользователя в том же потоке, стирая данные таблицы страниц, к которым обращается код ядра, из LFB до того, как атакующий пользовательский код сможет их утечь.

В отличие от Medusa, большинство этих PoC смягчаются рекомендацией AWS отключить smt. Однако, как и в случае с Medusa, сам Firecracker VMM не обеспечивает микроархитектурной защиты от этих атак.

5.3 Призрак

Далее мы сосредоточимся на уязвимостях Spectre. Хотя с момента первого обнаружения атак Spectre было разработано множество контрмер, многие из них либо приводят к (значительному) снижению производительности, либо лишь частично смягчают атаку. Поэтому,

системным операторам часто приходится выбирать между производительностью и безопасностью. В этом разделе мы оцениваем поверхность атаки Spectre, доступную арендаторам Firecracker в обеих моделях угроз, описанных ранее. Чтобы оценить широкий спектр атак Spectre, мы полагаемся на PoC, представленные в [15]. Для Spectre-PHT, Spectre-BTB и SpectreRSB репозиторий содержит по четыре PoC каждый. Они отличаются тем, как злоумышленник дезорганизует БПУ. Четыре возможности: (1) один и тот же процесс — злоумышленник контролирует процесс-жертву или его входные данные, чтобы ввести в заблуждение BPU; (2) перекрестный процесс — злоумышленник запускает свой собственный код в отдельном процессе, чтобы повлиять на предсказания ветвей процесс-жертва – (а) на месте – злоумышленник неправильно настраивает BPU с помощью инструкций ветвления, которые находятся по тому же виртуальному адресу, что и целевая ветвь, которую злоумышленник хочет неправильно спрогнозировать в процессе-жертве – (б) вне место — злоумышленник ошибочно загружает BPU инструкциями ветвления, которые находятся по адресам, совпадающим с целевыми ветвями в процессе-жертве.

(1) один и тот же процесс: злоумышленник контролирует процесс-жертву или его входные данные, чтобы ввести в заблуждение BPU,

(2) кросс-процесс: злоумышленник запускает свой собственный код в отдельном процессе, чтобы повлиять на предсказания ветвей процесса-жертвы,

(3) на месте: злоумышленник неправильно настраивает BPU с помощью инструкций ветвления, которые находятся по тому же виртуальному адресу, что и целевая ветвь, которую злоумышленник хочет неправильно спрогнозировать в процессе жертвы.

(4) неуместно: злоумышленник ошибочно загружает BPU инструкциями ветвления, которые находятся по адресам, совпадающим с целевыми ветвями в процессе-жертве.

Первые две и две последние ситуации ортогональны, поэтому каждый PoC объединяет две из них. Для Spectre-STL известны только варианты одного и того же процесса, поэтому в этом случае репозиторий предоставляет только два PoC. Для экспериментов между виртуальными машинами отключена рандомизация макета адресного пространства для ядер хоста и гостя, а также для уровня пользователя хоста и гостя, чтобы упростить поиск конгруэнтных адресов, которые используются для неправильного обучения.

5.3.1 Результаты. Благодаря рекомендованным AWS контрмерам [8] (по умолчанию для используемых ядер Linux, см. рис. 5), включенным в хост-системе и внутри виртуальных машин Firecracker, мы видим, что Spectre-RSB успешно подавляется как на хосте, так и внутри и между виртуальными машинами. (см. табл. 4). С другой стороны, Spectre-STL, Spectre-BTB и Spectre-PHT допускали утечку информации в определенных ситуациях.

PoC для Spectre-STL показывает утечку. Однако утечка происходит только в рамках одного и того же процесса и одного и того же уровня привилегий. Поскольку варианты кросс-процессов неизвестны, мы не тестировали сценарий кросс-VM для Spectre-STL. В нашей модели угроз между пользователями Spectre-STL не является возможным вектором атаки, поскольку неизвестны варианты межпроцессного взаимодействия. Если две рабочие нагрузки арендатора будут изолированы внутри процесса внутри одной виртуальной машины, Spectre-STL все равно может стать жизнеспособным вектором атаки. В модели «пользователь-хост» Spectre-STL смягчается контрмерами, которые включены в текущие ядра Linux и включены по умолчанию.

Для Spectre-PHT меры противодействия ядра включают очистку пользовательских указателей и использование барьеров (lfence) на переключателях уровня привилегий. Таким образом, мы приходим к выводу, что SpectrePHT практически не представляет угрозы для хост-системы. Однако эти

меры по снижению риска не защищают два гиперпотока друг от друга, если они выполняются на одном физическом ядре параллельно. Вот почему все четыре варианта ошибочного обучения Spectre-PHT полностью функциональны как в хост-системе, так и внутри виртуальных машин Firecracker. Как видно из Таблицы 4, это остается верным, даже если SMT отключен[4]. Фактически, привязка обеих виртуальных машин к одному и тому же физическому потоку позволяет использовать неуместную версию Spectre-PHT для кросс-процессов, тогда как в случае SMT мы не наблюдали утечек. Это делает Spectre-PHT серьезной угрозой для пользователей.

PoC Spectre-BTB частично работоспособны, если включены рекомендуемые AWS контрмеры. Исходный вариант, который неправильно настраивает BTB в том же процессе и по тому же адресу, является полностью функциональным, в то время как неправильное обучение того же процесса вне места является

успешно смягчено. Кроме того, все попытки утечки информации через границы процесса посредством неуместного неправильного обучения не выявили каких-либо утечек. Однако при межпроцессном неправильном обучении мы наблюдали утечку. В хост-системе утечка произошла независимо от SMT. Внутри виртуальной машины утечка происходила только в том случае, если все виртуальные ядра ЦП были назначены отдельному физическому потоку. На виртуальных машинах отключение SMT устранило утечку.

Помимо мер противодействия, перечисленных на рисунке 5, ядро хоста имеет контрмеры Spectre, скомпилированные в точки входа и выхода виртуальной машины[5], чтобы полностью запретить злонамеренным гостям атаковать ядро хоста, пока ядро обрабатывает выход виртуальной машины.

Подводя итог, можно сказать, что стандартные контрмеры Linux, рекомендованные AWS Firecracker, лишь частично смягчают угрозу Spectre. Точнее, мы показываем:

• Spectre-PHT и Spectre-BTB по-прежнему могут вызывать утечку информации между арендаторами в сценарии «гость-гость» при наличии рекомендованных AWS контрмер, включая отключение SMT.

• Ядро хоста, вероятно, достаточно защищено дополнительными мерами предосторожности, которые встроены в ядро Linux и защищают входы и выходы виртуальной машины. Однако это противоречит мерам безопасности, предоставляемым Firecracker.

Все наблюдаемые утечки не зависели от используемой версии Firecracker.

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

Читатель предупреждений может задаться вопросом, почему Spectre-BTB остается проблемой при наличии контрмеры STIBP (см. рис. 5), поскольку этот патч микрокода был разработан, чтобы помешать прогнозированию ветвей использовать информацию прогнозирования, исходящую из другого потока. Это также некоторое время нас озадачивало, пока недавно Google не опубликовал рекомендации по безопасности[6], в которых указана ошибка в Linux 6.2, которая продолжала отключать смягчение последствий STIBP при включении IBRS. Мы проверили, что раздел кода, который был идентифицирован как ответственный за проблему, также присутствует в исходном коде Linux 5.10. Поэтому мы предполагаем, что та же проблема, выявленная Google, возникает и в нашей системе.

[2] Обновление микрокода до более новой версии отключит TSX в нашей системе, что сделает невозможными тесты с вариантами MDS на основе TSX.

[3] https://github.com/firecracker-microvm/firecracker/blob/ dbd9a84b11a63b5e5bf201e244fe83f0bc76792a/docs/getting-started.md

[4] Это моделируется путем прикрепления процесса злоумышленника и жертвы к одному ядру ((1PT))

[5] https://elixir.bootlin.com/linux/v5.10/source/arch/x86/kvm/vmx/vmenter.S#L191

[6] https://github.com/google/security-research/security/advisories/GHSA-mj4w6495-6crx