VU-onderzoekers: Intel heeft RIDL-kwetsbaarheid nog niet volledig opgelost

Intel heeft de door VUSec ontdekte RIDL-beveiligingsproblemen in zijn processors nog steeds niet volledig opgelost. Dinsdag is een nieuwe patch uitgebracht, maar ook die lost nog niet alle problemen op.

De onderzoekers van de Vrije Universiteit Amsterdam melden op Twitter dat Intels nieuwe patch geen volledige oplossing biedt. Intel maakt in zijn patchnotes melding van een nieuwe kwetsbaarheid, maar volgens de onderzoekers is dat een variant van de lekken die al in september vorig jaar zijn gemeld. De onderzoekers hebben hun MDS Attacks-website aangevuld met informatie over het 'nieuwe' lek. Het gaat om een variant van het Rogue In-Flight Data Load-lek, één van de twee Microarchitectural Data Sampling, of MDS-kwetsbaarheden die eerder dit jaar naar buiten kwamen. De RIDL-kwetsbaarheid is een lek in speculative execution, een functie in de meeste Intel-chips.

Onderzoekers van de VUsec-afdeling van de Vrije Universiteit van Amsterdam ontdekten die kwetsbaarheid in september 2018. Zij coördineerden de disclosure ervan met Intel zodat het bedrijf op tijd een werkende patch kon uitbrengen. Dat gebeurde in mei van dit jaar. Nu zeggen de onderzoekers echter dat die patch slechts gedeeltelijk werkte, in tegenstelling tot wat Intel beloofde. Dinsdagavond bracht Intel een nieuwe patch uit, maar die heeft volgens de onderzoekers nog niet alle problemen opgelost.

De nieuwe microcode-update zou de rest van de kwetsbaarheden repareren waarvan Intel in mei al zei dat het die gerepareerd had. In de nieuwe update erkent Intel echter ook dat niet alle kwetsbaarheden ermee worden opgelost. Het is nog steeds mogelijk de Transactional Synchronization Extensions-feature in Intel-chips aan te vallen. Dat kan met een sidechannel-aanval die veel op de eerdergenoemde MDS-kwetsbaarheid lijkt, en die ook wel 'TSX Asynchronous Abort' wordt genoemd. De onderzoekers zeggen dat het met die aanval mogelijk is om een root-wachtwoordhash in een halve minuut te onderscheppen uit een chip.

Niet alle Intel-chips zijn kwetsbaar voor TAA voor. Het gaat voornamelijk om Cascade Lake-chips. Intel zegt dat het 'in de toekomst' een nieuwe microcode-update uitbrengt om dat lek te verhelpen. Zo'n microcode-update kan de kwetsbaarheid niet volledig dichten, maar wel moeilijker maken. Om zeker te weten dat het lek niet kan worden uitgebuit moeten gebruikers Hyper-Threading uitschakelen.

In een interview met de New York times zegt één van de VUsec-onderzoekers dat zij van Intel het verzoek kregen de nieuwe kwetsbaarheden stil te houden tot er een definitieve patch beschikbaar was. Dat hebben ze dit keer echter niet gedaan. Volgens de onderzoekers zijn er nog talloze kwetsbaarheden aanwezig en is het tijd om iedereen daarvan op de hoogte te stellen.

Enkele dagen voordat Intel de RIDL-kwetsbaarheden in mei bekendmaakte, kregen de onderzoekers ook het verzoek om hun paper daarover aan te passen en informatie over kwetsbaarheden waar nog geen patch voor was weg te laten. Destijds werd daar mee ingestemd, waardoor die informatie nu pas naar buiten komt.

Tweakers publiceerde in mei een analyse over het 'einde van Hyper-Threading', nadat Intel de door de VUSec-onderzoekers gevonden kwetsbaarheden bekendmaakte.

VUSec-onderzoekers demonstreren TSX Asynchronous Abort waarmee in dertig seconden een root-wachtwoordhash is te onderscheppen.

Reacties (38)

[bgttje]

Vergelijking veiligheid Intel & AMD:
https://www.tomshardware....md-most-secure-processors

[Reactie gewijzigd door bgttje op 23 juli 2024 15:35]

