В течение апреля и мая 2017 года компания Intel обновила документацию к процессорам Skylake и Kaby Lake, добавив одно небольшое примечание (errata KBL095, KBW095 для Kaby Lake, errata SKW144, SKL150, SKX150, SKZ7 для Skylake). Оно звучит следующим образом:
«В сложных микроархитектурных условиях краткие циклы менее чем из 64 инструкций с использованием регистров AH, BH, CH или DH, а также соответствующих более широких регистров (например, RAX, EAX или AX для AH) могут вызвать непредсказуемое поведение системы. Такое может произойти только если активны оба логических процессора на одном физическом процессоре».
Что означает это примечание — 25 июня 2017 года подробно объяснили в почтовом списке рассылки разработчиков Debian. Если вкратце, то процессоры Skylake и Kaby Lake с включенным HyperThreading могут вести себя неадекватно. Разработчики рекомендуют немедленно отключить HyperThreading в BIOS/UEFI, а потом обновить микрокод процессора от Intel или дождаться обновления BIOS/UEFI от своего вендора.
Ошибка затронула процессоры Intel Core 6-го и 7-го поколений, в том числе десктопные, встроенные, мобильные и HEDT, соответствующие версии серверных процессоров (такие как Xeon v5 и Xeon v6), а также некоторые модели процессоров Intel Pentium. Самый ранний процессор с наличием этого бага вышел в сентябре 2015 года. Если ваш процессор выпущен раньше этого времени или он не принадлежит к семействам Skylake и Kaby Lake, то данное предупреждение можно игнорировать.
> Список всех процессоров Skylake
> Список всех процессоров Kaby Lake
Некоторые процессоры из списка не подвержены ошибке, потому что не поддерживают HyperThreading
Баг действительно неприятный. «Непредсказуемое поведение системы» может проявиться в непроизвольных ошибках приложений и системных ошибках, повреждении данных и потере данных.
Предупреждение опубликовано в списке рассылки Debian, потому что проблема уже затронула нескольких пользователей стабильной ветки Debian. В то же время аналогичные неприятности могут возникнуть у пользователей на любой операционной системе, не только Debian и не только Linux.
Чтобы избежать проблемы, необходимо или отключить HyperThreading, как уже упоминалось, или установить официальный фикс. Компания Intel задокументировала описание бага в документации для Core 6-го поколения, Core 7-го поколения, Xeon v5 и v6, а также X series Core 6-го поколения.
В списке рассылки для пользователей Debian владельцам процессоров Kaby Lake рекомендуется связаться с производителями материнской платы и запросить обновление BIOS/UEFI, а до того момента отключить HyperThreading.
Для владельцев процессоров Skylake, в зависимости от модели, может быть доступен пакет
intel-microcode. В списке рассылки Debian объясняется, кто может установить этот пакет с номером версии 3.20170511.1 на операционных системах Debian GNU/Linux 9 «Stretch» и Debian GNU/Linux 8 «Jessie». Сначала нужно узнать номер модели и степпинг своего процессора. Пакет с микрокодом подходит только для процессоров модели 78 или 94, со степпингом 3, то есть для процессоров с подписями 0x406E3 и 0x506E3. Чтобы узнать характеристики, следует запустить из терминала следующую команду: grep -E 'model|stepping' /proc/cpuinfo | sort -u Если процессор соответствует указанным условиям, то можете обновить микрокод, следуя инструкциям из вики Debian.
В ином случае совет такой же: отключить HyperThreading и дожидаться обновления BIOS/UEFI.
Intel выпустила также микрокод Kaby Lake, который исправляет баг, но он доступен только для производителей оборудования, поэтому следует дожидаться обновления BIOS/UEFI, чтобы получить этот код. Разработчики Debian отмечают, что Intel внесла изменения в микрокод в начале апреля 2017 года. Поэтому есть вероятность, что микрокод для Kaby Lake с номером ревизии 0x5d/0x5e (и более поздний) *может* исправить проблему, но это только предположение.
Из-за непредсказуемой природы бага сложно проверить, какая программа может его вызвать, а какая нет, и при каких условиях он может проявиться. Поэтому отключить HyperThreading на всякий случай рекомендуется всем. Разработчикам Debian о баге сообщил Марк Шинвелл (Mark Shinwell), один из создателей набора инструментов Ocaml. Он сказал, что компилятор OCaml легко вызывает этот баг. Разработчики Ocaml внимательно исследовали проблему с января 2017 года, а первые глюки были замечены ещё во II кв. 2016 года, никто не мог понять, что происходит и в чём причина. Компилятор и приложение аварийно завершались со сбоем, программа вела себя некорректно, в том числе выдавала некорректную выдачу. Только теперь, когда Intel начала обновлять документацию к процессорам, ситуация прояснилась. Важно отметить, что код, который приводит к проявлению бага в процессоре, присутствовал в gcc-сгенерированном коде.
Комментарии (28)
EvgenT
26.06.2017 19:12+3Во как. По началу я связывал вылеты gcc и зависания системы, при компиляции Android прошивок, с перегревом. Хотя, все датчики показывали не совсем уж критическую температуру. Затем, при очередном обновлении UEFI, забыл включить HT и проблема исчезла. Через какое-то время заметил выключенный HT и включил его. Проблемы вылезли, но не сразу, поэтому и не связал это с HT. Теперь всё стало понятно…
Googlist
26.06.2017 22:40+2Желание апгрейдить і5 на і7 сильно уменьшилось.
dartraiden
06.07.2017 16:43Проблема, на самом деле, очень специфическая, шансов столкнуться с ней немного. Говорю, как обладатель инженерной версии Skylake, для которой свежего микрокода нет (и не будет).
Вдобавок, ходят слухи, что следующие мейнстримовые i7 будут 6-ядерными (i5 станут тем, чем сейчас являются i7, а i3 получат 4 полноценных ядра), поэтому лучше подождать до осени, там видно будет.
danfe
27.06.2017 08:49Интел продолжает «радовать»: RdRand, SYSRET, теперь это. На этом фоне AMD выглядит всё более привлекательно…
zikasak
27.06.2017 10:37как будто в амд нет багов...
danfe
27.06.2017 13:01Да есть, наверное; но почему-то баги Интел на слуху, а баги AMD мне пришлось гуглить (коих оказалось меньше и не таких серьезных).
willyd
27.06.2017 13:57А еще Linux неуязвим для вирусов.
Популярность Intel и AMD — 4 к одному (в серверном сегменте еще больше, скорее всего). Логично подумать, что и подобных багов обнаруживаться будет больше у Intel. Тем более, что проверить такой баг довольно тяжело и многие его списывают на программную ошибку, к примеру
romovs
27.06.2017 19:32+2Спешу вас огорчить. В любом процессоре есть errata длиною в километр.
Как пример,
https://community.amd.com/thread/215773
tl;dr Segmentation Fault при компилляции на процессорах Ryzen. Пока ничего не понятно почему это происходит, но сага длится несколько месяцев уже.
Помимо этого есть немалого других проблем уже подтвержденных AMD.
Интел просто популярней поэтому чаще слышно о его проблемах в новостях.
anmi
27.06.2017 11:39i7 6770hq, были баги с зависаниями, мерцанием экрана в некоторых играх и просто спонтанные ошибки. После отключения по крайней мере быстровоспроизводимые баги исчезли.
roboq6
27.06.2017 12:18Интересно, скоро ли мы дойдём до такой точки в развитии процессоров, что мы просто НЕ сможем совершенствовать их путём всё большего усложнения архитектуры и производственного процесса (ибо у нас будет будет вылезать слишком много ошибок и брака)?
anmi
27.06.2017 12:40+1Почти все процессоры, кроме самих дорогих уже являются продуктом отбраковки. Intel производит только три процессора: Atom, Core, Xeon. Вся вариация линейки это процессоры которые по тем или иным причинам не прошли тесты на какие-то фичи. Тут главное грамотно выявлять ошибки и иметь возможность их достаточно хорошо изолировано отключать, создавая младшие модели процессоров.
romovs
27.06.2017 19:38Была статья, по-моему, на eetimes с интервью главных экспертов. Таки да, на текущих технологиях примерно года через три-четыре это наступит, если я правильно помню. Но с другой стороны начнётся использование других материалов, производственных процессов, и еще много чего (например наблюдается тенденция возращения к "вертикальным" компаниям, то-есть производящих все начиная от процессоров до программного обеспечения. Квантовые компьютеры также многообещающая отрасль). Возможно будет огромный скачок в середине 20-ых годов.
CodeRush
Непонятно, зачем называть ошибку (да еще и уже исправленную обновлением микрокода) «критической уязвимостью»?
Уязвимостью этот баг станет только тогда, когда с его помощью научатся обходить какие-то защитные механизмы процессора\прошивки\ОС, а пока это просто баг, один из многих, в прошлый раз так пришлось TSX на Haswell отключить.
CodeRush
Советую также посмотреть презентацию с 32c3 (видео, слайды) — When hardware must «just work», там очень хорошо пояснено, почему баги в процессорах до сих пор регулярно находятся, и почему сделать процессор без единого бага — практически нереально.
Alexsandr_SE
Как я понял ошибка не исправлена. Интел недавно только предоставил код для разработчиков МП, а когда они выпустят новый биос и выпустят ли вообще никто не в курсе.
Black_Shadow
Кто мешает обновлять микрокод самостоятельно?
Taciturn
Цифровая подпись BIOS'а, например.
Black_Shadow
Что? А при чём здесь BIOS?
Taciturn
В подавляющем большинстве случаев микрокод загружается именно оттуда.
Black_Shadow
Правда что ли? И как же тогда так получилось, что у меня прошлогодняя прошивка в матери
# dmidecode | grep Release\ Date
Release Date: 09/19/2016
Но при этом свежий микрокод?
# grep microcode /proc/cpuinfo | head -n1
microcode : 0xba
Может быть, обновлять микрокод умеет не только BIOS?
# dmesg | head -n1
[ 0.000000] microcode: microcode updated early to revision 0xba, date = 2017-04-09
dartraiden
В подавляющем большинстве случаев свежий микрокод загружается операционной системой, потому что BIOS либо древний, либо производитель мат. платы уже забил на обновления.
Таким образом, микрокод подгружается 2 раза: сначала более старый из BIOS, потом свежий из ОС.
Поэтому, пользователи получат микрокод как только обновят соответствующий пакет в Linux/прилетит обновление в Windows.
Вдобавок, есть даже отдельный драйвер производства компании VMWare, который создан специально для загрузки файла, содержащего микрокод (а сам файл с микрокодом свободно доступен на сайте Intel).
dartraiden
Это можно обойти. Например, у ASUS из подписанного CAP-файла (UEFI Capsule) легко извлечь непосредственно образ прошивки, в котором самостоятельно заменить микрокод (через MMTool) и прошить получившуюся прошивку из операционной системы с помощью Intel Flash Programming Tool.
a5b
Микрокод для Kaby Lake с исправлением не был публично доступен, выложили только для Skylake — по данным письма от 25 числа — https://lwn.net/Articles/726496/ "[WARNING] Intel Skylake/Kaby Lake processors: broken hyper-threading" — Henrique de Moraes Holschuh, 25 Jun 2017:
В частности, дебиан собирает пакет микрокодов из https://downloadcenter.intel.com/search?keyword=linux+microcode, где сейчас самый свежий
Linux* Processor Microcode Data File; The microcode data file contains the latest Linux* microcode definitions for all Intel® Processors. Intel periodically releases these microcode updates.; Version 20170511; Date 11/4/2016.
Black_Shadow
Однако, он будет опубликован. И обновить его можно будет вне зависимости от желания производителя материнской платы выпускать новую версию прошивки.
KivApple
Как использовать эту ошибку? Да легко. Ищем хостера с серверами на базе соответствующих процессоров, покупаем у него самую дешёвую VPS, запускаем код, триггерящий уязвимость с очень высокой вероятностью, получаем DoS чужих VPS-ок, запущенных на этом же физическом хосте. Отсутствие публичного эксплойта никак не умаляет опасность уязвимости. Это именно что обход защитных механизмов процессора и ОС — код с минимальными привилегиями может вызвать сбои (пусть и случайные — для DoS этого достаточно) в других приложениях. Когда защитные механизмы процессора и ОС работают корректно такая ситуация невозможна.
Что касается исправления — пока официально доступно исправление только для Skylake. К тому же нередко информация о критических уязвимостях публикуется после официального выкатывания исправлений — чтобы юзеры побежали обновляться, потому что просто так обновляют микрокод далеко не все.