Intel ontkent berichten dat alleen zijn processors vatbaar zijn voor exploit

Intel heeft gereageerd op berichten dat zijn processors al jaren een ernstige bug bevatten. Volgens het bedrijf zijn chips van meer fabrikanten kwetsbaar voor exploits en is het plan om volgende week, samen met andere leveranciers, details te geven.

Intel claimt zich genoodzaakt te voelen nu vast naar buiten te treden met een verklaring, vanwege onjuiste berichten in de media. Het bedrijf ontkent niet dat er kwetsbaarheden zijn, maar deze zouden niet uniek zijn voor Intel-producten. "Gebaseerd op de analyse tot nu toe, zijn veel typen computingapparaten, met processors en besturingssystemen van veel verschillende leveranciers, vatbaar voor deze exploits."

De chipgigant zegt samen te werken met softwarebedrijven en onder andere AMD en ARM om de problemen industriebreed aan te pakken. Intel ontkent niet dat de oplossing een impact gaat hebben op de prestaties, maar deze zouden afhankelijk zijn van de werklast. "Voor de gemiddelde computergebruiker zijn deze niet significant en het zal in de loop der tijd verbeteren." Dat laat de optie open dat voor aanbieders van clouddiensten met bijvoorbeeld virtuele machines wel een ernstiger impact te verwachten is.

Intels verklaring is een reactie op claims van deze week dat zijn processors een bug hebben die toegang tot beschermd kernelgeheugen mogelijk maakt. De oplossing zou liggen in een page table isolation-patch, maar deze zou de prestaties met 5 tot 30 procent kunnen verslechteren, afhankelijk van de toepassing. AMD zei dat de aanval niet bij zijn processors mogelijk was en voorgestelde code om AMD-processors buiten de patch te houden is inmiddels gemerged, volgens beveiligingsdeskundige Alex Ionescu: "Dus ofwel riskeert AMD de beveiliging van miljoenen Linux-systemen, ofwel gebruikt Intel creatieve, maar accurate, bewoordingen." De verklaring zou accuraat zijn omdat AMD ook ARM-chips maakt en er inderdaad ARM64-code in de patch verwerkt wordt.

Intel geeft geen details over de kwetsbaarheid, maar waarschijnlijk heeft deze te maken met maatregelen om address space layout randomization weer veiliger te maken. Aslr moet voorkomen dat een aanvaller achter geheugenadressen kan komen en werkt door willekeurige locaties in het virtuele geheugen aan te wijzen waar programma's belangrijke componenten kwijt kunnen.

Een onderzoeksgroep softwarebeveiliging van de VU, ontdekte begin vorig jaar een kwetsbaarheid die het omzeilen van aslr mogelijk maakte en die werkte bij alle Intel-, AMD- en ARM-processors die ze testten. Ze ontwikkelden een aanval die uit te voeren is via Javascriptcode in de browser, bijvoorbeeld door gebruik te maken van een kwaadaardige website. Met behulp hiervan zou het mogelijk zijn aan de sandbox van Javascript te ontkomen en zo code uit te voeren op het systeem van een slachtoffer. Hier was toen nog een tweede bug voor nodig om van een exploit te kunnen spreken.

Reacties (160)

[Squee]

Zoals ik beloofd had bij het artikel vanmiddag, wilde ik nog wat uitgebreider posten na wat meer over dit alles gelezen te hebben. Onder ander de paper over KAISER is een zeer interessant stuk, dit legt behalve de nieuwe implementatie met wisselen van page tables ook uit wat voor soort aanvallen ze een oplossing voor zochten. De meeste waren het gebruik van slimme gedetailleerde timing metingen om te achterhalen op welke adressen delen van de kernel gemapped zitten, en zo om de Kernel Addres Space Layout Randomization (KASLR) heen te komen. Dit door page faults direct te timen, slim TSX toe te passen, of (gegokte) kernel adressen te prefetchen en daarna page faults te timen. KASLR is een mechanisme in moderne kernels die ook de adres-layout in kernel space per keer afwisselen, zodat het bij een exploit veel lastiger is om tot een privilege escalation te komen door middel van Return Oriented Programming bijvoorbeeld.

Maar goed, dan blijft er nog de vraag, waarom er zo'n "paniek" uit lijkt te zijn gebroken. KASLR is in feite een vorm van "security by obscurity", dus het maakt het alleen maar lastiger, maar niet onmogelijk om een exploit succesvol toe te passen. Ik heb daarom het vermoeden dat er meer aan de hand is. Onder andere ook vanwege de Post van AMD's Tom Lendacky die suggereert dat er bepaalde privilege issues zouden kunnen zijn met instructies die speculatief worden geexecuteerd. Dit is ook wat Anders Fogh probeerde te onderzoeken (niet te verwarren met Agner Fog). Fogh vroeg zich af of er een timing attack mogelijk zou zijn die informatie zou weggeven over de inhoud van bepaalde kernel geheugen adressen, maar het lukte hem niet om dat erg betrouwbaar er uit te krijgen.

* Het volgende is speculatie - een "educated guess", gebaseerd op ervaring *:
Ik heb eens zitten nadenken over wat Fogh probeerde te doen, en ik kan me voorstellen dat hij wel eens iets op het spoor zou kunnen zijn. Mocht het zo zijn dat een speculatieve "load" geheugen operatie in bepaalde Intel micro-architecturen inderdaad wel een waarde kan leveren aan opvolgende (ook speculatieve!) instructies, ondanks dat de huidige draaiende context daar geen toegang toe zou moeten hebben, dan heeft Intel wel een groot probleem. De opvolgende speculatieve instructie zou namelijk de waarde kunnen gebruiken om een specifiek geheugenadres te benaderen, en door de staat van je caches goed te prepareren zou je dan kunnen achterhalen door timing metingen welk adres benaderd werd, en zo dus (een deel van) de speculatieve waarde achterhalen. Dan wordt er kernel geheugen informatie "gelekt".