[retep69]

2 vragen;
- Bevat ARM ook een soortgelijk subsysteem als Intel ME of AMD PSP?
- Er gaan meerdere laptops uitkomen met de op ARM gebaseerde Snapdragon 8cx SoC. Bevat die een soortgelijk subsysteem als Intel ME of AMD PSP?

[Feni]

Om zeker te weten dat het lek niet kan worden uitgebuit moeten gebruikers Hyper-Threading uitschakelen.

ARM heeft geen hyperthreadingfunctionaliteit.

[Jerie]

Volgens mij wel. Als je een open architectuur wilt heb je momenteel twee keuzes: POWER en RISC-V.

Er zijn enkele ARM SoCs die out of order execution kunnen. Een secure enclave (of "TrustZone") hebben de meest recente ARM SoCs allemaal.

[Reactie gewijzigd door Jerie op 23 juli 2024 15:35]

[Cerberus_tm]

Uitstekend artikel, dank.

[AtHomer]

Zouden AMD-chips veiliger zijn, of zouden die ook (niet gecommuniceerde) lekken bevatten? Ik krijg het gevoel dat Intel hier steken laat vallen, en niet genoeg doet om de problemen op te lossen.

[Dennism]

Dat is een terechte vraag om te stellen, en het antwoord daarop is momenteel ja, de huidige generaties AMD cpu's zijn op dit moment veiliger dan de huidige generaties Intel cpu's. Er zijn op dit moment diverse kwetsbaarheden waarvoor AMD niet vatbaar is en Intel cpu's wel in meer of mindere mate (bij Intel is veel afhankelijk van welke generatie je de cpu koopt, hoe nieuwer de generatie, hoe meer zaken er in hardware zijn opgelost).

Dit is goed te zien aan de linux kernel parameters voor de diverse cpu's.

Dit zijn bijvoorbeeld de parameters voor Intels 8th gen cpu's en 9th Gen (Geen R0 Stepping):

"l1tf: Mitigation of PTE Inversion + mds: Mitigation of Clear buffers; SMT vulnerable + meltdown: Mitigation of PTI + spec_store_bypass: Mitigation of SSB disabled via prctl and seccomp + spectre_v1: Mitigation of __user pointer sanitization + spectre_v2: Mitigation of Full generic retpoline IBPB: conditional IBRS_FW STIBP: conditional RSB filling."

Dit voor Intels 9th (R0 Stepping) / 10th gen:

"l1tf: Not affected + mds: Not affected + meltdown: Not affected + spec_store_bypass: Mitigation of SSB disabled via prctl and seccomp + spectre_v1: Mitigation of usercopy/swapgs barriers and __user pointer sanitization + spectre_v2:Mitigation of Enhanced IBRS IBPB: conditional RSB filling."

En hier voor AMD Zen Sku's

Zen / Zen+

"l1tf: Not affected + mds: Not affected + meltdown: Not affected + spec_store_bypass: Mitigation of SSB disabled via prctl and seccomp + spectre_v1: Mitigation of __user pointer sanitization + spectre_v2: Mitigation of Full AMD retpoline IBPB: conditional STIBP: disabled RSB filling."

Zen 2

"l1tf: Not affected + mds: Not affected + meltdown: Not affected + spec_store_bypass: Mitigation of SSB disabled via prctl and seccomp + spectre_v1: Mitigation of __user pointer sanitization + spectre_v2: Mitigation of Full AMD retpoline IBPB: conditional STIBP: always-on RSB filling."

Hier kun je duidelijk zien dat Intel's 8th gen meer mitigations nodig heeft dan Intels 9th gen (R0 stepping) en 10th gen en dat Intels 9th gen (R0 stepping) en 10th gen vrijwel dezelfde mitigations nodig hadden als recente AMD cpu's.

Intel was dus bijna weer aangesloten bij AMD met hun recentie hardware mitigations.

Echter door bovenstaand nieuws zal Intel er minimaal weer een migitation bijkrijgen bij de 9th en 10th gen Sku's (Voor TAA) waarom AMD weer wat meer voorsprong pakt qua het nodig hebben van mitigations.

