Whiskey Lake-cpu's hebben hardwarematige bescherming tegen Meltdown en L1TF

Intel kondigde deze week zijn Amber Lake en Whiskey Lake-processors aan, waarbij die laatste reeks hardwarematige bescherming heeft voor Meltdown en L1TF. Dat bevestigt de chipmaker. Er is geen hardwarematige bescherming aanwezig in Amber Lake-cpu's.

Intel bevestigde de hardwarematige aanpassingen aan Tom's Hardware. Het stelt dat er volledige bescherming aanwezig is tegen Meltdown en L1TF ofwel Foreshadow, kwetsbaarheden die in de loop van dit jaar in Intel-processors zijn gevonden. De eerste maakt het mogelijk om kernelgeheugen vanuit userspace uit te lezen en de tweede heeft toegang tot de L1-cache van de cpu, die bijvoorbeeld data uit SGX-enclaves bevat. Daar zijn tot nu toe al softwarematige mitigations voor beschikbaar gesteld, maar nu dus ook in de hardware zelf. Die zouden minder nadelige gevolgen voor de prestaties van een systeem moeten hebben.

Dat betekent echter niet dat alle lekken die Intel aanduidt met side-channel methods zijn aangepakt in Whiskey Lake, zoals uit onderstaande tabel is op te maken. Bijvoorbeeld voor Spectre en aanverwante varianten zijn alleen patches via microcode en het besturingssysteem beschikbaar. Intel zegt verder tegen Tom's Hardware dat de hardwarematige aanpassingen alleen in Whiskey Lake aanwezig zijn, maar niet in Amber Lake. De chipmaker kondigde deze week laptopchips binnen deze generaties aan.

De Core i3-8145U, i5-8265U en i7-8565U zijn daarmee de eerste consumentenprocessors die een vorm van hardwarematige bescherming hebben tegen de Meltdown- en L1TF-kwetsbaarheden. Het zijn niet de enige chips die Intel van hardware aanpassingen heeft voorzien. Zo werd twee weken geleden bekend dat Intel ook hardwarematige bescherming aanbrengt in de komende Xeon-cpu's van de Cascade Lake-generatie. De beschermingsmaatregelen in Cascade Lake en Whiskey Lake zijn echter niet gericht op dezelfde kwetsbaarheden. Intel zegt dat het de aanpassingen in hardware in de loop van de tijd wil uitbreiden.

Kwetsbaarheidsvarianten	Whiskey Lake	Cascade Lake
Variant 1 / Bounds Check Bypass	OS	OS en VMM
Variant 2 / Branch Target Injection	Firmware en OS	Hardware + OS en VMM
Variant 3 / Rogue Data Cache Load (Meltdown)	Hardware	Hardware
Variant 3a / Rogue System Register Read	Firmware en OS	Firmware
Variant 4 / Speculative Store Bypass	Firmware en OS	Firmware + OS en VMM
Variant 5 / L1 Terminal Fault (L1TF)	Hardware	Hardware

Informatie afkomstig van Tom's Hardware en Intel

Reacties (65)

[Squee]

Mooi dat de hardwarematige oplossing voor Meltdown en L1TF er al is, dat zal een redelijk ingrijpende verandering zijn, dus ik ben best positief verrast dat ze dat na een jaar er nu in hebben zitten. Beide Metldown en L1TF problemen hebben dezelfde oorzaak in de processor namelijk; het niet goed controleren van page table permissies op een speculatieve load, en vervolgens de data van het geladen adres speculatief zichtbaar maken voor opvolgende instructies. Een oplossing zou simpelweg kunnen zijn dat als de permissie check faalt de doorgegeven waarde altijd 0 is, zo lek je gegarandeerd geen informatie.

Deze verandering is wel in een zeer kritiek pad binnen je Load-Store unit, dus die is niet zo simpel/snel gemaakt (namelijk op het 3 of 4-cycle pad om je L1D cache te benaderen). Als Intel dit sinds afgelopen zomer wist en nu in een nieuwe chip heeft zitten, kan je er van uit gaan dat dit een aanpassing is die zeer zeer laat in de processor design cycle geweest is, maar waarschijnlijk de eerstvolgende waar ze het op tijd in konden krijgen. Dit zal wellicht als een ECO patch^[1][2] gedaan zijn, waarbij alle place & route van de rest van je chip al vast ligt en je hooguit in je metal layers wat verbindingen kan omwisselen naar eventuele 'reserve logica' die vaak in de whitespace ingebakken zit. Opnieuw de layout doen en alle masks en tapeout zouden ze zo laat in het design niet meer doen verwacht ik.

Overigens is deze hardwarematige oplossing het ding wat AMD vanaf begin af aan wel goed had gedaan in hun designs; deze twee varianten waren ze daarom niet vatbaar voor.

