Beveiligingslekken in Intel-cpu's

[hans3702]

reviews: Beveiligingslekken in Intels cpu's - Is dit het einde van Hyper-Thre...

@TijsZonderH Dank voor een goed leesbaar bericht over een moeilijk en actueel onderwerp. De als H3 gemarkeerde tussenkopjes, een inleiding, en een samenvatting maken het TOP!! En daarbij ook veel links waar de lezer veel verdere info kan vinden.

Hans

[pven]

^ dat

[-The_Mask-]

En bij gaming is single clock speed ook meestal het relevantst.

Dat is tegenwoordig niet meer juist, tenminste niet voor moderne triple A games.

[downtime]

-The_Mask- schreef op zondag 19 mei 2019 @ 10:40:
[...]

Dat is tegenwoordig niet meer juist, tenminste niet voor moderne triple A games.

Dat ligt in werkelijkheid wel wat complexer. En die zin is genuanceerd genoeg om ook voor multithreaded games nog steeds op te gaan.

[-The_Mask-]

Hyper Threading geeft een groot voordeel in games. Probeer veel moderne games maar eens met een quadcore CPU zonder HT te spelen. Je zal ervaren dat zoiets op veel momenten eigenlijk niet meer gaat, terwijl dezelfde of vergelijkbare CPU met HT het stukken beter zal doen. Zelfs als die CPU met HT een iets lagere kloksnelheid heeft.

[ Voor 10% gewijzigd door -The_Mask- op 19-05-2019 10:54 ]

[makje]

@-The_Mask- er zijn games die met 4 cores te weinig hebben inderdaad, battlefield 5 bijvoorbeeld. In dat geval helpt HT op een quadcore, maar veel beter is om er echte cores bij te krijgen.
De Intel 9700k zonder HT wint soms van een 9900k met HT (en meer cache). De buren hebben zelfs een test gedaan met een 9900k met en zonder HT aan en de resulaten zijn gemixt maar gemiddeld zijn games beter af zonder HT https://nl.hardware.info/...et-en-zonder-ht-conclusie

Voor games heb je nog altijd liever snelle dan veel cores, terwijl een cpu met voldoende (bijvoorbeeld zes) fysieke cores zonder HT de voorkeur verdient boven bijvoorbeeld een quadcore mét HT, ook al zie je in dat laatste geval meer grafiekjes in Taakbeheer.

[ Voor 21% gewijzigd door makje op 19-05-2019 11:12 ]

[-The_Mask-]

Tweakers/HWI gebruiken dezelfde testdata voor reviews. Dus je hoeft in principe niet naar HWI te linken, Tweakers gebruikt dezelfde data. Maar het probleem is dat de testmethode zeer slecht is. De praktijk is heel anders. Is helaas al jaren bekend, maar men weigert fatsoenlijke testmethodes te maken voor PC hardware. Geen idee waarom trouwens. Maar dit is niet het topic voor het bespreken van die problemen.

[makje]

-The_Mask- schreef op zondag 19 mei 2019 @ 11:20:
Tweakers/HWI gebruiken dezelfde testdata voor reviews. Dus je hoeft in principe niet naar HWI te linken, Tweakers gebruikt dezelfde data. Maar het probleem is dat de testmethode zeer slecht is. De praktijk is heel anders. Is helaas al jaren bekend, maar men weigert fatsoenlijke testmethodes te maken voor PC hardware. Geen idee waarom trouwens. Maar dit is niet het topic voor het bespreken van die problemen.

ik weet niet wat de relevantie van je eerste zin is voor dit topic, zij waren een van de eerste hits met inhoud op google maar als tweakers eenzelfde review/test ergens heeft neergezet dan mag je die daar ook denken inderdaad. Maar als je ergens reviews of tests hebt die heel ander beeld geven van het nut van HT -naast die van een quadcore net even over het randje van "4 cores is te weinig in specifieke spellen" helpen- dan zie ik daar graag een linkje van, dat lijkt mij wel ontopic

[kluyze]

