Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door

Nieuwsredacteur

Meltdown en Spectre - Q&A

Gegevens uitlezen door cpu-lekken

167 Linkedin Google+

De belangrijkste vragen

Schreven we eind vorig jaar nog over het nut van branded vulnerabilities, beginnen we dit jaar meteen goed met twee nieuwe varianten met een eigen logo en website. Onderzoekers hebben details over de zogenaamde Meltdown- en Spectre-kwetsbaarheden gepubliceerd, die zich in het geval van het tweede lek voordoen bij moderne processors van Intel, ARM en AMD. De kwetsbaarheden maken het mogelijk om geheugen uit te lezen van de kernel en van andere processen, iets dat eigenlijk niet zou moeten kunnen door geheugenisolatie. Omdat dit wel blijkt te kunnen, behoort toegang tot gevoelige gegevens zoals wachtwoorden en privésleutels tot de mogelijkheden. In dit artikel gaan we kort in op de belangrijkste vragen rond de gepubliceerde lekken. Tweakers sprak daarnaast met Herbert Bos, die hoogleraar Systems and Network Security aan de VU Amsterdam is en aan het hoofd staat van de VUSec-onderzoeksgroep.

Waar hebben de kwetsbaarheden mee te maken?

Volgens Bos hebben alle kwetsbaarheden te maken met een techniek die bekendstaat als out-of-order execution: het berekenen van een resultaat voor het eigenlijk nodig is. Een goed voorbeeld hiervan is 
speculative execution, een truc die tot prestatiewinst moet leiden bij het uitvoeren van programma's. Bos legt speculative execution uit met behulp van een voorbeeld. Stel dat een programma de volgende instructies bevat: "Als een waarde in het geheugen, die geheim is en niet zichtbaar behalve voor de kernel, gelijk is aan een waarde n, laad dan uit het geheugen de waarde van het n-de element uit een tabel." Vervolgens legt hij uit hoe de processor hier speculatief aan gaat rekenen en hoe dit tot het lekken van informatie kan leiden.

"Wat een moderne cpu doet om dit sneller te maken, is alvast de waarde uit het n-de element van de tabel te laden, terwijl hij nog aan het bepalen is of de eerste waarde in het geheugen eigenlijk wel gelijk was aan n.  Als dat inderdaad zo was, dan heeft hij meteen de juiste waarde te pakken en dat scheelt tijd. Als dat niet zo was, dan heeft hij die waarde voor niks geladen. Maar dat geeft niet, want de cpu gooit die waarde dan gewoon weer weg. We noemen het laden van die waarde een 'speculatieve' operatie.  Er is niks aan de hand, tenzij een aanvaller op een of andere manier kan zien welke waarde speculatief werd geladen."

Dat laatste blijkt nu juist het probleem te zijn, vervolgt Bos. "Een slimme (Meltdown-)aanvaller kan zien welk element in de tabel werd geactiveerd. Dit heeft te maken met de manier waarop moderne processoren data die ze net gebruikt hebben tijdelijk in de cache zetten, zodat ze daar in de toekomst heel snel toegang toe hebben. Helaas is juist die extra snelheid een 'side channel' om informatie te lekken voor aanvallers. Door zelf te kijken of element n in de cache zit, bijvoorbeeld door te kijken of toegang tot deze data sneller gaat dan gebruikelijk, weten zij of het programma de waarde n had berekend. Op die manier lekt dus informatie uit het meest beveiligde deel van de kernel."

Wat zijn de verschillen tussen Meltdown en Spectre?

Zoals in het voorgaande nieuwsbericht al is beschreven, laat Meltdown het uitlezen van kernelgeheugen toe, terwijl Spectre dat toelaat voor processen onderling. De onderlinge verschillen worden ook nog eens duidelijk gemaakt door een afbeelding die het werk is van beveiligingsexpert Daniel Miessler. Het patchen van Meltdown is volgens de ontdekkers mogelijk, terwijl het voor Spectre moeilijker is om een omvattende oplossing te bieden en systemen te beveiligen. De onderzoekers stellen dat een oplossing in veel gevallen gezocht moet worden in aanpassingen van processorontwerpen en updates voor isa's. In het Meltdown-paper schrijven de onderzoekers dat ondanks tegenmaatregelen een attack surface overblijft. Zo blijft het mogelijk om pointers te lekken, die gebruikt kunnen worden om de kaslr-beschermingsmaatregel voor kernelgeheugen te omzeilen. De zogenaamde Kaiser-patches zouden echter de beste tegenmaatregel zijn.

Afbeelding via Daniel Miessler

 

Wie is getroffen? 

Uit het gepubliceerde onderzoek blijkt dat Meltdown zich hoofdzakelijk beperkt tot Intel-cpu's. Een proof-of-concept van Project Zero werkte op een Xeon-cpu van de Haswell-generatie en ook in het Meltdown-paper schrijven de onderzoekers dat ze hun aanval niet werkend konden krijgen op ARM- of AMD-processors. Ze stellen wel dat er een kans bestaat dat een geoptimaliseerde versie van hun techniek alsnog succes kan hebben op deze architecturen. Veel Intel-processors zijn kwetsbaar, volgens onderzoekers gaan getroffen cpu's terug tot 1995.

Spectre werkt zowel op Intel-processors als op die van AMD en ARM. Er zijn verschillende varianten van Spectre, gekenmerkt door CVE-2017-5753 en CVE-2017-5715. Respectievelijk duidt Project Zero deze aan als bounds check bypass en branch target injection. De eerste variant testten de onderzoekers met succes op cpu's van alle drie de fabrikanten. Maar die variant werkt alleen op een AMD Pro-cpu als eBPF om de een of andere reden is ingeschakeld. Dit staat standaard uit. AMD heeft in een eigen bericht geschreven niet of nauwelijks vatbaar te zijn voor de CVE's eindigend op 5754 en 5715, die toebehoren aan Meltdown en een van de Spectre-kwetsbaarheden. Over CVE-2017-5753 zegt AMD alleen dat dit verholpen kan worden met patches.

Inschatting door AMD zelf, waarbij met variant 3 Meltdown wordt bedoeld

 

Ook ARM heeft een overzicht gepubliceerd. Daaruit is op te maken dat alleen de Cortex-A75 vatbaar is voor Meltdown en Spectre, andere in het overzicht genoemde processors zijn alleen kwetsbaar voor de laatstgenoemde aanval. Er staan nog wel drie exemplaren tussen, de A15, A57 en A72, die vatbaar zijn voor alleen een Meltdown-variant. Die behoeft volgens ARM echter geen patch.

