Meltdown

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

Извлечением разведывательных данных из открытых каналов шпионы занимались давно. С 2022 очень многие умеют сопоставлять снимки местности с гуглокартами (я не умею). И потому считается, что любое военное фото и видео лучше выкладывать несколько дней спустя, когда извлечённая информация будет неактуальной. И именно это — утечка данных через открытый канал — случилось почти со всеми x86. К Meltdown были уязвимы все Intel начиная с Core, к Spectre — вообще все.

Вкратце о виртуальной памяти. Появилась на процессоре 80386 (1985), даёт каждой программе подобие выделенного процессора с 4 гигабайтами памяти (если процессор 32-битный). Таблицы преобразования из виртуальных адресов памяти (доступных программисту) в физические (какая ячейка ОЗУ) находятся всё в том же медленном ОЗУ.

Программе иногда приходится обращаться к функциям ОС — например, чтобы получить имя текущего пользователя. Эта функция обязана обращаться и к системной памяти (там находится имя), и к пользовательской (чтобы скопировать имя туда). Решено это так: часть системной памяти внесена в виртуальную память программы, но доступ к ней разрешён только из системных функций. Именно эту память, которую «видит око, да зуб неймёт», читает Meltdown. Отсюда название — эта уязвимость «плавит» границы памяти.

Закон дырявых абстракций

Чтобы прочитать эту память, нужны определённые технологии процессора.

• Чтобы поменьше обращаться к медленному ОЗУ, у процессора есть быстрая маленькая кэш-память. У современных процессоров есть три уровня кэш-памяти, нас интересует кэш 1-го уровня (ближайший к процессору, несколько килобайт объёмом, работает не с физическими адресами памяти, а с виртуальными).

• Процессор умеет выполнять операции наперёд. Но в любой программе есть команды ветвления — скажем, «если D<0, то уравнение решения не имеет, иначе корни такие-то». Все современные x86 ещё до того, как вычислят D, пробуют пройти по одной из веток (а то и по обеим).

• При этом процессор не знает наперёд, имеет ли он право выполнять эту операцию: для этого надо заглядывать в таблицы преобразования, а они если не в оперативной памяти, то в особом кэше преобразования адресов, который сидит между 1-м и 2-м уровнями. Так что просто выполняет — а потом уже разбирает, имеет ли он право это делать.

• Для высокоточного отсчёта времени (для мультимедиа, игр и прочего) в процессоре есть счётчик тактов.

Джоэль Спольский придумал так называемый «закон дырявых абстракций». Звучит он примерно так:

Если за простым фасадом сложная технология, тонкости этой технологии будут вылезать наружу.

Вот пример из автомобилей: чтобы машина с ДВС умела стоять, а также ездить на разных скоростях в разных режимах мотора, к двигателю приделана коробка передач. Переключать её — дело неблагодарное, и в околовоенные годы придумали автоматическую коробку. Удобно — нажал-поехал — но то, что за всем этим старые добрые мотор и коробка, вылезает сплошь и рядом.

Дисклеймер: я о традиционной коробке типа «гидроавтомат» без электронных помощников. Да простят меня обладатели вариаторов и роботов.

• ДВС не умеет стоять: коленвал остановился — двигатель заглох. А поскольку в автомате вместо сцепления две турбины, автоматическая машина всегда ползёт, если недостаточно сильно давить на тормоз.

• Чем выше оказалась случайно стрелка тахометра в момент T, тем лучше тянет машина, если резко нажать газ.

• А если нужно разогнаться максимально резко — дай коробке время переключиться, чтобы тахометр ушёл в 4000+ об/мин.

• Ну и целая куча тонкостей в сложных и экстремальных режимах езды.

Как работает Meltdown

Есть очень длинный массив, больше, чем кэш-память. Скажем, на 1001 позицию — от 0 до 1000. Программа будет такая.

Сбросить кэш-память

Если некое условие (гарантированно не выполняющееся)

……Считать число из запретного адреса

……Извлечь из числа один бит (то есть 0 или 1)

……Загрузить из массива элемент № (бит·1000) — то есть № 0 или № 1000

Иначе

……Загрузить из массива элемент № 0, измерить время доступа

……Загрузить из массива элемент № 1000, измерить время доступа

Условие гарантированно не выполняется, но надо заставить процессор пройти наперёд именно по первой ветке — и он выполняет её наперёд, не зная, что адрес запретный. Заодно перекидывая элемент № 0 или № 1000 в кэш. Массив длинный, оба сразу в кэш не попадут.

