Microsoft bespreekt impact Spectre- en Meltdown-patches op snelheid pc's

Microsoft heeft in een blogpost besproken voor hoeverre gebruikers een vermindering in processorprestaties moeten verwachten bij het installeren van de patches voor de Spectre- en Meltdown-kwetsbaarheden. Vooral bij oudere processors zal de prestatievermindering merkbaar zijn.

Microsoft vat in de blogpost op basis van zelfgedraaide benchmarks samen dat gebruikers met Intel Skylake-processors of nieuwer minder dan tien procent prestatievermindering kunnen verwachten. Bij oudere processors, zoals Haswell of eerdere generaties, kan de prestatieafname dermate groot zijn, dat gebruikers vertragingen zullen opmerken. Dit is ook het geval met gebruikers die Windows 7 of 8 draaien.

Voor computers die Windows Server draaien, wordt een nog grotere vermindering in prestaties verwacht. Myerson raadt hierbij aan om een afweging te maken tussen het risico van het draaien van onbetrouwbare code en het verlies in prestaties dat optreedt bij het beveiligen van je servers.

Vorige week kwam naar buiten dat er in bijna alle moderne processoren enkele belangrijke beveiligingslekken zitten, waarbij misbruik gemaakt kan worden van out-of-order execution. Het Meltdown-lek is alleen van toepassing op Intel-processoren, maar Spectre werkt ook bij chips van AMD en ARM.

Verschillende partijen hebben al patches uitgebracht om de beveiligingsrisico's te neutraliseren, al gaan die vaak ten koste van processorprestaties en weigerde in sommige gevallen de computer op te starten. Microsoft belooft binnen enkele weken met meer cijfers te komen over de exacte impact van de patches op prestaties.

Reacties (204)

[Verwijderd]

De highlights:

• Windows 10 - newer silicon (2016-era PCs with Skylake, Kabylake or newer CPU) = single-digit slowdowns
• Windows 10 - older silicon (2015-era PCs with Haswell or older CPU) = more significant slowdowns
• Windows 7 - older silicon (2015-era PCs with Haswell or older CPU) = most users to notice a decrease in system performance.
• Windows Server on any silicon = significant performance impact

[Reactie gewijzigd door Verwijderd op 29 juli 2024 14:43]

[Gijs007]

Heb zojuist de BIOS update voor spectre uitgerold op Windows Server 2016 met kaby lake CPU (Intel Xeon E3-1245v6).
CPU gebruik is toegenomen van gemiddeld 3% naar 37% over een periode van 15 minuten.

In de taskmanager staat het proces "System" dat tussen de 15 en 25% van de CPU gebruikt..
Dus dat is inderdaad een significante impact. Opvallend is dat de impact van de Spectre BIOS update dus veel groter is dan die van de Meltdown mitigatie.

[Reactie gewijzigd door Gijs007 op 29 juli 2024 14:43]

[Dannydekr]

Iets zegt mij dat Intel hierdoor ontzettend veel rechtszaken te verduren krijgt. Een belasting van 35% extra heeft gewoon heel veel impact in een serveromgeving.

[WCA]

'Single-digit slowdowns'

Over wat voor eenheid praten we hier? Benchmarkpunten? Percentages?

Dit zou in ieder geval wel verklaren waarom de test die ze bij de buren gedaan hebben, niets uitwees.

[Anonymoussaurus]

Voornamelijk benchmarkpunten die ook kunnen worden uitgedrukt in procenten. Hier wat tests die zijn gedaan:

• https://www.phoronix.com/...em=linux-415-x86pti&num=2
• https://www.youtube.com/watch?v=_qZksorJAuY
• https://www.computerbase....pu-pti-sicherheitsluecke/

[Reactie gewijzigd door Anonymoussaurus op 29 juli 2024 14:43]

[Tijgert]

Disagree, men doelt met simpele ‘digits’ altijd op procentuele prestaties, gemiddelde of maximale, nooit op benchmarks. Procentueel is en blijft altijd dezelfde groottes en dimensies en voor iedereen is meteen duidelijk over welke orde van grootte men het heeft. Benchmarks kunnen er wel honderd verschillenden zijn, dan is het nooit voor iemand duidelijk zonder grafieken of verdere informatie.

[Xerxes249]

Geekbench van 1000 -> 990 is ook gewoon een 1% slowdown...

[Tijgert]

Dat is mijn punt exact. Een 1% slowdown begrijpt een ieder, je hebt 99% van je performance over.
Maar van ‘een enkele’ benchmark double digit punten inleveren (10 in dit geval) lijkt super scary maar is gewoon hetzelfde, maar men weet het niet.

[Xerxes249]

Ja maar dat is volgens mij ook wat AnonymousWP bedoelt, dat je benchmark scores ook kunt omschrijven naar procentuele scores en dat je daar de single/double digits aan kunt hangen.

[bartmatsko]

Updated video: https://www.youtube.com/watch?v=JbhKUjPRk5Q (Meltdown & Spectre Updates Benchmarked, Big Slow Down for SSDs!)

[Reactie gewijzigd door bartmatsko op 29 juli 2024 14:43]

[doeternietoe]

single digit
=
< 10%

Oftewel een percentage van één cijfer (1-9).

[Twanekel]

Windows 7 - older silicon (2015-era PCs with Haswell or older CPU) = most users to notice a decrease in system performance.

Hoe heet de patch? Heb namelijk liever de performance op mijn PC dan die beveiliging.

[Keypunchie]

[edit] wat snedigs weggehaald. Mijn excuus.

[Reactie gewijzigd door Keypunchie op 29 juli 2024 14:43]

[mindcrash]

Windows Server on any silicon = significant performance impact

Alleen bij het isoleren van untrusted code op de server. Denk aan shared web hosting voor meerdere klanten binnen een Windows Server omgeving

[tc-t]

Wat er niet instaat is de impact van de patch op Windows 7 en 8 op "newer silicon".
Was dat nu zo moeilijk om dat ook even te testen?

[Reactie gewijzigd door tc-t op 29 juli 2024 14:43]

[apa]

Macs draaien Intel processors tegenwoordig en krijgen dezelfde patches (issue wordt op dezelfde manier aangepakt)...

[mhnl1979]

Mijn pc loopt als zonnetje. Wel eerste generatie i5. (2013 volgens mij) Kan dus 10% langzamer worden?

[Barsonax]

Eerste generatie was 2009 volgens mij. In ieder geval niet 2013.

[TonnyTonny]

Eigen testen:
Xeon uit 2008 (HP workstation XW8600 met 32GB RAM), Windows 10 en Mint Linux. Op beide met en zonder patches geprobeerd.

