De zoeveelste beschrijving van de effecten van een flat model. memory cpu het maakt niet veel uit,

Wil je dat in de basis goed krijgen zul je hardware ondersteuning nodig hebben.
https://domino.research.ibm.com/library/cyberdig.nsf/papers/B9D637F6D41FD7D78525788C00525519/$File/rc25155.pdf

Met Selinux is er een start om iets op het os niveau van security context's te weten.
Het parallelle proces is geen bedreiging als het een eigen proces dan wel vertrouwd proces is.
Het is een probleem omdat hardware resources zonder gedegen scheiding gebruikt worden op de zelfde hardware.
Een twister voor randomisatie voorkomt dat het voorspelbaar wordt (minimaliseren van de kans).niet dat het onmogelijk wordt.
Stop eens 64 sockets in een doos.

..(dubbel) ..

Interessant, maar ik weet nog niet zo zeker of dit tegen deze aanval zou helpen. Uit de inleiding van dat document:
Dit gaat over bescherming van data in registers. PortSmash is een timing side channel attack. Zoals ArsTechnica dat uitlegt[1]:
Tijd meten is iets anders dan de registerinhoud van een ander proces te pakken weten te krijgen.

[1] https://arstechnica.com/information-technology/2018/11/intel-cpus-fall-to-new-hyperthreading-exploit-that-pilfers-crypto-keys/

Dit ligt ook aan de manier waarop Openssl dit had geconstrueerd (programma-jumps gerelateerd aan key o.i.d.)
Versies nieuwer dan Openssl 1.1.0h zijn anders opgebouwd, en daarmee is deze aanval niet meer succesvol.

Hoe schakel je hyper-threading uit en wat zijn de gevolgen van het uitschakelen?

Bendken eerste wat jouw risico impact voor dit verhaal is. Als je er van uit gaat dat je malware op je machine gaat draaien of anderen software die je niet kent op jouw machine toelaat dan heb je een overweging. In een cloud server benadering kun je nadenken over het overgaan van shared naar dedicated machines.
https://bitsum.com/tips-and-tweaks/why-you-should-not-disable-hyper-threading-or-why-you-should/
Uefi is de bios setup https://www.pcmag.com/article2/0,2817,2422894,00.asp
Dat andere ik ken dat bitsum niet. Nooit eerder gezien en zou dat niet zo maar op een systeem zetten.

Interessant zijn al die opmerking dat oude en nieuwe softwarecode niet profiteert van HT. Parrallel code optimalisatie begint met het ontwerp waar je de logische processen zo moet ontwerpen. met matrixbewerkingen kun je er voordeel uit halen op een andere manier. Dat gaat tegenwoordig verborgen achter de vele talen. Je plakt wat blokken als packages bij elkaar.

Zoals vaak het geval in "cloud"-omgevingen.


Het gevolg is dat je de "voordelen" (q.v.) van hyper-threading niet meer geniet. Merk op dat of het ook werkelijk prestatiewinst oplevert nogal afhangt van de workload c.q. het soort programma dat er draait.

Uitschakelen doe je in het bios, wat in "serveromgevingen" betekent dat je afhankelijk bent van de beheerder en zijn provisioningsysteem.


Doe dat maar eens dan. Dan kom je algauw uit bij een sun starfire.

Tegenwoordig is alles "commodity" wat de klok slaat. Opgeleukte desktopjes die net doen of ze goed genoeg zijn als server. Met een ingebouwde kvm (ook al met achterdeurtjes en zwakheden) want het systeemontwerp gaat nog steeds uit van "een computer, een persoon ervoor". En daar begint het inbouwen van zwakheden al.

Dankjewel voor je deskundige informatie!

https://en.wikipedia.org/wiki/Sun_Fire en met de overname van Sun http://www.oracle.com/us/products/m9000-erp-101309-bmark-070237.html Let even op het verschil in processors (sockets) 64 en cores 256.

Met de red box https://www.oracle.com/technetwork/server-storage/linux/partners/default-1742089.html moeten "applicaties" van concurrenten en third parties gecertificeerd worden.
Met IBM heb je https://medium.com/@fudo.abazovic/ibm-power-9-scales-to-enterprise-server-6fab5dc51487
Het aantal sockets is beperkt (4s) maar in een node clustering loopt het op. Dit zijn de machines voor een private cloud dan wel dienstverlening in huis door externe partijen (dienstverleners).
Daar hoort bij https://www-01.ibm.com/common/ssi/rep_ca/2/897/ENUS116-002/ENUS116-002.PDF (hint kvm). Het is een gesloten omgeving, je zult niet snel iets vinden.

Inderdaad eens:
de virtualisatie en de dogma's van een virtuele server per applicatie en je hebt dat begin van de zwakheden.