Diensten als AWS hebben inmiddels maatregelen genomen. Hetzelfde geldt voor Google, dat een overzicht heeft gepubliceerd van getroffen diensten. Daarin is ook Android opgenomen, waarvoor deze maand patches zijn uitgekomen. Mozilla heeft eveneens een advisory gepubliceerd, waarin het schrijft dat uit interne experimenten blijkt dat een aanval via webcontent mogelijk is. Daarom heeft het eerste maatregelen genomen in Firefox 57. Chrome ontvangt tegenmaatregelen in versie 64, die op 23 januari moet uitkomen. In de tussentijd kunnen gebruikers site isolation inschakelen.

Wat is het risico? 

Het risico van Spectre voor gewone gebruikers is volgens Bos moeilijk in te schatten, omdat de aanval moeilijk uit te voeren is. Meltdown is makkelijker te gebruiken, maar daarvan bestaat er weer geen implementatie in Javascript. Het lijkt hem echter 'triviaal' om een dergelijke implementatie te ontwikkelen. Hij vervolgt: "Het probleem is sowieso dat dit soort kwetsbaarheden alleen maar erger worden. Meer en meer mensen gaan ernaar kijken en ontdekken dan nieuwe manieren om ze te misbruiken. Ondanks dat we deze kwetsbaarheden nog niet door criminelen misbruikt hebben zien worden, denk ik dat het een ernstig risico is."

Ook op de lange termijn kunnen de kwetsbaarheden effect hebben. "Dit soort aanvallen lijken de nieuwe frontlinie van computerbeveiliging. Waren zulke aanvallen tot voor kort nog te scharen onder science fiction, zien we nu elke paar maanden een nieuwe aanval in deze categorie. Het gevolg is dat besturingssystemen nu beduidend anders worden van structuur, dat veel van de aannames die we deden over de veiligheid van hardware opnieuw onderzocht worden en dat, specifiek voor deze kwetsbaarheden, computers significant langzamer worden."

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, maar ook voor zoiets alledaags als een webbrowser, waarin voortdurend Javascript-code van websites wordt uitgevoerd."

Zijn er patches voor besturingssystemen?

Vooropstaat dat Meltdown patchbaar lijkt te zijn, terwijl dit voor Spectre moeilijker is. Verschillende fabrikanten hebben inmiddels patches gepubliceerd. Zo heeft Microsoft deze inmiddels beschikbaar gesteld voor Windows 10. Daarbij speelt de aanwezige antivirussoftware een rol, omdat sommige versies van av-suites niet compatibel zijn met de patches en het systeem deze daarom niet ontvangt. Beveiligingsexpert Kevin Beaumont werkt aan een overzicht waarin hij bijhoudt welke informatie door beveiligingsbedrijven naar buiten is gebracht. In de Linux-kernel zijn de patches in versie 4.15 vrijgekomen met backports naar versie 4.14.10. Ontwikkelaars voor de Linux-kernel werkten al een tijd aan zogenoemde Kaiser-patches. Die zijn begin december omgedoopt tot x86/kpti-patches, waarbij kpti staat voor kernel page table isolation. Volgens The Register is macOS gepatcht vanaf versie 10.13.2.

Draait mijn systeem trager door de patches? 

Onder meer Phoronix, Hardware Unboxed en Computerbase publiceerden benchmarks na het toepassen van de nodige patches. De tests van Phoronix betroffen Linux en wezen op aanzienlijke prestatievermindering bij toepassingen als FS-Mark-, Compile Bench- en PostgreSQL. Hardware Unboxed ondervond bij i/o-benchmarks op Windows nagenoeg alleen een noemenswaardige prestatievermindering bij 4k reads en acces time reads. Bij gaming zou er bij zowel Windows als Linux geen verschil in prestaties optreden. Vooral het uitvoeren van syscalls zou trager verlopen. Volgens Microsoft gaat 'de meerderheid' van de Azure-klanten geen prestatieverschil merken. Een kleine groep klanten zou lagere netwerkprestaties kunnen ervaren, maar dit zou op te lossen zijn door Azure Accelerated Networking te activeren.

Bos stelt dat er percentages tot 30 procent prestatievermindering worden genoemd, maar dat hijzelf niet gelooft dat het zo hoog zal uitvallen. "Ik geloof zelf niet dat het 30 procent zal zijn, maar zelfs 5 procent vertraging van vrijwel alle computers ter wereld levert een grote schade op. Daarnaast worden er wel veel patches voorgesteld, maar lossen de huidige patches het echte probleem niet op. Ze houden dan enkele varianten van de aanval tegen, maar het probleem blijft. Vooral de Spectre kwetsbaarheid blijft problematisch", aldus Bos.

Wie ontdekten de kwetsbaarheden? 

Bij de ontdekking van zowel Spectre als Meltdown was Jann Horn van Googles Project Zero betrokken. In de blogpost van het project is genoemd dat Intel, AMD en ARM op 1 juni van vorig jaar op de hoogte zijn gesteld. Voor Meltdown geldt dat deze kwetsbaarheid daarnaast door Werner Haas en Thomas Prescher van Cyberus is ontdekt, naast een team van de Technische Universiteit van Graz. Spectre werd naast Horn door Paul Kocher in samenwerking met verschillende onderzoekers ontdekt.

Reacties (167)

Wijzig sortering
Nu ik Meltdown en Spectre nog wat meer in detail heb bestudeerd wil ik ook nog eens proberen in detail uit te leggen wat er nu precies aan de hand is. Grappig genoeg werd net dit stuk geplaatst terwijl ik dit aan het schrijven was.

Beide exploits maken gebruik van het observeren van speculatieve executie. Dat is een eigenschap van out-of-order processor micro-architecturen, alhoewel ik niet zou uitsluiten dat bepaalde (vooral superscalar) in-order processors ook dergelijk gedrag gemeten zou kunnen worden. Speculatieve executie gebeurt als de processor denkt bepaalde instructies uit te moeten voeren, maar dit afhangt van een eerdere instructie waarvan het resultaat nog niet bekend is. Wanneer de uitkomst van deze instructie bekend is worden de resultaten van de speculatieve instructies weggegooid. Op architectureel niveau is het gedrag dus als gewenst, maar het is mogelijk om bepaalde side-effects te meten in de cache hierarchie en door precies geconstrueerde stukken code op deze manier informatie te lekken als side-channel.

De Meltdown attack is gebaseerd op een stuk code binnen de controle van de aanvaller, wat met speculatieve instructies alle data van de kernel kan blootleggen - en ook vaak van alle andere processen, als de kernel een complete physical address space mapping bevat. Het idee hoe zo'n aanval werkt had ik gisteravond geschetst, toevallig net voordat de details van Meltdown beschikbaar kwamen: Squee in 'nieuws: Intel ontkent berichten dat alleen zijn processors vatbaar ...