Ik heb ook het gevoel dat de eerste zin onder het kopje:

Betekent dit het einde van Hyper-Threading?
Wat het lek een stuk gecompliceerder maakt, is de relatie met simultaneous multi threading, of smt, een proces waarbij een processor gebruikmaakt van verscheidene fysieke cores om dezelfde berekening uit te voeren. Intels variant daarvan heet Hyper-Threading en dat proces maakt deze kwetsbaarheid makkelijker uit te buiten. Een update van de microcode vanuit Intel lost dat probleem enigszins op, maar niet helemaal, zegt Van Schaik. “De nieuwe microcode geeft ontwikkelaars van besturingssystemen een barrière. Die zorgt ervoor dat data in de buffers vóór de barrière niet gelekt kan worden door code ná de barrière. Dus als je wisselt van applicaties, kan het oude proces het nieuwe niet uitlezen tijdens speculative execution. Zo kun je dus via onze methode ook niets meer aflezen. Maar wanneer je Hyper-Threading aan laat staan, kun je niet voorkomen dat die barrière op beide threads geforceerd wordt. Daarom is het het veiligst om Hyper-Threading maar uit te schakelen.”

Iets niet geheel klopt, nog iets ontbreekt of mijn kennis is verkeerd.

Maar HT is toch net niet het gebruik maken van fysieke core. Ook is SMT toch niet specifiek om meerdere keren dezelfde berekening uit te voeren. Ik zou net verwachten dat dezelfde berekening ook dezelfde delen van een pipeline nodig hebben waardoor dit net niet geschikt is om door SMT op te lossen.

[ACM]

kluyze schreef op zondag 19 mei 2019 @ 11:47:
Ik heb ook het gevoel dat de eerste zin onder het kopje:

[...]
Iets niet geheel klopt, nog iets ontbreekt of mijn kennis is verkeerd.

Maar HT is toch net niet het gebruik maken van fysieke core. Ook is SMT toch niet specifiek om meerdere keren dezelfde berekening uit te voeren. Ik zou net verwachten dat dezelfde berekening ook dezelfde delen van een pipeline nodig hebben waardoor dit net niet geschikt is om door SMT op te lossen.

Die zin gooit inderdaad twee dingen door elkaar in relatie tot de titel en de zin erna.

Het lijkt me dat je verschillende fysieke cores juist gebruikt om dezelfde berekening te parallelliseren. Dus in die zin klopt de eerste zin

Maar dat heet 'multi core' of 'multi processor' en niet Hyper Threading. Bij Hyper Threading maak je juist gebruik van het feit dat een specifieke core vaak niet volledig wordt belast, dus dat een andere thread prima (min of meer) tegelijk die andere delen kan gebruiken.

[downtime]

ACM schreef op zondag 19 mei 2019 @ 11:56:
[...]

Het lijkt me dat je verschillende fysieke cores juist gebruikt om dezelfde berekeningen te parallelliseren. Dus in die zin klopt de eerste zin

Volgens mij is dit beter. Het kan namelijk om verschillende applicaties gaan of threads die volledig verschillende dingen doen.

[ Voor 14% gewijzigd door downtime op 19-05-2019 12:09 ]

[ACM]

downtime schreef op zondag 19 mei 2019 @ 12:08:
[...]

Volgens mij is dit beter. Het kan namelijk om verschillende applicaties gaan of threads die volledig verschillende dingen doen.

Meerdere cores kan je inderdaad voor allerlei soorten berekeningen gebruiken. Ook helemaal verschillende processen op die manier scheiden kan nuttig zijn omdat je dan effectiever gebruikt maakt van de diverse caches.

Maar waar HT niet bruikbaar is om dezelfde soort berekening parallel te doen, is dat met meerdere cores juist wel zo. Maar je hebt gelijk dat dat slechts 1 situatie is

[-The_Mask-]

makje schreef op zondag 19 mei 2019 @ 11:41:
[...]