Tja misschien moet dit verholpen gaan worden in net zo een patch als dat ze Spectre destijds hebben bestreden.
Tevens misschien in de processor goed nakijken voordat ze een nieuwe bouwen dat deze bug ook verholpen wordt.
Maar ja waar gehakt wordt vallen spaanders toch?,niets gaat altijd 100% foutloos.
Met sommige kleinigheden valt te leven,maar die zijn niet merkbaar zo 123.

Bios optie. Boot optie van het OS, eventueel runtime optie in het OS .

Uitzetten kost je tussen de 0 en 30% performance van je systeem:
https://www.phoronix.com/scan.php?page=article&item=intel-ht-2018&num=1

(let op dat bij sommige grafieken 'kleiner is beter' ,bij andere 'groter is beter' - het staat er telkens bij, maar je moet daar wel naar kijken. )
Voor een wat oudere set van benchmarks voor specifiek gebruik , maar met erg grondige analyse en van een solide bron:

https://www.nas.nasa.gov/assets/pdf/papers/saini_s_impact_hyper_threading_2011.pdf

Linux - uitzetten tijdens runnen:
https://serverfault.com/questions/235825/disable-hyperthreading-from-within-linux-no-access-to-bios

Bij hyper threading heeft een CPU core een paar onderdelen dubbel uitgevoerd, en wordt de rest van de execution units daartussen gedeeld. Heel kort door de bocht kun je zeggen dat "1.x core gepresenteerd wordt als 2 core"

Hyperthreading werkt (en bestaat) omdat geheugen (access) tegenwoordig (15..20 jaar) enorm traag is vergeleken met de CPU. Een cache miss die naar DRAM moet kan honderden cycli kosten . In die tijd staan de execution units van de CPU niks te doen. Met HT kunnen ze dan werk doen voor de andere thread.
Met een bescheiden extra budget van transistors (en vooral stroom/warmte) heb je dus heel significante performance winst .

Als CPU bouwer heb je bepaald budget van transistors (of mm^2 silicium) en met name een bepaald budget van warmte wat je kunt laten produceren (en kunt afvoeren). Binnen die beperkingen wil je de meeste performance leveren.
Als je heel veel warmte laat produceren krijg je extreme koelingsoplossingen en ultra dure systemen (heel erg high end servers) . Als je veel transistoren gebruikt wordt de CPU duurder (meer kans op defecten bij fabricage), en moet je eventueel units dynamisch uitzetten tijdens gebruik, de klok frequentie terugbrengen. Hyperthreading is één optie om je plak silicum zoveel mogelijk nuttig werk te laten doen.

Ah, maar de problemen die bij spectre kwamen bovendrijven waren al bekend. Als in ze wisten heel goed dat de truuks die ze gebruikten om net dat beetje extra snelheid te halen wel eens voor problemen konden gaan zorgen.

Voor drie tientjes heb je al je eigen dedicated server. Dus voor zes tientjes kun je dus al volledig redundant werken. Zeker als je voor server 2 een totaal andere provider kiest.

Dat werken in de cloud veiliger is, is net zo een lulverhaal als dat je geld op de bank zetten veiliger is. (Ongeacht het saldo, meld maar eens dat je het morgen op komt halen en daarna de rekening gesloten mag. Dan maak je pas echt verwarde mensen mee.)

Cloud betekent wolk. Mist. Rookgordijn. Klink als McCloud, een oude politieserie van de TV. Van de good guys. Die dus altijd vechten tegen de bad guys. Dus dat klinkt veilig. Zolang je er niet mee gecloo(w)t wordt, of dat althans voorlopig niet door hebt kun je rustig gaan slapen. Detective McCould past op je data. En die is van de goeien.

Het blijft wel een mooi vak. Marketing.

Een gevatte opmerking van een commentator uit het Ars Technica forum:

“Intels chips run much like Windows users running everyday tasks on admin privileged accounts.”

De trucks zijn niet zo heel bijzonder. Meerdere werkers ipv een e enkele. Als je het als personeel/Slaven met eenvoudige opdrachten zou zien krijgt het handen en voeten.
Het probleem is dat codeurs zo niet denken deze hebben een lineaire wijze in denkwijze en handelen om een taak uit te voeren. Code en compiler moeten met de andere realiteit om kunnen gaan.

Na ik denk van niet. De CPU Central Processing Unit bestaat niet meer als je vele cores hebt.
Het klassieke doe eerst dit dan dat is daarmee achterhaald. Dat de mens als codeur daar problemen me heeft is wat anders.
"SMT uses resource sharing to make the parallel implementation economical." de overweging is:
"When one thread is waiting for a load instruction to complete, the core can execute instructions from another thread without stalling." het nadeel is dat je shared / gedeelde zaken hebt.
"Hyper-Threading (HT) allows instructions from multiple threads to run on the same core. "