Geen merkbaar performance verlies bij normaal gebruik, tenzij ik veel multithreaded disk-io ga doen.
Met name bij veel (200+) torrents en tegelijk multi-threaded newsgroupen leegtrekken (Newsleecher, 12 bots, geen SSL) zie ik 10-15% verlies aan bandbreedte verbruik (van 260-270 Mb/s naar 225-235 Mb/s) en zie ik tegelijk dat andere aktiviteiten op de PC minder responsive zijn dan voor de patches.
Tot op zekere hoogte (bij de torrents) kan ik dat compenseren met qTorrent een veel grotere in-memory cache-buffer te geven (4 GB ipv de 512 MB die ik normaal gesproken gebruik) , waardoor hij minder vaak naar disk hoeft te flushen, maar dan nog heb ik zo'n 5% verlies.
Bij Newsleecher lijkt de overal throughpuit ietsje beter te zijn als ik terug ga naar 10 bots, maar ik heb niet lang genoeg getest om dat met zekerheid te kunnen zeggen. (Sweetspot voor mijn systeem lag normaal gesproken op 12 bots, bij meer bots gaan ze onderling te veel ruzie maken over wie het eerst naar disk mag wegschrijven.)

[joyrider3774]

op deze site vind je benchmarks tussen de 3 stappen namelijk voor de de patch, na de patch zonder bios update en na de patch met bios update (= hoe het zou moeten zijn) op het eerste zicht zitten er wat vertragingen bij disk performance waarmee ze getest hebben maar er zouden meerdere test's moeten gedaan worden. Het geeft wel een idee wat ons (mogelijk) te wachten staat

https://www.techspot.com/...-cpu-performance-windows/

[RobWu]

Een hoop gepraat over de mogelijke invloed op CPU prestaties, maar zijn er hier tweakers die daadwerkelijk prestaties hebben getest voor, en na de patches?

Ook zouden de prestatieverliezen in de "zwaardere gebruiksgroepen" zitten, dus mensen die echt de CPU vol belasten, b.v. 3d renderen, video-editing, zware beeldbewerking.
Als daar 15-20% van wegvalt, dan is dat knap klote om het maar op zijn Hollandsch te zeggen.

Het vervelende is dat een aantal van mijn pc's/CPU's de bug niet heeft (volgens de Intel tools), maar wel de patch door de strot geduwd krijgt......

Dus.... Iemand daadwerkelijk zaken getest, en aan kunnen tonen dat er prestatieverlies te meten is??

[Scriptkid]

Ik ben wel benieuwed wat dit doet met de battery time van laptops,

30% meer betekend in mijn ogen ook 30% minder battery.

[Tim2010]

Ik vraag me af hoe Intel deze blunder gaat aanpakken want de grotere klanten die Windows Server en dergelijke draaien zullen hier enorm kwaad over zijn. De gewone consument zal niet snel schadevergoedingen gaan eisen, maar zulke grote zakelijke klanten wel.

[Reactie gewijzigd door Tim2010 op 29 juli 2024 14:43]

[jick]

En waarom zou de gewone consument dat niet doen? Een class action lawsuit richting Intel zou erg terecht zijn, zoals dat eerder ook al richting bijvoorbeeld Apple is gedaan betreffende de MacBook Pro's en falende GPU's. Ik hoop dan ook dat Intel hiermee te maken gaat krijgen. Ik heb 1,5 jaar geleden een 6850X gekocht voor teveel geld, zeker nu Ryzen op de markt is gekomen.
Overigens wordt er al over een classic action lawsuit gesproken over dit issue.

[Reactie gewijzigd door jick op 29 juli 2024 14:43]

[R.Klein]

In een class action lawsuit zou je eerst moeten aantonen dat Intel met kennis van de lek toch het product de markt op heeft geslingerd. Het is een fout geweest in de ontwerpfilosofie wat eigenlijk al laat zien dat Intel er niet van op de hoogte was, anders hadden ze de architectuur eerder drastisch veranderd. Zover bekend heeft Intel het best mogelijk product op de markt gebracht en zal het lastig worden om een rechtszaak te winnen, er worden aan consumenten namelijk ook geen garanties gegeven op het gebied van veiligheid. Misschien dat bedrijven met veel servers wel bepaalde garanties hebben afgesproken maar als particulier heb je geen poot om op te staan, wettelijk gezien.

[NBK]

Voor het afgelopen half jaar is dat simpel te bewijzen

[UltimusXI]

Was in dat half jaar al bekend wat de performance-impact zou zijn of in welk deel van dat half jaar dan wel? Of is dat pas nu duidelijk, nu de eerste patches in de praktijk zijn getest?

Zullen er niet vaker software-updates of OS-updates zijn geweest die een systeem een 'single digit'-percentage trager maakten? Firmware updates op mobiele telefoons, etc.? Zijn daar ook allemaal class actions voor nodig geweest? Je krijgt er namelijk wel ook iets voor terug.

Wat had je dan van ze verwacht een paar maanden geleden? Een bericht van Intel in de trant van: "Er is iets dat mogelijk jullie processor door een Windows-update iets trager zal maken, maar we zeggen nog niet wat de reden is (uit veiligheidsoverwegingen) en we kunnen ook nog niet zeggen wat de precieze impact is"? Tsja, was misschien netjes geweest, maar ook wel erg vaag.

[Reactie gewijzigd door UltimusXI op 29 juli 2024 14:43]

[kidde]

Het boeit geen iota wat Intel van de patches en prestatie verliezen wist: Voor producten verkocht na juni '17 (meldings datum defect) wist Intel dat ze een defect product verkochten en daarna zijn zij aansprakelijk voor alle daardoor geleden schade. Vraag maar aan Volkswagen. Of Tabata.

Als je airbag (of pacemaker?) niet werkt door een bekend defect, boeit het niet of de fabrikant wist hoeveel doden zouden gaan vallen: De fabriekant is aansprakelijk, punt uit. Daarom haalt bijna iedere fabrikant defecte producten gelijk van de schappen of roept ze terug. Zelfs Microsoft (op patch tuesday wordt Windows digitaal 'teruggeroepen' en worden ontwerpfouten hersteld). Behalve Intel dus. Of Volkswagen.

Van Arnout Engelfriets 'Ius Mentis' blog (wel over software trouwens):

Wanneer een leverancier geen algemene voorwaarden hanteert, dan geldt de wettelijke regel voor aansprakelijkheid. Die zegt dat de ontwikkelaar aansprakelijk is voor alle schade, als de fout hem te verwijten was. Daarvan is kort gezegd sprake als hij niet de gebruikelijke mate van zorg heeft betracht die een normaal ontwikkelaar in acht zou nemen.

