Борьба с различными уязвимостями семейства Spectre уже приводила к неоднозначным результатам. Даже сам создатель Linux, Линус Торвальдс, с негодованием отметил, что падение производительности на 50% явно не стоит такой «защиты». Речь шла об исправлении STIBP (Single Thread Indirect Branch Predictors) для процессоров с SMT/HT. На этот раз он выступил против включения в ядро Linux 5.8 опции сброса кеша данных L1 при переключении контекста.

Окно внесения различных нововведений в новое ядро Linux 5.8 открывается: так, мы уже писали о том, что эта ветка получит поддержку процессорной архитектуры MIPS R5. Как оказалось, в рамках борьбы с уязвимостями класса Spectre, а также другими потенциальными утечками из кешей, которым ещё нет названия, в ядре 5.8 должна была появиться такая неоднозначная функция, как сброс кеша данных L1 при переключении контекста. К счастью, Торвальдс не одобрил этой идеи и даже назвал её безумной.

Дело в том, что речь идёт не просто о сбросе кеша в действительно требующей этого ситуации. Это функция, позволяющая делать такой сброс по «приказу» любого приложения, причём это приложение в многозадачной ОС, каковой является Linux, будет замедлять не только себя, но и остальные процессы. Для высоконагруженных серверных систем это крайне вредная практика. Кроме того, сам сброс является осмысленной задачей только для процессоров Intel, и Торвальс закономерно посчитал навязывание сброса L1 даже тем конфигурациям, где оно не требуется, плохой идеей.

В своём посте, посвященном этой теме, он прямо заявил, что не желает видеть опции в стиле «я могу заставить делать ядро глупые вещи». Такая опция должна иметь двойное подтверждение. Кроме того, использование SMT делает всю идею практически бессмысленной. Далее Торвальдс отметил, что будет счастлив получить больше информации о том, почему он может быть неправ, но на данный момент он отзывает данную опцию ядра 5.8 по причине «нехватки информации».

За патч со сбросом данных из L1 при смене контекстов отвечает разработчик из Amazon, но пока с его стороны, а также со стороны Intel не поступало никаких комментариев и заверений в том, что этот патч действительно необходим и действительно спасает от реальных угроз. 

Уязвимости Spectre и Meltdown в своё время доставили немало беспокойства специалистам по ИТ-безопасности. Программные заплатки появились довольно быстро, но в некоторых случаях приводили к серьёзному падению производительности.

Сейчас, на волне роста популярности архитектуры ARM в ЦОД и серверных, разработчики Google всерьёз обеспокоены тем, что ряд 64-битных платформ ARM не имеет защиты от Spectre V2.

Ещё зимой 2018 года Google опубликовала описание новой техники защиты в своём блоге, посвящённом ИТ-безопасности. Этот способ получил название Retpoline, он требовал перекомпиляции ПО с заменой уязвимых последовательностей машинного кода, но не оказывал серьёзного влияния на производительность системы.

Изначально Retpoline разрабатывалась для архитектур x86, однако с тех пор многое изменилось — хотя x86 всё ещё является доминирующей серверной архитектурой, но популярность серверов на базе ARM с тех пор серьёзно выросла. Google оценивает возможность переноса этого метода на процессоры ARM, но имеются и опасения.

Дело в том, что ряд платформ AArch64 (ARM 64 бит) не имеют поддержки со стороны firmware для защиты от Spectre V2 (на основе неверного предсказания косвенных переходов). Подозревается, что данный метод может позволить атаку на цели косвенного ветвления (targets of indirect branches) со стороны кода, находящегося в пользовательском пространстве (userspace code). В настоящее время в рамках инициативы Safeside специалисты Google исследуют возможность использования предикторов стека возврата (return stack predictors) в процессорах ARM64 для реализации защиты от Spectre V2 даже в том случае, если сам производитель платформы не озаботился выпуском соответствующего патча для микрокода процессора.

Исследователи будут рады проявлению интереса и откликам по поводу подобной техники защиты; особенную ценность представляют отклики сообщества разработчиков компилятора LLVM. У Safeside существует свой репозиторий на GitHub.

После появления информации об уязвимостях Spectre и Meltdown в Linux изменили технологию обновления микрокода CPU с параллельной на последовательную. Однако это привело к увеличению накладных расходов. И вот вышел новый патч, который возвращает параллельную обработку, что может быть полезно для серверов с большим числом ядер.

Инженер Oracle вернул механизм, который позволяет обновлять микрокод сразу на нескольких ядрах процессора, а не только на одном. Судя по описанию, сейчас обновление выполняется для каждого ядра по отдельности, в то время как другие ждут своей очереди.

pixabay.com

Предполагается, что патч может появиться уже в ядре Linux 5.4, хотя пока официального заявления на этот счёт не было. Обновление будет крайне полезно для облачных провайдеров, которые недовольны долгим процессом апдейта микрокода и связанным с ним простоем. 

Напомним, что Spectre и Meltdown проблемы процессоров не ограничиваются. Недавно была выявлена уязвимость, которая обходит защиту от этих брешей. Компания Bitdefender нашла новые способы атаки, позволявшие читать данные из кеша процессора. Это могут быть пароли и прочие критически важные данные. И снова «виновником» стал механизм спекулятивного исполнения.

По данным специалистов, атаку можно провести с использованием стандартной инструкции SWAPGS в архитектуре x86-64, которая используется в «синих» процессорах с 2011 года. Представители чипмейкера уже заявили, что такие же бреши есть в процессорах ARM и AMD, но, по данным Red Hat, под угрозой только «красные» и «синие» чипы.