[Toevoeging]: Nog een belangrijke voetnoot die te maken is bij deze fix is dat Meltdown van alle Spectre varianten het makkelijste uit te buiten en daarom het meest schadelijk was. Wat dat betreft is het ook geen verassing dat we hier als eerste een solide fix hardware voor zien.

[Reactie gewijzigd door Squee op 22 juli 2024 14:49]

[xorpd]

Kleine aanvulling: Intel doet de permissie check vlak voor de retire terwijl AMD de permissie check doet bij de TLB-lookup. Dat scheelde Intel 1 kloktik.

[Squee]

Kleine aanvulling: Intel doet de permissie check vlak voor de retire terwijl AMD de permissie check doet bij de TLB-lookup. Dat scheelde Intel 1 kloktik.

Nee, dat is niet geheel correct, de permissie check gebeurt niet in Retire, maar wordt dan pas gesignaleerd en architectureel zichtbaar omdat de processor dan een exceptie om de oren krijgt. Dat is in AMD's micro-architectuur ook zo, maar die zijn wel zo slim om niet speculatief een ontoegankelijke waarde door te sturen, en dat staat daar los van.

Laat ik het proberen uit te leggen door echt even diep in de details te duiken. Een load/store unit pipeline in een moderne out-of-order processor doet ongeveer de volgende stappen voor een Load (vanaf issue);
1) adrescomputatie
2) memory disambiguation [prediction] (is er een oudere store die nog niet retired is die naar het zelfde adres schrijft als deze load)
3) TLB lookup en L1D cache set indexing
4) L1D cache tag comparison met TLB resultaat
5) memory disambiguation gebaseerd op het fysiek adres geproduceerd door de TLB (checkt dus of voorspelling bij 2) correct was), lees dan de waarde van de oudere store
6) Indien je een hit had in de TLB en in de L1D of via memory disambiguation, maak het resultaat beschikbaar voor dependent instructies, en anders begin een TLB miss of L2 cache request.

Dit is een beetje een grove schets, en sommige van deze stappen kunnen samen in een cycle uitgevoerd worden. In moderne processoren is het kritieke pad tussen de 3 en 5 cycles tussen het starten van de executie van een Load instructie, en dat een opvolgende instructie het resultaat kan gebruiken in het meest gunstige geval (TLB en L1D hit). Deze latency is ook niet altijd het zelfde in een design; het resultaat van een L1D hit is vaak sneller beschikbaar dan een uit de memory disambiguation unit. Het is ook eigenlijk niet een pipeline maar een splitsing in verschillende paden afhankelijk van waar het resultaat vandaan komt, en met verschillende exit paden om een resultaat te produceren.

Voor processor performance is het enorm belangrijk dat deze zogeheten load-to-use latency zo kort mogelijk is, het bepaald bijvoorbeeld de maximale snelheid waarmee je processor een stuk pointer-chasing code kan uitvoeren, omdat dit allemaal sequentieel afhankelijke loads zijn. Vandaar dat je wil dat het resultaat zo snel mogelijk doorgestuurd kan worden naar opvolgende, afhankelijke, instructies.

Afhankelijk van hoe het in een specifieke processor geimplementeerd is, weet je na 3) naast of het een TLB-hit was, en wat de adres translatie was, wel of niet meteen wat de permissies waren voor deze TLB entry. In Intel's implementatie is dat blijkbaar niet beschikbaar voordat stap 6) gebeurt, terwijl AMD dit wel heeft en dan (vermoedelijk) het resultaat wat in 6) wordt doorgestuurd op 0 zet. (dit is wat ze nu gefixed hebben bij Intel). De instructie krijgt dan een vlag dat er een exceptie moet plaatsvinden. Omdat dit allemaal nog in het out-of-order gedeelte van de processor plaatsvindt, betekent het dat deze instructie nog speculatief was, dus je gaat nog niet meteen actie ondernemen.

Nadat de instructie de load-store unit pipeline heeft verlaten moet hij wachten tot hij de oudste instructie wordt (dus dat alle voorgaande instructies klaar en retired zijn) voordat hij door de in-order Commit/Retire pipeline kan gaan. Daar wordt de architecturele staat geupdate, en worden alle excepties op een instructie gedetecteerd. Dit deel van de processor werkt weer in-order om de sequentieele semantiek van een programma te behouden. Het resultaat van een instructie is pas definitief na Retire, dus als er een exceptie vlag gedetecteerd wordt kan de hele core geflushed worden en is het net alsof deze instructie en alle instructies hierna nooit uitgevoerd zijn.... nou ja, behalve dan dat Spectre ons liet zien dat er bepaalde side-channels zijn waar je wel dit speculatieve gedrag kon detecteren