Het belangrijkste om te realiseren over Meltdown (Variant 3) is dat het doorgeven van speculatieve waarden van hogere privilege levels wel echt een bug is, die specifiek in Intel's moderne micro-architecturen voor lijkt te komen. Ik zou overigens niet uitsluiten dat er andere micro-architecturen zijn die een dergelijke bug bevatten. De reden dat dit gebeurt heeft te maken met verregaande optimalisaties voor het laden van data uit de L1 Data cache. De cache wordt benaderd tegelijk met de D-TLB, en blijkbaar wordt er niet op tijd bepaald of er permissie problemen mee waren, voordat de data via het bypass netwerk naar de volgende (speculatieve) instructies wordt doorgestuurd. Deze, zogeheten load-to-use latency, is iets waar je je micro-architectuur sterk voor wilt optimaliseren voor performance. Waarschijnlijk wordt er pas daarna een exceptie flag op deze instructie gezet, zodat de processor een exceptie neemt wanneer deze instructie retired/commit, op architectureel niveau correct, maar de informatie is dan al via een side-channel gelekt.

Spectre is een grotere klasse van problemen, die op een nog geavanceerdere manier informatie weet los te peuteren uit andere processen. Dit doen ze door de gedeelde branch predictor (BP) en branch target buffer (BTB) aan te vallen, wat heel erg standaard componenten zijn in zowat alle moderne processoren. Deze componenten zijn gedeeld, als in, gedeeld door verschillende processen afwisselend draaiende op dezelfde CPU core. Het is mij op dit moment niet duidelijk of het ook tussen twee HyperThreads zou werken; dat hangt af van of de micro-architectuur in kwestie de BP en BTB splitst of deelt tussen de threads.

Beide Spectre aanvallen werken op het zelfde principe. Door specifiek geconstrueerde instructie sequences te maken wordt of de BP of de BTB in een bepaalde staat gebracht. Als daarna een ander proces (of de kernel) op de core gaat draaien wordt hierdoor de speculatieve executie beinvloed. Deze kan dan weer meetbare side-effects opleveren, en op die manier data prijs geven.

De aanval via de BP is "Variant 1: bound check bypass". Door de BP te trainen met branches die binnen jouw virtual memory qua adres overeen komen met die binnen het virtual memory van de code die wordt aangevallen kan je proberen te forceren dat de volgende keer dat die code wordt uitgevoerd deze branch verkeerd voorspeld wordt. Het speculatieve pad achter deze verkeerd voorspelde branch zou dan een geheugen access moeten doen waarbij het adres afhankelijk is van de data, en je via cache preparatie en timing metingen (delen) kan achterhalen van de originele data.

De aanval via de BTB is "Variant 2: branch target injection". Omdat het erg lastig is om code patronen te vinden die geschikt zijn voor Variant 1, kan je ook proberen om te forceren dat de processor speculatief een specifiek stuk code uitvoert. Dit is gebaseerd op Return Oriented Programming (ROP) technieken; je zoekt naar bepaalde instructie sequences in een bekende binary (bijvoorbeeld libc), en probeert te forceren dat de code daar naartoe springt op het speculatieve pad. Dit kan gedaan worden door de BTB aan te vallen; deze zit helemaal voorin de processor pipeline in het Fetch gedeelte en probeert te voorspellen waar een indirecte branch heen zal springen. Door deze voor dat branch adres te trainen dat hij naar een verkeerd adres springt, kan je deze aanval uitvoeren. Waarschijnlijk is deze aanval vrij moeilijk omdat de BTB maar een kleine capaciteit heeft, dus de kans dat je speciaal geprepareerde state vervuild is voordat de aangevallen code deze branch bereikt is aanzienlijk.

Wat is hier aan te doen?
De beste oplossing is natuurlijk om dit allemaal op te lossen op micro-architectuur niveau; maar dat betekent een aantal jaar wachten op een nieuwe generatie processors waar dit in gefixed is. De false-sharing effecten binnen de BP en BTB waarbij twee verschillende contexten elkaar beinvloeden zou op te lossen zijn door deze data structuren een address space/process ID toe te voegen, zodat er geen aliasing meer ontstaat. In feite levert dat een sterkere scheiding op micro-architectureel niveau op tussen verschillende software contexten. Voor Meltdown zou een micro-architecturele aanpassing gemaakt moeten worden zodat de speculatieve privilage violation geen geldige data aan opvolgende instructies levert. Ook zou een betere MMU scheiding tussen hyperprivileged, kernel en user helpen.

Maar goed, dat is niet echt iets wat op de korte termijn werkt. Voor Meltdown hebben ze nu OS patches gebaseerd op het KAISER onderzoek; door de kernel page tables te unmappen als je in userspace bent, kan een dergelijk speculatieve instructie uberhaupt nooit bij het kernel geheugen komen omdat er geen translatie voor beschikbaar is. Dat kost wat performance, en zoals ik al eerder aangaf, bewijfel ik of dat werkt. (Zie laatste alinea van: Squee in 'nieuws: Intel ontkent berichten dat alleen zijn processors vatbaar ... ). Ik heb nog contact gezocht met Werner Haas (een van de onderzoekers) en het hier over gehad, en hij was van mening dat dat inderdaad best mogelijk zou kunnen zijn, en dat ze het zeker verder gaan onderzoeken na alle patches beschikbaar zijn gemaakt en uitgerold.

Voor de Spectre BTB aanval lijken ze nu patches te maken in de Linux kernel om indirecte branches non-speculatief te maken, simpelweg door er een barrier tussen te gooien. Dat is een vrij pijnlijke oplossing, al weet ik niet goed in te schatten hoeveel performance dit zou kosten. Voor de BP aanval heb ik nog geen duidelijke oplossing gezien.

Er zijn ook nog wel een aantal heel erg pijnlijke maatregelen die genomen zouden kunnen worden, zoals het compleet uitschakelen van branch prediction. Ik vind het lastig in te schatten wat voor performance effect dat zal hebben, maar dat zal *enorm* zijn. De vuistregel is dat ongeveer een in de vijf instructies een branch is, en als je dan regelmatig een 50+ cycle flush moet doen omdat een branch toch genomen moest worden... ouch, daar gaat je performance. Er zou ook in theorie een micro-code update kunnen komen die alle branches, en/of alle indirecte branches een barrier effect geeft, zodat er niet voorbij gespeculeerd kan worden. Dit zou ook een enorm performance effect hebben.

Ik ben heel erg benieuwd wat voor informatie we de komende dagen zullen krijgen over hoe de verschillende bedrijven dit op gaan lossen.
Ik verbaas me erover dat de CPU een waarde kan lezen van een memory page dat gemarkeerd is als niet user-accessible (i.e. kernel space). In het paper gebruiken ze het volgende voorbeeld:

1 ; rcx = kernel address
2 ; rbx = probe array
3 retry:
4 mov al, byte [rcx]
5 shl rax, 0xc
6 jz retry
7 mov rbx, qword [rbx + rax]

Instructie 7 is duidelijk afhankelijk van de kernel-space waarde ([rcx]) opgehaald in instructie 4. Hoe kun je instructie 7 speculatief uitvoeren zonder eerst te wachten op het resultaat van instructie 4? Ik had verwacht dat er tijdens het ophalen van [rcx] een SEGFAULT zou optreden waardoor de waarde niet eens de cpu zou bereiken - en dus instructie 7 nooit uitgevoerd kan worden.
Ik verbaas me erover dat de CPU een waarde kan lezen van een memory page dat gemarkeerd is als niet user-accessible (i.e. kernel space).

Instructie 7 is een store naar een geheugen-adres waar jij wel toegang tot hebt, Deze instructie wordt echter ook enkel speculatief uitgevoerd. Dus geen daadwerkelijk geheugen wordt geschreven. En er is ook geen SEGFAULT, want het is geheugen dat jij mag schrijven.

Dit koste mij ook wat hoofdbreken, maar de truc als volgt:

1) Zorgen dat je een speculatieve load krijgt van een waarde die je wilt lezen. Dit kan op verschillende manieren en is in feite wat de hele Spectre en Meltdown inhoudt, Dit is het moeilijke en nieuwe deel.

