Перевод мнения Джо Фитца относительно январских уязвимостей процессоров
Итак, новая тема! Почему 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%, в зависимости от задач и кода программы. На Хабре можно почитать и про другие проблемы патчей.