LVI-kwetsbaarheid in Intel-cpu's treft SGX en is niet op te lossen met microcode

Onderzoekers hebben een nieuw lek in processors gevonden dat niet met microcode is op te lossen. LVI, ofwel Load Value Injection, wordt omschreven als een 'omgekeerde Meltdown'-aanval en treft met name de SGX-enclave van Intel-processors.

Onderzoekers van universiteiten die eerder cpu-kwetsbaarheden als Meltdown, Spectre, Foreshadow en Zombieload ontdekten, hebben een nieuwe sidechannelaanval ontdekt. De onderzoekers noemen die LVI, of Load Value Injection en hebben een website online gezet met informatie.

Bij eerdere kwetsbaarheden was het mogelijk om data van de processor te onttrekken, met LVI gebeurt juist het omgekeerde. Door data te injecteren via verborgen processorbuffers kan de uitvoering van bepaalde processen beïnvloed worden, waarna gevoelige informatie buitgemaakt kan worden.

LVI omzeilt alle bestaande bescherming die tot nu toe is toegevoegd aan Intel-processors met microcode. Volgens de onderzoekers is de kwetsbaarheid ook niet met nieuwe microcode op te lossen. Dat kan alleen met hardwarematige aanpassingen aan de architectuur, of met vergaande compiler-aanpassingen die veel invloed kunnen hebben op de prestaties. Omdat het probleem niet met microcode is op te lossen, brengt Intel updates uit voor zijn SGX-software en -sdk. Ook heeft Intel samengewerkt met bedrijven als Microsoft om via software tegen LVI te kunnen beschermen.

Volgens de onderzoekers werkt de aanval in principe op alle processors die kwetsbaar zijn voor Meltdown, maar ze hebben zich gericht op Intel-cpu's om de aanval met name impact heeft op Intel-processors met Software Guard eXtensions en in situaties waarbij SGX ook daadwerkelijk wordt gebruikt. De SGX-enclaves zijn een deel van de processor waarin gevoelige informatie zoals een wachtwoord of encryptiesleutel in isolatie kan worden bewaard. Intel-processors sinds 2015 met SGX zijn getroffen. Alleen cpu's die op de nieuwe Ice Lake-generatie zijn gebaseerd zijn niet getroffen, omdat die architectuur hardwarematige veranderingen heeft.

Het gaat niet om een remote code execution-aanval, een aanvaller moet dus lokale toegang hebben om de kwetsbaarheid te misbruiken. Dat vormt vooral een risico in servers in datacenters waar meerdere gebruikers één processor delen. Intel schaalt de ernst van de kwetsbaarheid in als medium.

De nieuwe kwetsbaarheid heeft vermoedelijk geen directe invloed op consumenten. Bitdefender zegt tegenover The Register dat de aanval 'matig complex' is om uit te voeren. Het beveiligingsbedrijf verwacht niet dat het breed gebruikt zal worden tegen consumenten, maar stelt dat het wel een aanval is die staatsaanvallers zouden kunnen gebruiken in omgevingen als publieke cloudddiensten, waar meerdere gebruikers dezelfde cpu gebruiken. De aanval laat geen sporen na.

De nieuwe kwetsbaarheid is op 4 april 2019 ontdekt door Jo Van Bulck, van de imec-DistriNet-onderzoeksgroep van KU Leuven. Onderzoekers van tal van andere universiteiten hebben zich vervolgens aangesloten en samen hun bevindingen gepubliceerd in een paper. Intel heeft dinsdag zelf ook uitgebreide artikelen over LVI online gezet. Zo publiceert de cpu-fabrikant een deep dive met technische achtergrondinformatie, een lijst van getroffen processors en een blog.

De onderzoekers hebben voor publicatie contact gehad met Intel en waren van plan om in februari de details openbaar te maken. Na overleg bleek toen dat onderzoekers van beveiligingsbedrijf Bitdefender in de tussentijd een variant van het lek ook hadden ontdekt en een proof of concept aan Intel hadden getoond. Alle betrokken partijen publiceren nu hun informatie.

Reacties (53)

[Countess]

Volgens de onderzoekers werkt de aanval in principe op alle processors die kwetsbaar zijn voor Meltdown, maar ze hebben zich gericht op Intel-cpu's *snip*