De rest is oud spul dat al in andere aanvallen gedaan was en daarom niet overal even goed uitgelegd:

2) Vertaal die waarde naar een offset-getal. Dat is bijvoorbeeld een vermeningvuldiging. Dit gebeurt ook speculatief.

3) Schrijf een willekeurige waarde in een stuk geheugen dat jouw programma toegang heeft, maar dan op de offset die je in stap 2 berekent hebt. Dit is speculatief dus er wordt geheel niets geschreven.

Maar, ondanks dat er niets daadwerkelijk geschreven is naar het geheugen, is er wel naar het cache geschreven. Door nu stapje voor stapje jouw stuk geheugen te lezen en te timen, zul je zien dat één adres veel sneller laadt dan de rest. En dat is het adres op die offset, want ondanks dat de CPU alles speculatief deed, heeft het wel dit geheugen adres in de cache gezet. Je weet nu de offset en de oorspronkelijke waarde.
@Armin Moet je juist niet kijken naar cache rijen die _langzamer_ laden?

Want het speculatief laden van het multi associatieve cache laadt immers kernalgeheugen waar je niet bij kunt. Elke cacheline wordt door meerdere fysieke geheugenrijen gebruikt (aliassen). Er is dus altijd een userspace alias voor een kernal space geheugen gebiedje.

Lijkt me dat je dus eerst de cache moet vullen met aliassen uit userspace memory, vervolgens de probe draaien, en dan kijken welke userspace rijen overschreven zijn door kernalspace. Dit zijn de rijen met stale kernaldata en dus ververst moeten met userdata als je aan het meten bent duren ze dus langer.
Want het speculatief laden van het multi associatieve cache laadt immers kernalgeheugen waar je niet bij kunt. Elke cacheline wordt door meerdere fysieke geheugenrijen gebruikt (aliassen). Er is dus altijd een userspace alias voor een kernal space geheugen gebiedje.

Lijkt me dat je dus eerst de cache moet vullen met aliassen uit userspace memory, vervolgens de probe draaien, en dan kijken welke userspace rijen overschreven zijn door kernalspace. Dit zijn de rijen met stale kernaldata en dus ververst moeten met userdata als je aan het meten bent duren ze dus langer.
Wat je hier beschrijft is het geval voor de Spectre aanval, maar niet voor Meltdown. Dat is ook een bijkomende reden die mij doet vermoeden dat Meltdown heel veel makkelijker uit te voeren is. Voor Spectre moet je inderdaad cache effecten meten die in een andere address space plaatsvinden, terwijl die van Meltdown in je eigen address space effecten oplevert en je dus veel nauwkeuriger de staat van je cache daarvoor kan prepareren.

De truc lijkt me dat je bij Spectre een toegang moet forceren naar een gelimiteerde hoeveelheid cache sets, anders zit je al heel snel met veels te veel ruis. Alle ways in deze cache sets zal je dan moeten vullen met data van je aanval, en na het uitvoeren van de aanval zal je deze allemaal moeten uitlezen. In dit geval zal (met een beetje geluk) slechts een way in deze sets vervangen zijn door andere data, en zal deze langzamer zijn om te laden. Dit geeft dan informatie weg over de waarde die je probeert te achterhalen.
Bijna goed. Het belangrijke wat je mist is dat Instructie 7 een *LOAD* operatie moet zijn in plaats van een store. Een store zal namelijk niet speculatief geperformed worden, omdat je daarmee de memory state zou veranderen. Een store wordt pas geperformed, en dus zichtbaar in geheugen/caches, als de instructie werkelijk commit, dus wanneer hij niet langer speculatief is en je zeker weet dat deze uitgevoerd kan worden.

Dat is niet het geval van een load. Door te controleren in welke adres range deze load zal plaatsvinden, kan je zorgen dat geen van deze adressen in de cache staat. Na het uitvoeren van dit speculatieve deel zal een van hun nu *wel* in de cache staan. Door deze elementen een voor een uit te lezen en te zien welke je sneller leest, kan je nu achterhalen welke door de speculatieve load heeft plaatsgevonden. Deze zal dus *sneller* laden dan de anderen, in tegenstelling tot wat @alfredjodocus hier onder beschreef, maar let wel op dat dit specifiek is voor de Meltdown attack.
Je hebt gelijk, het moet in deze exploits een load zijn van een eigen gecontroleerde array, om de betreffende cache line te laden.

Het is echter niet zo dat een store niet speculatief uitgevoerd kan worden. Meeste moderne procerssoren hebben namelijk een store buffer, en kunnen dus ook geheugen schrijf acties speculatief uitvoeren. Maar dat maakt in dit geval niet uit, want het heeft inderdaad geen cache effect.
Het is de grap dat je zeker weet dat 7 niet uitgevoerd wordt, dus er zal ook nooit een segfault optreden, de processor weet dat echter niet en doet wel het caching voorwerk; want de intel processor gaat pas bij het retiren van de instructie checken of het mag of niet (maar doordat de processor misgokt met het speculatief executeren komt het zo ver niet).