Het gekke is dat het strikt genomen geen functionele bug zou zijn (en daarom dus ook nooit tijdens de verificatie van het processor ontwerp opduikt). De waarden worden niet direct zichtbaar in het programma, aangezien een instructie die dat geheugen direct zou proberen te benaderen een exceptie zou gooien. Het is een timing side-effect, wat een side-channel attack oplevert. Die exceptie was ook een beetje waar Fogh de mist in ging naar mijn idee; hij neemt een exceptie op de illegale load access, en in zijn handler probeert hij dan te testen welk adres de opvolgende instructie probeerde uit te voeren. Het zou veel beter zijn om beide geheugen toegangen samen in een speculatief pad te zetten wat nooit retired/commit (laten we het daarom een wrong-path exploit noemen); dan krijgt je programma nooit een exception maar zou je nog wel dit effect moeten kunnen meten zonder de "vervuiling" van de handler in je meting. Dit zou je kunnen doen door ze achter een branch instructie te zetten en te zorgen dat je de branch predictor om de tuin leidt, en een branch mispredict forceert, en gecontroleerd, maar speculatief, die loads uitvoert. Dit kan je doen door een conditional branch te gebruiken die op een lang durende dependency moet wachten (gooi er een ketting aan DIVs tegen aan bijv), terwijl de instructies daarna onafhankelijk zijn en hun input waarden al hebben en dus al kunnen executeren. Ik heb nog geprobeerd om hier een proof-of-concept voor te schrijven, maar loop nog tegen mijn beperkte kennis van de Intel micro-architectuur aan om dit goed werkend te krijgen qua timing/meting.

Een andere kanttekening die ik zou willen plaatsen is of de KAISER aanpak van aparte page-tables wel werkt. Ik vraag me af of je namelijk niet in de problemen komt als je Hyper Threading aan hebt staan, en twee hardware contexts hebt die de DTLB delen. Stel je hebt een malafide programma draaien met twee software threads en je zorgt dat ze op de twee HT's van een enkele core draaien. Ze delen de address space, maar hebben een los CR3 register. De ene zou dan continue syscalls kunnen doen en zo kernel mappings in de DTLB brengen, terwijl de andere thread dan hits op deze entries probeert te forceren met de hierboven geschetste aanval. Mits de DTLB inderdaad compleet gedeeld is, zou dit best wel eens kunnen werken, zeker op de processors voor Haswell die geen PIDs hebben.

[ezakimak]

TL;DR
Maar m.b.t. tot je educated guess: dit is dus PRECIES wat de Meltdown attack is: er wordt speculatief een memory access gedaan met als index data die speculatief is gelezen vanuit kernel memory. En dat alles wordt speculatief zonder mankeren uitgevoerd door Intel CPU's. Het resultaat wordt later weggegooid, want pending exception, maar het cache side-effect kun je dus wel gebruiken voor een side-channel attack.

[Squee]

TL;DR
Maar m.b.t. tot je educated guess: dit is dus PRECIES wat de Meltdown attack is

Even ter verduidelijking; ik beschreef en plaatste deze "educated guess" voordat de Meltdown/Spectre details bekend gemaakt waren. Het is inderdaad precies de Meltdown attack die ik beschreef, al gebruikt Spectre ook dezelfde soort trucs om speculatief geexecuteerde instructies te beheersen.

[Jean-Paul.nl]

Oud nieuws. Bij de implementatie van de nxp als non exec Space voor instructions was dit Al bekend. Dus Al meer dan 12 jaar geleden.

[OMX2000]

Het zou best kunnen zijn dat het "oud nieuws" is. Maar ik verwacht wel een beter onderbouwde reactie op een zorgvuldig geschreven reactie.

[Jean-Paul.nl]

Nee die krijgt je (nog) niet. Waarom? dat ga je vanzelf lezen.

[Kain_niaK]

[Astennu]

Ik vraag me af of alle AMD cpu's dan veilig zijn of dat vooral Ryzen wel goed werkt?

Extra info die op HWI staat:

AMD niet vatbaar

AMD ondersteunt het speculeren over toekomstige instructies ook, maar voert wel een controle uit of het geheugen dat het wil benaderen wel benaderd mag worden. De chips van het bedrijf zijn daarom ook niet vatbaar voor deze bug. Hoewel ze niet vatbaar zijn, levert KPTI ook voor AMD-processors een lagere prestatie op als het overal geïmplementeerd wordt. Het is dus van belang dat de update alleen doorgevoerd wordt voor Intel-chips, zoals Tom Lendacky ook zegt in LKML. Hij publiceerde een stukje code om AMD-processors uit te sluiten van KPTI.

[Reactie gewijzigd door Astennu op 22 juli 2024 18:47]

[kidde]

Volgens mij wordt de 'aanval' hier beschreven.

Hieruit wordt vrij duidelijk dat - in ieder geval voor deze specifieke aanval - Intel x86 en ARMv8 kwetsbaar zijn:

" Recent Intel CPUs have five instructions for software prefetching:
prefetcht0, prefetcht1, prefetch2, prefetch-nta , and prefetchw . These instructions are treated like hints to tell the processor that a specific memory location is likely to be accessed soon. The different instructions allow hinting future repeated accesses to the same location or write accesses. Similarly, recent ARMv8-A CPUs supply the prefetch instruction PRFM"

AMD wordt in dit hele artikel niet (!) genoemd.

De lijst van getroffen AMD processoren met ARMv8-A (wat niet op deze lijst staat is naar ik begrijp dus niet vatbaar voor deze kwetsbaarheid):
-Opteron 1120
-Opteron 1150
-Opteron 1170

Er staan er 3 op, AMD werkt kennelijk samen met ARM aan de KPTI-oplossing voor de kwetsbaarheid (netjes natuurlijk!) dus schrijft Intel dat AMD ook problemen heeft.

---Update 00:26: AMD claimt idd niet vatbaar te zijn voor de drie verschillende aanvallen.
"AMD, citing a report from Alphabet Inc.’s GOOG, +1.64% GOOGL, +1.71% Google Project Zero, said in a statement that its chips are not affected by the exploit.

“To be clear, the security research team identified three variants targeting speculative execution,” AMD said. “The threat and the response to the three variants differ by microprocessor company, and AMD is not susceptible to all three variants. Due to differences in AMD’s architecture, we believe there is a near zero risk to AMD processors at this time.”