ik weet niet wat de relevantie van je eerste zin is voor dit topic, zij waren een van de eerste hits met inhoud op google maar als tweakers eenzelfde review/test ergens heeft neergezet dan mag je die daar ook denken inderdaad. Maar als je ergens reviews of tests hebt die heel ander beeld geven van het nut van HT -naast die van een quadcore net even over het randje van "4 cores is te weinig in specifieke spellen" helpen- dan zie ik daar graag een linkje van, dat lijkt mij wel ontopic

Nee geen idee, geen onderzoek na gedaan. Maar je kunt niet eeuwig cores of threads toevoegen en verwachten dat de prestaties blijven stijgen. Als de CPU snel genoeg is, is die snel genoeg. Dan verschuift de bottleneck naar iets anders.

[Rudie_V]

kluyze schreef op zondag 19 mei 2019 @ 11:47:
Ik heb ook het gevoel dat de eerste zin onder het kopje:

[...]
Iets niet geheel klopt, nog iets ontbreekt of mijn kennis is verkeerd.

Maar HT is toch net niet het gebruik maken van fysieke core. Ook is SMT toch niet specifiek om meerdere keren dezelfde berekening uit te voeren. Ik zou net verwachten dat dezelfde berekening ook dezelfde delen van een pipeline nodig hebben waardoor dit net niet geschikt is om door SMT op te lossen.

Ik had dit ook al aangekaart toen ik spelfouten aangaf. En later nog in een reactie Rudie_V in 'reviews: Beveiligingslekken in Intels cpu's - Is dit het einde va... .
Het klinkt ook niet logisch "een proces waarbij een processor gebruikmaakt van verscheidene fysieke cores om dezelfde berekening uit te voeren". Ik weet niet hoe ik dit op moet vatten, het klinkt als dubbel op, waarom zou je dezelfde berekening op verscheidene fysieke cores uitvoeren? En een thread of taak van de ene core naar de andere core verplaatsen kost veelste veel latency en wil je niet.

Smt of ht is een techniek die een fysieke core virtualiseerd naar 2(of meer) logische cores zodat er twee(of meer) threads of taken op de ene fysieke core uitgevoerd kan worden. Dit gebeurt dan als de ene thread of taak iets doet waarop het moet wachten waarop deze uit de pipeline wordt gehaald en wordt 'geparkeerd' zodat de pipeline vrij komt voor een andere thread of taak. Het gevaar is dat de ene thread of taak door onjuiste beveiligingscontroles dan bij de data van de andere thread of data zou kunnen.

[Kabouterplop01]

@TijsZonderH Puike samenvatting. Ik zou graag zien wat voor prestatieverlies het bijwerken van de zachte waar tezamen met de microcode updates teweeg brengt.
Hele serverparken (In theorie) zijn ontworpen op een bepaalde schaalbaarheid en prestatie.
Misschien iets voor een deel 2? (Ik zelf denk een behoorlijke klus) Of een DEV Iteratie?

[Squee]

Ik hoop dat het stukje over SMT/HyperThreading nog wel aangepast wordt, we hadden daar bij het originele nieuwsbericht ook al een discussie over omdat er verwarring was ontstaan wat SMT/HyperThreading nou wel/niet is;
Squee in 'nieuws: Onderzoekers vinden nieuwe kritieke lekken in vrijwel alle ...

Kan SMT ook gewoon met hoofdletters worden geschreven in de tekst, omdat het een afkorting is? Het staat erg raar dat dit met kleine letters geschreven is.

Verder zit er nog een onjuistheid in het artikel;

En, niet onbelangrijk: bij zowel MDS als bij Meltdown ging het specifiek om alleen Intel-chips.

Dit is onjuist. De Arm Cortex-A75 core was namelijk ook getroffen door Meltdown.
Bron: https://developer.arm.com...e-processor-vulnerability (kolom "Variant 3")

Het is wel correct dat Intel het grootst/hardst getroffen was door Meltdown, aangezien in het geval van Arm alleen een enkel core ontwerp betrof. Aan de andere kant ook wel logisch; hoge bomen vangen veel wind.

