Группа немецких ученых из немецкого сообщества hardwaluxx.de обнаружила ошибку в работе процессоров Intel Skylake, приводящую к зависанию компьютера в процессе осуществления сложных вычислений. Позднее математики из проекта добровольных вычислений по поиску простых чисел Мерсенна (GIMPS) подтвердили наличие проблемы. Баг проявился в ходе работ по поиску простых чисел Мерсенна с помощью инструмента Prime95.
Представители Intel также заявили о наличии ошибки:
«Intel обнаружила проблему, которая потенциально может затрагивать продукты Intel Core шестого поколения. Ошибка проявляется только в определенных условиях при осуществлении сложных вычислений при запуске приложений вроде Prime95. В таких случаях процессор может зависнуть».
Компания создала исправление и в настоящий момент работает с партнерами над распространением его с помощью обновления BIOS.
В сообщении компании никак не объясняются причины возникновения проблемы, однако подтверждается тот факт, что ей подвержены как Linux, так и Windows-системы.
Приложение Prime95 традиционно применяется для осуществления стресс-тестов компьютеров — оно использует быстрое преобразование Фурье для умножения очень больших чисел. К примеру, сбой системы был обнаружен при работе с экспонентой степени 14 942 209.
Как считают обнаружившие ошибку ученые, она может проявляться не только в сфере математических вычислений, но и в других отраслях, где требуются сложные вычисления — например, в финансовой индустрии. При этом команда GIMPS отмечает, что их софт работает «супер нормально» на компьютерах железом от Intel прошлых поколений.
Подобные ошибки работы процессоров Intel случались и ранее — так, 19 октября 1994 года баг FDIV был обнаружен в оригинальном процессоре Pentium. Ошибка в модуле операций с плавающей запятой приводила к тому, что при проведении деления над числами с плавающей запятой при помощи команды процессора FDIV результат мог быть некорректным. Эта проблема практически не влияла на работу с компьютером обычных пользователей, однако тот факт, что в Intel знали о ней, но не планировали исправлять как раз из-за небольшого числа потенциально пострадавших пользователей, спровоцировал серьезный скандал. В результате компании пришлось объявить об отзыве дефектных процессоров и их замене на работающие корректно.
Кроме того, не так давно в СМИ обсуждались ошибки аппаратной поддержки транзакционной памяти (Transactional Synchronization Extensions, TSX) процессоров Haswell и Broadwell. В этом случае вместо отзыва неисправных процессоров компания просто отключила TSX-инструкции с помощью микрокода новой прошивки материнской платы.
Комментарии (36)
navion
12.01.2016 16:41+6Prime95 — это лучший тест стабильности процессора и оперативки, ловит баги там где остальные могут работать сутками.
fido_max
12.01.2016 18:42-2Недавно собрал на работе компьютер с Core i7-6700, поставил windows 10, включил в домен и столкнулся с неприятной ситуацией: время на компьютере живет своей жизнью и постоянно слетает на 19 декабря 2015 года (когда устанавливал систему), хотя все остальные компьютеры в домене (в том числе и windows 10) замечательно синхронизируют время с сервера. Может тоже Sky Lake виноват?
dr1v3
12.01.2016 19:30+2Читайте подробно логи системы. Часто бывает, что из-за кривых драйверов сетевая подсистема инициализируется очень поздно и возникают проблемы с AD.
NetBUG
12.01.2016 20:13А если совсем от сети отключить? А если в Setup посмотреть при включении?
Если и есть баг, то в коде UEFI, скорее :)
0xd34df00d
12.01.2016 19:57О, а я-то думал, чего у меня на i7-6700 вычислительный эксперимент себя странно ведёт, а на трёх других железках вполне нормально.
stepik777
12.01.2016 21:17+1Не думаю, что это прямо таки первый баг в процессорах Интела со времён FDIV. У меня i7-3770K, любые игры при использовании встроенной графики полностью вешали систему за несколько минут. Написал об этом на тот же интеловский форум, куда зарепортили и этот баг, там мне чуваки из Интела сказали, что нужно обновить биос. После обновления действительно всё стало работать нормально. О том баге по моему нигде особо не писали, в отличии от этого.
Думаю были и другие подобные баги, но, надо заметить, поддержка у Интела хорошая, на том форуме отвечают их сотрудники, которые реально разбираются в том, о чём пишут, в отличии от многих других компаний, до которых бывает просто невозможно достучаться.j_wayne
12.01.2016 21:57+2Да я бы сказал, далеко не первый… Посмотрите спецификации на процессоры, там длинные списки errata.
spmbt
12.01.2016 22:34+1Возможно, этот баг был связан с периферией процессора, типа конфигурации видеоподсистемы или даже вне его — каналы DMA, а этот — в ядре, что традиционно вызывает большой резонанс.
CodeRush
13.01.2016 02:37+2У всех современных процессоров очень длинные списки Errata, т.к. прцоессоры имеют запредельную сложность, и я не без оснований подозреваю, что современный микропроцессор — вообще самая сложная вещь, созданная человеком.
На некоторых чипах до трети всех возможностей процессора не используется, т.к. их реализации нашлись ошибки, которые нецелесообразно (т.е. слишком дорого) исправлять в текущем степпинге или текущей линейке, поэтому все больше вещей стараются делать программно — не только через микрокод, но и через код ME, прошивки Sensor Hub'а, PSP, SMU и тому подобных.
a5b
13.01.2016 03:00+6«Заявление представителя Intel», orlich, Jan 6, 2016 — communities.intel.com/thread/96157?start=15&tstart=0
Intel has identified an issue that potentially affects the 6th Gen Intel Core family of products. This issue only occurs under certain complex workload conditions, like those that may be encountered when running applications like Prime95. In those cases, the processor may hang or cause unpredictable system behavior. Intel has identified and released a fix and is working with external business partners to get the fix deployed through BIOS.
В обсуждении предположили, что проблема может быть связана с ошибкой в вычислении косинуса:
www.mersenneforum.org/showthread.php?t=20714&page=19#204
megabit8
Dec 2015
Talking It is a rounding problem in Skylake AVX after all… :)
I managed to isolate this piece of code:
#include <stdio.h> #include <math.h> const double M_PI = 3.1415926535897932384626433832795; double SkylakeAVXCosine() { double arg = (2 * M_PI) * 33 / 256.0; double cosValue = cos(arg); return cosValue; } int main() { double cosValue = SkylakeAVXCosine(); unsigned __int64 bytes = *(unsigned __int64*)&cosValue; printf("cos((2 * M_PI) * 33 / 256.0) == %llx \r\nPress enter to exit...", bytes); getchar(); }
The above code should be compiled with Visual Studio 2015, use the platform toolset: «Visual Studio 2015 (v140)» and in Code Generation set: «Advanced Vector Extensions (/arch:AVX)» so that the cos function will be computed with AVX.
On Skylake processor the result is:
cos((2 * M_PI) * 33 / 256.0) == 3fe610b7551d2cdf
On Ivy Bridge the result is:
cos((2 * M_PI) * 33 / 256.0) == 3fe610b7551d2cde
(Notice the last/lowest bit difference, on Skylake it is 1 on Ivy it is 0).
After all, this small program shows different result on Skylake vs other processors. I think this is related to the rounding problem posted here.
The exe is attached.
withkittens
13.01.2016 19:34Хм… Haswell (i5-4570) — аналогично Skylake:
cos((2 * M_PI) * 33 / 256.0) == 3fe610b7551d2cdf
robert_ayrapetyan
Интересно, как с помощью обновления bios можно исправить аппаратный баг процессора?
VBKesha
У современных процессоров есть такое понятие как микрокод, который заливается в процессор обычно биосом при старте системы(но может быть загружен и во время уже работы системы). Им в теории могут поправить этот баг.
robert_ayrapetyan
А можно ли как-то использовать это для написания своих микро-процдур?
hardex
Можно. Только заливается не микрокод, а патчи к нему. Придется сильно угадывать.
iSage
Начать можно с угадывания ключа цифровой подписи.
hardex
hireme.geek.nz/Intel_AMD_x86_microcode_attack_vector_cryptography_search.html
iSage
Не зашифровано != не подписано. Более того, это верно, емнип, только для К8.
VBKesha
Когда я искал информацию то ничего внятного не нашёл, кроме того что код либо зашифрован либо проверяется его контрольная сумма. Не знаю что поменялось с тех пор но скорей всего до сих пор нигде нет документации по этому микрокоду, кроме той что описывает как загрузить уже имеющийся.
a5b
Проверяется подпись по RSA-2048, затем расшифровывается (у Intel).
www.dcddcc.com/pubs/paper_microcode.pdf «patch data has always been observed to be encrypted or otherwise obfuscated… 520 byte block containing a 2048-bit RSA modulus… constant within each processor family… as well as a RSA signature computed using SHA-1 or SHA-2… patch data is encrypted using a symmetric block cipher such as AES or DES»
http://web.archive.org/web/20150315204530/http://inertiawar.com/microcode «Notes on Intel Microcode Updates Ben Hawkes» 2012-2013 (pdf) «The lack of timing artifacts corresponding to symmetric key algorithm block sizes (i.e. 128bits) may also indicate that authentication of the microcode contents is occurring prior to decryption of the microcode contents (i.e. the ciphertext is authenticated)»
beeruser
В x86 микрокод был всегда. С помощью него исполнятся сложные операции или редкие частные случаи аппаратно реализованных команд.
Отличие (более-менее) современных х86 процессоров в способности заменить любую(?) команду микрокодом.
icoz
Не всегда, а с каких-то pentium. То ли со 2го, то ли с 3го… Это примерно 97-98 года.
beeruser
Вы путаете наличие микрокода с возможностью его обновления.
Ещё K6 имел возможность патча микрокода (и инструкций)
https://en.wikipedia.org/wiki/Microcode
https://en.wikipedia.org/wiki/Intel_8086
The 8086 was sequenced[note 7] using a mixture of random logic[4] and microcode and was implemented using depletion-load nMOS circuitry with approximately 20,000 active transistors (29,000 counting all ROM and PLA sites).
http://tic01.tic.ec-lyon.fr/~muller/trotek/cours/8086/8086.html.en
The 8086 has a microprogrammed sequencer, but has also many wired functionalities such as to optimise the size of the microcode. The vertical microinstructions are 21-bit wide. The microprogram ROM contains 504 microinstructions. The start address of a microinstruction microcode is delivered by a PLA.
icoz
Ого. Спасибо. Не знал.
beeruser
Да тут легко запутаться. Сложные инструкции в современных процессорах разбиваются на микроперации — µOP (применительно к х86 часто называемые RISC-операциями), которые реализованы аппаратно. Но в некоторых сложных случаях (или для редких инструкций) может быть выполнена последовательность инструкций из специальной области памяти в процессоре, где хранится микрокод.
Что там за микроинструкции (названные так чтобы не путать с µOP?) доподлинно неизвестно, но вот тут немного приподнимается завеса тайны.
https://www.dcddcc.com/pubs/paper_microcode.pdf
В старых же процессорах микрокодом часто был реализован довольно приличный кусок функциональности.
Микрокод содержал непосредственно закодированные сигналы для управления блоками процессора.
Вот тут я наткнулся на довольно познавательную информацию про микрокод и нанокод(!) в Motorola 68000.
Но это уже довольно хардкорно.
The microcode is a series of pointers into assorted microsubroutines in the nanocode. The nanocode performs the actual routing and selecting of registers and functions, and directs results. This combination is quite efficient because a great deal of code can share many common routines and yet retain the individuality required of different instructions.
http://gendev.spritesmind.net/forum/viewtopic.php?t=1091
http://gendev.spritesmind.net/forum/viewtopic.php?t=922
http://www.easy68k.com/paulrsm/doc/dpbm68k1.htm
(в частности рассказано про vertical microcode, упомянутый в предыдущем комменте)
khim
Я вам больше скажу: микрокод появился задолго до x86. Даже какой-нибудь разнесчастный Z80 (не говоря уже о всяких 68k или PDP-11) был построен на базе микрокода!
Как раз отказ от микрокода в RISCах — это считалось шагом вперёд.
P.S. Современные RISCи микрокода, в традиционном смысле, не имеют, но всё-таки «разбирают» инструкцию на µopsы…
beeruser
Смотря какие. Например Power и производные имеют.
Ядро PPU в CELL и Xenon имеет вагон микрокода, причём для часто используемых инструкций вроде сдвигов.
http://cellperformance.beyond3d.com/articles/2006/04/avoiding-microcoded-instructions-on-the-ppu.html
Krey
не было в Z80 микрокода. Разве что в каких то поздних версиях.
grossws
ucode заливается не биосом, а загрузчиком или ядром ОС
navion
BIOS тоже и это основной путь его обновления, если верить этой статье.
grossws
Посмотрел подробнее. Был неправ.
Во многих статьях утверждается, что один из вариантов обновления микрокода — bios/uefi, но, т. к. они обновляются редко, то в linux и vmware используется другой способ.
После проблем с TSX в haswell и broadwell в ядре linux запретили позднюю загрузку микрокода после загрузки основной системы из /lib/firmware (или /etc/firmware), и заменили на загрузку в раннем initramfs. Иначе libpthread и всё, что собрано с использованием TSX сегфолтилось. lkml.org/lkml/2014/9/18/218
CodeRush
В данный момент для всех систем с поддержкой FIT (Haswell и более новые) микрокод загружается процессором еще до передачи управления на ResetVector, т.е. нельзя сказать, что его загружает firmware, она на тот момент даже не запущена еще. Затем можно загрузить другую версию микрокода, но у некоторых версий установлен флаг, запрещающий загрузку предыдущих версий на более поздних этапах.
lleo_aha
Почитайте про микрокод :)
Goodkat
Небось какую-нибудь оптимизацию отключат.