De cachelines zijn echter wel geladen en dan is het spel op de wagen, want welke cachelines precies geladen zijn hangt af van de waarde in de kernal adres locatie. En dat kun je vervolgens gaan tijdmeten door de cachetabel uit te lezen ("pingen"), en na die meting heb je het resultaat.

[Reactie gewijzigd door alfredjodocus op 4 januari 2018 18:40]

Instructie 7 is duidelijk afhankelijk van de kernel-space waarde (~[rcx]) opgehaald in instructie 4. Hoe kun je instructie 7 speculatief uitvoeren zonder eerst te wachten op het resultaat van instructie 4? Ik had verwacht dat er tijdens het ophalen van ~[rcx] een SEGFAULT zou optreden waardoor de waarde niet eens de cpu zou bereiken - en dus instructie 7 nooit uitgevoerd kan worden.
Dat heeft te maken met de tijd die er kan zitten tussen dat een instructie executeerd (performed) en retired (commit) in een lange out-of-order pipeline. Pas bij commit wordt de exceptie gedetecteerd en gegooid, en zal je operating system een signaal krijgen en een SEGFAULT genereren. De speculatieve waarde is dus al even aanwezig na de executie, dus de afhankelijke instructie kan ook executeren en zo een side effect zichtbaar maken. Om commit van de faulting instructie te vertragen zou je ervoor enkele "dure" instructies kunnen doen, aangezien commit over het algemeen in-order gebeurt. Dit zodat alle voorgaande instructie gegarandeerd klaar zijn en hun veranderingen in de architecturele staat zichtbaar zijn. Dit is een vereiste om precise-exceptions te hebben, zodat je na een exception handler weer terug kan naar de originele staat van je programma.
Maakt mijn Commodore C16 ook gebruik van speculatieve executie en indien ja, hoe update ik een patch?
Ik ga er voorlopig even van uit dat patchen voor jou niet nodig is; de C16 is gebouwd met een 7501 MOS. Dit is een customized versie van de MOS 6510.
Aangezien deze nog geen gebruik maakt van de beschreven technieken heb jij gelukkig geen last van mogelijke datadiefstal.
Ik zou wel zorgen voor een goed slot op je doos met cassettebandjes, euh, sorry, datatapes.

Zie je wel: ouder is echt niet altijd slechter.
De 6502 kent geen protective modus.
-Je kunt niet meerdere processen draaien.
-Al het geheugen is beschikbaar voor alle "processen. "

Ik denk dat de oplossing is: ieder proces zijn eigen computer, met een airgap ertussen. he.. nou is het me opeens duidelijk, intel wil ook gewoon meer cpu dozen verkopen. Niks VM's die kunnen lekken, elke machine gewoon op zijn eigen ijzer.
Ben ik ineens weer extra blij met mijn Atari's :) En daar kan ik zelfs het internet mee op...
Neen, de C16 ken geen speculatieve executie. Deze werkt volgens een klassieke fetch-decode-execute-write cycle waarbij er telkens maar 1 instructie 'in flight' is.
Dus wil je een nieuwe pc/laptop kopen...moet je wachten?
Dat wordt dan al snel 1-2 jaar wachten. De kern van een CPU core aanpassen kan alleen relatief vroeg in het ontwerp. De diverse predictors zijn dan ook nog eens een relatief groot en complex onderdeel van de CPU core dat bovendien zeer grote impact kan hebben op de performance van de uiteindelijke processor wanneer het beter of slechter werkt.

De op deze lekken gerichte patches zullen proberen alles behalve beveiligingsgevoelige operaties gewoon lekker door te laten tuffen en het lijkt er sterk op dat bijvoorbeeld gaming performance niet te lijden zal hebben onder de patches. Echter ga je de CPU zelf aanpassen dan beïnvloed je haast alles dat uitgevoerd wordt en dus mogelijk ook gaming (scores).

Naast de functionele tests die moeten blijven slagen zit je ook met performance testen wat enorm lastig is door de hoeveelheid hardware die je moet simuleren in combinatie met de gigantische combinatorische mogelijkheden van instructies die door zo'n predictor heen gaan. Respect voor de ontwikkelteams die met deze uitdagingen bezig zijn :Y)

[Reactie gewijzigd door OruBLMsFrl op 4 januari 2018 21:29]

Komt nog bovenop dat als we de CPU architectuur aan gaan passen de bovenliggende operating systemen ook weer van de nodige aanpassingen en vernieuwingen moeten worden voorzien! |:(
Mogelijk kan er ook iets gebeuren op software niveau.
Er zijn programmeer methoden paradigm waar branches pointer zo veel mogelijk gemeden kan worden en goed gebruik wordt gemaakt van de prefetcher.
Data oriented programming.
Waarbij je excistance based de check for null kan mijden door goed gebruik van domein kennis.

In DirecX en Opengl worden drawcall gebundeld omdat syscall expensive zijn.
Vereist uiteraad voorhand syscall te matchen vooraf dat die geldig zijn.
Geen idee of dat met VM software ook mogelijk is het bundelen van kernel acces.

Dus ik denk dat naast de nood van architectuur overhaul ook de software geoptimaliseerd moet worden om hardware optimalisatie verval op te vangen.
Als een leek denk ik dan dat dit kan dus misbruikt worden om bijvoorbeeld iPhones die gelockt zijn te kunnen unlocken.. :) of gaat dit net een stap te ver?
Begin er maar aan als hacker. Compleet wezenloos door het geheugen zitten scrollen met een hex-editor, op zoek naar iets dat mogelijk een of ander paswoord zou kunnen zijn of een pointer naar een geheim document op iemands harde schijf. Als ze klaar zijn met scrollen door de tweede geheugenpagina, is de eerste alweer helemaal met wat anders gevuld. Pfff, volgens mij verkiezen zelfs hackers toch wel wat trefzekerder methodes om hun slag te slaan.
In de kernel staat ook de mapping van waar alle programma's draaien (aka taskmanager). Je kunt dus het adres van een proces opvragen en als er een static buffer wordt gebruikt kun je simpelweg de offset van die buffer optellen bij het adres en je weet precies waar je moet scannen. Bij "gewone" exploits gaan de makers ook niet random maar wat proberen te vinden.

deze is leuk: https://twitter.com/misc0110/status/948706387491786752
Om even uit te breiden op @Belgar's reactie; dit soort aanvallen zouden waarschijnlijk in incrementele stappen verlopen, die je grotendeels, al dan niet geheel, kan automatiseren. Ik kan me een Meltdown aanval voorstellen op je Firefox passwords (om even als voorbeeld te nemen) die ongeveer zo zou verlopen;