2 omdat ze een andere implementatie hebben dan Intel, 1 vanwege een update met weinig effect voor de gebruiker; zie deze matrix. Variant 1 kan voor zover ik begrijp met compiler-opties verholpen worden, in ieder geval voor ARM.

Zie voor de ARM Cortex A serie de ARM kwetsbaarheidsmatrix; hierin wordt m.i. bevestigd dat de Cortex A57 die in de hierboven genoemde Opterons zit kwetsbaar is.

De officiele aanklacht tegen Intel door Intel-aandeelhouders is al onderweg
* kidde was toch lekker short INTC en long AMD dus houdt de popcorn paraat!

---Ed - Nog wat info van Google Project Zero::

• Variant 1 (Spectre) kan wel data lezen op AMD, maar de 'proof of concept' is niet gemaakt om 'grenzen te overschrijden':
  " A PoC that demonstrates the basic principles behind variant 1 in userspace on the tested Intel Haswell Xeon CPU, the AMD FX CPU, the AMD PRO CPU and an ARM Cortex A57 [2]. This PoC only tests for the ability to read data inside mis-speculated execution within the same process, without crossing any privilege boundaries."
  Volgens mij is deze variant met de software-patch te verhelpen.
• Variant 2 (ook Spectre) werkt alleen op AMD als er een niet-standaard instelling gedaan is:
  If the kernel's BPF JIT is enabled (non-default configuration), it also works on the AMD PRO CPU

[Reactie gewijzigd door kidde op 22 juli 2024 18:47]

[Squee]

De Meltdown paper beschrijft overigens dat ze (nog) niet succesvol waren in het uitlezen van kernel geheugen op de ARM en AMD platformen die zij getest hebben, al zijn ze niet duidelijk welke ze getest hebben:

6.4 Limitations on ARM and AMD
We also tried to reproduce the Meltdown bug on several ARM and AMD CPUs. However, we did not manage to successfully leak kernel memory with the attack described in Section 5, neither on ARM nor on AMD. The reasons for this can be manifold. First of all, our implementation might simply be too slow and a more optimized version might succeed. For instance, a more shallow out-of-order execution pipeline could tip the race condition towards against the data leakage. Similarly, if the processor lacks certain features, e.g., no re-order buffer, our current implementation might not be able to leak data. However, for both ARM and AMD, the toy example as described in Section 3 works reliably, indicating
that out-of-order execution generally occurs and instructions past illegal memory accesses are also performed.

Dit is ook wel in lijn met wat ik eerder over AMD zei; ze laten wel speculatieve geheugenoperaties toe, maar doen daar waarschijnlijk wel de juiste privilege checks op voordat de data aan opvolgende instructies wordt overgedragen. Hun toy example in de paper had namelijk geen privilege violation in de speculative path (of "transient instructions") zoals ze dat in de paper noemen.

Edit: Inmiddels heeft ARM een officieele reactie gegeven. Voor geheugen speculatie zoals Meltdown (categorie 3) zou alleen de Cortex-A75 core kwetsbaar zijn.

[Reactie gewijzigd door Squee op 22 juli 2024 18:47]

[Archcry]

Je hebt volgens mij niet helemaal goed in het artikel gekeken. AMD PRO wordt in variant 2 niet genoemd, wel in POC 2. POC 2 gaat nogsteeds over variant 1. Er wordt met betrekking tot variant 2 in combinatie met AMD CPUs niets gezegd.

A PoC for variant 1 that, when running with normal user privileges under a modern Linux kernel with a distro-standard config, can perform arbitrary reads in a 4GiB range [3] in kernel virtual memory on the Intel Haswell Xeon CPU. If the kernel's BPF JIT is enabled (non-default configuration), it also works on the AMD PRO CPU. On the Intel Haswell Xeon CPU, kernel virtual memory can be read at a rate of around 2000 bytes per second after around 4 seconds of startup time. [4]

[CMD-Snake]

Ik vraag me af of alle AMD cpu's dan veilig zijn of dat vooral Ryzen wel goed werkt?

AMD is wel kwetsbaars volgens Google's Project Zero:

We have discovered that CPU data cache timing can be abused to efficiently leak information out of mis-speculated execution, leading to (at worst) arbitrary virtual memory read vulnerabilities across local security boundaries in various contexts.

Variants of this issue are known to affect many modern processors, including certain processors by Intel, AMD and ARM. For a few Intel and AMD CPU models, we have exploits that work against real software. We reported this issue to Intel, AMD and ARM on 2017-06-01 [1].

https://googleprojectzero...ged-memory-with-side.html

Google heeft in hun proof of concepts o.a. de bug vastgesteld bij AMD FX CPU's (Bulldozer/Piledriver), AMD Pro CPU's (Excavator) en bij Intel op Haswell-EP processoren. Zen wordt niet genoemd, maar Project Zero spreekt ook niet over de generaties die na Haswell-EP zijn gekomen. Maar uitgesloten worden ze ook niet.

In de PoC's heeft Google vanuit een VM via het geheugen van de host het geheugen van een andere VM die op die host draait uitgelezen. Zo te zien blijft de exploit voorlopig bij lezen wat je niet mag lezen. Er is nog geen informatie dat het ook mogelijk is om zaken zo te manipuleren.

Overigens is de patch van AMD niet door Linus Torvalds opgenomen in zijn Git:
https://www.phoronix.com/...x-Tip-Git-Disable-x86-PTI

AMD CPU's worden dus niet uitgesloten voor de patch aan de Linux kernel.

Edit: Amazon bevestigd ook dat AMD CPU's ook getroffen zijn
https://aws.amazon.com/se...y-bulletins/AWS-2018-013/

[Reactie gewijzigd door CMD-Snake op 22 juli 2024 18:47]

[Verwijderd]

https://spectreattack.com/

Jij hebt het nu over 'Spectre', welke industrie-breed een probleem lijkt te zijn, maar ook veel moeilijker uitbuitbaar. De topics van vandaag gingen echter over 'Meltdown', welke uitgezonderd ARM-chips, niet AMD treft, maar wel bijna alle chips van Intel.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 18:47]

