aktualności

Błąd w mikrokodzie procesorów Skylake i Kaby Lake - Intel poprawkę miał już w kwietniu

40
3 lipca 2017, 03:20 Piotr Gontarczyk

Pigułka na uspokojenie. Tydzień temu przez internet przetoczyła się wieść o błędzie w mikrokodzie procesorów Intel Core szóstej (Skylake) i siódmej (Kaby Lake) generacji. Błąd był związany z działaniem techniki Hyper-threading, a jego skutki miały ujawniać się w bardzo specyficznych sytuacjach.

Źródłem całego zamieszania był informacja, którą opublikował Henrique de Moraes, jeden z twórców Linuksa Debian. Przekazy tej informacji wzbudziły sporo emocji, zwłaszcza że samo źródło twierdziło, że sposobem na uniknięcie skutków opisanego błędu jest wyłączenie Hyper-threadingu w BIOS-ie.

Okazuje się, że cała sprawa była naciągana, zwłaszcza że poprawka do mikrokodu procesora to nic nowego, ani nadzwyczajnego. Jak twierdzi sam Intel, potwierdzając oczywiście wystąpienie błędu, prawdopodobieństwo padnięcia jego ofiarą jest niskie, gdyż wystąpienie jego skutków wymaga jednoczesnego zadziałania skomplikowanego zestawu warunków.

Druga kwestia jest taka, że Intel o błędzie wiedział wcześniej, a stosowną poprawkę mikrokodu zaczął udostępniać już w kwietniu bieżącego roku. Poprawki konsumenci mogą uzyskiwać poprzez aktualizacje BIOS-ów swoich płyt głównych, na których mają osadzone procesory Skylake lub Kaby Lake. Oznacza to, że od kwietnia wszystko jest w rękach producentów płyt głównych i to od nich należy oczekiwać aktualizacji BIOS-ów.

Użytkownicy nie powinni więc poddawać się panice, wyłączając Hyper-threading, jak sugerował Henrique de Moraes, gdyż prawdopodobieństwo wystąpienia skutków błędu, o który rozpętała się afera, jest niewielkie. Co z tymi, dla których płyt głównych producenci nie udostępnią aktualizacji BIOS-ów? Warto zwrócić uwagę chociażby na to, że procesory Skylake na rynku są już od blisko dwóch lat i dopiero po tym jak Intel zrobił poprawkę dla określonego błędu, ktoś go w ogóle zauważył.

petertechZobacz profil
Poziom ostrzeżenia: 0%
petertech2017.07.03, 04:41
20#1
Warto zwrócić uwagę chociażby na to, że procesory Skylake na rynku są już od blisko dwóch lat i dopiero po tym jak Intel zrobił poprawkę dla określonego błędu, ktoś go w ogóle zauważył.


Może były przypadki występowania błędu tylko nikt nie potrafił znaleźć przyczyny ;)
Listonosz_złej_nowinyZobacz profil
Poziom ostrzeżenia: 0%
Listonosz_złej_nowiny2017.07.03, 05:18
-11#2
Czyli jednym słowem totalna gównoburza i pożywka dla fanbojów AMD których sporo tutaj ostatnimi czasy
Markiz88Zobacz profil
Poziom ostrzeżenia: 0%
Markiz882017.07.03, 06:59
13#3
Jak twierdzi sam Intel, potwierdzając oczywiście wystąpienie błędu, prawdopodobieństwo padnięcia jego ofiarą jest niskie, gdyż wystąpienie jego skutków wymaga jednoczesnego zadziałania skomplikowanego zestawu warunków.

Niskie ryzyko to nie w cale takie małe, jak by występował tylko w laboratorium to tak. Tym bardziej że błąd ten nie powodował w żadnym wypadku zawieszenia systemu, więc jak mogą oni mówić o skali występowania problemu?
komisarzZobacz profil
Poziom ostrzeżenia: 0%
komisarz2017.07.03, 07:33
-11#4
Markiz88 @ 2017.07.03 06:59  Post: 1077790