AMD heeft een gebruikelijke mate van zorg betracht, door te zorgen dat ringen gescheiden zijn (userspace kan geen kernel space lezen dus niet vatbaar voor Meltdown!). SPARC bijv vziw ook (Kernel tabel geheel gescheiden zelfs). Intel - met veel meer geld, R&D en personeel - heeft AMD's extra autorisatie-controle 'voor luttele procenten meer prestatie' achterwege gelaten, vermoedelijk bewust, dus nalatig. Daarna volgt geen terugroepactie, maar wordt zelfs nog een lading nieuwe (!) defecte product-modellen gelanceerd, genaamd 'Coffee Lake'.

Grote databoeren, zoals Google of Amazon, zullen vast schikken in plaats van procederen. Ze zijn sowieso (nu nog) afhankelijk van Intel. Consumenten daarentegen...

[Reactie gewijzigd door kidde op 29 juli 2024 14:43]

[Gijs007]

Ik denk dat je het verschil tussen een probleem verhelpen en een workaround niet begrijpt.
In dit geval kun je gewoon aantonen dat er een workaround is, maar dat je daardoor wel op de prestaties inlevert.

Metafoor: Je koopt een stuk vlees kopen waarvan een deel rot is, het rotte deel wordt er afgesneden. Je hebt echter ook betaald voor het rotte deel.

[MSalters]

Jouw mening is duidelijk, dat het een workaround betreft, maar dat heeft weinig juridische waarde. Een workaround is een niet-elegante oplossing voor een probleem, en elegantie is niet objectief meetbaar.

[Gijs007]

Wat is er niet objectief meetbaar aan het inleveren van prestaties? Volgens mij is dat gewoon te meten als je de monitoring van je IT-diensten goed hebt geregeld.

[Reactie gewijzigd door Gijs007 op 29 juli 2024 14:43]

[MSalters]

Tuurlijk kun je meten wat het performance verschil is tussen de oude, onveilige situatie en de nieuwe veilige situatie. Maar je kunt Intel niet de schuld geven van het feit dat security ten koste gaat van performance. Volgens die redenering zou elk Anti-Virus programma per definitie een defect zijn

[kidde]

Wel dus, want AMD heeft het Meltdown probleem _niet_, dus de Meltdown pleister-vertraging ook niet. AMD heeft namelijk een hardware-matige beveiliging ('ring'-controle waarbij exception volgt bij overtreden authorisatie) waardoor ze en snel _en _veilig zijn. Intel heeft die controle bewust achterwege gelaten (tenzij je gelooft dat ze bij Intel echt heel heel dom zijn en dat per ongeluk doen!), waardoor een software workaround het overtreden van de autorisatie moet tegengaan, dus of snel, _of_ veilig. Als AMD met minder middelen wel een snel en veilig product maakt en Intel niet, ja, dan kan je dat Intel kwalijk nemen!

Mijn mening, juridische 'waarde' hier (had het nog niet gelezen toen ik bovenstaande typte, maar genoemd bij punt 21 en 93):
https://www.scribd.com/do...of-californian#from_embed

[Reactie gewijzigd door kidde op 29 juli 2024 14:43]

[MSalters]

Voor het geval je 't gemist had - Meltdown is een bug bij de speculatieve executie, na een conditional branch. De essentie is dat de exceptie niet optreedt, omdat die zit op de niet-genomen tak, maar tijdens speculatieve executie weet je nog niet welke tak genomen wordt. Dat is CPU semantiek, en Intel doet hetzelfde als AMD daar.

Het verschil is dat AMD de exceptie al wel voorbereid tijdens speculatieve executie, nog voor de branch. Intel stelt dat uit tot na de branch.

[kidde]

Precies wat ik zeg

[Fijinees]

Voor bedrijven die veel VM's draaien hadden ze in ieder geval kunnen waarschuwen. Die bedrijven kan het dus echt veel geld kosten.

[Gijs007]

Daarom moet je op Windows Server deze beveiligingsmaatregelen handmatig activeren.
Zie: https://support.microsoft...the-speculative-execution

[catfish]

Vervang die "kan" maar in "zal".
Als je opeens 20 tot 30% extra servers nodig hebt om dezelfde service te leveren gaan de kosten serieus stijgen.

[Tim2010]

Het blijft altijd een kleine groep die het doet. De gewone consument is erg mak wat dat betreft. Natuurlijk is het goed dat mensen compensatie eisen als blijkt dat Intel nalatig is geweest maar 9 op de 10 mensen doet dat niet.

[SirBlade]

Om (in Nederland) compensatie te krijgen moet je kunnen bewijzen financiële schade te hebben geleden. Veel succes om dat als consument te doen. Misschien dat je het kan gooien op een hogere energie rekening, maar dat zal zo'n klein bedrag zijn dat het niet de moeite waard is om er werk van de maken.

[Fredi]

Tuurlijk heb je financiele schade als je rapper je processor moet upgraden omdat hij nu ineens >10% van zijn prestatie verliest door deze patch.

[SirBlade]

Dat is pas een probleem als je processor regelmatig meer dan 90% van zijn capaciteit gebruikt.

[Fredi]

Zoals bij miljoenen pc-gebruikers het geval is.

[MSalters]

Het probleem is dat die 10% performance in vergelijking met een onredelijke situatie is, namelijk die van een onveilige PC. Intel kan wijzen op al die anti-virus programma's die ook performance kosten - er is dus al jarenlang sprake van acceptatie. Veiligheid is niet gratis. Dat de kosten nu hoog zijn is juridisch niet zo relevant; dat is een kwestie van pech en was niet voorzienbaar.

[EraYaN]

Het is dan wel weer dubieus dat er dan wel voor iedere bug een class action lawsuit gestart kan worden. Je zou toch zeggen dat men het niet express heeft gedaan.

[Vizzie]

Prima als Intel hier op aangesproken wordt en er iets aan moet doen, maar dat jij een cpu gekocht hebt voor teveel geld is onzin. 1,5 jaar geleden was er nog geen ryzen en vond jij dat ding blijkbaar t geld waard dus dat is geen argument in dit verhaal.

[jick]

Eens, ik moet dat wat verduidelijken, ik vond dat geld het toen waard, maar ik heb dan ook betaald voor bijbehorende prestaties. Intel had al een monopolie en er was niet echt een alternatief. Dat is er nu wel, dus de situatie is nu idd anders, maar dat ik nu de gevolgen van teruglopende prestaties zou moeten dragen zonder dat dit gecompenseerd wordt voelt erg wrang. Tenslotte heb ik voor die prestaties in de eerste instantie betaald, en ze zijn me beloofd door de producent.

[Nicael]

Echt? Ik denk dat de Nederlandse wet je hierbij geen gelijk zal geven. Gezien dat de wet voorziet in een deugdelijk product, welke kan wat de verkoper heeft beweert.