[WhatsappHack]

“Pulled” betekent in dit geval niet “teruggetrokken” maar juist dat hij het wél heeft geïmplementeerd. Denk even aan git?

Zie: https://git.kernel.org/pu...6ac249a9ce&utm_source=anz

Het zit er dus wel degelijk in, volgens dat artikel van jou zei een developer dan ook: "Not necessarily a fix, but if AMD is so confident that they are not affected, then we should not burden users with the overhead."

[Enchantress]

Ik heb steeds meer erover gelezen en het is inderdaad wat MicbenSte al zei, het gaat over “meltdown” = Intel probleem en niet over “spectre”.

Je haalt twee zaken doorelkaar nu.

[supersnathan94]

De "fix' zit er gewoon in hoor:

Update: Linus Torvalds has now ended up pulling the latest PTI fixes that also include the change to disable page table isolation for now on all AMD CPUs. The commit is in mainline for Linux 4.15 along with a few basic fixes and ensuring PAGE_TABLE_ISOLATION is enabled by default.

hier is de wijziging die expliciet AMD uitsluit:

- /* Assume for now that ALL x86 CPUs are insecure */
- setup_force_cpu_bug(X86_BUG_CPU_INSECURE);
+ if (c->x86_vendor != X86_VENDOR_AMD)
+ setup_force_cpu_bug(X86_BUG_CPU_INSECURE);

De minnetjes geven aan dat de code verwijderd is en de plusjes geven aan wat er voor in de plaats is gekomen. Er is dus duidelijk een check bijgekomen die ervoor zorgt dat de beveiliging alleen aan wordt gezet als de maker van de CPU niet AMD is.

[PizzaMan79]

Intel's bericht suggereert zo sterk dat AMD chips ook betrokken zijn.

...working closely with many other technology companies, including AMD, ARM Holdings...

...many types of computing devices — with many different vendors’ processors and operating systems — are susceptible to these exploits.

Als AMD inderdaad niet betrokken is, is bovenstaande toch gewoon liegen? Het excuus "dat staat er niet letterlijk" kan alleen een jurist samen met een PR medewerker bedenken.

Voor mij is dit gedrag echt reden om mijn volgende cpu van AMD te kopen.

[Reactie gewijzigd door PizzaMan79 op 22 juli 2024 18:47]

[Terracotta]

AMD gebruikt ARM chips in sommige van zijn processoren, ARM chips zijn ook kwetsbaar, semantisch gezien heeft Intel gelijk. Het feit dat ze dit zo verwoorden is echter wel smerig omdat het zo de indruk geeft dat Ryzen (hun grootste directe concurrent) ook kwetsbaar is... Reden genoeg om geen Intel te kopen blijft bestaan, maar liegen is het niet.

[PizzaMan79]

Ik vind dat moedwillig een verkeerde suggestie wekken liegen is. We pikken veel te veel bewuste desinformatie van bedrijven als Intel. Alleen als je dat per ongeluk doet is het geen liegen.

[Reactie gewijzigd door PizzaMan79 op 22 juli 2024 18:47]

[Sugocy]

Je beschrijft imho bijna alle reclames

[PizzaMan79]

Ik denk eerlijk gezegd dat zelfs de reclame code commissie hierover zou vallen.

[Thekilldevilhil]

Reclames op TV (crèmes, alternatieve rommel en ook wasmiddel) doen precies dit. Zeggen "helpt bij" en "verbetert x" is zo vaag dat hoewel en het positief effect lijkt te suggereren het niet rechtstreeks een bewering doet. Grootte van het effect bijvoorbeeld, of de meetmethode, biologische relevantie van het effect. Het wordt nergens genoemd. Of uitspraken als "80% van de vrouwen/mannen zegt dat dit middel helpt tegen X".

Al deze uitspraken zijn niet eens gelogen, maar zijn strikt genomen niet waar.

Intel liegt helemaal nergens in zijn statement, maar ze zijn niet oprecht. Moreel even erg, maar wel iets wezenlijk anders. Wat mij betreft net zo erg, aangezien ze van alles lijken te suggereren. Maar dat ik deels ook hoe je het zelf invult. Wat de notie dat AMD ook vatbaar zou zijn komt is eigen interpretatie. Maar dat Intel niet een eerlijk bedrijf is mag niet echt nieuws heten. Dus waar hebben we het eigenlijk over...

[Sugocy]

Grijs gebied maar ik heb hier geen kaas van gegeten en het gaat mijn pet te boven. Wat ik er wel van begrijp, maakt voor mij Intel nog geen leugenaar.

Ze hebben ergens een punt, zij het een kleine. Ik zie dit als de Vanish Oxi reclames: gooi jodium bij water en laat zie hoe goed je oxidatie product werkt. 84% weet niet dat jodium een van de betere reducing agents is en redox reacties geeft, maar liegen ze nu als ze zeggen dat het product werkt?

Intel doet hier imho hetzelfde, kijk we zijn echt niet de enige met het probleem en we werken er allemaal hard aan. Nu lees ik uiteindelijk in de reacties dat ARM en enkele AMDs getroffen zijn, Windows en Apple er aan werken ofwel industriebreed. Enfin, ze liegen dus niet.

Daar gelaten, ik begrijp het hele timing adress location KITLR lookup table spock me go to warp gebeuren niet volledig. Zie ook niet hoe het verschil met AMD en Intel zo groot kan zijn, want ik weet niet 100% gedetailleerd de werking van beide en andere CPUs.

Edit: Tekst en Barney% toegevoegd

[Reactie gewijzigd door Sugocy op 22 juli 2024 18:47]

[WhatsappHack]

Suggesties wekken is afhankelijk van de kennis en intepretatie van de lezer, de rest is marketing en noemen we geen liegen; het zou nog eerder politiek bedrijven zijn.

[PizzaMan79]

Dat vind ik dus niet. Ik vind het gewoon liegen. De rest zijn smoesjes.

[WhatsappHack]