[The Zep Man]

het antwoord daarop is momenteel ja, de huidige generaties AMD cpu's zijn op dit moment veiliger dan de huidige generaties Intel cpu's

Met als kanttekening dat je hiervoor alleen naar bekende kwetsbaarheden kijkt.

Als universiteitsonderzoeker ga je natuurlijk eerst voor de populairste keuze. Mogelijk zijn AMD CPU's dus niet zo diep onderzocht als Intel, en zitten daar ook nog kwetsbaarheden in.

[user109731]

Als universiteitsonderzoeker ga je natuurlijk eerst voor de populairste keuze. Mogelijk zijn AMD CPU's dus niet zo diep onderzocht als Intel, en zitten daar ook nog kwetsbaarheden in.

Feit blijft dat veel onderzoekers hier nu al zeker een jaar mee bezig zijn (de meeste van deze lekken zijn door meerdere partijen onafhankelijk van elkaar gevonden) en toch AMD niet vatbaar is voor de meeste van de gevonden kwetsbaarheden. Ik geloof niet dat "ze proberen alleen Intel" op al die onderzoekers en experimenten van toepassing is. Het lijkt erop dat AMD speculative execution wat conservatiever en voorzichtiger toegepast heeft en Intel daar bepaalde shortcuts heeft genomen die ze nu opbreekt.

Bovendien is dat ook weer extra motivatie voor iemand om toch een probleem in AMD-hardware te vinden natuurlijk

Los daarvan, lijkt het er bovendien op dat Intel slecht omgaat met de gevonden problemen. In plaats van een team experts erop te zetten en dit alles zo snel mogelijk tot op de bodem uit te zoeken (en samen te werken met externe onderzoekers), geven de onderzoekers aan dat de afhandeling door Intel veel te wensen overlaat, zie de website voor details.

[Reactie gewijzigd door user109731 op 23 juli 2024 15:35]

[batjes]

Intel gaat niet alleen slecht om met de gevonden problemen. Ze hebben duidelijk design keuzes gemaakt waarbij security ondergeschikt gesteld is aan performance. Waarbij AMD duidelijk andere keuzes heeft gemaakt in hun ontwerpen..

De bedrijfsethiek van beide bedrijven zegt ook genoeg. Intel heeft koste wat het kost een voorsprong genomen op AMD, terwijl AMD de strijd een stuk netter gevoerd heeft.

Ergens ben ik wel eens benieuwd hoe slecht die Bulldozers nu daadwerkelijk waren. Er is door de jaren heen een hele stapel optimalisaties vanuit software developers en OS bouwers gekomen, waardoor een Battlefield bv vanuit een grote achterstand, jaren later vrijwel gelijke resultaten wist te boeken als Intel CPU's met hetzelfde bouwjaar en uit dezelfde klasses, en soms een streepje voor wisten te behalen. Met de performance verlies die Intel nu op die oude chips van hun er bij heeft gekregen (als ze al patches kregen), lijkt het zo te zijn dat achteraf gezien, AMD het winnende ontwerp in huis had.

[Oet]

Ik zou zo'n onderzoek ook wel graag willen zien. Er is, vermoed ik, in die tijd veel gebeurd wat het daglicht niet kan verdragen, een keer kritisch terugkijken zou absoluut interessant zijn.

[Dennism]

Dat klopt, daarom duid ik dat ook met "momenteel". Wat er mogen, volgende week, over 6 maand of over 5 jaar gevonden gaat worden weet natuurlijk nog niemand.

Echter momenteel is Intel gewoonweg minder veilig dan AMD. Wat opzich ook niet onlogisch is, de fundering voor de huidige Intel architectuur is immers ergens halverwege de jaren 2000 gelegd. Die van AMD ergens tussen 2012 en 2015, waardoor AMD in dat opzicht het voordeel heeft van meer voortschrijdend inzicht op security gebied.

Het kan inderdaad zeker voorkomen dat er in de toekomst ook meer ernstige zaken in AMD cpu's ontdekt worden, echter maakt dat niet anders dat als je op dit moment een cpu gaat kopen en security is zeer belangrijk voor je dat momenteel met de huidige kennis beter af bent bij AMD dan bij Intel