1) Eerst wordt met een aanval de KASLR verslagen; zodat je weet op welke kernel adressen bepaalde delen van de kernel gemapped zitten
2) Daarna ga je, zoals Belgar suggereerde, op zoek naar een Firefox proces in de proces tabel. Omdat je nu de plaatsing van de kernel weet, weet je op welk adres je daarnaar moet zoeken.
3) Door de informatie in de proces tabel weet je waar het geheugen van Firefox gemapped is. (heb je ook geen last meer van user space ASLR)
4) Door bepaalde informatie uit te lezen uit het Firefox proces geheugen kan je afleiden welke versie/build van Firefox dit is
5) Door zelf die versie/build geinspecteerd te hebben weet je op welke adressen de password manager data staat
6) Je leest de adressen met password informatie uit.

Dingen als geheugen mappings en symbol tables zijn je grote hulp bij het vinden van dit soort informatie. Of eerst op je eigen systeem kijken naar hoe een bepaalde binary draait door er een debugger aan te hangen. De mogelijkheden zijn eindeloos ;)

Voor de 2 variant Spectre aanval moet je wel bepaalde patronen vinden in binaries (de "gadgets"), dat zou je inderdaad kunnen doen door door hex dumps te scrollen zoals je schetste, maar een script of programma schrijven om automatisch naar bepaalde patronen te zoeken is natuurlijk zo gedaan. Zo kan je zonder problemen heel snel dergelijke dingen vinden in hele grote hoeveelheden data.

[Reactie gewijzigd door Squee op 5 januari 2018 11:31]

deze Amsterdamse VU student als eerste proof of concept gevonden:
https://twitter.com/brain...48561799875502080/photo/1
Kun je toelichten waar ik naar kijk?
Wat ik in de screenshot zie is dat hij met een tool (speculative_table_lookup.c, wat ik precies nog nergens teruggevonden heb) waarschijnlijk oa. het adres (of de offset vanaf een adres) 3a50 heeft gevonden voor de syscall sys_read (en alle andere syscall addressen in de sys_call_table). Wat die 72 erachter is weet ik niet zonder de source van zijn tool bij de hand te hebben. In ieder geval niet de syscall nummer voor sys_read want die is 0 op x86. Die voor 72 is fcntl.

Edit: aha hij legt het zelf uit wat de tweede column is:
second column is rdtsc_after-rdtsc_before (and yes, I ran it several times :-P) if the cache line is not present in the right cache, the signal gets very noisy (hits on every first cacheline into each page)

[Reactie gewijzigd door freaxje op 4 januari 2018 17:52]

CPU's die vatbaar zijn voor Spectre:
-AMD
-Intel
-ARMA
-IBM PowerPC
-IBM Z-series
-SPARC
-Qualcomm
-VIA
Bron = reddit.com

En heb van VIA CPU's inmiddels ook kunnen verifiëren of deze er ook last van gaan ondervinden, en ja dat gaat het geval zijn.
Al viel dit ook wel te verwachten natuurlijk, aangezien VIA CPU's van dezelfde micro processor architectuur gebruik maken als zo'n beetje alle andere bovengenoemde merken, al zij het dat ieder merk dit op zijn eigen manier in een chip implementeert, maar dit laatstgenoemde maakt de werking ervan dus niet veel anders.

Ik heb voor de liefhebbers alle info die ik vandaag heb kunnen vinden over Meltdown & Spectre nog even netjes op een rijtje kunnen zetten inmiddels:
klik = Intel Investor Call Regardingg Security Reearch Findings
klik = Goolge Project Zero: Reading privileged memory with a side-channel (vandaag nieuw geplaatst)
Meltdown & Spectre leesvoer (voor de mensen die echt het fijne er vanaf willen komen te weten, waaronder ikzelf)
En de twee desbetreffende links naar Wiki die hier over gaan er ook nog even bij, gewoon omdat het kan:
- Meltdown
- Spectre

Edit: Typo

[Reactie gewijzigd door SSDtje op 4 januari 2018 19:56]

How to Check and Update Windows Systems for the Meltdown and Spectre CPU Flaws
https://www.bleepingcompu...wn-and-spectre-cpu-flaws/

En dan even naar beneden scrollen totdat je bij How can you check the status of the patches? bent.
Dank voor de link. Ik had inmiddels ook alle stappen hier en daar kunnen vinden. Echter is het mij onduidelijk wat nu precies die firmware update inhoud. Is dat nu een update die Intel moet uitgeven voor hun chipsets of via de fabrikant van het moederbord (bv ASUS)? Of is het een BIOS update?

De website van Intel verwijst je ook weer door (net zoals MS doet) naar "de manufacturer". Ook op de download pagina's staan geen firmware updates. Zoals ik het begrijp moet de firmware (chipset of bios update?) dus komen van de fabrikant van het moederbord?
Details hoe PTI werkt (Linux). Gaat bijv uitvoerig in op de overhead. Zo te lezen zitten er zelfs bugs in (zie debugging).