De waarheid polijsten zodat mensen er anders over kunnen denken is geen leugen. Een leugen is als je bewust iets zegt dat niet waar is; maar dat doet Intel niet. Wat ze zeggen is wel waar, ze vermelden er enkel niet bij dat de scope veel en veel kleiner is dan de concurrenten en of t over hetzelfde gaat - maar dat detail maakt de rest geen leugen.

Kijk dat je het abject vindt dat ze dit doen is een heel ander verhaal natuurlijk, en een beetje smerig is het inderdaad wel.

[ISaFeeliN]

Een beetje? Poeh hee ..

[PizzaMan79]

Ze zeggen iets waarvan ze bewust weten dat de boodschap zoals die bij de ontvanger aankomt niet waar is. Ik snap het verschil waar je op doelt, maar vind dat verschil niet relevant. Ze hadden net zo goed letterlijk kunnen zeggen wat ze nu heel sterk suggereren.

[CMD-Snake]

AMD gebruikt ARM chips in sommige van zijn processoren, ARM chips zijn ook kwetsbaar, semantisch gezien heeft Intel gelijk. Het feit dat ze dit zo verwoorden is echter wel smerig omdat het zo de indruk geeft dat Ryzen (hun grootste directe concurrent) ook kwetsbaar is...

Nee, AMD Opteron CPU's zijn ook kwetsbaar. Lees het blog van Project Zero. Met een AMD Opteron processor (Excavator) is het ook mogelijk om vanuit user privileges geheugendelen van de kernel uit te lezen.

[spookz0r]

Google beweert ook dat AMD cpu's er vatbaar voor zijn https://security.googlebl...bility-what-you-need.html

[mphilipp]

Jullie moeten toch eens leren lezen...

...working closely with many other technology companies, including AMD, ARM Holdings...

Hier staat niets anders dan dat Intel samenwerkt met (oa) AMD en ARM om erachter te komen hoe het precies zit. En dat is ook wat er gebeurt. Je kunt ervan maken wat je wilt, maar er staat echt niet dat AMD gevoelig is voor de exploit.

...many types of computing devices — with many different vendors’ processors and operating systems — are susceptible to these exploits.

Ook dit is waar. Het is niet alleen Intel. Dus Intel beweert of insinueert helemaal niets. En het is ook geen overdreven juridisch ingedekt taalgebruik. Het is gewoon duidelijke taal. Je moet gewoon lezen wat er staat en niet wat je denkt/wil dat er staat.

[Verwijderd]

De x86 (-64) processoren van AMD zijn veilig - dat is bevestigd niet alleen door AMD zelf, maar ook door tests van derden.

Enige vraag is hoe het met AMD-gemaakte ARM-chips zit - die kunnen wel de ontwerpfout hebben die alle Intel-chips hebben.

[Astennu]

Je kan die natuurlijk wel uitfilteren en de X86-64 AMD chips buiten de batch houden

[Flipwork]

Juist, de exploit kan ook AMD ARM-chips gebruikt worden, maar niet op AMD chips met x86 architectuur.

De fix die in de Linux code stond was alleen toepasbaar op processors met x86 architectuur, dus het lijkt me logisch dat als x86 processors van AMD niet vatbaar zijn voor de exploit, dat ze geen onnodig prestatieverlies willen introducteren voor hun processors.

De comment bij de originele fix was dan ook:

/* Assume for now that ALL x86 CPUs are insecure */

[SuperDre]

Maar dat druist dan toch in tegen wat die 'onderzoekers' beweren, die zeggen dat ook amd en arm vatbaar zijn hiervoor.

[Verwijderd]

Mijn commodore C16 heb ik niet op het www aangesloten.
Moet ik me toch zorgen gaan maken?

[Opperpanter2]

Inmiddels is het embargo opgeheven en zijn de meeste details bekend: https://googleprojectzero...ged-memory-with-side.html

[Squee]

Heel erg interessant. De Spectre aanval lijkt precies wat ik in mijn andere reactie hier beschreef, Variant 1 in het bovenstaande artikel. Ook heel erg grappig om te zien dat Werner Haas aan beide papers heeft meegewerkt, dat is een oud medewerker van Intel Labs Duitsland, die ik meerdere malen ontmoet heb flink wat jaren geleden toen we beide met de Intel SCC chip werkten.

[OMX2000]

Yeah yea, don't feed the trolls. Maar de reactie van @Squee voegt wel extra context toe, voor mij in ieder geval.

En als jij Bush, Clinton en Willem Alexander ontmoet hebt, en zo trollt dan ben je best wel "speciaal" ja.

[Verwijderd]

https://spectreattack.com/

Site die een samenvatting *lijkt* te geven (ben zelf geen chipontwerper, dus kan het bijna onmogelijk verifieren uitgezonderd secundaire bronnen). Als ik die site goed begrijp en de persverklaring van Intel, doet Intel alsof het reageert op 'Meltdown', terwijl het 'Spectre' addresseert - wat juist niet de grote ophef over was, maar 'Meltdown'.

[loekf2]

Dit artikel van Ars is ook goed:

https://arstechnica.com/g...unfixable-security-flaws/

Inmiddels heeft ARM ook z'n info openbaar:

https://developer.arm.com/support/security-update
https://developer.arm.com...0-8431-7e4ed42fb90b&la=en

En ja, de meest recente Cortex (bv. A-57) die in Qualcomm SoCs zit (en straks in bv. een Windows ARM laptopje) is ook gevoelig hiervoor.

Er dus twee soorten vulnerabilities waar moderne CPUs voor gevoelig zijn:

Meltdown: virtueel geheugen mapping en feit dat kernel en user mode data in dezelfde geheugen hierarchy gelijktijdig aanwezig zijn. Intel doet pas laat een check, omdat ze aggressief instructies en data laden om de CPU pipeline maar vol te houden. Geloof dat AMD ook een patent heeft, waardoor Intel iets andere moest verzinnen.

Spectre: dit heeft meer te maken waarop CPUs omgaan met branches en array bound checks. Ook dit kun je misbruiken voor aanvallen. Hiervoor is nog geen fix in zicht, hoewel ARM er speciale instructies voor schijnt te hebben (AMD en Intel ook) om bv. een reeks van instructies soort atomic te maken. CPU mag dus tijdens het uitvoeren van de instructies niet speculatief alvast meer code gaan laden.