[edit]: Text nog wat verbetert

[Reactie gewijzigd door Squee op 22 juli 2024 14:49]

[xorpd]

Ik neem aan dat je met 2) store forwarding bedoelt.

Verder zover ik het begrepen heb is bij Intel pas tijdens de retire bekend dat de load niet toegestaan was maar bevindt de data zich al wel in cache. Bij AMD is echter de cache lookup niet gebeurd en hoeft er dus ook geen 0 voor in de plaats te komen.

Als dit waar is zoals ik beschrijf is de meest eenvoudige fix voor Intel niet het veranderen van de pipeline maar simpelweg het invalideren van de betreffende cacheline.

[Squee]

Ik neem aan dat je met 2) store forwarding bedoelt.

Ja en nee. Bij 2) voorspel je of een load waarschijnlijk het zelfde adres als een store zal benaderen, maar je hebt de adres translatie nog niet van de TLB dus je weet het nog niet zeker. Door dit vroeg te voorspellen kan je eerder de data van de store ontvangen. Pas bij 5) kan je werkelijk de waarde van de store lezen en forwarden. Het is deze voorspelling bij 2) die om de tuin geleid kan worden voor Spectre v4, Speculative Store Bypass.

Verder zover ik het begrepen heb is bij Intel pas tijdens de retire bekend dat de load niet toegestaan was maar bevindt de data zich al wel in cache. Bij AMD is echter de cache lookup niet gebeurd en hoeft er dus ook geen 0 voor in de plaats te komen.

Als dit waar is zoals ik beschrijf is de meest eenvoudige fix voor Intel niet het veranderen van de pipeline maar simpelweg het invalideren van de betreffende cacheline.

Het is mij niet duidelijk wat het invalideren van de cacheline je hier zou opleveren. Je hebt een Load instructie die schrijft zijn resultaat naar een register, en dan een opvolgende instructie die dat register als input waarde gebruikt. Deze waarde zal dus via je bypass netwerk tussen de instructies worden overgedragen, en daar heeft de cache niets mee te maken. Het is deze bypass die je wil afvangen indien de Load een permissie fout oploopt terwijl je data wel terug komt uit je L1D cache. De data is al onderweg uit de L1D cache omdat dit parallel gebeurt met je TLB lookup (Virtually Indexed, Physically Tagged cache).

Het is belangrijk te realiseren dat Retire in een out-of-order core wel honderden cycles later kan plaatsvinden dan de werkelijke executie van een instructie (als er bijvoorbeeld een oudere Load is die helemaal naar geheugen moest). Op het moment dat een Load retired maakt het ook niet meer uit of de data die hij geladen had op dat moment nog in de cache staat of niet, want deze is al tijdens de executie fase doorgestuurd aan opvolgende instructies.

[xorpd]

Volgens mij was het probleem met Meltdown (waar ik het over heb) dat een speculative load heeft plaatsgevonden waardoor de L1D cache data bevat waar het proces eigenlijk niet bij mag. Vervolgens wordt met een truc deze data uit de cache gevist. Correct me if I'm wrong.

[Squee]

Volgens mij was het probleem met Meltdown (waar ik het over heb) dat een speculative load heeft plaatsgevonden waardoor de L1D cache data bevat waar het proces eigenlijk niet bij mag. Vervolgens wordt met een truc deze data uit de cache gevist. Correct me if I'm wrong.

Dat er data in de L1D cache staat waar het huidig draaiende proces niet toegang tot hoort te hebben is in principe geen probleem. Dit soort situaties kunnen ook makkelijk voor komen; bijvoorbeeld net na een context switch, dan staat er waarschijnlijk nog informatie van de kernel of het vorige proces in de cache, of als je met HyperThreading (of een andere SMT implementatie) verschillende processen tegelijkertijd op je core gescheduled hebt omdat ze dezelfde L1D cache delen. Dit is een van de redenen dat elke geheugentoegang door je TLB/MMU vertaald wordt, om uit elkaar te houden welke data van wie is en wie waar bij mag.

Het is wel inderdaad het geval dat om Meltdown succesvol uit te voeren op een stuk data, deze data aanwezig moet zijn in de L1D cache. Vreemd genoeg bleek het ook mogelijk te zijn om bepaalde kernel data met prefetches naar de L1D te halen zonder dat toegang tot die data mogelijk zou zijn (ik vraag me af of ze dat nu ook gefixed hebben). Wat ze nu hebben aangepakt is dat je niet meer deze data kan lekken naar opvolgende speculatieve instructies, en flushen van de data uit de cache is daarom niet nodig. Dat zou waarschijnlijk ook een meer kostbare operatie zijn, bijvoorbeeld als je eerst een write-back moet doen.

