Как запустить легендарный баг FOOF на процессоре Pentium

27 Мар в 12:05 Прокомментировать Просмотры: 24

Приветствую всех любителей ретро-железа и компьютерной истории!

Когда заходит речь о печально известных дефектах в архитектуре Intel Pentium, большинство сразу вспоминает ошибку деления с плавающей запятой (FDIV). Однако это было далеко не единственное слабое место легендарных чипов.

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

❯ В чем суть?

Многие наверняка помнят громкие заголовки о том, что процессоры Intel допускают погрешности в вычислениях.

Тот случай с делением стал хрестоматийным и теперь фигурирует в каждом списке «самых разрушительных программных и аппаратных ошибок в истории ИТ».

Но дефект FDIV был не единственным скелетом в шкафу Intel. Менее медийный, но крайне эффективный способ вывести систему из строя получил название F0 0F. О нем мы сегодня и поговорим.

❯ Что это за феномен?

Погрузимся в технические детали. Процессоры линейки Pentium (на базе архитектуры P5) содержали аппаратный изъян: попытка выполнить определенную некорректную инструкцию вместо стандартной обработки исключения приводила к тому, что CPU впадал в ступор до полной перезагрузки. В классическом виде эта команда выглядела так:

lock cmpxchg8b eax

Данная инструкция предназначена для сравнения 8-байтовых значений. При обычном использовании она бы просто вызвала ошибку доступа, но в комбинации с префиксом lock процессор намертво блокировал шину памяти в ожидании цикла записи, который никогда не наступал. Результат — полная потеря отзывчивости процессора на любые внешние раздражители, включая прерывания. Байт-код этой «команды смерти» — F0 0F C7 C8 — и дал название уязвимости.

Хотя физического вреда компонентам это не наносило, для восстановления работы требовался Hard Reset. Проблема усугублялась тем, что для исполнения этих байт не требовались права администратора — любая пользовательская программа могла парализовать сервер или рабочую станцию, уничтожив несохраненные данные.

Со временем решение было найдено. Сначала на уровне ОС появились программные «заплатки», блокирующие выполнение подозрительного кода, а позже, начиная со степпинга B2, баг был исправлен на уровне кремния. Известно, что дефектные процессоры подлежали замене, хотя этот процесс не был столь масштабным, как в ситуации с FDIV.

❯ Подготовка стенда

Перейдем к практической части эксперимента.

Для тестов я задействовал компьютер, который уже мелькал в моих прошлых материалах.

Под радиатором скрывается тот самый «камень», подверженный аппаратной ошибке.

Вот аналогичный экземпляр. Все сказанное ниже в полной мере относится и к нему.

Проверка по коду sSpec подтверждает: перед нами процессор степпинга B1.

❯ Установка инструментов

Для создания тестового исполняемого файла я выбрал Microsoft Visual C++ 5.00. Запускаем систему под управлением Windows 98 и приступаем к инсталляции.

Более новые (6.0) или совсем ранние версии капризничали: то требовали фантомный «Disk 1», то оригинальный CD в приводе. Видимо, образы были не самыми удачными. Пятая версия же встала без лишних вопросов.

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

Спустя четверть часа среда разработки готова.

Проверяем работоспособность на простом проекте.

Все компилируется и запускается. Время для главного теста.

❯ Исполнение приговора

Пишем минималистичный код, содержащий нашу последовательность байт:

#include 

char main[] = {0xF0, 0x0F, 0xC7, 0xC8};

Компилируем проект в EXE.

Наступает момент истины.

Запуск. На мгновение появляется консольное окно, курсор замирает, и система превращается в «кирпич».

Полный паралич: даже Caps Lock на клавиатуре не переключается. Помогает только физическая кнопка сброса на корпусе.

❯ Поведение на альтернативных ОС

Посмотрим, как справляются другие системы. Попробуем загрузить Windows 2000.

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

На современном железе результат предсказуем: консоль открывается и тут же закрывается без каких-либо последствий для ОС.

❯ Итоги

История с F0 0F наглядно показывает, как быстро ИТ-индустрия реагирует на критические угрозы. Патч для ядра Linux был готов уже через неделю после обнаружения бага. Microsoft выпустила исправление в рамках обновления KB163852. Сегодняшний тест подтвердил, что программные заслоны в более поздних ОС надежно защищают от этого аппаратного изъяна.

Интересно, что позже название F0 0F стало нарицательным для подобных зависаний — аналогичные проблемы находили, например, в чипах Cyrix.