Если из запретного адреса считан 0, доступ к элементу № 0 будет быстрым (он в кэше), а к элементу № 1000 — медленный. И наоборот.

И так бит за битом читают запретную память.

Spectre

Сбросить кэш-память

Если некое условие (гарантированно не выполняющееся, с доступом к ОЗУ)

……Считать число из адреса, совпадающего с виртуальным адресом жертвы

……Извлечь из числа один бит (то есть 0 или 1)

……Загрузить из массива элемент № (бит·1000) — то есть № 0 или № 1000

Иначе

……Загрузить из массива элемент № 0, измерить время доступа

……Загрузить из массива элемент № 1000, измерить время доступа

Самый известный вариант Spectre очень похож на Meltdown, и главная разница такова: а) мы хотим получить доступ к памяти другой (атакуемой) программы, и мы знаем желаемый адрес в её виртуальной памяти; б) атакуемая программа постоянно имеет дело с этим адресом — и потому секретный байт в кэше (напоминаю, кэш 1-го уровня имеет дело с виртуальными адресами); в) «некое условие» вычисляется по формулам, требующим доступа к ОЗУ; г) запретный адрес тоже вычисляется по формулам, но более простым и быстрым.

Следите за руками. Не видя способа быстро рассчитать условие, процессор начинает наперёд крутить ветку «то». Вычисляет адрес, считывает из него число, а пока оно ползёт из ОЗУ, пробует прокрутить следующие шаги с тем числом, что завалялось в кэше . Число из ОЗУ не успеет прийти («если некое условие» будет вычислено раньше), но эти шаги, опять-таки, приведут к тому, что либо № 0, либо № 1000 будет закэширован и доступ к одному будет быстрый, а к другому — нет.

Название Spectre («призрак») происходит из-за крайней сложности ошибки (уязвимы почти все x86, программно не закрывается, и ожидалось, что она ещё некоторое время будет преследовать) и технологии «выполнение наперёд» (speculative execution).

К чему это привело

Разработчики ОС экстренно закрыли Meltdown так. Сделали две таблицы преобразования адресов: одну сокращённую для программы, другую полную для системных функций. Это несколько замедлило систему, но закрыло уязвимость. В дальнейшем её закрыли на уровне процессоров и забыли.

Разработчики браузеров внесли свою лепту — дело в том, что в современном браузере JavaScript частично компилируется в машинный код! И они подкорректировали компиляцию так, чтобы шансы на удачную эксплуатацию были минимальны.

Больше всего напряглись провайдеры виртуальных машин и контейнерных служб (Microsoft Azure и прочие) — они-то и напрягли производителей процессоров. И виртуальная машина, и контейнер позволяют запускать любой машинный код в изолированной среде (например, чтобы сделать нестандартный или высоконагруженный сервер), но в виртуальной машине ядро ОС отдельное, а в контейнере — общее на все контейнеры.

Spectre в 2018 начали понемногу прикрывать на уровне процессора. В 2021 году появилась информация о новой версии Spectre, к которой якобы уязвимы даже те процессоры, что закрыли в 2018.

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

Перевод мнения Джо Фитца относительно январских уязвимостей процессоров

Итак, новая тема! Почему Intel не могут просто быстренько пропатчить уязвимости Meltdown и Spectre, выпустив новую линейку процессоров? Почему процесс может растянуться на годы? Разве они не практикуют agile-методы разработки (если простым языком - постоянное тестирование, параллельная работа групп инженеров и т.п., с возможностью отката проблемных изменений за минимальное время) или методы x/y/z? На самом деле, причин множество:

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

Для начала разберем создание программной начинки процессоров. Первое - каждый раз, когда ты кликаешь "build" ("собрать проект" в программе разработки ), ты создаешь очередной степ, который обходится в миллионы долларов и несколько месяцев тестирования. Чтобы новый продукт оставался финансово выгодным, проект следует собирать не более 10 раз. (Вот тут можно глянуть перечень существующих степпингов от Intel - их реально мало)

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

Представьте себе ISA (шина ввода-вывода для IBM-PC компьютеров, индустриальный стандарт), которая поддерживает вызовы и прыжки на расстояние не более 8 бит. Можно двигаться вперед-назад не более, чем на 128 байт от текущего адреса. Ты не можешь просто взять и вставить еще 256 байт кода между двумя существующими блоками микропроцессорного кода без массивной переработки существующей архитектуры с соответствующими потерями таймингов (производительности, с точки зрения пользователя).