[xorpd]

De prefetcher heeft geen privilige checks onderdeel van de semantiek van de instructie (prefetch zal nooit een exception triggeren). Ik zal eens op zoek gaan naar de Meltdown proof-of-concept code, anders blijft het speculeren van mijn kant.

[Squee]

De prefetcher heeft geen privilige checks onderdeel van de semantiek van de instructie (prefetch zal nooit een exception triggeren). Ik zal eens op zoek gaan naar de Meltdown proof-of-concept code, anders blijft het speculeren van mijn kant.

Dat is waar; prefetch instructies zijn ook in feite "hints" waar de hardware mee kan doen en laten wat ze wil. Maar ook een prefetch zal vertaald moeten worden naar een fysiek adres door de TLB/MMU, dus als dat naar een adres is waar die context geen toegang toe hoort te hebben, dan is het toch wel vreemd dat er alsnog een request naar de L2 cache en verder wordt gestuurd. Die informatie is in principe wel beschikbaar, maar het zijn een beetje fire-and-forget instructies, dus ja ze kunnen geen exception genereren. Op sommige implementaties kan een prefetch ook een hardware tablewalk genereren bij een TLB miss voor het prefetch adres, maar ook dat is niet gegarandeerd.

Goed, misschien drijven we wel een beetje erg ver af off-topic nu...

[Silence]

Vind het hele gebeuren sowieso al opgeblazen van deze exploits

[kaas-schaaf]

Voor jouw wellicht wel, maar voor iedereen die VM's gebruikt, clusters aanspreekt, AWS/Azure/Google gebruikt voor bedrijfstoepassingen en nog veel meer bedrijfsmatige systemen, heeft dit wel impact (decreased performance voornamelijk als het gepatched is).

edit: dit is dus eigenlijk iedereen, maar jij merkt het alleen niet

[Reactie gewijzigd door kaas-schaaf op 22 juli 2024 14:49]

[Verwijderd]

Vergeet niet dat wij als consument ook gewoon allemaal langzamere computers hebben na de patches!

[kuurtjes]

Vanaf dat ze die domme namen zijn beginnen geven ben ik ook beginnen facepalmen.

L1TF is tenminste nog een deftige naam.

[Sandor_Clegane]

WTF was een betere geweest.

[Finraziel]

Mijn eerste gedachte was ook "huh? Ze hebben toch al heel lang beveiliging tegen oververhitting? Oh wacht dat zijn die cpu lekken!"

[Nijl]

Moet ik me als consument nou echt zorgen gaan maken om dit -lek-?

[Axewi]

Zorgen maken zou ik niet doen, er zijn patches beschikbaar voor zo'n beetje elk OS. Wat je wel moet doen is zorgen dat je de boel dus bijgewerkt hebt (maar dat is sowieso al best practice).

Verder zou ik even wachten met upgraden totdat je een cpu kan aanschaffen met de hardwarematige fix.

[totaalgeenhard]

Het zijn geen patches maar workarounds.

Kwaadwillende kan het ongedaan maken.

Bovendien voor computer die als werkplek in gebruik is maakt het niet uit, men heeft dan al toegang tot gegevens van gebruiker.

Je hebt een veel groter probleem als derde van afstand al op je computer code kan uitvoeren.

Heb je meer rechten nodig kun je lokale exploit gebruiken:

nieuws: Amerikaans Cert waarschuwt voor op Twitter verschenen Windows-zero-day

[Dennism]

Patches en microcode updates kunnen inderdaad ongedaan gemaakt worden. Echter als iemand al zover in je systeem zit dat deze microcode aanpassingen kan doen en patches verwijderen zonder dat dit gemerkt zal worden dan heb je een veel groter probleem dan een spectre of meltdown kwetsbaarheid.

[totaalgeenhard]

Doh....

Op Windows client maakt workaround daarom niets uit.

Lees me andere reactie eens je deed een halve cut and paste.

[Mellow Jack]

Sowieso geen zorgen maken als je niet direct met het internet bent verbonden, geen vage zooi download en je systeem netjes op orde is.

In theorie kan je telefoon kwetsbaar zijn maar die worden meestal netjes op andere manieren beschermd op OS niveau. Tot nu toe heb ik 1 remote voorbeeld gezien maar voordat dat specifieke voorbeeld echt bruikbaar is ben je 10 jaar verder

Deze issues veroorzaken meestal pas echt een risico bij hosting partijen (van websites tot virtual private cloud) waarbij hardware gedeeld word door meerdere afnemers. Als je als consument daar niets mee doet loopt je vrijwel geen risico

[totaalgeenhard]