[The Zep Man]

Dat klopt, daarom duid ik dat ook met "momenteel".

Het punt is dat niet aangetoond is dat AMD CPU's "momenteel" veiliger zijn. Mogelijk zijn er nu kwetsbaarheden (groter dan die van Intel) die overheden of criminelen wel weten maar het grote publiek niet. AMD zou dan minder veilig zijn dan Intel.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 15:35]

[BlaBla1973]

Het punt is juist wel aangetoond, de Intel cpu's bevatten bekende lekken en die van AMD niet. Dus is AMD veiliger,want daar kan je geen werkend exploit voor schrijven ... (En misschien zijn er na de nog grotere lekken van AMD, nog wel grotere voor Intel in de toekomst.... Ff in de glazen bol kijken)

[Reactie gewijzigd door BlaBla1973 op 23 juli 2024 15:35]

[kidde]

Niet onderbouwde speculatie.

Het is vrij simpel, AMD gebruikt een extra bit als 'veiligheids-check' op bepaald cache, Intel niet.

Er is een hele familie kwetsbaarheden, waaronder MDS / RIDL, die gebruik maakt van het feit dat Intel dat bitje en die check achterwege heeft gelaten 'voor prestatie-doeleinden'. Dus ja, AMD CPU's zijn momenteel veiliger voor de familie kwetsbaarheden, die het ontbreken van dat bitje op Intel processoren uitbuiten! Dat is gewoon simpelweg een feit, met geen enkele hoeveelheid speculatie valt dat te ontkennen.

For performance reasons, processors store a copy of these virtual to physical translations in a Translation Lookaside Buffer (TLB). AMD processors store translations in the TLB with a valid bit and all the protection bits from the page table which include user/supervisor, read/write bits along with other information. On each instruction that uses virtual addresses to access memory, AMD processors access the TLB and use the valid bit and the protection attributes to decide whether to access the caches. If the protection check fails, AMD processors operate as if the memory address is invalid and no data is accessed from either the cache or memory. This occurs whether the access is speculative or non-speculative. When the instruction becomes the oldest in the machine, a page fault exception will occur. A validated address is required for AMD processors to access data from both the caches and memory. The result is AMD processors are designed to not speculate into memory that is not valid in the current virtual address memory range defined by the software defined page tables.

[Reactie gewijzigd door kidde op 23 juli 2024 15:35]

[Wim-Bart]

Van alle bekende lekken is er een vinkje bij Intel te zetten en in een paar gevallen bij AMD. Het grote plaatje is, maar dat Intel meer issues heeft, waarbij de opmerking gemaakt moet worden dat wanneer de patches op Intel uitgevoerd worden de kracht van de CPU's dramatisch afneemt, zeker wanneer je geen consessies wilt maken. Zonder consessies moet je dus Hyperthreading uitschakelen op Intel.

Wanneer je dus Intel afzet tegen AMD dan heb je per core een verlies van 20% op IPC op een core die al iets mindere IPC heeft dan de moderne AMD's. Tel daarbij op dat je HT moet uitzetten, dan mag je er van uit gaan dat je dus op een 16 core socket (xeon/epyc) bij 2.8 GHz op een Intel 16 threads hebt en op een AMD 32 threads waarbij AMD ook nog eens een IPC heeft van 120% per thread. Kortom een AMD is dus per chip 2,2-2,4 maal zo snel. Onder ESX is dat dus een 2 keer zo grote farm als een AMD farm. Bij niet uitschakelen van HT bij Intel moeten er een aantal mitigaties worden uitgevoerd waardoor het verlies op IPC voor Intel zeker 30-40% is per twee HT cores ten opzichte van AMD. Beide scenario's heb ik aan mogen meten en vooral bij SQL, Oracle en Postgress is het verschil dramatisch slecht voor Intel ten opzichte van AMD.

[raro007]

Als universiteitsonderzoeker ga je natuurlijk eerst voor de populairste keuze. Mogelijk zijn AMD CPU's dus niet zo diep onderzocht als Intel, en zitten daar ook nog kwetsbaarheden in.