Als je hem doorwerkt zie dat de geoptimaliseerde vector code geen doorlooptijd winst oplevert.
Het zijn dit soort programma's die ook weinig zullen lekken in een parallelle thread. Je hebt dan wel meer capaciteit om die andere thread ook te benutten zodat er in het geheel meer verwerkt kan worden. big data map reduce sparx.

Alweer 30%? Spectre en Meltdown mitigeren kostte ook al ca.20% performance.
Zitten we allemaal opeens met een halfbakken machine...

Is het ook niet een kwestie dat belangrijke afnemers gewoon openhardware vereisen bij leveranciers?

Open hardware met maar een beperkt aantal chip bakkers em motherboard fabrikanten op de wereld? Nee het groot commercie met schaalvergroting waar je uit bestaande componenten iets neerzet. Met die grote commerciëlen is het vrijwel onmogelijk om geen patentstrijd over triviale zaken te krijgen. Het is het kenmerk van een volwassen markt.

Het code ontwikkelen voor hardware met parallelle eigenschappen en security by design is hardcore software engineering. Niet iets wat verkopers en kopers als eis stellen. Die noemen een dbms erp analytics en een front end. Het zijn totaal andere belevingswerelden.

Ja als je ht al uitgezet ivm spectre jan je het niet nog eens uitzetten voor dit. Twee keer uit kan aan betekenen maar hier beter van niet. Deze keer kost je het 0%.

En hoe doe ik dat voor een Mac, eventueel voor een Mac met Linux daarop?

De mitigatie van Meltdown en Spectre bestond uit OS patches en microcode updates , niet uit het uitzetten van hyperthreading.

Het klopt dat als je om welke reden dan ook HT al had uitgezet je het niet nog een keer hoeft/kunt uit te zetten, maar als het aan stond en je vindt dat je het uit moet zetten kost het je dus typisch enkele tientallen procenten performance. Bovenop de performance die je had ingeleverd met de OS patches en microcode. (ook dat afhankelijk van workload)

Korte antwoord : nee. Dit soort side channels is ook niet echt een 'bug' die aangewezen had kunnen worden in chip code.

(dat is anders dan Meltdown, waarbij access speculatief gedaan werd zonder eerst naar privilege/owner van het object te kijken , dat kun je wel een echte chip-bug/design flaw noemen).

Het is haast dezelfde categorie als de eindeloze serie side-channels dat die ene universiteit als onderzoekjes hyped .
(spelen met ventilator, spelen met temperatuur, geluid van spoelen, etc waarmee een systeem wat bitjes informatie over een airgap naar buiten kan laten lekken.

Een Mac met Linux erop is gewoon een x86 met linux, en dan doe je wat ik hierboven geschreven heb.

Op een Mac met OS-X weet ik het niet.

Maar hoe gebruik je je OS-X mac dan dat je op één core malicious code hebt runnen en op een andere core een TLS server hebt hebt draaien ?

Ja je hebt gelijk met Spectre en Meltdown waren het andere delen van het shared gebruik op de cpu.
- de gedeelde memory cache (ook die weer)
- dat het willekeurig branches uitproberen toch tijdwinst oplevert. Waarom code niet beter zou kunnen zodat de cache beter bij is hebben nooit begrepen. Ja, het wordt veel meer cpu afhankelijk en vraagt veel meer onderhoud.

https://www.extremetech.com/computing/276138-is-hyper-threading-a-fundamental-security-risk
Het advies ht ofwel smt uit te zetten loopt gelijk op met Spectre en Meltdown.
Leg het onbegrip met shared resources op de sockets cpu met het eerdere ibm onderzoeksverslag en je ziet waar het wringt.
Een os kan met resource toewijzing in classes veel doen. Tijden veranderen de uitdagingen blijven zich herhalen.

Alu hoed mode:
lek ?
meh, NSA achterdeurtje die ontdekt is worden.

Waarom is AMD iets langzamer? Nou... Omdat zij wel de beveiliging in orde hebben. Intel geeft teveel beveiliging op voor snelheid.

Dit soort side channels is ook niet echt een 'bug' die aangewezen had kunnen worden in chip code.

(dat is anders dan Meltdown, waarbij access speculatief gedaan werd zonder eerst naar privilege/owner van het object te kijken , dat kun je wel een echte chip-bug/design flaw noemen).

Het is haast dezelfde categorie als de eindeloze serie side-channels dat https://whatstatus.co/non-veg-jokes die ene universiteit als onderzoekjes hyped .
(spelen met ventilator, spelen met temperatuur, geluid van spoelen, etc waarmee een systeem wat bitjes informatie over een airgap naar buiten kan laten lekken.