Nee, omdat als men dit op een privé Windows machine kan uitbuiten je een veel groter probleem hebt, immers ze hebben al toegang tot je computer en de data van de gebruiker die ingelogd is.

Via browser dit benutten maakte daarbij ook niet veel uit.

De grootste risico is voor gevisualiseerd omgeving zoals CLOUD hosting waarbij elke klant een risico is omdat via zijn toegang meer rechten en toegang tot hardware en daarmee (mogelijk) andere gevirtualiseerde omgevingen kan verkrijgen.

[InsanelyHack]

En dat maakt dan weer minder uit als je bij je cloud provider op rerserved / private instances / hardware zit. Dit is niet voor iedere cloud klant te betalen maar voor systemen die cruciale data processen in enterprise omgevingen is dit dan wel weer belangrijk.

[flippy]

nee.

[ferragosto]

Een terugroepactie voor alle overige 8th gen processoren zou ik niet meer dan netjes vinden, maar ik denk dat we dat wel kunnen vergeten...

[Croga]

Waarom alleen van 8th gen? ALLE processoren sinds (heel lang geleden) hebben deze kwetsbaarheden. Gaan we die allemaal terugroepen dan? En alle processoren die andere kwetsbaarheden hebben dan? Ook maar terugroepen? Alle software met kwetsbaarheden? Alle telefoons, tablets, laptops, cameras, autos, koelkasten, magnetrons, etc die kwetsbaarheden hebben terugroepen?

Ik denk dat er heel erg weinig van de economie over blijft als we aan dat soort acties gaan beginnen.......

[Countess]

ALLE intel processoren

FTFY

natuurlijk hebben AMD CPU's ook fouten, maar voor deze hele familie aan security problemen is AMD aardig buiten shot gebleven. er is zelfs nog geen succesvolle demonstratie gegeven op een ongemodificeerd AMD systeem van spectre.

AMD zegt dat er near zero risk is. Meteen vanaf het begin al.

[Reactie gewijzigd door Countess op 22 juli 2024 14:49]

[Dennism]

AMD heeft zelf al aangegeven dat ze vatbaar zijn voor bepaalde Spectre varianten en daar microcode voor uitgebracht via hun partners, al geven ze ook aan dat ze geloven dat enkele van deze exploits lastig uit te voeren zullen zijn. Zie AMD's eigen guidance op met de door AMD aanbevolen mitigations op https://www.amd.com/en/corporate/security-updates

In deze PDF gaan ze er nog wat dieper op in en geven ze ook wat duidelijker aan wat wel / niet van toepassing is op AMD cpu's.

https://developer.amd.com...ion_WP_7-18Update_FNL.pdf (Meltdown en andere varianten waar AMD niet vatbaar voor is, staan niet in het document voor zover ik kan zien, dus alleen de varianten waar ze wel vatbaar voor zijn).

[Reactie gewijzigd door Dennism op 22 juli 2024 14:49]

[Countess]

AMD zelf noemt het risico 'naar zero'. Dat is dus totaal anders als bij Intel.

Tot nu toe zijn ze alleen theoretische vatbaar. Zelfs de beveilingsexperts samen met amd konden geen manier bedenken om van spectre misbruik te maken op een niet gemodificeerd AMD systeem.

Het enige dat amd heeft gedaan is zelfs dat theoretische risico weggenomen.

Totaal anders als bij Intel dus.

[Reactie gewijzigd door Countess op 22 juli 2024 14:49]

[Dennism]

Ik meende ook dat AMD het eerder had over "Near zero", echter zijn die verwijzingen niet meer te vinden in officiële documentatie van AMD, ten minste, ik kan ze niet meer vinden. Het enige dat er nog staat is dat ze bij variant 2 geloven dat die variant lastig uit te voeren is.

Verder zijn zaken als "near zero" en "geloven dat iets lastig uit te voeren is" leuk, maar kan je daar, zeker op de zakelijke markt, eigenlijk maar weinig mee. Tenzij je een bevestiging krijgt dat een exploit niet uitvoerbaar is en er dus geen vatbaarheid is, zoals Meltdown of L1TF, zal je alsnog gewoon moeten patchen en kun je ook niet roepen dat je niet getroffen bent. Dat ze minder getroffen zijn dan Intel staat vast, maar minder is niet hetzelfde als "niet getroffen". En ga ik liever uit van de documentatie zoals verstrekt door AMD dan van random informatie op websites van 3de partijen.

[Reactie gewijzigd door Dennism op 22 juli 2024 14:49]

[Proxx]

Intel bedient 80% van de desktop markt. hoge bomen vangen veel wind lijkt me.

[Countess]