Na de patch staat KPTI standaard aan, als je boot met pti=off in GRUB staat het uit (bron.

Hoe je de performance impact ("overhead") test, weet ik niet. Het is belangrijk dat mensen die data delen, ook delen hoe ze precies aan die data komen zodat het reproduceerbaar is.

EDIT: RedHat heeft zojuist relevante info gedeeld in hun KB over de performance impact:
[...]

In order to provide more detail, Red Hat’s performance team has categorized the performance results for Red Hat Enterprise Linux 7, (with similar behavior on Red Hat Enterprise Linux 6 and Red Hat Enterprise Linux 5), on a wide variety of benchmarks based on performance impact:

Measureable: 8-19% - Highly cached random memory, with buffered I/O, OLTP database workloads, and benchmarks with high kernel-to-user space transitions are impacted between 8-19%. Examples include OLTP Workloads (tpc), sysbench, pgbench, netperf (< 256 byte), and fio (random I/O to NvME).

Modest: 3-7% - Database analytics, Decision Support System (DSS), and Java VMs are impacted less than the “Measurable” category. These applications may have significant sequential disk or network traffic, but kernel/device drivers are able to aggregate requests to moderate level of kernel-to-user transitions. Examples include SPECjbb2005, Queries/Hour and overall analytic timing (sec).

Small: 2-5% - HPC (High Performance Computing) CPU-intensive workloads are affected the least with only 2-5% performance impact because jobs run mostly in user space and are scheduled using cpu-pinning or numa-control. Examples include Linpack NxN on x86 and SPECcpu2006.

Minimal: Linux accelerator technologies that generally bypass the kernel in favor of user direct access are the least affected, with less than 2% overhead measured. Examples tested include DPDK (VsPERF at 64 byte) and OpenOnload (STAC-N). Userspace accesses to VDSO like get-time-of-day are not impacted. We expect similar minimal impact for other offloads.

NOTE: Because microbenchmarks like netperf/uperf, iozone, and fio are designed to stress a specific hardware component or operation, their results are not generally representative of customer workload. Some microbenchmarks have shown a larger performance impact, related to the specific area they stress.

[...]

[Reactie gewijzigd door Jerie op 5 januari 2018 00:41]

Kan Tweakers een kort overzicht plaatsen van wat te doen in deze situatie en links geven naar de patches over een aantal dagen?. Zo te zien werken sommige ondernemingen nog aan de patches en hebben al een paar gepubliceerd. Er zijn vooral tegenstrijdige berichten over prestatievermindering, want HardwareInfo geeft aan het niet zo ernstig is na de patch: https://nl.hardware.info/...ch-de-prestaties-van-cpus
Voor de mensen die het helemaal boven de pet gaat is wellicht dit artikel van Bert Hubert (van PowerDNS) verhelderend.
Wat een commotie zeg - maar wat is nu het gevolg voor de gewone thuisgebruiker? Zowieso moet de software toegang tot je computer hebben. Dus je hebt het al geinstalleerd. Komt dus binnen net zoals een virus of trojan. En daar heb je al allerlei maatregelen voor zoals virus- en malware scanners. De toegang via websites b.v. javascript lijkt al snel afgesloten te kunnen worden via patches in de browsers. Het is zowieso aan te raden om adblockers en tracker blockers te gebruiken.

En als je dan als trojan al toegang hebt lijkt het helemaal niet zo eenvoudig om enige zinnige informatie uit de ruwe cache data te halen. Want wat betekenen die getallen dan? En als je dan zinnige informatie hebt wat doe je daar dan mee, een verbinding maken met een dubieuze site is zo gefixed. Het lijkt me nog niet zo makkelijk om hier een goede werkende exploit mee te maken zonder dat iemand (een anti-malware scanner) het merkt. Het is allemaal veel (maat)werk. Ik denk daarom dat de gemiddelde thuisgebruiker niet de doelgroep zal zijn van deze eploit. Iemand een andere mening?

Dit artikel op de BBC site licht dit verder toe:

How would a hacker target my machine?

An attacker would have to be able to put some code on to a user's computer in order to try to exploit either Meltdown or Spectre.

This could be done in a variety of ways, but one - running such code in a web browser - is already being closed off by companies such as Google and Mozilla.

Users can also, for example, use Chrome's "site isolation" feature to further protect themselves.

Some cyber-security experts have recommended blocking ads, browser scripts and page trackers as well.

Even if an attacker did get access, they would get only "snippets" of data from the processor that could eventually be pieced together to reveal passwords or encryption keys, says cyber-security expert Alan Woodward, at the University of Surrey.

That means the incentive to use Meltdown or Spectre will at first probably be limited to those prepared to plan and carry out more complex attacks, rather than everyday cyber-criminals.
Wat je schrijft is wat er vandaag geldt voor een computer thuis. Echter waar staat steeds vaker de data? Ergens in de cloud in een gedeelde virtuele omgeving. Als je dan vanuit de ene virtuele machine de andere kunt uitlezen dan is jouw data ook niet meer zo veilig. Erg leuk voor web based crypto wallets bijvoorbeeld. Met de juiste paar honderd bytes heb je iemand anders zijn wallet in handen. Of misschien wel een private key voor een certificaat van een website of breder inzetbaar account van een test VM ergens in een betaalbaar hoekje van een cloud.

Virus- en malwaredetectie is ook stukken lastiger dan normaal, want deze aanvallen lijken gewoon op legitieme code. Gewoon een app in userspace die soms wat data doorstuurt naar een web URL, zijnde jouw gegevens en wachtwoorden wanneer die uiteindelijk een keer buitgemaakt worden. Voor een scanner is daar van buitenaf weinig verdachts aan. Zit misschien straks wel verborgen in de volgende versie van OpenCandy die je bij de Incredimail icoontjes krijgt. Allemaal userspace, normaal enkel vervelend en niet dodelijk voor een PC, maar nu opeens wel heel gevaarlijk. De normale computergebruiker moet dus nóg meer op de hoede zijn. Wat een fijn en gemakkelijk apparaat toch zo'n PC ;)

Grootste probleem is nog dat er nu pas echt naar gekeken gaat worden door een breed publiek. Wie weet wat hier de komende periode nog meer uit naar voren gaat komen. Dat er nog allerlei nieuwe narigheid gaat volgen die via Javascript te exploiten valt is bepaald niet uitgesloten en wat die (browser) patches mogelijk nog aan performance kosten is ook nog niet bekend. Zie dit vooral als de eerste klap, de wedstrijd is eigenlijk pas net begonnen...
Goede aanvulling. Maar wel met veel speculatie.

Met de juiste paar honderd bytes heb je iemand anders zijn wallet in handen.
En zoek die juiste paar honderd bytes maar eens op die servers met software die je niet eens kent. Is een super specifieke en dure aanval.

deze aanvallen lijken gewoon op legitieme code
Elke nieuwe virus / ransom code lijkt in eerste instantie op legitieme code. Er zijn altijd mensen die dat gewoon niet zien en gebruiken. Of op een link klikken. Of een attachment openen en uitvoeren.

Zit misschien straks wel verborgen in de volgende versie van OpenCandy die je bij de Incredimail icoontjes krijgt. Ja dus? Daar kan nu ook al vanalles inzitten. OpenCandy is een draak van een applicatie die nu al heel veel van de gebruiker verzamelt en doorstuurt. Misschien stuurt het nu al wachtwoorden door weet jij veel?

Grootste probleem is nog dat er nu pas echt naar gekeken gaat worden door een breed publiek.
Ja dat is waar het is nog nieuw en het geeft nieuwe mogelijkeheden om aanvallen te ontwikkelen. Maar wat we wel weten is dat je zelf code moet uitvoeren op je systeem. Dat is mijn punt. Dat is te voorkomen. En dat het ontwikkelen van een echte aanval via deze weg (het uitlezen van cache data van andere processen en daar chocola van maken) veel moeilijker lijkt dan de vele mogelijkheden die er nu al zijn voor trojans en virussen.
kwaadwillende apps op google play bijvoorbeeld?
Precies, je hebt bijvoorbeeld nog steeds kwaadwillende apps nodig. Zie ook mijn reactie op @citegrene hierboven.

Dat is mijn punt, je moet nog steeds malware software binnenhalen om deze hack te gebruiken en het lijkt me veel ingewikkelder en moelijker om te maken dan een willekeurig ransom virus of een keylogger die stiekum je wachtwoorden uitleest en opstuurt naar een hacker.
kwestie van een malifide whatsapp klone op play zetten. zodoende heeft ook iemand miljoenen aan reclame inkonsten binnengehengeld. easy
wat ontzettend naief, ransom ware komt zeker ook nooit voor. Iets uitvoeren wat via de mail binnen komt kan zomaar
Dat is precies wat ik bedoel - het is te vergelijken met ransom ware of andere malware. Iets moet eerst via de mail of via een andere weg binnenkomen en je moet het uitvoeren op je PC voordat er iets aan de hand is. Het is niet zo dat alle PC's opeens nu open staan voor de wereld en iedereen bij je binnen kan komen.

Of is dat niet wat jij bedoelde toen je mij naief noemde?
Het proof of concept is in javascript een besmette website bezoeken is dus al genoeg.
Naief omdat je denkt dat het wel mee valt en denk je niet dat het in combinatie met een andere exploit de wereld in geslingerd kan worden. Als je full-access toegang combineerd met een exploit die niet full-access heeft maar wel voor distrubutie kan zorgen dan hang je. Aangezien updaten nog steeds niet bij iedereen de regel is, is dit ook zeer gevaarlijk voor de normale user.

[Reactie gewijzigd door citegrene op 5 januari 2018 12:33]

Ik denk helemaal niet dat het mee valt, ik probeer op internet objectief de menigen van experts te verzamelen om in te schatten hoe erg het nu eigenlijk is. Mij naïef noemen is flauw. Kom met feiten. Mijn inschatting is nu op basis daarvan vooralsnog: voor de thuisgebruiker niet erger dan andere malware.

Uit het artikel samengevat:
  • Het risico van Spectre voor gewone gebruikers is volgens Bos moeilijk in te schatten, omdat de aanval moeilijk uit te voeren is.
  • Meltdown is makkelijker te gebruiken, maar daarvan bestaat er weer geen implementatie in Javascript.
  • Vooropstaat dat Meltdown patchbaar lijkt te zijn, terwijl dit voor Spectre moeilijker is.
En dan nog steeds heb je user access nodig tot de PC.
Dus als ik het goed begrijp als ik de laatste Windows updates doe zit ik goed tegen meltdown, maar spectre niet.

Of moet ik speciale patches bij Intel van hun website plukken? Zou fijn zijn als dit in het artikel ook onder een kopje staat.
Nee je zit niet goed tegen `meltdown`, het grootste probleem overigens.

'Daarnaast worden er wel veel patches voorgesteld, maar lossen de huidige patches het echte probleem niet op. Ze houden dan enkele varianten van de aanval tegen, maar het probleem blijft. Vooral de Spectre kwetsbaarheid blijft problematisch", aldus Bos.'

Met een Intel processor blijf je een kwetsbaarheid hebben helaas.

[Reactie gewijzigd door Enchantress op 4 januari 2018 19:07]

Als ik het artikel lees, lees ik eigenlijk het tegen overgestelde, het Intel only Meltdown lijkt relatief simpel te patchen, terwijl juist spectre, waar iedere vendor last van heeft lastiger te patchen lijkt, zie o.a. je eigen quote en bijv. deze
Vooropstaat dat Meltdown patchbaar lijkt te zijn, terwijl dit voor Spectre moeilijker is
Maar Meltdown is zo te zien wel de ergste van de drie.

Spectre (Intel/AMD/ARM) is "alleen maar" userspace-naar-userspace, dus het ene programma naar het andere.
Meltdown (alléén intel) stelt userspace in staat om op OS/kernel-geheugen te bespioneren, dat is een privilege-escalation van de allerbovenste plank. En zoals hierboven al staat ‘het houd niet alles tegen, dus het probleem blijft’ en daarbij kan het voor server toepassingen de prestaties 5 tot ~40% verlagen na de ‘update’, daarbij moet wel gezegd worden dat die ~40% wel om zeer speciafieke workloads gaat.
Voor de ‘gewone consument’ lijkt er qua prestaties weinig te veranderen, maar het probleem is dus niet weg omdat dit niet met een update op te lossen is. Het probleem is in mijn ogen ook niet de prestaties maar het lek in de hardware.

En overigens, AMD kan vatbaar zijn voor 1 van de 3 varianten van spectre, 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. En voor spectre geldt dat het zeer lastig is om te ‘hacken’.

je AMD systeem is in dit geval dus gewoon veilig, je intel systeem niet/stuk minder.

En volgens mij betreft het sowieso niet de AMD ZEN (Ryzen/TR/Epyc/RR) achitechtuur? Zoals ik begrepen heb.
Ik weet wel dat de machine waar ik nu achter zit, mijn laatste Intel build zal zijn.

Premium prijzen voor matig ontworpen CPU's. Nee, dat valt niet goed bij mij als consument. Laat staan bij de datacenter boeren.
en dus stap je over naar...?
En bij ... staat dan iets waar Spectre dan weer iets mee kan. En is dat niet minstens zo kwalijk?
Je kan Intel gaan slaan met de stok die je momenteel aangeboden wordt, maar hoezo is het 'matig'?
Voorheen was AMD matig en was Intel de kip met het gouden ei.

Zoals de processor-wind waait, waait ons chipjasje... laten we niet in de fanboi-valkuil trappen ook nu toevallig Intel de sjaak is met Meltdown.
Wie weet toont een volgende projectnaam wel aan dat AMD weer op een andere manier superslecht is.
Ik verwacht dat er toch wel veel beweging gaat komen.
Intel kon de prijzen hoog en de vooruitgang jaren laag houden omdat AMD een erg matig aanbod had.
Met Ryzen is dat anders geworden.
Maar Intel is wel in beweging gekomen.
Ja, ik geef eerlijk toe dat zelfs voor de in dit draadje besproken bugs, Ryzen op mijn boodschappenlijstje staat. Maar toch zal ik Intel niet matig noemen.

Wel ga ik mijn aankoop uitstellen totdat ik zekerheid heb.
Waarschijnlijk zal het een volgend model Ryzen (of i7) worden, omdat ik van beide producenten verwacht dat ze zeer hard werken om de bug te fixen.
1 2 3 ... 6


Om te kunnen reageren moet je ingelogd zijn


Apple iPhone X Google Pixel 2 XL LG W7 Samsung Galaxy S9 Google Pixel 2 Far Cry 5 Microsoft Xbox One X Apple iPhone 8

© 1998 - 2018 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Hardware.Info de Persgroep Online Services B.V. Hosting door True

*