3 января 2018 года мировая общественность узнала о возможности атак Meltdown и Spectre, обусловленных архитектурными особенностями современных процессоров. Это произошло примерно на неделю раньше запланированного срока из-за утечек. Мы много писали об этом, а потому повторяться не будем — достаточно сказать, что уязвимости являются самыми большими из вскрытых в последнее десятилетие и требуют полного переосмысления микропроцессорных архитектур, а также принципов взаимодействия ПО и CPU.

Публичные облачные компании вроде Amazon Web Services (AWS) были проинформированы об уязвимостях до обнародования информации и работали над подготовкой системных исправлений, которые предотвратили бы раскрытие информации в облачной инфраструктуре со множеством арендаторов. На данный момент нет универсального исправления для Spectre, поэтому большинство смягчающих мер на сегодняшний день прежде всего нацелены против более лёгкой для использования злоумышленниками уязвимости Meltdown.

Недавно в своём блоге SolarWinds решила поделиться опытом использования инфраструктуры AWS в течение последних недель в связи с Meltdown. Компания, как и многие другие в секторе SaaS (ПО как услуга), пострадала от частичного простоя, вызванного усилиями AWS по борьбе с Meltdown. Первым признаком предстоящих проблем стали полученные в середине декабря email-сообщения о необходимости перезагрузки всех паравиртуализированных (PV) хостов до 5 января. SolarWinds в основном работает с HMV-системами, но для поддержки устаревших платформ используют и несколько PV. Как видно из приведённой диаграммы, взятой из сервисного звена серверов Python, когда 20 декабря были перезагружены PV-системы, результатом стал рост нагрузки CPU на внушительные 25% — были и другие сообщения о схожих проблемах, связанных с производительностью или стабильностью работы серверов после их перезагрузки накануне 5 января:

Для HVM-серверов AWS смогла выпустить заплатку против Meltdown, не требующую перезагрузки. Судя по всему, для серверов HVM EC2 они начали развёртываться около 4 января 00:00 UTC по времени восточного побережья США и закончили в 20:00 UTC. Это очень быстро — очевидно, Amazon форсировала процесс из-за преждевременной утечки информации. Подобный рост нагрузки процессоров был замечен на нескольких сервисных звеньях:

В этот же период было зарегистрировано дополнительное увеличение нагрузки CPU на PV-серверах, которые уже были обновлены. По-видимому, они тоже получали какие HVM-исправления примерно в то же время, как и все полноценные HVM:

С точки зрения производительности, затронуты обновлением были почти все уровни платформы — как инфраструктура EC2, так и управляемые службы AWS (RDS, Elasticache, VPN Gateway). Например, SolarWinds активно использует Kafka для обработки потоков в Solarwinds Cloud. Рост нагрузки на CPU во время развёртывания обновления оказался умеренным, около 4 %:

Но в то же время частота обмена пакетами в том же кластере Kafka, снизилась на значение до 40 %. Пропускная способность при этом не уменьшилась, так что, по мнению SolarWinds, время отклика отдельных пользователей увеличилось, что привело к увеличению размеров пакетов данных и уменьшению количества небольших пакетов:

Звенья СУБД Cassandra, которые SolarWinds использует для хранения данных, тоже были затронуты по всем направлениям. Наблюдались всплески нагрузки CPU примерно на 25 % на экземплярах вроде m4.2xlarge и других типов. Даже если мощностей достаточно, это заставляет задуматься о расширении, чтобы компенсировать потенциальный рост нагрузки.

Влияние на производительность также наблюдалось и для внутренних звеньев SolarWinds. Например, задержки p99, связанные с записью в Cassandra, возрастали на значение до 45 %.

Также были обнаружены скачки в задержках в управляемых службах AWS, таких как AWS Elasticache Memcached. Например, на приведённом memcached-кластере при средней нагрузке на CPU в 8 % рост оказался почти двукратным:

Это привело к весьма существенному удлинению хвоста задержек (Tail latency) и таймаутов кеша, то есть для некоторых пользователей ожидание отклика возросло многократно:

Как видно из диаграмм, новый базовый уровень производительности систем существенно изменился после исправлений для борьбы с Meltdown. Заплатки KPTI необходимы для поддержки изоляции памяти, чтобы предотвратить использование уязвимостей в публичной облачной инфраструктуре, сдаваемой множеству арендаторов. Разработчикам ПО необходимо будет понять, как можно снизить возросшие накладные расходы ресурсов CPU от переключений между пользовательским адресным пространством и ядром, которые добавляют KPTI-исправления.

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

Для оптимизации программистам потребуется доступ в реальном времени к точным и подробным измерениям, которые способны показать частоту системных вызовов, генерируемых их приложениями или базами данных. Активное отслеживание системных вызовов станет необходимостью.

Также неясно, к чему приведёт появление новых заплаток против Meltdown и Spectre, — можно лишь предположить, что они будут продолжать влиять на производительность любой масштабной бизнес-инфраструктуры. Придётся адаптировать принципы разработки программного обеспечения для распределённых систем, чтобы приспособиться к меняющимся условиям. Стоит добавить, что на общую производительность также повлияют исправления для клиентских систем. Впрочем, по состоянию на 12 января SolarWinds заметила существенное снижение CPU-нагрузки своих систем. Неясно, стало ли это следствием развёртывания дополнительных заплаток или были иные причины, однако уровни нагрузки процессоров возвращаются к уровням до появления HVM-исправлений.