[Reactie gewijzigd door loekf2 op 22 juli 2024 18:47]

[Verwijderd]

Ben benieuwd want de comments van het eerdere artikel werd gelinkt naar een quote van een hoge pief bij AMD die zei dat deze fout NIET in hun processoren mogelijk was.

edit:

bdbfz in 'nieuws: 'Patch voor ernstige Intel-bug verlaagt softwareprestaties ...

bijvoorbeeld. Als de linux kernel blijkbaar prima draait zonder de patch op AMD dan is deze statement alleen een damage control poging.

edit2: Intel CEO sells a LARGE part of his shares and keeps only what he is required to keep as CEO

https://www.fool.com/inve...-sold-a-lot-of-stock.aspx

Those two transactions left Krzanich with exactly 250,000 shares -- the bare minimum that he's required to hold as CEO.

What does this mean?
Perhaps Krzanich sold those 245,743 shares valued at nearly $11 million at the time of the transactions to pay for a new house or buy a rare piece of artwork.

However, I find those explanations tenuous at best, particularly in light of the big windfall that he received when he exercised and sold all those stock options.

Mhm alu hoedje ( check website naam ) of toch niet

edit3:

Reactie van AMD -> https://www.amd.com/en/corporate/speculative-execution

Variant One Bounds Check Bypass Resolved by software / OS updates to be made available by system vendors and manufacturers. Negligible performance impact expected.
Variant Two Branch Target Injection Differences in AMD architecture mean there is a near zero risk of exploitation of this variant. Vulnerability to Variant 2 has not been demonstrated on AMD processors to date.
Variant Three Rogue Data Cache Load Zero AMD vulnerability due to AMD architecture differences.

2/3 niet toepasbaar op AMD ( zover nu bekend ). En die eerste variant was toch al van oct. vorig jaar ( bounds check bypass )?

[Reactie gewijzigd door Verwijderd op 22 juli 2024 18:01]

[Loggedinasroot]

https://twitter.com/bryanlunduke/status/948430797266042880

Wat een if statement

[kidde]

Verwijzend naar het T.net artikel De zin en onzin van 'branded bugs' : Deze zou moeten krijgen als naam:

FUCKWIT

The fix is to separate the kernel's memory completely from user processes using what's called Kernel Page Table Isolation, or KPTI. At one point, Forcefully Unmap Complete Kernel With Interrupt Trampolines, aka FUCKWIT, was mulled by the Linux kernel team, giving you an idea of how annoying this has been for the developers.

https://www.theregister.c...02/intel_cpu_design_flaw/

Ed - ook voorgesteld, maar ook niet geworden; User Address Space Separation a.k.a. uass

[Reactie gewijzigd door kidde op 22 juli 2024 18:47]

[Laloeka]

De naam 'FUCKWIT' is een onofficiële naam voor de fix die op Linux geimplementeerd is. Officiëel wordt de naam KPTI aangehouden. De naam slaat op de negatieve gevoelens tegenover Intel van de linux developers.

Voor zover ik weet is er geen naam voor deze Intel bug, anders dan dat de naam Intel overal groot en duidelijk zichtbaar is.

[Reactie gewijzigd door Laloeka op 22 juli 2024 18:47]

[EaS]

Als de linux kernel blijkbaar prima draait zonder de patch op AMD dan is deze statement alleen een damage control poging.

Linux Will End Up Disabling x86 PTI For AMD Processors

M.a.w. die patch komt er inderdaad niet in voor AMD CPU's.

[Verwijderd]

Het was een retorische vraag

Misschien waren er nog updates geweest sindsdien maar zie inderdaad dat dit niet zo is. @Loggedinasroot heeft eigenlijk de beste reactie die ik zou kunnen bedenken, ik zou het ook zo als billboard gebruiken

[mg794613]

Niet in de vanilla source tree van 4.15.
In hetzelfde artikel word namelijk ook uitgelegd dat het merge window in 3 weken is.
En Linus is (gelukkig) niet iemand die gehaast iets merged "omdat het leuk lijkt".
Maar dit zegt nog niks over de toevoeging in patchsets van distro's of een latere versie (wellicht 4.16, of niet als het niet waar blijkt te zijn)

Update: Toch wel gemerged!

https://git.kernel.org/pu...6ac249a9ce&utm_source=anz

[Reactie gewijzigd door mg794613 op 22 juli 2024 18:47]

[erwinwernars]

Gaat mijn processor nu ook op een windows machine prestaties inleveren? want als ik het goed begrijp is de exploit alleen met het linux besturingsysteem?

[RedShift]

1ste vraag ja, 2de vraag, het probleem is een hardware probleem en hangt niet van het besturingssysteem af. De kernel is de enigste plaats waar een workaround kan geplaatst worden (in het geval van Linux d.m.v. KPTI). De aandacht gaat naar Linux omdat de patches om dit probleem te fixen openbaar zijn, maar zowel Apple als Microsoft zijn al bezig geweest om hun kernels te patchen.

[erwinwernars]

Maar mijn processor wordt dus slomer dan dat die bij aankoop is beloofd, dat zou toch eigenlijk niet mogen? of blijven de specs van het product wel gewoon hetzelfde? maar is het enkel de prestaties in optimalisatie?

[vectormatic]

Nee, je OS gaat (mits gepatched) de processor anders gebruiken, waardoor je applicaties minder snel draaien, de CPU blijft compleet onveranderd, je zou kunnen dual booten tussen een gepatched en niet gepatched OS, waarbij de applicatie performance naargelang ook meewijzigt.

Zie het als, je ontdekt dat als je je portemonee achterstevoren in je broekzak stopt, er af en toe een muntje uitvalt, nu check je elke keer bewust of je je portemonee wel goed gedraaid is voor je em wegstopt, waardoor die handeling 1 seconde langer duurt. Je portemonee is niet veranderd, maar jouw gebruik wel, om een naderhand ontdekt risico te ondervangen.

Zie ook bijvoorbeeld de TLB-bug op de eerste generatie AMD Phenoms, die fix had ook negatieve performance impact.

