Как Red Hat борется с Spectre и Meltdown
Оцените эту статью

Eсли вы хотя бы поверхност­но следите за технически­ми новинками, то, конечно, слышали о Spectre и Meltdown (http://www.datacenterknowledge.com/security/intel-microsoft-dcal- widespread-chip-security-vulnerability), двух уязвимостях, не похожих на все известные прежде, поскольку это аппаратные, а не программные изъяны в системе безопасности. Кроме того, они заслуживают внимания, поскольку присутствуют почти в каждом процессоре, изготовленном за несколько прошедших десятилетий.

Устранение уязвимости в ОС Linux, обращайтесь [email protected]

У многих пользователей, возможно, создалось впечатление, что Spectre относится к процессорам Intel, AMD и ARM, a Meltdown затрагивает только продукцию Intel или все процессоры Intel и некоторые микросхемы ARM. Это не так, как разъяснил нам Джон Мастерс из компании Red Hat. Обе уязвимости свойственны всем архитектура без исключения. «Полагаю, на долю Intel пришлось нео­правданно много внимания,— поясняет Мастерс на сайте Data Center Knowledge.— Проблема затрагивает не только Intel, AMD и ARM, но и любую современную архитектуру».

Мастерсу это должно быть известно не понаслышке. Хотя его основная должность— главный архитектор ARM в компании Red Hat, он стал одним из тех специалистов, которые возглавили усилия по борьбе с Meltdown и Spectre.

Вопрос об Intel возник, когда Мастерс рассказывал о влиянии мер для противодействия Meltdown на производительность в компани­ях, имеющих большое число серве­ров. В некоторых статьях в прессе указывалось, что после применения исправлений производительность серверов может снизиться до 30%. Специалисты Red Hat считают, что потери составят до 20%.

«Наши обновления изначально следуют в русле политики без­опасности Red Hat,— подчеркнул Мастерс.— Мы всегда будем делать их максимально надежными, поэ­тому, устанавливая обновления, клиенты наверняка столкнуться со снижением производительности. Однако они могут провести анализ рисков и решить, до какой степени нуждаются в полной безопас­ности. Например, в закрытой лабо­раторной среде, для высокопроизво­дительных вычислений и т. д., когда существует очень высокая степень контроля, можно будет обойтись без защитных мер. В таких условиях можно отключить их и вернуть 99% производительности».

Потери производительности при полной защите зависят в первую очередь от рабочей нагрузки ком­пьютера.

«На наших тестах было очень мало нагрузок порядка 18-20%,— пояс­няет Мастерс.— Большинство рабочих нагрузок находятся в диа­пазоне от 5 до 10%, в зависимости от поставщика и поколения про­цессора».

Основное внимание было обращено на Meltdown, так как этой уязвимо­стью проще воспользоваться благо­даря наличию в свободном доступе программного кода, доказывающе­го правильность концепции.

«Я действительно полагаю, что в долгосрочной перспективе уязвимость не так важна, как сейчас о ней говорят,— заявил Мастерс.— Да, это опасная угроза. Нет сомнений, что ее нужно устранить как можно скорее. При этом атака чрезвычайно сложная. Уязвимость потенци­ально существует уже несколько десятилетий в различных семействах процессоров. Атака такого класса теоретически возможна, но, чтобы отыскать слабое место, потребовалось много усилий. Воспроизвести атаку очень трудно. Вряд ли многим удалось найти способ сделать это самостоятель­но, прежде чем способ стал обще­известен, а устранить угрозу срав­нительно нетрудно».

Ошибка Spectre на самом деле пред­ставляет собой две связанные уяз­вимости и также стала причиной опасений, когда на нескольких новостных сайтах появились сообщения о том, что устранить изъян безопасности невозможно. Однако это не совсем верно, как утверждает Мастерс, хотя устранить угрозу нс так просто, как в случае с Meltdown.

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

Однако это не особенно беспокоит Мастерса, поскольку атака через Spectre практически невозможна.

«Исследователи Google утверждают, что однажды им удалась атака против одной модели процессора с определенной версией операци­онной системы,— рассказа! он.— На подготовку атаки ушло нескольких часов. Осуществить ее было очень трудно, а скорость извлечения данных в итоге составила полтора килобайта в секунду. Этого достаточно, чтобы вызвать серьезные опасения, поскольку таким образом можно извлечь ключ безопасности, но задача очень трудная и, настолько мне известно, вне лабораторий таких атак не предпринималось». Поскольку проблема аппаратная по сути, меры для ее решения в современных процессорах напоминают долгосрочное применение лейкопластыря. В конечном итоге уязвимость должна быть устранена поставщиками в процессорах следующих поколений. К счастью, это возможно, хотя для окончательного решения потребуются и некоторые изменения в программном обеспечении.

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

Для Spectre потребуются некоторые изменения в программном обеспечении, и, возможно, поэтому в некоторых сообщениях уязвимость называют неустранимой. «Первый компонент Spectre легко устранить программным способом, который, в сущности, не приводит к снижению производительности,— объясняет Мастерс.— Но его очень трудно устранить аппаратно. Скорее, всего, нам придется жить с первым компонентом Spectre долгие годы. Чтобы автоматически устранять уязвимость, потребуется изменить пакеты инструментальных средств, компиляторы и т.д. Пока же мы используем средства сканирования, которые проектировались для поиска уязвимость, и вставляем небольшие фрагменты кода в ядро, чтобы предотвратить проблему»