Maar in wezen heeft Intel je hier een dienst bewezen door je product veiliger te maken. Dat jij hierdoor inboet op performance is in wezen jouw keuze geweest (vooral hierop het tech-savvy Tweakers). Want je had ook de update niet kunnen installeren.

[Janpietertje89]

Dat is natuurlijk onzin, een processor hoort veilig te zijn, blijkt er een significante design fout in een product te zitten waardoor het niet veilig is lijkt me dat zeker geen deugdelijk product. Beetje als een auto met een topsnelheid van 220km per uur verkopen welke later begrenst wordt op 180km per uur omdat hij niet veilig is bij 220. Lijkt me zeker valide reden om te klagen.

[jubes]

Ik ben het eens met je punt maar niet met je vergelijking De auto kan 220km/u maar is onveilig. Ze kunnen hem veilig maken maar dan gaat hij maar 180km/u. Eigenlijk exact het volkswagenschandaal wanneer je veiligheid voor vervuilend inruilt en snelheid voor vermogen

[Janpietertje89]

Dat maakt de vergelijking toch alleen maar beter. Daarvoor heeft Volkswagen juist flinke schadevergoedingen moeten betalen.

[MSalters]

Volkswagen is een bijzonder geval, want er zijn wettelijke regels over uitstoot, en "defeat devices". Juist omdat je expliciete regels overtreed is het makkelijk om rechtzaken te voeren. Intel is maar een toeleverancier van onderdelen, en het is uiteindelijk het OS wat onveilig is, terwijl er geen wettelijke regels zijn voor computerveiligheid. Dat maakt je zaak veel complexer.

[Spanky79]

Het is een ondeugdelijk product en dus levert jouw leverancier een wanprestatie. Nu zal deze wel te goeder trouw zijn. Dus niet nalatig.

Ikzelf heb net 2 maanden en nieuwe Alienware... Ik denk dat ik nu om een nieuwe kan vragen..... Echter zijn er geen veilige processoren...

[Roy_WL]

Amd

[sambalbaj]

Reken maar dat er in de VS al advocaten een class action rechtszaak voorbereiden.
Hier zullen de stichtingen Intelclaim of zoiets ook wel komen. Kan uiteraard wel jaren duren voor er iets uitkomt.

[Shark.Bait]

nou...
Intel Hit With Three Class Action Lawsuits Related to Security Vulnerability

maar ja, iNtel heeft zich natuurlijk goed ingedekt (hopen ze/verwachten ze)

"The products described in this document may contain design defects or errors known as errata which may cause the product to deviate from published specifications. Current characterized errata are available on request." (van de intel website geplukt) Dit zit natuurlijk bij elke CPU van intel die je koopt maar die niemand leest.

[Squee]

maar ja, iNtel heeft zich natuurlijk goed ingedekt (hopen ze/verwachten ze)

"The products described in this document may contain design defects or errors known as errata which may cause the product to deviate from published specifications. Current characterized errata are available on request." (van de intel website geplukt) Dit zit natuurlijk bij elke CPU van intel die je koopt maar die niemand leest.

Sterker nog, de Spectre/Meltdown lekken zijn waarneembaar door extra-functioneel gedrag (de side-effects van cache accesses tijdens speculatieve executie die normaliter niet waarneembaar is). Dergelijk gedrag is niet onderdeel van de processor architectuur specificatie, oftewel de "published specifications" die hier worden aangehaald. Elke succesvol uitgevoerde instructie zal niet-speculatief precies de gewenste semantiek vertonen. Dus wat dat betreft heeft Intel prima een sterke claim dat hun producten exact volgens de specificaties werken, ondanks de aanwezigheid van de door Spectre/Meltdown blootgelegde informatie via side-channels.

Aan de andere kant kunnen ze ook niet ontkennen dat er security defecten zijn in hun producten, die voorbij gaan aan de product specificaties. Vooral het feit dat er "schade" optreed in de vorm van een afname van performance, danwel veiligheid, lijkt mij ze toch ook wel juridisch aan te merken. Het gaat in ieder geval interessant worden wat er hier wel en niet hard gemaakt kan worden in de rechtzaal. Ik ben geen expert op juridisch gebied, maar ik vraag me dan af waar dan de grens van het acceptabele ligt. Stel je voor; Microsoft vind een groot veiligheidslek in Windows, en komt met een patch die je 5% performance kost. Gaan mensen dan simpelweg de patch installeren "want je wil veilig zijn", of gaan ze dan Microsoft aanklagen vanwege het performance verlies?

[Pb Pomper]

Men wist dondersgoed waar men mee bezig was bij Intel, maar koos voor dat extra beetje performance ten koste van de ingebouwde veiligheid.
Je kan zoveel in je voorwaarden zetten, maar dat betekent niet automatisch dat je bent ingedekt.

[MSalters]

Intel verkoopt in de VS, dus dat zou mee kunnen vallen. Consumenten in de EU hebben niet direct bij Intel gekocht, dus de tussenhandel heeft mogelijk een groter probleem.

Overigens: hoe bewijs je dat Intel wist dat ze nalatig waren? Spectre was een issue op meer CPU's, dus Intel is daar eigenlijk al meteen veilig. Meltdown zou je nog iets mee kunnen proberen, maar er is geen spat bewijs dat iemand daar vooraf van op de hoogte was.

[Fredi]

Ik zou ook wel een klacht willen indienen tegen Intel. Je processor die zomaar eventjes meer dan 10% van zijn prestatie verliest dat kan gewoon niet. Ik heb een 4790K en dat wordt stilletjes aan krap bij de nieuwste games en als die door deze patch nog eens >10% prestatie verliest wordt het helemaal mooi. Ik heb deze dure processor niet gekocht om enkele jaren later zomaar eventjes aan prestatie te verliezen buiten mijn wil om.

[Pablo]

installeer je de updates toch niet ?

[Fredi]

Ja en dan met een onveilige pc zitten zeker, nee dank u. Je hebt gewoon geen keus.

[Trommelrem]

Reken maar dat hordes mensen hun oude PC uit 1995 uit het archief halen en conformiteit gaan claimen!

[Soldaatje]

Moet je eerst een patch zien te krijgen voor Windows NT die je Pentium Pro 10% langzamer maakt.
(Tenzij je er Linux op draait die nog updates krijgt.)

[jick]

Dat argument is vrij makkelijk onderuit te halen lijkt me als gevolg van het verlopen van de expected life span. Voor een processor van 1 of 2 jaar oud ligt dat toch wel wat anders.

[Martinspire]

Niet helemaal. Het kan best mogelijk zijn dat iemand destijds al wel wist van het probleem. Of bv overheden en bedrijven die de bugs misbruikten om informatie te winnen van andere landen en concurrenten.