[RedShift]

Afhankelijk van wat je er mee doet kan hij inderdaad slomer worden dan bij de aankoop, dat zou inderdaad niet mogen, maar aangezien dit een hardware probleem is... Er worden eigenlijk nooit beloftes gedaan naar prestaties toe - enkel de fysieke eigenschappen, kloksnelheid, cache geheugen, ... en die zullen dus niet veranderen. De manier waarop de processor aangestuurd wordt verandert (een workaround voor het hardware probleem) en dat zorgt voor het prestatieverlies.

[erwinwernars]

aah top, ja ik render er videos mee dusja slomer wordt die wel

[MiesvanderLippe]

Dan zit je waarschijnlijk hoog in het bereik van 5 tot 30%, je gebruikt namelijk met renderen veel directe systeem objecten voor wat ik er van begrijp.

[erwinwernars]

en daar kan je zeker niet tegen op overclocken

[Verwijderd]

Je kan wel (gaan) overclocken, maar je verliest ook daar x% van de prestatiewinst van - en gezien de normale marge van overclocken, denk ik niet dat je erin zal slagen het normale verlies compleet te compenseren dan. Erger nog, ik vraag me af of je de boel dan niet mogelijk erger kan maken.

[asing]

Hoe meer system calls, hoe meer last je hebt. Als rendering veel disk access heeft ga je het zeker merken.

[StGermain]

Daar zet ik mijn gtx1070 voor in, gaat nog heel wat sneller dan mijn 6600K

[erwinwernars]

renderen op gpu geeft rare beelden bij sony vegas.

rendert op 1 of andere manier niet goed

[asing]

Ja, het probleem zit in de microcode van de processor. Intel kan daar niets mee en dus moet het OS de klap maar opvangen.

Microsoft stopt het in zijn kernel, maar die is closed source. Het balletje ging rollen toen de commits in de Linux kernel werden gedaan. Die zijn wel openbaar.

[RedShift]

Het probleem zit NIET in de microcode. Er kan nieuwe microcode ingeladen worden in de CPU (is niet zoals een BIOS flashen - moet iedere keer bij het opstarten van de computer gebeuren), maar het probleem zit in een stuk van de processor waar het probleem niet op te lossen is door middel van een microcode update.

[spookz0r]

En Intel heeft zich daar tegen ingedekt met hun garantie. Het volgende wordt namelijk niet gedekt:

design defects or errors in the Product (Errata). Contact Intel for information on characterized errata.

https://www.intel.com/con....5x11_for_Web_English.pdf

[Reactie gewijzigd door spookz0r op 22 juli 2024 18:47]

[Dark_man]

Dat is leuk en aardig maar de wet staat toch daarboven.

Dus als het een rechtzaak word kan Intel altijd nog verliezen.

[Richo999]

Intel zegt dit, amd zegt weer iets anders. Afwachten dan maar. Wel typische marketing van intel, ze kunnen het niet ontkennen dan maar iedereen de schuld geven om het minder erg voor zichzelf te maken.

[jimzz]

Zolang er geen concrete antwoorden zijn is ook dat een conclusie die je (nog) niet mag trekken.

[kidde]

Kijk maar naar de terugopverende trampoline-beurskoers, dan ziet u dat alle beleggers daar feces aan hebben Van $46 begin van de dag, naar $43,75 na de bekendmaking van Intel's ontwerpfout, naar $45 na deze 'damage-control' ...

[Little Charlie]

Dat komt omdat beleggers vaak de ballen verstand hebben van de producten die het bedrijf maakt waarin ze beleggen.
Verder nog de nodige speculanten die denken goedkoop te kunnen kopen en daarmee de prijs weer terug opdrijven, et voila; we eindigen waar we begonnen.

Daarom zijn de koersen van bijvoorbeeld apple en tesla ook zo belachelijk; mensen snappen niet waar ze zich inkopen.

[Richo999]

gebaseerd op acties van intel in het verleden, is dit een presumptie die nog wel eens kan kloppen. zeg ook duidelijk dat we moeten afwachten.

[RedShift]

AMD zegt niets. Het enigste wat AMD heeft bijgedragen is een patch voor de Linux kernel zodat de remedie tegen de Intel bug (KPTI) niet uitgevoerd wordt op hun CPU's. Anders worden ze meegesleept in een gigantische performance loss door een fout in de CPU's van Intel.

[haling]

Anders worden ze meegesleept in een gigantische performance loss door een fout in de CPU's van Intel.

Heb je al benchmarks gedraaid? Degene die ik gezien heb zeggen dat het bijna onmerkbaar is.

[Sp3ci3s8472]

Dat zijn alleen de OpenGL benchmarks in Linux, dus met name games. Voor dingen zoals databases is er wel degelijk een performance penalty. Het is afwachten wat de performance penalty op Windows gaat worden en wat voor velen die games spelen de impact gaat zijn. Blijkbaar heeft Windows de fonts volgens mij al in userspace gezet in hun komende patch (pin me er niet op vast).

Lees anders het artikel op phoronix, hierin kan je de performance resultaten zien op Linux.

[RedShift]

De grootste verliezen gaan naar applicaties die veel syscalls doen en systemen waar tijdens het werken veel interrupts voorkomen. Zoals bijvoorbeeld deze PostgreSQL benchmark. Een vertraging van 7 tot 23%. Dat vind ik toch wel gigantisch. Als je een 6 cylinder motor koopt en de garagist zegt dat je 20% van je vermogen kwijt bent, heb je nog maar een 4,8 cylinder motor... Daar zou ik allesinds niet tevreden over zijn.

Overigens, de impact van KPTI inschakelen is nog erger op AMD CPU's, daar heb ik cijfers gezien van 40% (kan nu even de link niet meer terugvinden).

[Verwijderd]

Tsja, maar dat komt ook denk ik doordat er onnodig iets wordt 'opgelost' dan wat niet bestaat in de chips, dus de chips gaan extra werk verzetten terwijl hun infrastructuur anders ingericht is dan wat de patch van uit gaat. Lijkt me op zich logisch.

[Enchantress]