Intel was de enige was die vatbaar was voor meltdown, terwijl de zinsbouw hier doet vermoeden alsof er nog meer CPU's zijn, naast die van intel, die vatbaar zijn voor deze kwetsbaarheid.

edit: dat zal me leren tweakers als bron te gebruiken (de link in dit article naar het meltdown article)

[Reactie gewijzigd door Countess op 23 juli 2024 20:14]

[Squee]

Intel was de enige was die vatbaar was voor meltdown, terwijl de zinsbouw hier doet vermoeden alsof er nog meer CPU's zijn, naast die van intel, die vatbaar zijn voor deze kwetsbaarheid.

Ik lees dit statement al meer dan twee jaar op Tweakers hier, maar nee, dit is nog steeds niet waar dat alleen Intel vatbaar was voor Meltdown. Meerdere implementaties hadden het Meltdown probleem, wat een stuk groter probleem was dan Spectre omdat het veel makkelijker concreet uit te buiten was. Het statement in het artikel hier is dus gewoon correct.

Want behalve Intel:
* Ook bepaalde Arm designs. bron
* Ook bepaalde IBM POWER designs. bron
... en wellicht meer omdat niet iedereen even open is over de status. Apple heeft zover ik weet nooit duidelijk uitsluitsel gegeven voor welke varianten ze wel en niet vatbaar zijn in hun processors.

[decide1000]

De impact op Intel processoren is anders wel een stuk groter dan bij ARM en IBM.. Intel is de enige die enorme moeite heeft de boel te patchen en er nog steeds problemen van heeft. Daarnaast is bij Intel gele ranges getroffen in tegenstelling tot ARM en IBM.
Oh en Intel kan het probleem niet fixen zonder de processor op drama snelheid verder te laten tikken..

Security by design hebben ze bij Intel gewoon niet zo serieus genomen. AMD doet het erg goed de laatste tijd, ook binnen de server markt.

[Opperpanter2]

nieuws: Onderzoekers vinden nieuwe cachekwetsbaarheid in AMD-processors

[batjes]

Alles heeft kwetsbaarheden. De hoeveelheid (en de impact daar van) bij AMD is bijna niets vergeleken met de beerputten die bij Intel opengetrokken worden.

AMD heeft duidelijk betere security design keuzes gemaakt bij het ontwerpen van hun processors. En -zeer- waarschijnlijk heeft Intel bepaalde design keuzes gemaakt op hun security ten faveure van de snelheid van hun processors.

[Mellow Jack]

Hoewel ik denk dat AMD met de zen het beter heeft geregeld is het natuurlijk ook zo dat Intel nou eenmaal het grootste marktaandeel heeft in de meest cruciale sector (server virtualisatie).

Al het Intel nieuws betekend niet veel voor AMD. Ik ben benieuwd of dr überhaupt een product bestaat die goed uit de situatie komt waar de Intel cpu's zich nu bevinden. 9 v/d 10 onderzoeken richten zich specifiek op Intel en hebben soms anders processors als gelukkige bijvangst. En volgens mij is er een leger aan universiteiten bezig met dit soort onderzoeken

[Reactie gewijzigd door Mellow Jack op 23 juli 2024 20:14]

[TheVivaldi]

Wacht maar tot AMD grondiger onderzocht wordt. Misschien heb je gelijk, maar misschien vinden ze daar toch ook meer kwetsbaarheden. De tijd zal het leren...

[Ultraman]

Welke triviaal is vergeleken met Meltdown en Spectre op Intel CPU's.

Kleine sidenote, de professor van deze onderzoekers gaf ook volgende commentaar op de vraag of deze vulnerabilities even erg waren als Zombieload en Meltdown

"Certainly not. The attacks leak a few bit of meta-data. Meltdown and Zombieload leak tons of actual data."

https://mobile.twitter.com/gnyueh/status/1236178639483527168

[Nielsbr12004]

Ik heb net even opgezocht wat meltdown inhield voordat ik dit las want er stond ook iets over op Hardware Info, maar volgens Wikipedia zijn Intel x86, arm en IBM processors vatbaar voor Meltdown. Zie https://en.m.wikipedia.or..._(security_vulnerability)(ja ik weet het Wikipedia is niet betrouwbaar). Volgens de website over Meltdown zijn iig Intel en arm processors vatbaar, en is het mogelijk dat AMD processors ook vatbaar zijn. Zie https://spectreattack.com.