Het is wel iets meer als dat. Spectre was bijna iedere vatbaar voor, tot alle moderne ARM cpu's van verschillende fabrikanten aan toe. En zelfs amd heeft ook de originele fout. Maar omdat AMD zijn zaakjes beter op orde heeft op een dieper nivo kan je er als nog niks mee.

Vandaar ook dat amd vrij snel met de statement kwam dat er een near zero risk was. En dat statement staan ze nogsteeds achter.

Er gaan nog veel meer spectre achtige exploits komen, en AMD zal voor de meeste, zo niet alle, niet vatbaar zijn.

[Reactie gewijzigd door Countess op 22 juli 2024 14:49]

[Proxx]

Ik Kan niet anders dan onderkennen dat jij beter op de hoogte bent dan mij

Maar die laatste zin daar geloof ik dat weer niet veel van

Er gaan nog veel meer spectre achtige exploits komen, en AMD zal voor de meeste, zo niet alle, niet vatbaar zijn.

Dit is een uitspraak die nogal een hoog fanboy gehalte heeft, ik denk dat geen enkele hardware en software producent dat waar kan maken

[Powermage]

Als een autofabrikant nu nog auto's uitlevert die productieproblemen voor de veiligheid hebben mogen ze ook alles terug roepen, intel produceert op dit moment nog honderduizenden 'defecte" processoren die ze gewoon nog uitleveren.
Oke, een stop op die cpu productie en wachten tot een nieuwe versie er is dat is ook niet te doen, maar ergens is het wel gek dat ze er zo makkelijk mee weg komen.

[Croga]

Als een autofabrikant nu nog auto's uitlevert die productieproblemen voor de veiligheid hebben mogen ze ook alles terug roepen, intel produceert op dit moment nog honderduizenden 'defecte" processoren die ze gewoon nog uitleveren.

Als die auto softwarematig weer veilig is, wordt die echt niet terug geroepen. Tesla doet dit regelmatig. Intel doet hier hetzelfde.

Oke, een stop op die cpu productie en wachten tot een nieuwe versie er is dat is ook niet te doen, maar ergens is het wel gek dat ze er zo makkelijk mee weg komen.

Waar mee? Met patchen en doorgaan? Je weet wel, zoals iedereen dat doet?

[Powermage]

Voor zover ik t begreep is het probleem net dat een deel van de problemen niet goed op te lossen zijn met alleen patches, in sommige gevallen moet je bijvoorbeeld ook nog Hypertreading uit zetten of haal je geen totale bescherming, mocht ik dat fout hebben dan gaat mijn vergelijking niet op nee.

[Mellow Jack]

Als je naar de totale cpu verkoop kijkt is het probleem ook echt een probleem voor maar een klein percentage van de cpu markt. Als je ervoor kiest om shared resources te gebruiken dan accepteer je het risico... Nou ja eigenlijk accepteer je het feit dat elk component wel z'n fouten bevat en dat de combinatie van verschillende tegenmaatregelen iets veilig maken... Elke tegenmaatregel heeft z'n impact, het maakt iets complexer of langzamer. Dat is naar mijn mening totaal niet te vergelijken met de auto branche.

[OruBLMsFrl]

Dat hyperthreading verhaal lijkt vooral iets om rekening mee te houden als je andere processen of virtuele machines op je eigen systeem niet zou vertrouwen. Bijzonder relevant voor providers/hosters, niet tot nauwelijks voor consumenten nu browsers ook proces isolatie zijn gaan toepassen.

Vermoedelijk is het virtuele machine verhaal ook hoofdreden dat de nieuwe Cascade lake server processoren al wat hardware bescherming krijgen, dat marktsegment is al spannend genoeg voor Intel met de AMD Epyc die nog meer cores bevat en toch al wat minder last van heeft van dit lijstje kwetsbaarheden.

[AmigaWolf]

Ow Tom's Hardware neem ik ook al niet meer serieus, vooral als je DEZE gezien heb, ze zijn de laatste jaren echt slecht geworden.

[Reactie gewijzigd door AmigaWolf op 22 juli 2024 14:49]

[Pb Pomper]

Tom's Hardware US welteverstaan. Tom's Hardware Germany was ook niet bepaald blij met de acties van hun US naamgenoten en hebben dit ook laten weten op hun forum, waarna ze vervolgens gebant werden

[AmigaWolf]

Ow ja, of maak je nu een geintje?

[GTB]

Bij ons (kleine leverancier van Cloud diensten zoals Online Werkplekken) is alles "opgelost" zonder hyper-threading uit te schakelen. Daar hebben wij best wat voor moeten doen, zoals een 2e keer micro-code updates installeren en de scheduler van onze hyper-v servers aan moeten passen.

Al met al nog aardig kunnen oplossen. We draaien nog steeds dezelfde hoeveelheden users & VM's op onze fysieke servers..