Toch wel aanzienlijk. (dit zijn nog maar de eerste en een paar benchmarks, meer volgt)
https://www.phoronix.com/...em=linux-415-x86pti&num=2

[Verwijderd]

Wanneer je workload veel syscalls heeft (m.a.w. vaak naar kernel-mode en terug moet), zal het performantie verlies groter zijn.

Typische workloads die zo zijn zijn I/O zoals disk en netwerk.

[WhatsappHack]

AMD zegt wel iets:
https://lkml.org/lkml/2017/12/27/2

[Richo999]

https://www.theregister.c...02/intel_cpu_design_flaw/
"AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against. The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault."

[Powermage]

Naja, intel zegt niet dat AMD vatbaar is, ze zeggen alleen dat meer fabrikanten vatbaar zijn hiervoor (er zijn wat meer partijen die X86 cpu's bakken), ze zeggen daarnaast met partijen als AMD en ARM dit industriebreed op te lossen, wederom zegt dat niet dat AMD wel vatbaar is.

Wat ze voor t gemak vergeten is dat intel een 80% van de markt in handen heeft, de paar overige vatbare CPU bakkers een verwaarloosbaar percentage hebben en AMD een 20% in handen heeft, maar dat is gewoon marketing praat.

[SuperDre]

Tja, het zijn juist toch de 'onderzoekers' die aangeven dat de fout in zowel intel, amd als arm cpu's zit, niet intel.

[kamerplant]

Het probleem zou in de laatste update van MacOS al zijn gefixt, aldus MacRumours. Ik snap niet hoe dat kan als Intel aangeeft dat het nog industriebreed moet worden opgepakt. Al met al ben ik erg benieuwd naar het verloop, tot 30% minder performance is huge!

https://www.macrumors.com...flaw-fixed-macos-10-13-2/

[Reactie gewijzigd door kamerplant op 22 juli 2024 18:47]

[Jay-v]

Microsoft heeft ook al "beta" patches gereleased naar de fast-ring en de patches zitten ook in Linux Kernel 4.15-rc6.

De verwachting is dat Microsoft de patches volgende week dinsdag vrij geeft. Ik ben benieuwd naar benchmarks

[Loller1]

Patches komen zo dadelijk om 23:00 al uit voor Windows 7, Windows 8.1 en Windows 10 version 1507, 1511, 1607, 1703 en 1709.

[Verwijderd]

bron?

edit: TY enjoy the +2

edit2: oops toevoeging was door iemand anders gedaan, sorry!

[Reactie gewijzigd door Verwijderd op 22 juli 2024 18:47]

[Opperpanter2]

https://www.theverge.com/...cessor-bug-windows-10-fix

[Pain_E]

Op Phoronix zijn de eerste benchmarks binnen en uit hun artikelen blijkt dat er wel degelijk performance problemen zijn, maar zeker niet 30%. Ook geeft hij aan dat de gemiddelde gebruiker/gamer er weinig tot niks van gaat merken.

Het blijft afwachten, pas als de patch massaal wordt geïmplementeerd kunnen we zien wie de meeste performance problemen krijgen.

Bron:
https://www.phoronix.com/...em=linux-415-x86pti&num=1
https://www.phoronix.com/...-PTI-Initial-Gaming-Tests
https://www.phoronix.com/...m=linux-more-x86pti&num=1

[Wulfklaue]

Het probleem is niet games omdat die weinig sys end interupt calls doen, het probleem zit hem dat alles op gebied van databanken, VMs enz erdoor getroffen is.

En dat is net de magische combinatie van cloud hosts. Databank op een VM op een Intel CPU. Plop, je word dubbel getroffen omdat je calls hebt naar de databank maar ook naar de VM.

Voor de gewone eind gebruiker zal je weinig van merken op een paar bepaalde specifieke applicaties na maar Cloud hosts, die gaan volgens mij gaan foamen op de mond. Want zelf een maar 10% hit, dat is miljarden in performance waarover we spreken.

En Intel hun grootste inkomsten deze dagen is juist op de markt van Server hardware en niet meer op de markt van desktop hardware. Waardoor deze "issue" dubbel zo pijnlijk is.

Natuurlijk dat Intel de vaarwaters wilt bevuilen door in hun PRs te doen alsof AMD en ARM manufacturen ook dezelfde issues hebben want het zou wel eens kunnen dat veel bedrijven die trouwen Intel klanten zijn maar ook hogere prijzen betaalde voor de "Intel betrouwbaarheid" ( en het feit dat AMD niet veel deftigs had tot Ryzen en nu dus hun EPIC server platform ), dat dezelfde managers wel eens meer gaan kijken naar de goedkopere concurrent.

[xiphoid]

Beta 10.13.3 heeft zelfs nog meer dingetjes op dit gebied.

[WhatsappHack]

Het mooie is dat 32-bit MacOS dit probleem niet had, maar omdat ze in de pas zijn gaan lopen met de rest van de industrie op hun 64-bit versie zijn ze kwetsbaar geworden.

[Quakie]

Logisch, damage control en ik heb zelf geen reden om hun verhaal niet te geloven. Mochten ze uiteindelijk toch de enige zijn met deze bug komt het dubbel zo hard terug.

De grote vraag die bij mij komt... hoe snel fixen ze het in in hardware... of gaan ze ervoor om het voortaan in software op te laten lossen.

[SG]

Als er sprake is van damage control, is zelfde als smoke screen. Werkelijkheid mooier maken dan het is. Of ramp verdoezelen als klein probleempje. Bedrijven doen nou eenmaal aan damage controle. Om hun Image en prestige te beschermen. Maar dat maakt hun allemaal ook niet betrouwbaar wat er publiekelijk wordt gezegd. En daar mee is uiteraard rot als automatiseerder net de knoop wilt doorhakken om tussen Xeon en Epyc te kiezen. Je dat dan voor de zekerheid maar moet uitstellen.
Tot de rook is opgetrokken en er duidelijkheid is.

Nu lees ik dus her en der tegenstrijdige berichten. Op korte termijn geen CPU upgrade dus kan de kat uit de boom kijken. November '17 voor threadripper gegaan.