[mikesmit]

Gebruik de life hack die iedereen gebruikt. Citeer de bronnen die Wikipedia ook gebruikt

[SpiceWorm]

Dat kan, mits je de bron leest en kijkt of datgene wat je wil onderbouwen in die bron staat en of het een fatsoenlijke bron is. Komt hier op tweakers ook nogal eens voor dat mensen ongelezen bronnen plaatsen die níet onderbouwen wat ze beweren wat die bron onderbouwt.

Anders krijg je alsog misinformatie / nepnieuws.

[N8w8]

Niet waar, kwetsbaar zijn ook ARM Cortex A75 en IBM POWER (Meltdown = CVE-2017-5754).

[Dennism]

Meltdown, waar de reactie over gaat waarop jij reageert staat los van SGX. ARM, IBM, Apple en uit mijn hoofd Sun hebben ook cpu's die daar vatbaar voor zijn.

En ook de vunerabilities van vandaag zijn niet van toepassing op SGX enclaves. DE onderzoeken hebben daar de nadruk opgelegd, echter ook cpu's zonder SGX zijn vatbaar voor deze exploit. +

Zie ook deze quote uit de nieuwspost:

Volgens de onderzoekers werkt de aanval in principe op alle processors die kwetsbaar zijn voor Meltdown, maar ze hebben zich gericht op Intel-cpu's om de aanval met name impact heeft op Intel-processors met Software Guard eXtensions en in situaties waarbij SGX ook daadwerkelijk wordt gebruikt.

[Reactie gewijzigd door Dennism op 23 juli 2024 20:14]

[Rataplan_]

Deze aanvallen zijn allemaal niet heel simpel uit te voeren. Toch mag Intel zn lake-cpu's wel eens hernoemen naar leak...
Ik heb laatst overigens eens een performance test gedaan op mn 5e generatie Intel NUC met i5 cpu, omdat ie steeds trager aanvoelt. Met de bios van vóór de lekken en met de huidige bios waar o.a. meltdown en spectre gepatcht zijn. Het verschil was reproduceerbaar slechts 1-2%. Ik had een veel groter verschil verwacht in met name de cpu en misschien ram benchmarks. Maar voor dagelijks gebruik heb ik het idee dat de eindeloze zwerm aan Windows en chrome (en andere applicatie) updates de zaak veel meer vertragen dan de patches van deze lekken. Misschien ligt het voor heel specifieke taken anders.

[edit]
Typo

[Reactie gewijzigd door Rataplan_ op 23 juli 2024 20:14]

[_Dune_]

Voor het daagelijks gebruikt merk je er ook niet echt veel van, heb je echter een datacenter waar je een omgeving draait met VDI's bijvoorbeeld, dan kan de impact aanzienlijk zijn. Het ligt er dus maar net aan waar betreffende Intel processoren voor gebruikt worden. Voor huis, tuin en keuken gebruik heeft het weinig tot geen impact, maar dat was hier op de frontpage wel vaker te lezen.

[Rataplan_]

Wij hosten een hoop vm's op HPe hardware, gen8 t/m gen10, allemaal geraakt door deze lekken. Toch merk ik ook daar eigenlijk geen verschil in performance.

[MrDrako]

Wij draaien +- 4000 gebruikers op HPe blades, en als we daar de windows update voor spectre/meltdown installeren, draaien single threaded applicaties die afhankelijk zijn van hoge clock frequenties, ineens een heel stuk, merkbaar trager. Zodra we daar die register setting aanpasten waardoor de update "uit" stond, waren de klachten weg. Het betekent voor ons uiteindelijk dat we processoren met hogere klokfrequentie moeten gaan kopen, en dus minder cores per cpu, en dus meer blades, en dus meer chassis, en dus meer netwerk aansluitingen,etc, etc, en dus uiteindelijk als je alles bij elkaar op telt een heel stuk duurder uit zijn.

[Ayporos]

Wellicht een nogal goedkope vraag maar, als je toch nieuwe CPU's moet kopen waarom niet Epyc bakken?

[Gepstra]

Lijkt mij best een reële vraag, ben ook zeer benieuwd.