Het gaat er vooral om of ze van het probleem wisten en bewust alles onder de pet hielden.

[jimzz]

Ik denk dat degene die er wel vanaf wist (als die er al is) multi multi multi multimiljonair geweest zou zijn als hij dat voor zo’n lange periode verborgen heeft weten te houden. Ik denk dan ook dat Intel hier daadwerkelijk geen weet van had en dus zal Intels boete (wanneer ze die ook gaan krijgen) een stuk lager zal uitvallen.

Maar goed dit kan nog alle kanten uit, het enige vreemde vind ik dat iedereen enkel Intel noemt, maar ARM en AMD buiten beschouwing laten. Dit lijkt dus alsof enkel Intel met de bug te maken heeft terwijl de Spectre bug voorkomt op vrijwel alle processors.
Tuurlijk ze zijn niet kwetsbaar voor de meltdown bug waardoor het kwaad van de meltdown bug de spectre bug (die dus veel meer aangaat dan alleen intel) compleet overschaduwd.

[Nas T]

Ik zou eerst kijken in hoeverre Intel aansprakelijk gesteld kan worden voor een zaak te starten. Ik zou namelijk ook niet blij zijn met een dure cpu waar "ineens" 10% van het vermogen van verdampt. Alleen is de vraag: kan Intel aansprakelijk gesteld worden? In hoeverre had Intel dit van tevoren kunnen/moeten zien aankomen en daarop kunnen anticiperen?

[Trommelrem]

Waarschijnlijk komt er net als met de FDIV bug een swap actie. De CPU's zijn namelijk niet conform en het swappen is waarschijnlijk goedkoper dan procederen. Bovendien kan Intel ook gewoon via Windows Update microcode updates doorvoeren.

[Madden]

Bovendien kan Intel ook gewoon via Windows Update microcode updates doorvoeren.

Dat is het hem juist. Dit probleem is niet via microcode op te lossen (want ontwerpfout) en op dit moment nog alleen op te lossen door op een hoger nivo een 'omleiding' in te stellen waardoor de CPU juist die prestatievermindering gaat vertonen.

[field33P]

De vraag is alleen tot hoever terug Intel CPU's wil gaan verwisselen (aangezien alles sinds P6 getroffen is).

[Euronitwit]

Swappen van een laptop CPU, die vast gesoldeerd is?
Zie ik niet gebeuren.

[Vedette.]

Überhaupt is het nog maar de vraag of Intel verantwoordelijk is voor lagere prestaties. Technisch gezien leveren de processoren nog exact dezelfde rekenkracht. Een verandering in het ontwerp van besturingssystemen heeft een vertraging tot gevolg. Dat de aanleiding voor deze wijziging naar het ontwerp van de CPU is terug te leiden maakt niet dat de CPU's slechter zijn geworden. Je zou ook kunnen beargumenteren dat een ontwerp fout in besturingssystemen jaren lang extra performance uit CPU's heeft gemolken ten koste van security. Desalniettemin is het uiteraard zuur dat we er allemaal op achteruit gaan. Kunnen we niet gewoon afspreken dat niemand misbruik zal maken van Spectre en Meltdown, dan patchen we gewoon lekker niet

[tzunix]

Volgens mij is het anders behoorlijk duidelijk: De prestatieverminderende patches op OS level worden alleen ingevoerd doordat er een ontwerpfout in de CPU taakafhandeling zit, om die ontwerpfout te vermijden. Niet omdat de prestaties 'uitgemolken' worden (bizar idee trouwens... klinkt een beetje alsof je het gebruiken van standaard functies van een CPU als het opvoeren van een scooter ziet of zo)... OS-en maken keurig gebruik van de mogelijkheden van de CPU, En die zijn onveilig gemaakt.

Oorzaak = Ontwerpfout. Gevolg = Prestatievermindering (tenzij je de patch niet doorvoert, en dus wenst insecure te draaien). Aansprakelijkheid lijkt mij zo klaar als een klontje.

Insecure is thuis natuurlijk een optie die je kan overwegen, maar in grote datacenter met enorme aantallen concurrent gebruikers lijkt dit gezien de aard van de bugs niet echt een optie.

[MSalters]

Dat klopt niet. Het probleem is dat Windows en Linux kernel geheugen lekken, omdat ze de page table voor user space nog steeds descriptors hebben staan naar kernel geheugen. Dat is een beslissing van de OS makers. Begrijpelijk uit performance overwegingen, want dan hoef je niet bij een syscall die descriptors op te halen, maar niet veilig naar nu blijkt. Kun je Intel verwijten dat het OS z'n page tables zo gebruikt?

[tzunix]

Dat OS-en een platform bieden voor exploit: ja, dat is zeker. Geen OS op de CPU levert vrijwel zeker geen kans op het exploiteren van de bug (maar dat betekent dat de CPU niets nuttigs meer doet uiteraard). Het OS is dus de enabler van misbruik van de ontwerpfout in de CPU.

Dat de bugs een feature van de CPU betreffen die flawed is is ook zeker. Kortom: De CPU is fout. Het OS moet daar nu omheen werken om exploits van de fout onmogelijk (moeilijker?) te maken, en introduceert daarmee 'traagheid', performance verlies. Met als gevolg verlies aan processing power voor de eigenaar van de CPU. Die dus mogelijk moet gaan investeren om zijn performance weer zodanig op te krikken dat de boel weer werkbaar wordt.

Nog steeds een simpel geval oorzaak-gevolg nog steeds lijkt mij, waarbij de grondoorzaak van performance verlies bij de CPU en zijn ontwerp ligt. Niet bij de OS makers.

[MSalters]

Dat de bugs een feature van de CPU betreffen die flawed is is ook zeker.

Hoezo, "flawed"? Intel levert dikke handleidingen die het gedrag beschrijven, maar in dit geval staat er niets over in. En een CPU die zich conform specificatie gedraagt kun je niet zomaar als "flawed" beschrijven.

Nu hadden een heleboel mensen (inclusief kernel coders bij Microsoft en Linux) aannames gemaakt, en die aannames waren wel flawed (want niet in overeenstemming met de werkelijkheid), maar als de aanname niet overeenkomt met de werkelijkheid kun je niet zomaar zeggen dat de werkelijkheid flawed is.

[tzunix]

'maar in dit geval staat er niets over in' - Ja dat dus.

Over een absoluut oordeel of we het nu hebben over een hardware flaw of documentatie flaw, dat laat ik graag over aan juristen (of filosofen), en voor mij hoeft daar geen discussie over te zijn, en is wat mij betreft lood om oud ijzer. Product CPU en bijbehorende documentatie is wat mij betreft één geheel.

