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

 ( trey | 2017. június 26., hétfő - 19:51 )

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:

Idézet:
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.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

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

"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)

systemd? :D
ahol a farok csovalja :D

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

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?

https://wiki.debian.org/Microcode

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

ugyanez, E3-1240 v5, ubi 16.04 lts server, apt install intel-microcode + reboot nem oldotta meg.

apt-get install intel-microcode
<reboot>
dmesg | grep microcode
[ 0.000000] microcode: microcode updated early to revision 0x24, date = 2016-04-29
[ 1.059632] microcode: sig=0x306d4, pf=0x40, revision=0x24
[ 1.059713] microcode: Microcode Update Driver: v2.2.

--
trey @ gépház

Az Ars technica szerint a microcode fix májusi, szóval ez a verzió nem lenne elég új (bár fentebb kiderült, hogy a te cpu-d nem is érintett.)

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

:(

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.

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

Nyugodtan megemlítheted, bár attól önmagában, hogy az Intelnél is vannak problémák (sosem volt olyan állítás, hogy nincs), az AMD egy hangyafasznyival sem lesz jobb választás.

--
trey @ gépház

:)

: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.

Szavaztassuk meg? :D

(Ha a döntés súlya a te válladat nyomná, nem vagyok biztos benne, hogy úgy döntenél, ahogy hiszed.)

--
trey @ gépház

Az én vállamat nyomja. Akkor is az enyémet nyomta.

Most nem vennék sehova AMD szerve processzort. Főleg mert mindenhol Intel alapú infrastruktúra van és a kettő közt az átjárást nem megy leállás nélkül.

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

Köszönöm a pontosítást! Azzal a megkötéssel, hogy a desktop piacra szánt 64 bit, meg x86 kompatibilitás, már igaz, amit írtam.


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

"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.

Rosszul fogalmaztam, csak Intel/AMD viszonylatban értettem az elsőséget.

Persze úgy általában nem az Intel volt az első 64 biten, mint ahogy 32/16-on sem.

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

Mi vitt rá arra hogy ennyi marhaságot összeírj?

Az Itaniumnak sok köze nincs az x86-hoz, az, hogy tud futtatni konkrétan emuláció.

Annyi köze van, hogy az Intel azt tervezte az x86 utódjának.

Illetve valami hw rásegítés is volt ahhoz az emulációhoz.

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

"Annyi köze van, hogy az Intel azt tervezte az x86 utódjának."
Ok...

"Illetve valami hw rásegítés is volt ahhoz az emulációhoz."
Valami volt, de az architectúra tök más, meg elvileg későbbi itaniumokban már ki is lőtték mert a full softveres emuláció gyorsabb volt.

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

Elég sokan vannak emögött a NAT IP mögött, whois elárulja melyik cég.

Gondolom IT-jük van.

(A kérdés költői volt, mert már valaki kapcsolatba lépett velük.)

--
trey @ gépház

È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

Ja, ezek a publikusak.

--
robyboy

Mikrokontrollerekben is van egy rakás bug. Van, amelyikre van workaround, de van, amire nincs. Na, az utóbbi a szívás.


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

Hát még hardverhiba mennyi lehet!

:))


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

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

Idézet:
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

Szerintem akkor egyezzünk ki abban, hogy a microcode az firmware. ;) De nem, nem úgy, mint például a SOHO router-eké, mert az valójában vaskosan software már.


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

Ok.

--
robyboy

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?

Dobd ki!
Csak szólj előtte, hogy hová... ;)

Á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