[Ayporos]

Mja, HPE biedt wel epyc bakken aan (tegenwoordig) dus het kan in theorie wel.

Gezien al die recente CPU issues die vooral Intel heeft gehad zou ik als ik mocht beslissen over zulk soort aanbestedingen toch liever voor Epyc gaan. (sowieso heb ik nogal een 'Fuck Intel' houding, die hebben echt jaren op hun reet gezeten omdat ze geen echte concurrentie hadden)

[Dennism]

Volgens mij heeft HPE nog geen blades met AMD Epyc, alleen standaard rack servers. Als je dus een deployment wil gebaseerd op blades lijk je dus, in ieder beval momenteel, nog bij Intel uit te komen.

Het laatste wat je zegt klopt trouwens niet direct, Intel staat stil omdat ze al jaren problemen hebben met hun volgende generatie productie proces, de 10nm node, deze zou in 2016 al in gebruik genomen moeten worden echter zijn producten gebaseerd op deze node nu pas slechts mondjesmaat te verkrijgen. Doordat Intels nieuwe architectuur ontwikkeld is om op deze node geproduceerd te worden kan Intel deze architectuur eigenlijk vrijwel niet lanceren (er zijn een aantal laptop Sku's verkrijgbaar, maar dat is het). Tegen de tijd dat de eerste 10nm Xeon op de markt gaan komen zit daar een jaar of 5 vertraging in.

[batjes]

https://www.hpe.com/nl/nl/solutions/amd.html#portfolio

HPE heeft gewoon blades met EPYC.

Intel staat ook stil omdat ze geen noodzaak hadden om hun producten te verbeteren. AMD liep donders achter en Intel had absoluut niet verwacht (niemand niet) dat AMD even in 1 generatie de vloer met ze zou aanvegen.

[Dennism]

Dat zijn geen blades maar standaard rackservers, die benoemde ik al.

Dit is HPE's blade portfolio en daar zie ik geen Epyc tussen staan: https://www.hpe.com/us/en...-systems/bladesystem.html en https://buy.hpe.com/emea_...arch=Proliant&pageSize=10

Verder zou ik zeggen lees je eens op Intels 10nm en de problemen daaromheen, als Intel 10nm volgens roadmap had kunnen introduceren was AMD ook niet 1,2,3 zo makkelijk aangehaakt met de eerste generatie en zelfs op bepaalde vlakken Intel enorm gepasseerd zoals ze nu met de op Zen 2 gebaseerde Ryzen en Epyc producten doen. Het punt is nu juist dat Intel eigenlijk alle geplande verbeteringen niet of nauwelijks kan lanceren sinds 2016. AMD had dit zelf namelijk ook niet verwacht, dat hebben ze zelf al meerdere malen op investor calls toegelicht. AMD had verwacht op dit moment te concurreren met een Intel dat vrijwel volledig over zou zijn op 10nm producten met veel meer cores dan dat Intel nu daadwerkelijk op de markt kan brengen.

AMD heeft deze mogelijkheid nu deels door hun eigen harde werken, maar ook deels omdat Intel enorme problemen heeft met het 10nm productie proces en dat niet vlotgetrokken krijgt. Die problemen bij Intel zullen zeker deels te wijten zijn aan het feit dat ze met kosten besparingen bezig zijn geweest, maar het is zeker niet zo dat Intel stilgezeten heeft qua ontwikkeling, ze hebben een nieuwe architectuur (die al een tijdje "in de kast" staat) ze kunnen hem alleen niet breed inzetten door de productie problemen.

[computerbart]

Eh, waar dan in je link?

[RJG-223]

Het laatste wat je zegt klopt trouwens niet direct, Intel staat stil omdat ze al jaren problemen hebben met hun volgende generatie productie proces

Integendeel. Het is een bijkomende factor. Intel deed al jarenlang daarvoor niet echt veel moeite, bijvoorbeeld door de core-count eindelijk eens (flink) te verhogen, of gewoon door een fundamenteel nieuwe archtectuur te introduceren. De laatste keer was toen ze flink achter liepen. Toen moesten ze wel. Het feit dat sinds Zen de veranderingen ondanks intel's huidige problemen ineens toch sneller gaan, is voldoende bewijs dat Intel lui is geweest.

[Dennism]

Welke veranderingen gaan exact sneller dan? Je ziet nu juist dat ze zaken aan het introduceren zijn die eigenlijk jaren geleden al gepland waren, denk bijvoorbeeld aan de handvol Sku's die op 10nm beschikbaar komen.

Het enige dat optisch sneller lijkt te gaan is het feit dat ze op de 14nm producten wat noodgrepen uitvoeren. Dat ze die noodgrepen moeten uitvoeren komt uiteraard deels door de concurrentie van AMD, echter is het een gevolg van de problemen met het 10nm proces. Hadden ze geen problemen gehad met 10nm, hadden ze ook geen extra cores hoeven toevoegen op hun 14nm producten. Dat is geen innovatie, dat zijn noodgrepen omdat ze de producten waar de innovaties inzitten waar ze aan gewerkt hebben de afgelopen jaren amper kunnen produceren. En zolang Intel die productie problemen blijft houden zal er ook weinig innovatie komen vanuit Intel, vooral noodgrepen.

Ook zorgt dat ervoor dat ze niet van deze security problemen afkomen, kun 14nm architecturen zijn gewoon weg niet veilig op deze vlakken. Ook hier ze je dat weer, Ice Lake is niet getroffen, echter Ice Lake kunnen ze momenteel niet fabriceren op meer dan 4 cores en ook nog eens alleen op low power. Enkel geschikt voor laptops dus. En laat laptop nu juist het enige vlak zijn waar Intel het laatste jaar wat echte innovatie heeft laten zien. Enkel en alleen omdat ze daar wel hun voor 10nm ontwikkelde Ice Lake architectuur kunnen gebruiker, zij het op zeer kleine schaal.

En dat is ook het mooie voor AMD, had Intel hun roadmap wel kunnen lanceren zoals in 2016 de bedoeling was dan moet AMD nu tegen volledig andere producten concurreren. En daar heeft AMD zich dus ook op gericht. AMD had nooit verwacht nu nog tegen 14nm producten te moeten concurreren op alle vlakken.

Juist doordat deze omstandigheden zo vallen, Intel heeft problemen, AMD die daardoor heeft overschat welke producten Intel op dit moment zou hebben zorgt ervoor dat AMD op alles dat meer dan 8 cores heeft (op de desktop), alles dat meer dan 16 cores heeft (op HEDT) en alles dat 32 of meer cores heeft (in server) op dit moment enorm voorloopt op Intel.

[Reactie gewijzigd door Dennism op 23 juli 2024 20:14]

[mae-t.net]

Of Threadrippers als budgetalternatief.

[Cobiwan]

Dus wordt Intel beter van zijn eigen fouten...

[Blackboard]

Is het inderdaad zoals @Sj44k13 en @Ayporos aangeven, niet beter om de Intel CPU's te vervangen voor AMD aangezien je zo in een vicieuze Intel-vervang cirkel raakt.

[Reactie gewijzigd door Blackboard op 23 juli 2024 20:14]

[SadisticPanda]

Enige info over welke registry aanpassing die je gebruikt hebt? Ben benieuwd om ook eens te kijken of ik problemen met 1 bepaalde singlethread app daarmee kan oplossen

[Lizard]

Zie deze reddit post met links: https://www.reddit.com/r/...tre_and_meltdown/ephjogw/

[Dennism]

Deze kan je o.a. hier vinden: https://support.microsoft...e-channel-vulnerabilities

dit is in ieder geval voor Spectre, Meltdown, L1TF en MDS.

[Jonathan-458]

Waarom niet kiezen voor AMD? Lager energie verbruik betere performance, minder hardware issues.

Intel is naar mijn verwachting pas weer intersant als zij een nieuwe architectuur ontworpen hebben en geen shortcuts meer gebruiken als optimalisaties.

Het is momenteel gewoon niet logisch om voor Intel te kiezen mits applicaties hier niet afhankelijk van zijn.

[Reactie gewijzigd door Jonathan-458 op 23 juli 2024 20:14]

[Jonathan-458]

Deze vulnerability zijn niet nieuw, dit geven beide partijen aan en zijn bij lange na niet zo ernstig als de problemen bij Intel, bij Intel gaat het veel al om lekken waar bij volledige data inzichtelijk is ten opzichte van de door u gerefereerde side channel attacks.

AMD heeft overigens in hun statement niet gezegd dat er geen fix komt maar adviseert gebruikers always up to date te zijn.

[Reactie gewijzigd door Jonathan-458 op 23 juli 2024 20:14]

[Alfa1970]

Vandaar ook dat nieuw in quotes stond. Of AMD zelf dat gezegd heeft of niet weet ik niet, maar het is wel wat er letterlijk in het artikel van Tweakers van 10 maart staat..

[Reactie gewijzigd door Alfa1970 op 23 juli 2024 20:14]

[Sp3ci3s8472]

Er is een groot verschil met het lekken van echte data en wat metadata in het geval van het AMD lek. Metadata is een heel stuk minder serieus, dat geven de onderzoekers ook zelf aan.
Dit lek van Intel is een heel stuk ernstiger.

[RJG-223]

Uhm, zijn we dan nu al weer de "nieuwe" vulnerability voor AMD CPU's van gisteren vergeten dan?
Diegene die niet gefixed gaat worden door AMD omdat ze dat niet nodig vinden?

Inderdaad. Het bekende ongemak, hoe groot ook, is nog altijd beter dan de 'onzekerheid' van de nieuwe mogelijkheden - of de hogere performance en de betere TCO in dit geval.

/s

En vergeet niet: als je doet wat iedereen doet, en wat al je voorgangers deden, dan kun je altijd nog wegkomen met 'mogelijke incompatibilteit', 'niet langdurig bewezen', 'onbekende risico's', en eventueel: 'geen tijd/geld voor een grondige evaluatie' om de keuze te verdedigen, terwijl als je voor het nieuwe kiest, en er is toch een probleem, je heel wat moeilijker gesprek tegemoet gaat, want dan kan juist je baas al die bovenstaande argumenten gebruiken...

[Alfa1970]

jij begrijpt m ..

[Wim-Bart]

Wij hosten een hoop vm's op HPe hardware, gen8 t/m gen10, allemaal geraakt door deze lekken. Toch merk ik ook daar eigenlijk geen verschil in performance.

Heb je ook alle Register mitigaties aangezet die nodig zijn om de bescherming aan te zetten. Voor bijna alle Meltdown en Spectre varianten moet je dus in Windows wel de mitigaties aanzetten. Staan ook netjes beschreven in de KB artikelen van de diverse fixen. Zelfde als onder ESX, standaard krijg je een Microcode patch mee, maar je moet nog wel even de mitigaties aan zetten in ESX.

Wanneer je dus de Windows updates installeert ben je nog totaal niet klaar.

https://support.microsoft...e-channel-vulnerabilities

Met name de register sleutels halverwege genoemd. Zonder deze is er dus niks gemitigeerd.
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management
FeatureSettingsOverride:DWORD
FeatureSettingsOverrideMask:DWORD

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization
MinVmVersionForCpuBasedMitigations:REG_SZ

Bij ESX is het zelfs nog wat complexer, daar moet je keuzes maken of je Hyperthreading uit zet of een aantal mitigaties voor VMs laat uitvoeren (keuze full HT, alleen HT op enkele core, geen 2 VM's op 1 core simultaan etc.)
https://kb.vmware.com/s/article/52085
https://www.vmware.com/se...ories/VMSA-2018-0020.html

Hier heb je settings zoals:
VMkernel.Boot.HyperthreadingMitigation
VMkernel.Boot.Hyperthreading

En nog een aantal settings zo her en der.

Helaas is mitigeren dus niet alleen patches en Microcode. Je moet handmatig werk doen. 1 van de redenen dat wij Qualys gebruiken, die geeft per patch aan wat je vergeten bent te zetten. Bijvoorbeeld flags voor IE op een server om bepaalde patches in IE aan te zetten bijvoorbeeld.

[Lawrentium]

Een deel van de security patches zitten ook in Windows (of welk ander OS je ook gebruikt), waardoor je verschillende Windows builds zou moeten testen om een representatieve benchmark uit te voeren.

[WhiteDog]

Veel van deze patches in Windows kan je selectief in- of uitschakelen. Het is alleen vrij complex en ben nog geen tool of script tegengekomen die je helpt "kiezen".

[t link]

Dit heeft zeker wel consequenties. DRM maakt hier bijvoorbeeld gebruik van, secure browsing, etc. ook voor huis tuin en keukengebruik heeft dit invloed, misschien niet op hun eigen veiligheid direct (al met secure browsing mogelijk wel maar niet bepaald groot risico). ze zullen makkelijker pirated content kunnen vinden.

[jqv]

Vreemd.
Je doet een test en een prestatie verlies van 1-2 %. En vervolgens leg je het gevoel van vertraging bij Windows en Chrome zonder verdere uitleg en bronnen/bewijzen.
En het is je idee.

Dus je gevoel was onterecht, dus wat kan er dan waar zijn van je idee zonder daadwerkelijke onderbouwing.

[Rataplan_]

Ik heb met bios zonder en met mitigaties getest, en daar merk ik nauwelijks verschil. Maar zoals hierboven al gezegd, het OS zelf zou ook wel eens trager kunnen zijn door de patches. Ik stel ook nergens dat ik een of andere wetenschappelijk onderbouwde benchmark heb gedaan. Gewoon een paar keer pcmark draaien met oude en nieuwe bios. That's it.
En ja ik merk verschil. Waar ik 'vroeger' bv chrome kon starten en binnen 1 seconde mn url intypen, duurt dat nu gewoon langer. Dusja, dat wijt ik aan ofwel Windows of Chrome die logger geworden is.
Wat is nou precies je punt?

[ToAoM]

Windows patcht de CPU microcode ook automatisch. Je moet een aardig oude Windows build zonder updates draaien om niet tildens de boot alsnog de tragere microcode in te laden.

[Dennism]

Dat hangt ook al van de geteste Windows versie. Bepaalde versie's hebben de mitigations standaard aan staan na het patchen, terwijl ze op andere versie's standaard uit staan. Zie bijvoorbeeld dit document voor Windows Server: https://support.microsoft...e-channel-vulnerabilities

[Hackus]

Deze aanvallen zijn allemaal niet heel simpel uit te voeren. Toch mag Intel zn lake-cpu's wel eens hernoemen naar leak...
Ik heb laatst overigens eens een performance test gedaan op mn 5e generatie Intel NUC met i5 cpu, omdat ie steeds trager aanvoelt. Met de bios van vóór de lekken en met de huidige bios waar o.a. meltdown en spectre gepatcht zijn. Het verschil was reproduceerbaar slechts 1-2%. Ik had een veel groter verschil verwacht in met name de cpu en misschien ram benchmarks. Maar voor dagelijks gebruik heb ik het idee dat de eindeloze zwerm aan Windows en chrome (en andere applicatie) updates de zaak veel meer vertragen dan de patches van deze lekken. Misschien ligt het voor heel specifieke taken anders.

[edit]
Typo

als je waarde hecht aan zgn veilig zou ik sowieso geen Google gebruiken, en Windows uitkleden wbt ze allemaal van je opslaan. verder is het niet gek dat een i5 5thgen uit nuc tegenwoordig trager wordt, waar ook vaak een T versie voor is gebruikt.

[Wim-Bart]

Heb je ook alle register aanpassingen gemaakt in je VMs, en de settings in ESX gedaan om de patches daadwerkelijk aan te zetten.

Overigens is een i5 niet echt een vergelijk met een Xeon met HT. Om je een indruk te geven, wanneer de HT mitigaties uit gevoerd zijn, zal ESX eerst de complete cache flushen voor hij de volgende VM op het zelfde core paar zet (1 van de keuze mogelijkheden). Met een i5 zonder HT merk je het dus niet in dat geval. En zo zijn er veel meer scenario's. Wij merken impact met IO en dat is geen pretje met SQL servers.

Wij hebben ook keuzes moeten maken, alle mitigaties doorvoeren, dan moesten we het park met 35% vergroten omdat HT fysiek uit zou moeten, nu de minst kwade, die toch stiekum 5-20% meer belasting geeft op de omgeving (we hebben wat ruimte).

[Olaf van der Spek]

Maar voor dagelijks gebruik heb ik het idee

Windows al eens op een lege SSD opnieuw geinstalleerd?

[Pukson]

Vond de trailer voor deze exploit toch wel leuker dan de video onder het bericht.

https://twitter.com/lavados/status/1237423957491486720?s=21