Als dit niet wordt aangemerkt als hardware flaw (en daar lijk je nogal gebrand op te zijn, ik ben daar iets minder tegen), is dit een flaw in documentatie vanuit de CPU leveranciers. De dikke handleidingen zijn blijkbaar nog niet dik genoeg, of hadden minstens moeten worden aangevuld met een waarschuwing in dikke letters aan programmeurs en gebruikers van de CPU, en deze was er zeker niet op het moment van aan het licht komen van de meltdown en spectre CVE's. Toen was deze 'undocumented feature' ( ) nog niet bekend tenslotte.

Dat je in de werkelijkheid als geheel tot aanname's moet komen lijkt me helder (die is vanwege zijn omvang wat lastig te bevatten voor een individu), maar met betrekking tot een CPU lijkt het me normaler dat ruimte voor aannames zoveel mogelijk wordt voorkomen. Hetzij door een sluitend secure hardware ontwerp (zou wat mij betreft het netste zijn), hetzij door documenteren.

[MSalters]

"Sluitend secure hardware" is een vrij loze kreet. Hardware kan niet afdwingen dat je encryptie gebruikt, hardware kan niet afdwingen dat je passwords unencrypte in databases zet, en hardware kan ook niet afdwingen dat je OS sensitieve data onleesbaar maakt voor user-space apps. Hoe moet een Core i7 nu weten dat de string "hunter2" een password is?!

En het is in de praktijk volledig onmogelijk om een complexe chip volledig te documenteren. Dat geldt voor Intel, dat geldt voor AMD, dat geldt voor ARM. Zelfs bij RISC-V is alleen de layout openbaar. In hoeverre RISC-V vatbaar is voor Spectre mag je zelf proberen af te leiden uit de transitoren.

[tzunix]

Sluitend secure hardware is zeker geen loze kreet. Wat ik ermee bedoel is blijkbaar (misschien interpreteer ik je verkeerd ) iets anders dan wat jij interpreteert.

Ik bedoel dat een apparaat of onderdeel zodanig ontworpen zou moeten zijn dat er naast de bedoelde functies geen ruimte is voor onbedoeld of onvoorspelbaar gedrag. En waar dat niet tot de mogelijkheden behoort (niet geheel ondenkbaar bij complexere hardware), dat dat dan netjes gedocumenteerd wordt zodat een beoogde gebruiker van je product, zoals een OS leverancier van een CPU bijvoorbeeld, daar rekening mee kan houden in gebruik.

Ik bedoel daarmee niet dat hardware security zou moeten leveren voor de hele functie die uitgevoerd moet worden door de hardware. Secure elementen insecure gebruiken, natuurlijk kan dat, altijd. Ik kan ook een emmer water over een huis-tuin-keuken lichtschakelaar dumpen, of er een hoogspanningskabel over proberen te schakelen. Beide niet de bedoeling, maar lastig te vermijden in hardware, en beide serieus onveilig te noemen. Maar beide wel gedocumenteerd als 'niet de bedoeling', hetzij als plaatje of tekst op het doosje waarin de schakelaar zit/zat, hetzij in de CE norm waaraan de schakelaar voldoet.

Als een belangrijke performance verbeterende feature wordt aangeboden op een CPU, maar deze veroorzaakt insecure zijeffecten (zonder privilege check geheugen kunnen lezen op hardware level bijvoorbeeld), dan hoort dat bekend te worden gemaakt. Dat had ook aan het licht moeten komen tijdens de ontwerpfase of simulaties van de CPU's, voor productiegang. Zo niet, dan heb je een security flaw geintroduceerd op het laagste niveau, de hardware (elementaire fysica even buiten beschouwing gelaten natuurlijk, waarop flaws moeilijk te introduceren zijn, maar foute aannames des te meer).

Dat je daarnaast insecure ontworpen/geschreven code kunt laten draaien op zo'n CPU is in dit geval totaal niet relevant (je referenties aan encryptie en password herkenning). Dat is uiteraard de verantwoordelijkheid van de maker van de code.

Het is tenslotte zeker niet onmogelijk om een complexe chip te documenteren. Het is op zijn hoogst veel werk. CPU Ontwerpen worden al heel lang gemaakt door middel van grotendeels geautomatiseerde processen of in ieder geval geautomatiseerde systemen, en uitgebreid gesimuleerd voordat ze worden geproduceerd in nagenoeg volledig automatische processen, en documenteren zou daar echt wel in meegenomen kunnen worden. Ik zeg niet dat ik het allemaal zou willen lezen, maar een OS leverancier zou dat mogelijk (hopelijk) wel willen, zeker als dat aspecten (performance, security) van zijn eigen producten daardoor worden beinvloed.

Voordat er mensen dingen als 'get a room' of iets dergelijks gaan roepen ... ik ben klaar met deze discussie hoor... voor mij is het zo klaar als een klontje (suiker bijvoorbeeld). En aangezien ik altijd overal gelijk over heb kom ik daar ook gewoon nog mee weg.

[Verwijderd]

Het is gewoon een compleet nieuwe cpu maken die deze exploits gewoon niet heeft. Alle cpus zijn vatbaar vanaf 1995.

[Mellow Jack]

Ik vraag me af hoe Intel deze blunder gaat aanpakken want de grotere klanten die Windows Server en dergelijke draaien zullen hier enorm kwaad over zijn.

Geen idee hoe bedrijven over de hele wereld hierop gaan reageren. Het bedrijf waar ik werk, een klant van 1 v/d grotere Intel klanten is blijkbaar niet enorm onder de indruk. Er zijn meerdere security analyses uitgevoerd (in en extern) en er is voor onze infrastructuur niet direct een gevaar.

Voor de cloud/external facing organisaties is het natuurlijk een heel ander verhaal. Weer ergens een slecht ingerichte MongoDB kan nu, heel theoretisch, impact hebben op andere VM's op dezelfde host

[apa]

Meltdown kan je als een bug zien en daar zou je een vergoeding voor kunnen bedenken... Iedere ontwikkelaar zal je garanderen dat bugs nooit volledig te vermijden vallen. Je voorziet daarom mogelijkheden om die later op te lossen (via updates). Het lijkt mij sterk dat je een vergoeding zal kunnen eisen... Voor zover ik het begrijp heeft de fix/work-around voor Meltdown bovendien minder effect op de performance...

Spectre is echter geen bug, maar draait om het vernuftig uitbuiten van een side-effect van OoO execution... Ik zie niet hoe je de fabrikanten iets kwalijk kan nemen omtrent dit probleem.

[PulsatingQuasar]

Waarom iedere keer dat commentaar op Intel? Alle processoren hebben last van de Spectre bug. AMD, ARM en Power CPU's ook.