Что такое "легкий фикс" на уровне чипа? Изменение бита в паре байтов. Добавление операции инверсии проверки, изменение константы в коде, замена "плохой" инструкции на пустую, правка неверной вычислительной ветки, смена порядка if/else инструкций.

Более крупные изменения наверняка отразятся на всём остальном. Из-за увеличения потребляемой энергии может нагреться соседний вентиль, поэтому придется замедлить операцию, что приведет к общей потере скорости в 100 МГц на всех процессорах серии. А увеличение пространства между элементами приведет к увеличению задержек, с которыми вообще ничего поделать нельзя.

Простейший возможный фикс требует пары месяцев на билд схемы, несколько месяцев на тестирование исправления, плюс регрессионные тесты кода, выпущенного за последние 50 лет - новый процессор обязан поддерживать старые программы. Затем - запуск крупносерийного производства. Скажем, 6 месяцев от фикса до появления на полках.

Но на самом деле, малейшее исправление означает билд, тестирование, прогонку (тюнинг), еще билд, еще тестирование, брендинг и выпуск. Исходя из оптимистичных 2-3 степпингов, выпуск переносится уже с 6 месяцев на один год.

А что насчет новых мелких особенностей (которые планировались к реализации в новых сериях)? Если архитектура и спецификация уже готова, то нужно внедрить всё на уровень логики чипа , провести симуляции, подтвердить работоспособность, и снова прогнать через билд/тестирование/выпуск. Итого уже 2 года.

Реальность такова, что новые фичи крайне опасны, если на них отводится мало этапов тестирования. В кремние заложено ОГРОМНОЕ количество возможностей, для которых еще не пришло время - они могут оставаться заблокированными в течение целых поколений, пока инженеры не решат, что новинка безопасна. На практике большинство новых фич проводят около 5 лет в режиме ожидания, а затем еще и ждут софта, который умеет работать с ними.

Но мы еще не закончили! Атаки Meltdown и Spectre затрагивают фундаментальные особенности архитектуры процессоров, на которой те строились десятилетиями. Взгляните на визуализированный жизненный цикл продукции Intel. Пока что всё происходило в желтой фазе "development".

Предполагая, что в исследованиях рынка мы не нуждаемся, мы просто должны изменить архитектуру, написать новые спецификации, внедрить архитектуру на программном уровне, спроектировать чип и запустить конвейер, а также пройти процедуру подтверждения качества перед стартом продаж. И снова речь идет о 4-5 годах работы.

Что же все это значит? Я предполагаю, что уже этим летом мы увидим пару быстрофиксов на уровне железа. Инженеры компаний знали о проблеме уже полгода на момент публикации информации, и 12 месяцев должно хватить на простейшие исправления. Возможно, фиксы повлияют на производительность, но они всё равно должны оказаться быстрее предлагаемых сейчас решений с уровня софта.

В 2019 и 2020 выходят другие продукты, в которые также должны будут внести соответствующие правки, что непременно скажется на производительности. Тем не менее, опять же, они будут быстрее, чем альтернативы с фиксом через ОС.

А тот самый вариант с решением, которое не снизит производительность, я бы не ждал раньше 2021 года.

Я покинул Intel более 5 лет назад и не в курсе их текущих или грядущих продуктов. Всё это - мои личные предположения, основанные на общих знаниях о процессорах и технологии производства чипов.

Примечание: защита от уязвимостей заключается в сбросе кэша после каждого ветвления кода. На практике падение производительности может достигать и 50%, а может колебаться в пределах 5-10%, в зависимости от задач и кода программы. На Хабре можно почитать и про другие проблемы патчей.

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

Айфоны тормозят на 30-40% после обновления, исправляющего уязвимость.

И никак ее не исправить софтовым путем без солидного падения производительности

Совпадение?

В последние годы шла стагнация в настольном сегменте процессоров, да и айфоны старые работают вполне неплохо. И бах - а давайте раскроем один из бэкдоров архитектуры и стимулируем продажи новых поколений без уязвимостей? По моему гениально, смысл апгрейда будет в компенсации потерь мощностей ввиду исправления ошибок.

Обыватель: Все в моем доме соединено в интернет вещей! Я контролирую это все через свой смартфон! Мой умный дом имеет блютус и я могу управлять домом голосом через Алексу! Я обожаю будущее!
Программист/инженер: Самая новая технология у меня - это принтер 2004 года и я держу заряженный пистолет, чтобы пристрелить этот принтер, если он внезапно зашумит.
Специалист по безопасности: *делает большой глоток виски* Я хотел бы родиться в эпоху неолита