Mostantól biztonsági okokból az OpenBSD alapértelmezetten tiltja a Hyper-threading támogatást az Intel CPU-kon

 ( trey | 2018. június 20., szerda - 8:34 )

SMT (Simultanious Multi Threading) implementations typically share
TLBs and L1 caches between threads. This can make cache timing
attacks a lot easier and we strongly suspect that this will make
several spectre-class bugs exploitable. Especially on Intel's SMT
implementation which is better known as Hypter-threading. We really
should not run different security domains on different processor
threads of the same core. Unfortunately changing our scheduler to
take this into account is far from trivial. Since many modern
machines no longer provide the ability to disable Hyper-threading in
the BIOS setup, provide a way to disable the use of additional
processor threads in our scheduler. And since we suspect there are
serious risks, we disable them by default. This can be controlled
through a new hw.smt sysctl. For now this only works on Intel CPUs
when running OpenBSD/amd64. But we're planning to extend this feature
to CPUs from other vendors and other hardware architectures.

Note that SMT doesn't necessarily have a posive effect on performance;
it highly depends on the workload. In all likelyhood it will actually
slow down most workloads if you have a CPU with more than two cores.

ok deraadt@

Egyelőre csak amd64-en, de a tervük az, hogy kiterjesztik más gyártók CPU-ira / más architektúrákra is.

Forrás: https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/arch/amd64/amd64/cpu.c

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

maradni fog valami a végére ezen a k. intel procin ami még működik?

OpenBSD-n? Mert ugye itt arról van szó, hogy "kurva nagy munka lenne az ütemezőnket megfelelően rendbe tenni, ezért az ultimate megoldás, hogy tiltsuk le a picsába, oszt' a munka meg is van oldva" esete forog fenn.

"Unfortunately changing our scheduler to take this into account is far from trivial."

--
trey @ gépház

A szokásos válasz van erre az OpenBSD projekt részéről:

Kevés az ember
A kevés fejlesztőt sem érdekli az adott probléma megoldása
Küldj patchet

Én azért szeretem használni :)

Végül is nem sok teljesítményvesztést jelent, - mindent egybevetve szálanként kb. 20-25 %-ot. - Ha van 12 mag, észre sem venni. (Ezt az AMD-t nem értem.., ott a HT nem másnéven és másként implementált?)

Az AMD64 a 64-bites architektúra neve, amit az Intel CPU-k is használnak

Így van és sokszor ez az elnevezés félrevezető. Éppen ezért sok gyártó a gyártósemleges x86_64-et vagy x64-et használja.

--
trey @ gépház

igen, de
'But we're planning to extend this feature
to CPUs from other vendors and other hardware architectures.'

És akkor visszakanyarodunk az elejére. Azért tervezik, mert nem csak az Intel processzorok érintettek napjaink népszerű támadásaiban. Éppen ezért tervezik más CPU/arch-okon is a bevezetni.

--
trey @ gépház

Nepszeru alatt ugye azt erted, hogy tele vannak veluk a hirek.
Mert sikeres tamadasrol meg nem hallottunk.

Ha jól emlékszem a spectre-s mókából, az új ARM-ok is érintettek lehetnek.

Szálanként 20-25%? Van erre valami forrásod?


Normális HUP-ot használok!

En is valami 30% korul mertem anno Linuxon.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Ha valamilyen IO korlátos taszk, akkor a várakozó időkben a másik szál tud végrehajtani. Ebből jön ki az említett plusz.

Nem csak abbol.
Ha az egyik thread mondjuk a mag FP reszet hasznalja masik meg az ALU -kat
akkor megint kevese akadalyozzak egymast.
Vagy 3 ALU/Integer egysegebol csak 2-t hasznal egy thread akkor 3ik szabad.
De altalaban a memoriara varakozast szoktak felhozni.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Jaja, + TLB miss-eknél is tud a másik szál dolgozni.

Ezek a dolgok az elmelet es az Intel marketingje.
Normal napi hasznalatban kb eszre sem veszed, hogy be van kapcsolva. De arra nagyon jo, hogy a top jo sok procit mutasson.
Szerintem is jobb, ha emiatt nem nyulnak hozza egy amugy stabilan mukodo cucchoz.

Egy régebben olvasott szakcikkből származik, a HT inteles alkalmazásával elérhető átlagos teljesítménytöbblet mínuszolásával "képeztem" - de nem tudnám most, hol olvastam..

Egyenlőre, - alaposabb fordítás, - után nyugtalankodni kezdtem, amikor a HT-n kívül a 2 fizika mag feletti processzormagok szükségtelenségét is emlegeti...
:)

