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

OpenBSD

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

( apostroph3 | 2018. 06. 20., sze – 09:52 )

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

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.

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

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

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

Ú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-m…

(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-…)

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

( uid_19006 | 2018. 06. 20., sze – 13:49 )

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

( Kormoran | 2018. 06. 20., sze – 17:00 )

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

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

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] <revskills> [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] <revskills> [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] <cperciva> [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... :/

( nagy_peter v | 2018. 06. 20., sze – 19:18 )

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..??)