[ReLexEd]

Als die auto softwarematig weer veilig is, wordt die echt niet terug geroepen. Tesla doet dit regelmatig. Intel doet hier hetzelfde.

True... maar als Tesla een patch zou vrijgeven die ervoor zou zorgen dat de topsnelheid van de auto ineens met 20% naar beneden gaat als gevolg daarvan, dan hebben ze de poppen aan het dansen...

Dat verhaal op een CPU die ineens 20% minder performance levert, tja.... Daar kan ik me van voorstellen dat mensen die in de afgelopen laten we zeggen 12 maanden een processor hebben gekocht, zich best wel bekocht voelen.,..

Tuurlijk, je koopt een Tesla niet vanwege z'n topsnelheid, maar een CPU daarintegen.... daar is performance toch wel een sellingpoint.... Iets met Bang-for-buck.....

[Reactie gewijzigd door ReLexEd op 22 juli 2024 14:49]

[G4n0nD0rf]

Dat is anders exact wat er gebeurd is met dieselgate

[mjl]

Als en het al te vergelijken is het meer dat de fabrikant eenmaligere tdp aan geeft dan in de praktijk het uiteindelijk is ....

[ReLexEd]

Dat is anders exact wat er gebeurd is met dieselgate

True, en daar zaten ook behoorlijke financieele sancties aan vast... boetes, afkoopsommen om vervolging/aansprakelijkheid te schikken...

Ik zou er niet gek van op hebben gekeken, als Intel door instanties zou zijn gedwongen om kopers van laten we zeggen de afgelopen anderhalf jaar te compenseren, en kopers in de afgelopen 6 maanden zelfs de mogelijkheid te moeten geven om hun CPU's kostenloos te retourneren, of tegen gereduceerde meerprijs te upgraden naar een 'gefixed' model...

[Croga]

Dat verhaal op een CPU die ineens 20% minder performance levert, tja.... Daar kan ik me van voorstellen dat mensen die in de afgelopen laten we zeggen 12 maanden een processor hebben gekocht, zich best wel bekocht voelen.,..

Dan is het maar goed dat deze "kwetsbaarheden" voor 99% van de gebruikers helemaal niet van toepassing zijn.

[SgtElPotato]

20% is ook erg overdreven. In benchmarks is vaak 5% gemiddeld, dat zal vrijwel niemand merken in de praktijk.

[ReLexEd]

Klopt... doelde ook niet op een percentage dat deze softwarematige oplossingen aan performance-hit hebben.