Nyilván ha hozzányúlnak valamihez, ami már szarásig ki van tesztelve, az mindig sok potenciális hibát hordoz magában -> több kárt hozhat, mint hasznot. A másik meg, hogy he bele is ölnék az X mennyiségű munkát, megérné-e? Nem tudom, mennyire van jövője a HT-nek.

Szerintem is gáz. De a cikkben írják, hogy ez a letiltás default beállítás lesz, de könnyen visszacsinálható. Így akinek kell, hipp-hopp visszakapcsolja. Ezek a CPU cache-támadások túl vannak spilázva, OpenBSD-t úgyis szerveren szoktak futtatni, azon meg úgyis ellenőrzött forrásból raknak fel szoftvereket. Ezek a cache-támadások inkább desktop gépen veszélyesek, ahol a user tölt le meg telepítget innen-onnan mindenféle szutykot, meg böngészővel mindenféle gány oldalt látogat össze. Ugyanez áll a Spectre/Meltdown esetére.


No keyboard detected... Press F1 to run the SETUP

Kérdés, hogy az Intel ME, az AMT mennyire alkalmas a processzorcache elérésére, mert onnantól a szervereknél is bármi lehet.

És más rendszerek ezt a (feltételezett?) problémát figyelmen kívül hagyják, vagy más rendszereken az ütemezőt rendbetették, hogy odafigyeljen ezekre az esetekre?

100%-ra egy módosított ütemezővel sem lehet ezt a problémát megoldani, mert vannak olyan használati esetek, ahol ugyanazon jogosultsági szinten hajtodnak végre potenciálisan rosszindulatú kódok.

De ha már a rosszindulatú kód is admin jogokkal fut, akkor megette a fene, az ellen nem létezik folt, ott már rég vége a történetnek.


No keyboard detected... Press F1 to run the SETUP

nem kell, hogy admin jogokkal fusson

Ja, értem. Először félreértettelek. Azt írod, mikor legalsó jogszinten, user space-ben azonos user két folyamatáról van szó. Szerintem az ütemezőnek ezt meg kell tudnia oldani.


No keyboard detected... Press F1 to run the SETUP

persze, csak pontosan olyan hatásfokkal tudja megoldani, mint ha ki lenne kapcsolva a HTT

Ebben lehet igazad van. Ilyen mélységében nem ismerem a témát, hogy a 4.9+ kernelek ütemezőügyileg ezt hogyan oldják meg, és milyen hatásfokkal.

Egyébként ezek a cache-kiolvasó támadások elég elméletiek, mert egy normális gépre nem kerül fel potenciálisan ártó kód sem. Ahol meg felkerül, ott meg egyáltalán azzal kéne kezdeni valamit (user error), hogy ne kerüljön fel.

Egy necces pont van, a böngészők, minden desktop gépen fent vannak, és előre nem meghatározott oldalról előre nem meghatározott kódokat futtatnak, és hiába a sandboxing, sok ártó kód meg tudja kerülni.


No keyboard detected... Press F1 to run the SETUP

>> Ilyen mélységében nem ismerem a témát, hogy a 4.9+ kernelek ütemezőügyileg ezt hogyan oldják meg, és milyen hatásfokkal.

Kevered a Lazy FP hibával. Ez egy másik biztonsági probléma.

> Egyébként ezek a cache-kiolvasó támadások elég elméletiek, mert egy normális gépre nem kerül fel potenciálisan ártó kód sem

Shared hosting, paravirtualizált gépek, esetleg full virtualizált gépek is érintettek lehetnek.

XScale, StrongARM? :P

Eladtak, nem gyartjak mar, es kulonben sem x86 - bar Intel. De - ha jol emlekszem - az meg nem volt erintett a spectre-ben, tul buta ahhoz.

--
If you get a good wife, you'll become happy; if you get a bad one, you'll become a philosopher. -Socrates

Majd a Microsoft EDGE CPU design-ja megment minket a haláltól:
Microsoft ports Windows 10, Linux to homegrown CPU design

Apple is lehet, hogy pont ilyenen dolgozik.

Úgy tudom ők ARM-et fognak használni desktopon is nem pedig egyedi architektúrát: https://www.macrumors.com/2018/05/29/pegatron-to-make-arm-based-apple-macbook/

(Fun-fact: Az ARM 8.3 szabvány tartalmaz javascript-specifikus string/float -> integer gyorsító utasítást: https://community.arm.com/processors/b/blog/posts/armv8-a-architecture-2016-additions)

ARM eseten mi lehet AMD64-hez kepest nagyon erosen lassabb?

Egyetlen dologrol tudok: virtualizacio, foleg mas architekturae.

Mas pelda?

Valószínű már a virtualizacio sem: Overall ARM and X86 are on par with each other in terms of virtualization overhead (más architektúra az x86 esetében is problémás)

A cloudflare tesztek alapján a Go futtatás, de elvileg azóta már az is jelentősen javult és el is kezdték az átllást:
CEO says ARM would be cheaper for Cloudflare’s workload even if x86 chips were free

Már várom azt a foltot, ami letiltja az egész intel cpu-t. :)

