Hibás a hyper-threading implementáció az Intel Skylake/Kaby Lake processzorokban

Intel

A Debian fejlesztő Henrique de Moraes Holschuh arra figyelmeztet, hogy hibás a hyper-threading implementáció a 6. és 7. generációs (kódnevükön Skylake / Kaby Lake) Intel processzorokban. A fejlesztő azt javasolja, hogy ideiglenes megoldásként az érintett processzorok tulajdonosai tiltsák le a hyper-threading funkcionalitást a BIOS-ban / UEFI-ben:

TL;DR: unfixed Skylake and Kaby Lake processors could, in some situations, dangerously misbehave when hyper-threading is enabled. Disable hyper-threading immediately in BIOS/UEFI to work around the problem. Read this advisory for instructions about an Intel-provided fix.

Henrique de Moraes Holschuh egy perl scriptet tett elérhetővé, amellyel a felhasználók tesztelhetik rendszerük esetleges érintettségét: 


#!/usr/bin/perl
# Copyright 2017 Uwe Kleine-König
#
# This program is free software; you can redistribute it and/or modify it under
# the terms of the GNU General Public License version 2 as published by the
# Free Software Foundation.

open(my $cpuinfo, "</proc/cpuinfo") or die "failed to open cpuinfo\n";

my $cpunum, $vendor, $family, $model, $stepping, $microcoderev, $hyperthreading;

while (<$cpuinfo>) {
	if (/^$/) {
		print "cpu $cpunum: ";
		if ($vendor eq "GenuineIntel" and $family == 6) {
			if ($model == 78 or $model == 94) {
				if ($stepping eq "3") {
					print "Your CPU is affected, ";
					if (hex($microcoderev) >= 0xb9) {
						print "but your microcode is new enough\n";
					} elsif ($hyperthreading ne "on") {
						print "but hyper threading is off, which works around the problem\n";
					} else {
						print "you should install the latest intel-microcode\n";
					}
				} else {
					print "You may need a BIOS/UEFI update (unknown Skylake-Y/H/U/S stepping)\n";
				}
			} elsif ($model == 85 or $model == 142 or $model == 158) {
				print "You may need a BIOS/UEFI update (Kaby Lake, or Skylake-X processor)\n";
			} else {
				print "You're likely not affected\n";
			}
		} else {
			print "You're not affected\n";
		}

		$cpunum = undef;
		$vendor = undef;
		$family = undef;
		$stepping = undef;
		$microcoderev = undef;
		$hyperthreading = undef;

		next;
	}

	$cpunum = $1 if /^processor\s*:\s(.*)/;
	$vendor = $1 if /^vendor_id\s*:\s(.*)/;
	$family = $1 if /^cpu family\s*:\s(.*)/;
	$model = $1 if /^model\s*:\s(.*)/;
	$stepping = $1 if /^stepping\s*:\s(.*)/;
	$microcoderev = $1 if /^microcode\s*:\s(.*)/;

	if (/^flags\s*:/) {
		if (/^flags\s*:.*\bht\b/) {
			$hyperthreading = "on";
		} else {
			$hyperthreading = "off";
		}
	}
}

Részletek itt.

( trey | 2017. 06. 26., h – 20:52 )

trey@alderaan:/tmp$ ./detect.pl
cpu 0: You're likely not affected
cpu 1: You're likely not affected
cpu 2: You're likely not affected
cpu 3: You're likely not affected

--
trey @ gépház

( _Franko_ v | 2017. 06. 26., h – 21:02 )

"Your CPU is affected, but your microcode is new enough"

Na, akkor most hibás, de javították?

Az egyik levelben:

I must say I'm utterly disappointed by this crap. "hey there is a hug bug, we
dont tell you what it is exactly, or how we fixed it, but YOU MUST INSTALL THIS
BINARY BLOB TO FIX IT. (and btw, this is for skylake, for kaby lake, ahem, maybe,
we have no idea, but do install that crap^wblob too.")

Szoval javitas van... az meg az o sajat szegenysege, hogy azt szeretne, ha az Intel ASM-ben (vagy akarmilyen nyelven irva), kommentelve az o kis pici szivenek megfeleloen adna oda a javitast ...

Van javitas ? igen... szoval az, hogy neki nem tetszik a szive joga. Van X masik disztribucio ahol nem fognak sirni azert, mert a nagy gonosz X gyarto csak binaris formaban javitja a hibat (teszem hozza, hogy azert van egy pici kulonbseg egy Linux disztribucio es egy CPU kozt ... amolyan nehogy mar a farok csovalja erzesem van)

Hibás, de van microcode fix (vagy inkább workaround).
A microcode-ot minden boot után frissíteni kell, ezt vagy a BIOS/UEFI teszi meg, vagy az OS.
Szóval vagy bios frissítés kell (a fix májusi, szóval annál nyilván frissebb kéne), vagy a megfelelő update/csomag az adott OS-hez.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

( SPYFF v | 2017. 06. 26., h – 21:10 )

cpu 0: Your CPU is affected, you should install the latest intel-microcode
cpu 1: Your CPU is affected, you should install the latest intel-microcode
cpu 2: Your CPU is affected, you should install the latest intel-microcode
cpu 3: Your CPU is affected, you should install the latest intel-microcode
cpu 4: Your CPU is affected, you should install the latest intel-microcode
cpu 5: Your CPU is affected, you should install the latest intel-microcode
cpu 6: Your CPU is affected, you should install the latest intel-microcode
cpu 7: Your CPU is affected, you should install the latest intel-microcode

Sima apt upgrade megoldja?

( s7stM | 2017. 06. 26., h – 22:16 )

:(

cpu 0: You may need a BIOS/UEFI update (Kaby Lake, or Skylake-X processor)
cpu 1: You may need a BIOS/UEFI update (Kaby Lake, or Skylake-X processor)
cpu 2: You may need a BIOS/UEFI update (Kaby Lake, or Skylake-X processor)
cpu 3: You may need a BIOS/UEFI update (Kaby Lake, or Skylake-X processor)
cpu 4: You may need a BIOS/UEFI update (Kaby Lake, or Skylake-X processor)
cpu 5: You may need a BIOS/UEFI update (Kaby Lake, or Skylake-X processor)
cpu 6: You may need a BIOS/UEFI update (Kaby Lake, or Skylake-X processor)
cpu 7: You may need a BIOS/UEFI update (Kaby Lake, or Skylake-X processor)

-------
It is our choices that define us.

( freeoli v | 2017. 06. 27., k – 06:41 )

Az AMD processzorat erinto microcode szalban megjelent az intel neve. A kiegyensulyozottsag miatt szeretnem megemliteni az AMD nevet.

:D Ennyi.

Amikor döntési helyzetben voltunk mert lehetett dönteni a két gyártó terméke között akkor mértünk. Egy nagyon elosztott, sok szálas és vegyes feladatra kellett szervereket vennünk és sikerült mérnünk az akkor elérhető HP DL 380 G8 és 385-ös kiszolgálókat 16 és 32 maggal. A végeredmény szerint kb 30-40%-al több számítási kapacitás jött ki az adott költség keretből, igaz sok kiszolgálóról volt szó. Végül hasonlóan vallásos, beleszólós de nem döntéshozók miatt az intel processzoros de G9 lett egy picivel több kedvezménnyel.

Hamarosan ismét lehet majd dönteni, de sokaknak akkor sem.

( nvik | 2017. 06. 27., k – 07:16 )

Autentikáció nélküli hardware backdoor, bugos CPU, AMD-től lopott utasításkészlet és multicore architektúra...

Miért nem tud az Intel semmit se jól csinálni?

AMD-től lopott utasításkészlet

Ez azért csúsztatás, mert kényszer volt. Az AMD csinálta meg előbb a 64 bitet, az MS pedig benyögte, hogy nem hajlandó két különböző utasításkészletű CPU-ra fordítót írni és az oprendszerét portolni. Így az Intelnek egy csinos kis arcvesztés mellett maradt az az opció, hogy a nála kisebb konkurens dokumentációi alapján csinál CPU-t. Csinálhatott volna az Intel bármit, de a felhasználás nagyobb részt Windows volt.

Mondom mindezt úgy, hogy az asztali gépemben egy AMD Phenom II X4 955 van, a notebook-omban pedig egy Intel Celeron n3450, s általában AMD-t választok, ha van ebben mozgásterem.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nem, az Intel csinálta meg a 64 bitet először IA-64 néven (Itanium), és még tudott is futtatni x86 kódot, csak rohadt lassan, és az Intel az egész 64 bitet prémium feature-nek gondolta szerver környezetben, és ennek megfelelően árazta.

Ezután jött az AMD. IA-64-ra nem volt licensze, és egyébként is jó x86 kompatibilitást akart, így lett az AMD64.

MS meg látta, hogy Intel nem akar 64 bites desktopot, AMD meg igen. Nem igazán volt kérdés mi a jó irány...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

"az Intel csinálta meg a 64 bitet először IA-64 néven (Itanium)"
Mármint a DEC Alpha, ami workstation is volt. Vagy éppen az SGI munkaállomásokban lévő R400. Előbb volt, mint az IA-64.
És ez csak a munkagépek.
Szerver/mainframe oldalon közel 2 évtizeddel ezek előtt volt már 64 bit.

( trey | 2017. 06. 27., k – 09:20 )

A több mint 20K hitért 91.82.100.59 :(

--
trey @ gépház

Másodpercenként több száz hit erre a cikkre erről az IP-ről tegnap este óta = 22867 olvasás = ip ban

Gondolom valami beragadt fos script.

(Közben valaki jelentkezett az IP mögül, így ideiglenesen leszedtem a bant.)

--
trey @ gépház

( uid_16313 | 2017. 06. 27., k – 10:46 )

Èn valójában arra lennék kíváncsi, hogy ezen felül hány szoftverhiba lehet még egy CPU-ban úgy, hogy soha nem kap publicitást?

--
robyboy

Rengeteg:
Intel Technical Resources --> <Your CPU Family> --> Specification Update --> Errata
AMD Developer Guides --> Revision Guide for <Your CPU Family> --> Product Errata

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

A microcode software és mint olyan, bugos. De már a "hangkártyák" is 90%-ban szoftveresek, meg minden. Szóval persze, a hardver is hibás bizonyára, de akkor az tervezési hiba és nem implementálási, illetve gyártási, de azt kezelik pl. frekvencia leszabályzással, vagy cache csökkentéssel vagy kukázással.

A legszebb nyilván az, amikor hw-hibát orvosolnak szoftveresen :)

--
robyboy

Ez eléggé vitatható. Én a mikrokódot nem tekintem software-nek, mint ahogyan egy CPLD-be vagy FPGA-ba letöltött adatot sem, amely a belső logikai kapumátrix kötési listáját tartalmazza. Ez lényegében nem más, mint egy rugalmasan, memóriából konfigurált hardware. Nyilván a mikrokóddal lehet javítani a CPU egyes hibáit. A baj akkor van, ha valami fixen bedrótozott hardware részletben van a bug.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Èn mindent szoftvernek tekintek, ami fizikai behatások nélkül módosítható. Pl. a firmware-eket is. "Memóriából konfigurálható hardware". Pont ez a lényeg. A memóriában tárolódik a kód, ami befolyásolja a hardware müködését. Ez a kód inkább szoftver mint hardware.

--
robyboy

Ez definíció kérdése, s magam nem tudom a pontos meghatározást. Egy kötéslista statikus, az olyan, mintha a hardware-t az adott huzalozás szerint gyártottak volna le. Persze tudom, vékony jég ez, mert akkor egy maszkprogramozott ROM sem egyéb, mint egy rakás multiplexer, amelynek a bemenetei meghatározott logikai szintre vannak kötve. Viszont ott mégis csak egy állapotautomata - a CPU - dolgozza ezt fel szekvenciálisan.

Na, szép, több évtized után jöttem rá, hogy használok egy szót, s fogalmam sincs, mit jelent. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Na, szép, több évtized után jöttem rá, hogy használok egy szót, s fogalmam sincs, mit jelent. :)

<troll>
Na, hajbazer csak jól csinálja az összevont bloatware megnevezéssel, abban minden benne van :)
</troll>

Rejtett subscribe voltam.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Wikipédia is hasonlóképpen fogalmaz a firmware címszó alatt idézem:

"Nincs éles határ a firmware és a szoftver között, lévén mindkettő elég tág fogalom. Mindenesetre a firmware kifejezést eredetileg a hardverkomponens cseréje nélkül megváltoztatható, magasabb szintű szoftverrel szembeállítva definiálták."

--
robyboy

( zoli78 | 2017. 06. 27., k – 23:51 )

Hát most egy picit nem örülök ennek. Kb. 20 év után lett egy inteles gépem és erre kiderül, hogy pont kifogtam egy hibás szériát.
Most zúzzam be szegény Latitude-öt?

Átlag felhasználásnál nem valószínű, hogy futtatsz olyan szoftvert vagy kódot, amelyiknél érintene ez a hiba. Másrészt írják a források, hogy adnak ki rá BIOS-frissítést, meg talán ha Linuxot használsz, akkor az intel microcde csomag is lehet megoldja.

„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek stb…” Aron1988@Proharder Fórum