[ACM]

Kabouterplop01 schreef op zondag 19 mei 2019 @ 18:52:
@TijsZonderH Puike samenvatting. Ik zou graag zien wat voor prestatieverlies het bijwerken van de zachte waar tezamen met de microcode updates teweeg brengt.
Hele serverparken (In theorie) zijn ontworpen op een bepaalde schaalbaarheid en prestatie.
Misschien iets voor een deel 2? (Ik zelf denk een behoorlijke klus) Of een DEV Iteratie?

Ik weet niet in of en wanneer de redactie van Tweakers er iets over gaat schrijven.

Maar het develoment team is er niet actief mee bezig. We hadden wel een tijd lang 1 webserver met spectre-mitigations en de rest zonder draaien. En het verschil was wel vrij groot; niet zo groot dat je het als gebruiker merkt, maar wel groot genoeg om die server er negatief uit te zien komen.
Dat is echter het enige soort server waarvan we het uberhaupt praktisch kunnen meten. Al onze andere servers hebben een of meer van deze 'nadelen' (en wellicht vergeet ik er nog een paar):
- relatief lage load - of juist met loadpieken - waardoor de verschillen moeilijk te zien zijn
- 1 primaire server die het gros van het werk krijgt en er dus geen 'real time' vergelijking mogelijk is
- we monitoren de performance er niet van op het hiervoor benodigde detailniveau

Alle andere tests vereisen dat we fictieve situaties gaan opzetten; en los van dat we dan in potentie productieservers uit productie moeten halen is dat een behoorlijke klus (en zoals de reacties van @-The_Mask- suggereren is het moelijk om dat dan alsnog goed te doen ).

Maar gelukkig heeft in ieder geval Phoronix al een eerste artikel hierover gepubliceerd. Dus specifiek voor jouw behoefte is er al minstens 1 antwoord dat lijkt op de tests die we vanuit ons serverbeheer zouden doen

[TijsZonderH]

@kluyze @Rudie_V Jullie hebben gelijk, slordige fout van mijn kant. Ik heb het aangepast, thanks voor de oplettendheid!

[Squee]

Bedankt voor de correcties!

[Rudie_V]

TijsZonderH schreef op maandag 20 mei 2019 @ 09:03:
@kluyze @Rudie_V Jullie hebben gelijk, slordige fout van mijn kant. Ik heb het aangepast, thanks voor de oplettendheid!

[Kabouterplop01]

ACM schreef op maandag 20 mei 2019 @ 08:37:
[...]

Ik weet niet in of en wanneer de redactie van Tweakers er iets over gaat schrijven.
..snip..

Maar gelukkig heeft in ieder geval Phoronix al een eerste artikel hierover gepubliceerd. Dus specifiek voor jouw behoefte is er al minstens 1 antwoord dat lijkt op de tests die we vanuit ons serverbeheer zouden doen

Waanzinnig goed!

[ACM]

Kabouterplop01 schreef op dinsdag 21 mei 2019 @ 07:20:
Waanzinnig goed!

Phoronix heeft ondertussen trouwens ook een serverversie uitgebracht, maar het effect lijkt ruwweg hetzelfde behalve bij de allernieuwste Intel cpu's, die (deels?) hardwarematige mitigatie van Spectre/Meltdown heeft. Die wordt wat minder sterk beinvloed (meer vergelijkbaar met AMD).

[Kabouterplop01]

ACM schreef op dinsdag 21 mei 2019 @ 08:04:
[...]

Phoronix heeft ondertussen trouwens ook een serverversie uitgebracht, maar het effect lijkt ruwweg hetzelfde behalve bij de allernieuwste Intel cpu's, die (deels?) hardwarematige mitigatie van Spectre/Meltdown heeft. Die wordt wat minder sterk beinvloed (meer vergelijkbaar met AMD).

Dank! (Ik denk namens meer medetweakers) Goed naslag werk wil je voor (specifieke) setups bepaalde performance hebben, hier rekening mee houdend.