Wat denk je dat criminelen denkwijze is? Juist ja zelfde als die onderzoekers..

[Jerie]

Met als kanttekening dat je hiervoor alleen naar bekende kwetsbaarheden kijkt.

Als universiteitsonderzoeker ga je natuurlijk eerst voor de populairste keuze. Mogelijk zijn AMD CPU's dus niet zo diep onderzocht als Intel, en zitten daar ook nog kwetsbaarheden in.

Met als kanttekening dat deze opmerking puur theoretisch is, en geen bewijs bevat. Want tja, "ze zijn er nog niet!" Tot op heden doet Intel het in dit opzicht bar slecht tov concurrentie (ALLE concurrentie: AMD, POWER, ARM, RISC-V, enz).

[Verwijderd]

Ja, die zijn aantoonbaar veiliger en daarom ook de aangewezen keuze bij bepaalde toepassingen.

[MMaI]

AMD heeft een andere techniek voor hyper threading welke in theorie minder vatbaar is voor dit type kwetsbaarheden. Het meeste onderzoek heeft zich tot dusver op Intel gericht, het is dus goed mogelijk dat kwetsbaarheden in AMD chips nog niet ontdekt zijn.

Voor Intel zijn deze kwetsbaarheden moeilijk op te lossen omdat ze deels in de fysieke chip zitten, iedere software fix heeft dan een impact op de prestaties van de CPU. Hyperthreading uitschakelen heeft uiteraard de grootste impact op prestatie maar is momenteel de enige mogelijkheid als je bijvoorbeeld veilig virtuele machines met meerdere klanten per CPU wil hosten.

[computerjunky]

Zelf ben ik van menig dat er gewoon veel actiever gezocht word dan bij AMD.
1. omdat ze groter zijn qua marktaandeel en
2. omdat het anti intel geluid la vele jaren luider is dan het anti AMD geluid.

Als er echt beter gezocht zal worden naar lekken in AMD hardware dan word er vast en zeker vanalles gevonden maar ik krijg altijd het gevoel dat er specifiek bij intel gezocht word en dan gekeken word of er bij AMD ook een lek is wat natuurlijk een verkeerde aanpak is.
Je kan niet op 1 architectuur zoeken en dan vergelijken met de ander ze zijn immers verschillend en dus moet je individueel zoeken.,

[choogen]

Dinsdagavond bracht Intel een nieuwe patch uit, maar die heeft volgens de onderzoekers nog niet alle problemen opgelost.

Hoe krijg je deze patch binnen? Gaat dat via de Windows updates? Of via een nieuw bios voor je mobo? Of op (nog) een andere manier?

[Lizard]

Dit kan inderdaad via de manieren die je aangeeft.
Windows update biedt de mogelijkheid om microcode updates te gebruiken/installeren. Dit gebeurt elke keer als je Windows start.
Via een bios update zit de microcode in de bios verwerkt, dus je cpu heeft de patch wanneer je de pc aanzet.

Zie ook https://support.microsoft...f-intel-microcode-updates

[Dennism]

Dat kan via beide, microsoft verwerkt microcode updates vaak in Windows Updates, al is het regelmatig wel zo dat deze (initieel) enkel via de Windows Updata Catalog handmatig te verkrijgen zijn.

Zie hier voor voorbeelden: https://support.microsoft...f-intel-microcode-updates

De updates van vandaag staan er nog niet op.

Verder kan je dit inderdaad via een biosupdate binnen halen als je moederbord fabrikant of systeem fabrikant deze uitgebracht heeft.