Niskie ryzyko to nie w cale takie małe,


J23 znowu nadaje. Jedyne wiarygodne wiesci prawda prosto z warzywniaka.


jak by występował tylko w laboratorium to tak. Tym bardziej że błąd ten nie powodował w żadnym wypadku zawieszenia systemu, więc jak mogą oni mówić o skali występowania problemu?


moze dlatego: 'gdyż wystąpienie jego skutków wymaga jednoczesnego zadziałania skomplikowanego zestawu warunków'

A jako ze intel pisze najlepsze kompilatory na rynku to wie jakie jest prawdopodobienstwo zaistnienia takich warunkow.

SetnikZobacz profil
Poziom ostrzeżenia: 0%
Setnik2017.07.03, 07:38
12#5
Stopień występowania tego błędu jest 100% przy wirtualizacji na procesorze kilku maszyn. Piszą tak by uspokoić ludzi. Mamy w firmie około 500 sztuk stanowisk do obsługi zdalnej i problem występuje zawsze przy włączeniu maszyn wirtualnych na procesorach. Sprawa w sądach z Dell kilkukrotnie wyczyściło dane( backup) i po sprawie lecz wielokrotnie zmienia dane w bazach danych, a to cholerstwo żeby sprawdzić już trzeba kilku dni.
AssassinZobacz profil
Poziom ostrzeżenia: 0%
Assassin2017.07.03, 07:39
Daremny trud. I tak w komentarzach będą teraz jeszcze przez pół roku pisali, że 'Intel każe wyłączyć HT' ;)
DabmanZobacz profil
Poziom ostrzeżenia: 0%
Dabman2017.07.03, 07:48
wylaczyc HTC, dobre to. Jezeli jest to glowna metoda i jedyna skuteczna, czy intel da mozliwosc zwrotu procesorow i ew. plyt glownych?
No nie mozna zmusic ludzi to tego aby pozbyli sie jakiejs opcji badz zmniejszyli wydajnosc swojej maszyny po to aby blad nie wystepowal.
KenjiroZobacz profil
Poziom ostrzeżenia: 0%
Kenjiro2017.07.03, 08:22
11#8
Przede wszystkim nieprawdą jest stwierdzenie, że:
dopiero po tym jak Intel zrobił poprawkę dla określonego błędu, ktoś go w ogóle zauważył

Gdyż jeden z błędów odkryli deweloperzy Debiana:
http://www.zdnet.com/article/debian-linux-...yper-threading/
A fix dla tego błędu został przygotowany w maju i wydany w czerwcu (paczka 3.20170511.1), a nie w kwietniu i co więcej, jest dostępny dla Debiana w gałęzi non-free, ale już nie dla Windowsa i innych systemów.
Warto przejrzeć listę poprawek Intela:
https://www.intel.com/content/www/us/en/pr...pec-update.html
Gdyż jak wynika z aktualnej listy, to oficjalnie te błędy są cały czas nienaprawione.
NomadDemonZobacz profil
Poziom ostrzeżenia: 0%
NomadDemon2017.07.03, 08:50
13#9
ta.. a jak phenomy mialy blad, to 4 miesiace trabili o tym wszyscy...
kiokioZobacz profil
Poziom ostrzeżenia: 0%
kiokio2017.07.03, 09:02
-7#10
Setnik @ 2017.07.03 07:38  Post: 1077800
Stopień występowania tego błędu jest 100% przy wirtualizacji na procesorze kilku maszyn. Piszą tak by uspokoić ludzi. Mamy w firmie około 500 sztuk stanowisk do obsługi zdalnej i problem występuje zawsze przy włączeniu maszyn wirtualnych na procesorach. Sprawa w sądach z Dell kilkukrotnie wyczyściło dane( backup) i po sprawie lecz wielokrotnie zmienia dane w bazach danych, a to cholerstwo żeby sprawdzić już trzeba kilku dni.


A kto robi VM w firmie na procesorach klasy SOHO?
Zaloguj się, by móc komentować
1