Alle fabrikanten bouwen al 15 jaar CPU's volgens eenzelfde basis architectuur dus hebben ze er allemaal last van. Het is een complexe materie waarbij niet zomaar duidelijk is wat er allemaal aan problemen kan optreden.

Voor elke processor van welke fabrikant dan ook worden al jaren software fixes door gevoerd in het BIOS en het OS alleen hebben we het hier over een fundamenteel probleem die zich niet zo maar laat dichten.

Dus ik denk niet dat Intel nalatig is geweest. Ze hebben er allemaal last van. Niet omdat ze allemaal nalatig zijn geweest maar omdat het even heeft geduurd voordat men deze problemen zag

[Verwijderd]

Dat commentaar op Intel komt omdat de patches aanzienlijke performance problemen kunnen gaan zorgen bij met name server systemen. Daar komt bij dat ze niet bepaald briljant hebben gereageerd op dit -zoveelste- security breach.

[PulsatingQuasar]

Ik denk dat dit niet alleen voor Intel geldt. Ook voor AMD. Ook voor de Power CPU's.

Op mijn werk hebben we van zowel Redhat voor de Linux systemen als van IBM voor de AS400 met de Power CPU's bevestigd gekregen dat de Spectre vulnerabilities aanwezig zijn en dat ze nog niet weten wat de impact zal zijn op performance.

[ardvark99]

Hoe zit het eigenlijk met virtuele machines? Moeten de VM's ook gepatched worden?

[Verwijderd]

Ja natuurlijk! Host en client OS. Sowieso elk OS, maar VM's is het meest genoemde voorbeeld van waar het fout gaat.
Ook docker.
Quote uit het vorige artikel op tweakers:

Bos omschrijft de kwetsbaarheden als ernstig en stelt: "Zeker op computers waar code draait van meerdere gebruikers kan gevoelige informatie worden gelekt. Dit geldt bijvoorbeeld voor cloudomgevingen waar programma's van verschillende organisaties dezelfde fysieke hardware gebruiken, ..."
Hetzelfde geldt voor hosted services, waar je een stukje hardware huurt en dus gezamenlijk gebruik maakt van dezelfde hardware.

[ardvark99]

Ok, maar in mijn geval heb ik thuis een eigen server draaien, met Hyper-V 2012 R2, en 3x een 2012 R2 server en een W10 VM's heb draaien. Alleen ik heb toegang tot deze machines, ik vraag mij dus af hoe belangrijk deze patches voor mij zijn. Ja, altijd alle patches installeren is natuurlijk de voorkeur, maar aangezien deze patches ook de performance beinvloeden, ben ik niet zo happig om dit gelijk te installeren.

[Verwijderd]

" Alleen ik heb toegang tot deze machines"
Hoe bedoel je? Elke VM kan gehackt worden. (anders zou niemand security updates hoeven te doen).
Door het nieuwe beveiligingslek zouden alle andere VM's en de host eveneens in gevaar zijn. Terwijl VM's en host van elkaar afgeschermd horen te zijn.

Vreemd dat dit nog niet duidelijk was. Maak je een grapje? Heb je de berichten over spectre/meltdown niet gelezen? Als je er zo weinig van begrijpt is het belangrijk dat je de adviezen opvolgt. Dus alle updates uitvoeren zodra die voor het OS beschikbaar zijn.

[Anonymoussaurus]

Moet is wat anders, maar het kan nooit kwaad natuurlijk. Sterker nog: door één van deze lekken is het mogelijk om bijvoorbeeld bij een andere VM te komen, als jullie dezelfde fysieke processor delen: https://en.wikipedia.org/...ity_vulnerability)#Impact

[Mocro_Pimp®]

En hoe zit het dan met een gepatched linux hostsysteem zoals dat van TransIP. Althans, ik dacht dat de VM's daar op een Linux hostsysteem draaien.

Maar als wat jij zegt klopt, dan is de veiligheid dus nooit meer gegarandeerd, want er hoeft maar één afnemer te zijn die (al dan niet met opzet) een ongepatchte VM draait.

[Verwijderd]

Uiteindelijk zullen ongepatchte systemen afgesloten worden van het netwerk (en andere resources). Net zoals je bij een gewoon computernetwerk niet toestaat dat het netwerk door 1 slecht beveiligde PC in gevaar gebracht wordt.

[Reactie gewijzigd door Verwijderd op 29 juli 2024 14:43]

[Mocro_Pimp®]

Ja en precies dit lijkt mij - geen expert - onmogelijk.

Stel de hoster heeft een hostsysteem dat gepatched is voor Meltdown. Op dit systeem laat hij alleen gepatchde VPS'en toe. Problem solved? Die afnemer van de VPS kan weer een VM binnen de VPS draaien. Om toegang te krijgen tot het geheugen is verder ook geen netwerkverkeer nodig. Met andere woorden. VPS'en kunnen nooit meer veilig zijn, tenzij iedere VPS een eigen geheugenreepje en CPU krijgt, maar dan is het niet echt virtueel meer en gewoon een private server.

[Verwijderd]

De afnemer kan zelf ook gaan hacken. Dus inderdaad, je kan nooit alles uitsluiten.
Maar situaties die de regels overtreden, en die gemakkelijk vastgesteld kunnen worden door de beheerder. Die worden tot een minimum beperkt.

[Anonymoussaurus]

Ook Linux is gewoon vatbaar voor Meltdown. Het is nogal verwarrend af en toe; welke scenario's, geldt het ook voor VM's, etc etc. Echt duidelijke 1-op-1 antwoorden krijg je niet. Het is natuurlijk wel een tikkeltje naïef om te denken dat alle hosters netjes updaten.

[dyrc]

sprekende voor mijzelf (met een recente intel processor): voor een abuse die "must have code execution on the system" nodig heeft ga ik geen structurele 6-9% performance inleveren (6-9% gebaseerd op "anders hadden ze het wel anders verwoord"). hopelijk komt dit in een losse KB die ik kan overslaan.
dan is de fix erger dan de potentiele kwaal(?)

[PolarBear]

"must have code execution on the system"

Kan dus ook via Javascript.

[MSalters]

Javascript, mits dat draait in een kwetsbare VM. Het is aannemelijk dat de VM's gefixt gaan worden, en de performance impact daarvan is natuurlijk een heel stuk kleiner (en sowieso beperkt tot JS)

[EraYaN]

Het is dus ook niet structureel natuurlijk, eigenlijk alleen een extra delay als er van user mode naar kernel mode geswitched moet worden. Het meeste zal komen van de nieuwe microcode (dus BIOS update). "Code execution" is ook javascript in de browser.

[Carni]

Als de oplossing is een nieuw besturingssysteem en processor klinkt dat niet erg vervelend voor Microsoft en processor bakkers en hoop ik maar dat het echt zo is dat oude processors Windows 7 en 8 er meer last van hebben i.p.v. een kunstmatig gegenereerde reden.

