Pull to refresh

Comments 28

Непонятно, зачем называть ошибку (да еще и уже исправленную обновлением микрокода) «критической уязвимостью»?
Уязвимостью этот баг станет только тогда, когда с его помощью научатся обходить какие-то защитные механизмы процессора\прошивки\ОС, а пока это просто баг, один из многих, в прошлый раз так пришлось TSX на Haswell отключить.
Советую также посмотреть презентацию с 32c3 (видео, слайды) — When hardware must «just work», там очень хорошо пояснено, почему баги в процессорах до сих пор регулярно находятся, и почему сделать процессор без единого бага — практически нереально.

Как я понял ошибка не исправлена. Интел недавно только предоставил код для разработчиков МП, а когда они выпустят новый биос и выпустят ли вообще никто не в курсе.

Кто мешает обновлять микрокод самостоятельно?
Цифровая подпись BIOS'а, например.
В подавляющем большинстве случаев микрокод загружается именно оттуда.
Правда что ли? И как же тогда так получилось, что у меня прошлогодняя прошивка в матери
# 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
В подавляющем большинстве случаев свежий микрокод загружается операционной системой, потому что BIOS либо древний, либо производитель мат. платы уже забил на обновления.

Таким образом, микрокод подгружается 2 раза: сначала более старый из BIOS, потом свежий из ОС.

Поэтому, пользователи получат микрокод как только обновят соответствующий пакет в Linux/прилетит обновление в Windows.

Вдобавок, есть даже отдельный драйвер производства компании VMWare, который создан специально для загрузки файла, содержащего микрокод (а сам файл с микрокодом свободно доступен на сайте Intel).
Это можно обойти. Например, у ASUS из подписанного CAP-файла (UEFI Capsule) легко извлечь непосредственно образ прошивки, в котором самостоятельно заменить микрокод (через MMTool) и прошить получившуюся прошивку из операционной системы с помощью Intel Flash Programming Tool.

Микрокод для 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:


Users of systems with Intel Kaby Lake processors should immediately disable hyper-threading in the BIOS/UEFI configuration. Please consult your computer/motherboard's manual for instructions, or maybe contact your system vendor's support line.

The Kaby Lake microcode updates that fix this issue are currently only available to system vendors, so you will need a BIOS/UEFI update to get it. Contact your system vendor: if you are lucky, such a BIOS/UEFI update might already be available, or undergoing beta testing.

… Users of systems with Intel Skylake processors may have two choices:

If your processor model (listed in /proc/cpuinfo) is 78 or 94, and the stepping is 3, install the non-free "intel-microcode" package with base version 3.20170511.1, and reboot the system. THIS IS THE RECOMMENDED SOLUTION FOR THESE SYSTEMS, AS IT FIXES OTHER PROCESSOR ISSUES AS WELL.

В частности, дебиан собирает пакет микрокодов из 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.

Однако, он будет опубликован. И обновить его можно будет вне зависимости от желания производителя материнской платы выпускать новую версию прошивки.
Как использовать эту ошибку? Да легко. Ищем хостера с серверами на базе соответствующих процессоров, покупаем у него самую дешёвую VPS, запускаем код, триггерящий уязвимость с очень высокой вероятностью, получаем DoS чужих VPS-ок, запущенных на этом же физическом хосте. Отсутствие публичного эксплойта никак не умаляет опасность уязвимости. Это именно что обход защитных механизмов процессора и ОС — код с минимальными привилегиями может вызвать сбои (пусть и случайные — для DoS этого достаточно) в других приложениях. Когда защитные механизмы процессора и ОС работают корректно такая ситуация невозможна.

Что касается исправления — пока официально доступно исправление только для Skylake. К тому же нередко информация о критических уязвимостях публикуется после официального выкатывания исправлений — чтобы юзеры побежали обновляться, потому что просто так обновляют микрокод далеко не все.
Во как. По началу я связывал вылеты gcc и зависания системы, при компиляции Android прошивок, с перегревом. Хотя, все датчики показывали не совсем уж критическую температуру. Затем, при очередном обновлении UEFI, забыл включить HT и проблема исчезла. Через какое-то время заметил выключенный HT и включил его. Проблемы вылезли, но не сразу, поэтому и не связал это с HT. Теперь всё стало понятно…
Эх. Выключение HT привело к +6 минут к сборке прошивки
Желание апгрейдить і5 на і7 сильно уменьшилось.
Проблема, на самом деле, очень специфическая, шансов столкнуться с ней немного. Говорю, как обладатель инженерной версии Skylake, для которой свежего микрокода нет (и не будет).

Вдобавок, ходят слухи, что следующие мейнстримовые i7 будут 6-ядерными (i5 станут тем, чем сейчас являются i7, а i3 получат 4 полноценных ядра), поэтому лучше подождать до осени, там видно будет.
Интел продолжает «радовать»: RdRand, SYSRET, теперь это. На этом фоне AMD выглядит всё более привлекательно…
Интел долго лидировал, может пора истории развернуться?

как будто в амд нет багов...

Да есть, наверное; но почему-то баги Интел на слуху, а баги AMD мне пришлось гуглить (коих оказалось меньше и не таких серьезных).
А еще Linux неуязвим для вирусов.
Популярность Intel и AMD — 4 к одному (в серверном сегменте еще больше, скорее всего). Логично подумать, что и подобных багов обнаруживаться будет больше у Intel. Тем более, что проверить такой баг довольно тяжело и многие его списывают на программную ошибку, к примеру

Спешу вас огорчить. В любом процессоре есть errata длиною в километр.


Как пример,
https://community.amd.com/thread/215773
tl;dr Segmentation Fault при компилляции на процессорах Ryzen. Пока ничего не понятно почему это происходит, но сага длится несколько месяцев уже.
Помимо этого есть немалого других проблем уже подтвержденных AMD.
Интел просто популярней поэтому чаще слышно о его проблемах в новостях.

i7 6770hq, были баги с зависаниями, мерцанием экрана в некоторых играх и просто спонтанные ошибки. После отключения по крайней мере быстровоспроизводимые баги исчезли.
UFO just landed and posted this here
Почти все процессоры, кроме самих дорогих уже являются продуктом отбраковки. Intel производит только три процессора: Atom, Core, Xeon. Вся вариация линейки это процессоры которые по тем или иным причинам не прошли тесты на какие-то фичи. Тут главное грамотно выявлять ошибки и иметь возможность их достаточно хорошо изолировано отключать, создавая младшие модели процессоров.

Была статья, по-моему, на eetimes с интервью главных экспертов. Таки да, на текущих технологиях примерно года через три-четыре это наступит, если я правильно помню. Но с другой стороны начнётся использование других материалов, производственных процессов, и еще много чего (например наблюдается тенденция возращения к "вертикальным" компаниям, то-есть производящих все начиная от процессоров до программного обеспечения. Квантовые компьютеры также многообещающая отрасль). Возможно будет огромный скачок в середине 20-ых годов.

Sign up to leave a comment.

Articles