Maar 5%... De gemiddelde tweaker werkt dat toch wel?
(Da's bij mij meestal het kantelpunt dat ik me afvraag of ik software opnieuw moet gaan installeren, of dat het tijd wordt om hardware te gaan upgraden... ;-) )

[Knightwolf]

Dat verschil is goed te onderbouwen. Bij auto's gaat het meestal om fysieke veiligheid van mensen, bij computerhardware gaat het alleen om digitale veiligheid. Das toch echt anders.

[Dennism]

Hou er rekening mee dat het niet alleen Intel is, zoals bijvoorbeeld @Squee ook al regelmatig heeft aangegeven is iedere CPU hier in meer of mindere mate vatbaar voor, dus Intel, AMD, ARM (en afgeleiden), CPU's van IBM, Oracle noem ze allemaal maar op.

Ik zie niet echt in hoe je daar een terugroep actie voor wil uitvoeren, zeker gezien het feit dat er nog niet eens een model is dat alles kan oplossen in hardware, patchen terwijl in nieuwe generatie's de zaken waar mogelijk in hardware opgelost worden is dan een veel betere oplossing.

[Proxx]

Veiligheid tussen een auto en een processor zijn nogal verschillende begrippen.
als bij een auto de veiligheid in het geding komt kunnen er dode/gewonden vallen,

zodra de meltdown exploit misbruikt word zijn er niet direct levens in gevaar.

[SuperDre]

Ja duh, heeft toch ook totaal geen zin. Hoop procs zijn gesoldeerd/gelijmd, hoop mensen weten niet eens hoe je een proc moet vervangen (en wil je ook niet dat ze dat zouden doen), en voor de meeste mensen hebben deze kwetsbaarheden ook niet echt veel gevolgen.

[Stannieman]

Maar ik denk eigenlijk niet dat Intel nu mindere prestaties levert dan het zegt. Met patches duurt het werk dat je m geeft misschien langer, maar de chip heeft nog altijd dezelfde kloksnelheid, evenveel cache en noem maar op.
Behalve de vage cijfers "x% sneller dan vorige generatie" die sowieso al met een korrel zout te nemen zijn vertelt Intel niks over performance in de praktijk. Het zijn de nieuwssites die er daarna wat benchmarks tegenaan gooien en dat neemt iedereen dan (terecht) als referentie voor de prestaties. Intel zelfs zal je echter nooit horen roepen dat ze garanderen dat hun CPU xxx punten haalt in CineBench, dus denk dat er niet veel tegen te beginnen is.

Wat veiligheid betreft: Is opgelost met microcode van hun kant.

[computerjunky]

snap niet dat ze niet gewoon alle lekken hardwarematig fixen.
Ik wou wachten op een nieuwe serie zodat alles gefixed word maar de 9 serie doet er iets aan en de 10 serie blijkbaar ook niet zal wel tot 2023 duren met dit tempo voordat alles gefixed is. Dus misschien maar een systeempje kopen zonder fixes. Ik draai immers al sinds 2012 op deze pc zonder enige update gedaan te hebben en alle beveiliging eruit gehaald te hebben en heb nog altijd nergens last van.
Als ik op intel moet wachten heb ik in 2030 nog geen fixes dus dan maar zonder.

[Dennism]

Omdat zoiets tijd kost, een cpu generatie ontwikkelen en naar de markt brengen duurt al snel een jaar of 1,5 tot 2. de komende generaties zullen de eerst ontdekte zaken in hardware verhelpen, waarbij het er op lijkt dat de Meltdown fix ook de L1TF variant verhelpt, de L1TF variant is immers pas redelijk recent bekend geworden. Voor Varianten die korten geleden ontdekt zijn zal mogelijk een generatie langer gewacht moeten worden op de hardware fix, voor varianten die mogelijk morgen of over 2 weken ontdekt worden zijn we misschien wel 2 generaties verder voordat ze in hardware opgelost zijn.

[Verwijderd]

Handige utility om te zien of je systeem kwetsbaar is en om bescherming van OS tegen meldtdown en spectre aan/uit te zetten.

https://www.grc.com/inspectre.htm

[Reactie gewijzigd door Verwijderd op 22 juli 2024 14:49]

[Squee]

Ik ben trouwens benieuwd of we weer performance terug zullen gaan zien na deze fixes. De oplossing zal niet slechtere performance hebben in hardware dan de originele implementatie verwacht ik, maar de vraag is of de OS/software wereld de patches weer zullen durven uit te schakelen voor deze gerepareerde micro-architecturen. Zo zal ik OpenBSD niet snel weer HyperThreading zien inschakelen, en ik vraag me ook af of de Linux KPTI oplossing dan weer uitgeschakeld zal worden voor deze generatie. Ook bij alle L1D flush workarounds voor L1TF zoals RedHat en Phoronix hadden gebenchmarked zouden weer uit moeten kunnen op Whiskey Lake.

De vraag is eigenlijk; zal Intel voldoende het vertrouwen van de OS/software makers weer weten te winnen, of zullen deze paranoide blijven onder het motto van 'better safe than sorry'....

[WasMachinator]

De Core i3-8145U, i5-8265U en i7-8565U zijn daarmee de eerste consumentenprocessors die een vorm van hardwarematige bescherming hebben tegen de Meltdown- en L1TF-kwetsbaarheden.

Impliceert dit niet dat AMD er niks aan heeft gedaan terwijl ze eigenlijk niet vatbaar zijn voor Meltdown en L1TF.

[SuperDre]

Consumentenprocessors van intel....

[WasMachinator]

Dat wordt pas in de volgende zin soort van geimpliceerd.
Intel maakt consumentenprocessors maar consumentenprocessors worden niet alleen gemaakt door intel. Naar mijn idee is het een te brede verwoording waarmee je ook kan impliceren dat AMD er niks mee doet.

[Dennism]

Ik denk dat dit ook juist is, AMD is niet kwetsbaar voor Meltdown of L1TF, Ze hebben dus ook geen hardwarematige bescherming nodig voor die exploits. Het zou juist raar zijn als AMD er wel wat mee had gedaan (anders dan aangeven dat ze niet kwetsbaar zijn).

[Dennism]

Waarom zou AMD iets moeten doen aan iets waar ze niet vatbaar voor zijn. Waar AMD actie heeft moeten ondernemen omdat ze ook geraakt worden, hebben ze dat ook gezien. Zie https://www.amd.com/en/corporate/security-updates voor AMD's guidance.

[Pyrone89]

Ben ik de enigste die door de benamingen van Intel niet meer weet wat nu welke generatie is? Ook in het artikel wordt gesproken over een generatie, maar zover ik weet hebben deze processoren nog als eerste cijfer een 8 en is het dus niet de nieuwe (9e generatie)

Als ze nou 1 naam per generatie hanteren (is dit nu wel of niet de 9e generatie) wordt het duidelijker.