[MSalters]

Ik vermoed dat het probleem is dat Windows 7 nog geen gebruik kan maken van de PCID feature, omdat Win7 oude processoren ondersteunt. Alle processoren waarop Win10 draait zijn nieuw genoeg om PCID te hebben.

PCID is een feature waarmee je address spaces kunt nummeren. Je kunt vooral ook kernel space en user space aparte nummers geven.

[Carni]

Dat zou dan alleen voor die gevallen gelden waar de CPU wel al PCID heeft, maar het oude OS hier geen gebruik van kan maken, vergeleken met de zelfde CPU onder b.v. W10. Want in het geval van een oude CPU zonder PCID zou er dan weer geen verschil (m.b.t. dit lek) moeten zijn of je deze gebruikt met W7, 8 of 10 ?

[MSalters]

W10 installeert niet eens op de oude CPU zonder PCID, dat is waarom W10 dat feature kan gebruiken.

[Carni]

Aha. Ik wist niet dat W10 niet op een CPU zonder PCID kon draaien. Ik had het al eens getest i.c.m. een Core D en dat werkte. Die had dan blijkbaar toen al PCID. Verbaast me dan wel weer dat het OS dit pas kon gebruiken lang na dat de Core D ergens in een la belande.

[MSalters]

PCID is inderdaad een oude techniek die lang niet gebruikt is.

[computerjunky]

Precies. Nou zelfs als ik een nieuwe pc zou kopen zou ik toch eerst weer windows 7 erop kwakken als mogelijk.

Zat te denken aan de 8700k als hij iets gezakt was maar wacht nu wel op de eerste generatie met gepatchde cpu zodat ik niet afhankelijk ben van een software oplossing die je pc op zn gat legt.

[Durandal]

AMD is ook een optie.

[computerjunky]

Niet echt. Per core prestatie is erg belangrijk voor mijn gebruik en de amd is ook lek dus dat schiet ook niet op. Wachten en hopen dat ryzen 2 en 9xxx gefixed zijn.

[Roy_WL]

Denk niet dat iemand nu nog vertrouwen heeft in intel. Amd gaat komende tijd goede zaken doen.

[3V3RT]

AMD heeft ook nog niet helemaal zijn straatje schoon, zie dit artikel: https://support.microsoft...or-some-amd-based-devices

[Enchantress]

Dit is een probleem van Microsoft en niet van AMD.

AMD heeft eigenlijk geen echt probleem, zoals je ook gewoon kan zien als je zoekt op spectre.
https://www.amd.com/en/corporate/speculative-execution

AMD kan last hebben van spectre variant 1, maar alleen als eBPF JIT aan staat in de bios, wat standaard niet het geval is en in de praktijk ook heel weinig voor komt. Dit is ook extreem moeilijk te hacken en moet je sowieso fysiek aanwezig zijn. Zoals gezegd als je fysiek aanwezig moet zijn heb je wel andere problemen...

AMD is dus gewoon veilig.

[catfish]

Is het dan echt al bewezen dat AMD cpu's in normale omstandigheden (dus eBPF JIT uit) nooit problemen hebben?
Ik lees die claims wel, maar lees ook dat anderen daar aan twijfelen.

[Morphin3]

Voor zover ik dat begreep was het niet zozeer een probleem dat AMD veroorzaakte, maar dat de Spectre update van Windows bij bepaalde AMD processors veroorzaakte. Geen idee of AMD daar echt iets aan kon doen?

[grobbel]

MS claimt dat de documentatie van AMD incorrect was (http://mashable.com/2018/...-amd-athlon/#T6L2DqT4Fkqh).

[Anonymoussaurus]

@gabba25 @Tourmaline @Fire69 Leuke tegenspraak, maar het is natuurlijk wel heel toevallig dat de auteur van het Microsoft-artikel, Terry Myerson geen woord rept over AMD en het alleen maar heeft over Intel-CPU's die het systeem doen vertragen. Doe hier maar eens een ctrl + F: https://cloudblogs.micros...tions-on-windows-systems/

Zal dan wel over een specifieke vulnerability gaan, bijvoorbeeld het lek wat alleen Intel gebruikers treft. Meltdown treft bijvoorbeeld alleen maar Intel-processors.

[Reactie gewijzigd door Anonymoussaurus op 29 juli 2024 14:43]

[PPie]

Meltdown treft bijvoorbeeld alleen maar Intel-processors

Incorrect. Meltdown treft ook de ARM Cortex A75 en de Apple ARM processoren.
Daarnaast begreep ik dat oudere AMDs ook vatbaar waren voor Meltdown.
Ze zijn zeker vatbaar voor Spectre.

[Anonymoussaurus]

Dat klopt, dat weet ik (dat staat namelijk zelfs in het artikel wat ik heb gelinkt), maar omdat zij overkwamen alsof Intel absoluut niet de enige was qua Intel & AMD, had ik het iets anders verwoord.

[Reactie gewijzigd door Anonymoussaurus op 29 juli 2024 14:43]

[gabba25]

AMD is ook kwetsbaar

[Enchantress]

Bij AMD is er eigenlijk geen spraken van een lek, je moet sowieso al fysiek aanwezig zijn en het is dan nog extreem moeilijk om dat te hacken. Als je überhaupt al fysiek aanwezig moet zijn heb je wel andere problemen.
Bij Intel is het een echt groot veiligheids probleem, zeker nu de ‘hackers’ in de wereld het weten!!
Bovendien is het bij Intel nog een probleem op hardware niveau dus de patches en updates zijn pleisters en verhelpen het probleem niet, dat komt pas bij de nieuwe CPU/architectuur en dat is 2020 geloof ik pas (?).

[Reactie gewijzigd door Enchantress op 29 juli 2024 14:43]

[R.Klein]

Bij AMD moet je fysiek toegang hebben tot de PC dus daarbij valt de kwetsbaarheid wel mee geloof ik

[Fire69]

Je kan het niet uit het artikel halen, maar AMD heeft hier ook gewoon last van hoor.
Net als bijna elke andere processor ter wereld, inclusief die in je telefoon/tablet...

Bvb: https://www.macworld.com/...or-safari-and-webkit.html

[Tourmaline]

Nee hoor, Intel en AMD zijn gelijk getroffen. Dat komt omdat zij patentovereenkomsten met elkaar hebben en elkaars technieken mogen gebruiken.

[bkor]

AMD en Intel zijn helemaal niet gelijk getroffen. Meltdown heeft de meeste performance impact. Daar heeft AMD bijna geen last van. Voor Intel heeft elke processor een enorm performance impact. Spectre heeft zowel AMD en Intel last van, impact van 1-1.5% ofzo.