Diverse Linux distributies leveren deze microcode updates ook mee.
Ook kun je ze bij Intel downloaden om ze zelf te activeren in Linux ( downloaden hier: https://github.com/intel/...ssor-Microcode-Data-Files)

[Jerie]

Normaliter hoef je op "Linux" niets extras te downloaden voor de laatste mitigaties. Die staan gewoon tussen je software updates in bijvoorbeeld Gnome of KDE of fwupdmgr. Zoals bijvoorbeeld in dit geval:

https://blogs.gnome.org/h...gitech-hardware-on-linux/

Het Linux Vendor Firmware Service (LVFS) project levert die zooi aan, en die krijgen het vaak rechtstreeks van de vendors.

Kan deze nog aanraden om te checken naar de laatste CPU vulnerabilities:

https://github.com/speed47/spectre-meltdown-checker

(Werkt ook in VM mocht je niet als root willen draaien, maar ja als je vulnerable bent...)

[Dennism]

Als je day one beveiligd wil zijn kan het zeker wel nodig zijn om de microcode zelf te downloaden en in te laden onder Linux. Lang niet iedere distro heeft day one de microcode updates klaar staan. Terwijl het in sommige gevallen het fijn is deze z.s.m. te hebben, aangezien firmware / bios updates vaak nog langer op zich laten wachten of zelfs in bepaalde gevallen nooitr zullen komen. https://github.com/intel/...ssor-Microcode-Data-Files is dan ook gewoon een officiële github pagina van Intel, waar je dit soort zaken het snelst kan ophalen wanneer nodig, bijvoorbeeld omdat voor jouw systeem er nog geen officiële uodate uit is, maar je toch beveiligd wil zijn.

Ik vraag me trouwens of dat LVFS project de Intel microcode wel distribueert, volgens hun eigen pagina niet: https://fwupd.org/lvfs/se...PFNhgCMJdruV8&value=intel

Dat script kende ik inderdaad al, Microsoft heeft trouwens ook zo iets, maar dan voor Windows https://www.powershellgal...SpeculationControl/1.0.14 (is nog niet geupdate voor TAA).

[Reactie gewijzigd door Dennism op 23 juli 2024 15:35]

[Jerie]

Windows interesseert mij niet. Het zal wel.

Dat fwupd is gewoon een soort van package manager. Als een Linux distributie fwupd gebruikt, dan gebruikt de gebruiker het automatisch ook. Vervolgens krijg je via GNOME of KDE of whatever netjes een notificatie dat je software updates hebt.

Dat geldt voor firmware, en daarmee heb je gelijk dat fwupd dit niet bevat want het zijn microcode updates die na iedere boot moeten worden ingeladen. Firmware wordt eenmalig geflashed en dan is het flash geheugen overschreven.

De microcode die via de package manager beschikbaar is, is in de Linux distributie die ik hier in VM draai van september. Wat dat betreft heb je gelijk, slechte zaak dat je zoiets dan van GitHub moet plukken.

edit:
Ik zie dat hij inmiddels wel na 1 dag was geupdate in Debian (muv de fix van de 13e): http://ftp.debian.org/deb...n-free/i/intel-microcode/

[Reactie gewijzigd door Jerie op 23 juli 2024 15:35]

[Dennism]

fwupd zal ik eens naar kijken, ik heb het nog nooit gezien eigenlijk, moet wel zeggen dat ik eigenlijk voornamelijk RHEL en afgeleide installaties beheer (volgens mij zit het daar standaard in ieder geval niet in) zonder grafische interface en eigenlijk altijd in VM's, in dat geval zal zijn firmware update manager niet veel doen. Het ziet er echter wel handig uit mocht ik ooit nog weer eens fysiek geïnstalleerde machines beheren.

Wanneer Microcode beschikbaar is hangt erg af van de distributie verwacht ik, Red Hat had bijvoorbeeld gister netjes de updates al beschikbaar ( zie bijv https://access.redhat.com/solutions/2019-microcode-nov ) maar dat zal zeker niet voor iedere distributie gelden.

Je hoeft het uiteraard niet van Github te halen, je kan ze volgens mij ook van de Intel website halen (al is dat imho meer gedoe, dus gebruik ik direct hun Github site).

[Jerie]

Of het in RHEL zit weet ik niet. Fedora heeft het sinds 24 en Ubuntu sinds 16.04

https://en.wikipedia.org/wiki/Fwupd

Het is ook al wat ouder. Er is een CLI frontend voor, en een GUI. Ik gebruik zelf Topgrade als frontend voor alle package managers.

Debian heeft ook de microcode upgrade (die van 12 november, nog niet de update van 13 nov). Het ligt aan Kali. Waarschijnlijk omdat ze gebaseerd zijn op Testing. En Testing is altijd als laatste met security fixes...

[LEX63]

Hmmm

Ik ben niet zo enthousiast over deze patchen.

Deze kunnen nadelige gevolgen hebben op de snelheid van de computer, zeker als deze al iets ouder is. Hyperthreading uitschakelen dan is zoon computer al helemaal niet meer vooruit te branden.

Intel we zijn weer lekker bezig.

Hoeveel jaar moeten we nog wachten op patch vrije processoren. Tijd dat aan de processor een extra onderdeel word toegevoegd die deze ellende buit de deur houd.

Op mijn oude notebook heb ik Spectre en Meltdown uitgeschakeld gebeurd er wat dan is het opnieuw installeren. Ik maak elke week een kloon van de C: partitie.

[Reactie gewijzigd door LEX63 op 23 juli 2024 15:35]

[Dennism]

Hoeveel jaar moeten we nog wachten op patch vrije processoren. Tijd dat aan de processor een extra onderdeel word toegevoegd die deze ellende buit de deur houd.

Ik denk dat die periode mogelijk wel voorbij is, al had je vroeger natuurlijk ook al microcode patches, dus een "patch vrije" cpu is er eigenlijk nooit geweest, in ieder geval niet de laatste 20 jaar zeg maar.

Ik verwacht zelf eigenlijk dat dit vanaf nu iets gaat zijn waar eigenlijk altijd rekening mee gehouden moet gaan worden.

[WienerBlut]

Het enige dat je kan doen is alles in FPGAs pakken, maar dat heeft zoooooveel nadelen, dat het ook onbegonnen werk is... Je zou maar een datacenter hebben waar je veel servers op 60% load kan laten draaien ipv 100% (omdat HT uit moet...)

Aan de andere kant denk ik dat Intel wel blij is, want dit zal zeker invest/replace cycles korter maken voor draaiende servers. Dus meer omzet en misschien kortere cycles in toekomstige projecten.

[Fijinees]

En dan kan het wel weer zo zijn dat afnemers toch wat meer naar AMD gaan kijken omdat ze wellicht veiliger zijn, zeker nu met Rome op de plank.

Dus dat ze dan Intel nemen is niet zo zeker.

[WienerBlut]

Is AMD echt een alternatief voor enterprise? (niet cynisch bedoeld)

Alhoewel, het zal mijn klanten een worst zijn, zolang het maar werkt, veilig is, MTBF dat vergelijkbaar is, energie gebruik en prijs... AMD heeft goede kaarten denk ik!

[Fijinees]

Als je de berichten moet geloven dat bijvoorbeeld Google een aardig stel van die dingen heeft besteld zal het voor de grote datacentra wel goed zijn.

Die hebben natuurlijk wel het personeel om de omzetting te regelen.

[Verwijderd]

Voor een ieder die snel wil controleren of ie onder de groep 'additional mitigations required' valt kan deze code uitvoeren op een Linux machine:

if lscpu | grep --quiet tsx; then sudo dmidecode -t 4 | grep 'Family 6' | grep 'Model 142, Stepping 12\|Model 158, Stepping 13\|Model 85, Stepping 6\|Model 85, Stepping 7'; fi

[choogen]

@Lizard & @Dennism Bedankt voor jullie reacties.

Nog een andere vraag: aan het eind van dit stukje wordt gesuggereerd om HyperThreading eventueel uit te schakelen, met een verwijzing naar een eerder artikel uit mei 2019: Tweakers publiceerde in mei een analyse over het 'einde van Hyper-Threading', nadat Intel de door de VUSec-onderzoekers gevonden kwetsbaarheden bekendmaakte. reviews: Beveiligingslekken in Intels cpu's - Is dit het einde van Hyper-Thre...

HT uitschakelen leidt tot slechtere prestaties. Ben wel benieuwd hoe de gemiddelde Tweaker die uitruil heeft gemaakt. Gaan prestaties voor veiligheid of andersom? Het blijft natuurlijk zo dat zelfs met HT uitgeschakeld er nog geen 100% veiligheidsgarantie bestaat. Dus wat doe je dan met bijv. je game bak?

[Reactie gewijzigd door choogen op 23 juli 2024 15:35]