Ahhoz előbb legyen egy PCI-express-es AMD APU, hogy átvehesse a hatalmat :D

Aztan Inteles gep majd csak PCI express-en keresztul lehet PCI Compliant? :P

lehet hogy mégse akkora faszság spórolni egy Talos II-re?


"all submitted complaints will be forwarded to /dev/null for further investigation"
"ez ilyen hippi kommunás felfogás, ahogy Stallman sámán módjára dobol a nagy hasán, hogy GNU, free software, free as free beer."

laptopnak meg pinebook?

simán, nincs ezzel gond. mondjuk a mai napig várok egy olyan mobil ARM eszközre ami ezeknél azért egy picivel combosabb, de kifejezetten laptop use case-re ezek is megfelelnek (kicsit bezavar az ítélőképességembe hogy soha nem volt normális asztali gépem csak laptopom, asztalinak is ezt használom)


"all submitted complaints will be forwarded to /dev/null for further investigation"
"ez ilyen hippi kommunás felfogás, ahogy Stallman sámán módjára dobol a nagy hasán, hogy GNU, free software, free as free beer."

Sajnos power processzoral szerelt laptop meg 2004 óta nem igazán létezik a piacon. :(

Kapcsolódhat: Az Intel a múlt héten fizetett ki 3 x 20000 USD értékű bug bounty-t: https://hackerone.com/intel/hacktivity?sort_type=latest_disclosable_activity_at&filter=type%3Aall%20to%3Aintel&page=1&range=forever
Illetve egy 30000 USD értékűt a hónap elején.
Ez elvileg 7.0 és 10.0 CVE score közötti hardware vagy firmware jellegű hibákat jelent.
Összehasonlításképpen:
- Meltdown: 5.6
- Spectre: 5.6
- Lazy FPU: 5.6

Az új fantázianév: TLBleed

A Blackhat és Usenix már be is fogadta.

Twitteren is használták páran a hashtaget:

$ grep -i tlbleed \#twitter/201*
#twitter/2018-06-20.log:[20:12:46]  [65c] RT @gober: Our upcoming #TLBleed paper leads to (finally) disabling SMT in security-sensitive environments (#OpenBSD in this c… https://t.co/ke6ROy0sgp
#twitter/2018-06-20.log:[20:16:48]  [29b] I do not usually like the names chosen in some vulns, but #TLBleed sounds good to me.
#twitter/2018-06-20.log:[21:29:16]  [789] I haven't read the #TLBleed paper yet, but I think it's worth mentioning that one of the big lessons from 2005 is t… https://twitter.com/i/web/status/1009518401801207808

A paper alapján tényleg nem érdemes a következő 1-2 évben Intel procit venni... :/

Király: "Our TLBleed exploit successfully leaks a 256-bit EdDSA key from libgcrypt (used in e.g. GPG) with a 98% success rate after just a single observation of signing operation on a co-resident hyperthread and just 17 seconds of analysis time." disclosure coming on June 27

Jah, úgy tűnik, hogy Nehalem óta mindegyik érintett.

Off: mivel csinalsz ilyen naponkenti #tripper log-ot?

tircd + irc client/bouncer, de tircd elég nagy fos

Koszi

Ugysem szamit sokat.

Nálunk éppen gépbeszerzés van, és többek közt a fentihez hasonló sorban előkerülő hibák miatt veszünk most AMD Ryzen II-es gépeket.
Remélem fél év múlva nem annak a hibáival lesz tele a sajtó.
Bár gépet venni kell, ezek a hibák meg már ismertek, szóval rosszabbul úgy sem járunk, legfeljebb ugyanolyan rosszul.

Mivel az AMD "ami" cég, Ő sem "backdoor"-mentesítheti a processzorait szabadon. Időben feltárásra-konkretizálásra fognak kerülni ott is a "hibák" újabb, AMD-re optimalizált kihasználási módjai.

(Az ezzel foglalkozó biztonsági cégek és fejlesztői adtak némi haladékot az AMD-nek, talán számukra mindig is szimpatikusabb cég volt, - aki "visszatelepült" az első hívó szóra Amerikába, - és nem Izraelbe migrálódott teljesen,) de persze csak az üzlet érdekében...) - Az már hab a tortán, hogy miért izraeli cég kezdte "döntögetni" az Intel processzorait..??)