Onderzoekers vinden nieuwe Spectre-achtige lekken in cache van Intel en AMD

Beveiligingsonderzoekers van twee Amerikaanse universiteiten hebben nieuwe kwetsbaarheden gevonden in de caches van Intel- en AMD-cpu's. Het gaat om nieuwe vormen van de bekende Spectre-exploits. Bestaande patches helpen niet, maar de exploits zijn moeilijk uit te buiten.

De onderzoekers van de Universiteit van Virginia en de Universiteit van Californië beschrijven de kwetsbaarheden in een onderzoek dat het I See Dead μops noemt. Het gaat om kwetsbaarheden in de manier waarop chips van Intel en AMD aan simultaneous multithreading of SMT doen, waarbij fysieke cores worden onderverdeeld in meerdere virtuele cores.

Het onderzoek richt zich specifiek op micro-ops- of μops-caches. Die worden in moderne chips gebruikt voor het optimaliseren van prestaties en het energieverbruik. De onderzoekers hebben drie manieren gevonden om informatie die tussen de caches wordt uitgewisseld af te kunnen luisteren. Dat kan tussen verschillende gebieden binnen dezelfde thread met verschillende gebruikersrechten, tussen virtuele threads op een fysieke thread, en een aanval die hard- en software-mitigaties van Intel zoals Lfence kan omzeilen.

De onderzoekers zeggen dat de kwetsbaarheden zitten in vrijwel alle AMD-chips vanaf 2017, en in alle Intel-chips die sinds 2011 zijn gemaakt. De aanval borduurt voort op eerder onderzoek naar chip-kwetsbaarheden, met name Spectre. Er zit wel een belangrijk verschil tussen de kwetsbaarheden. Omdat een μops-cache erg klein is en dat het enige soort cache is dat wordt aangesproken, kan er méér informatie worden afgeluisterd dan bij een Spectre-aanval. Bij Spectre moesten meerdere soorten caches worden bekeken door malware in plaats van slechts een.

De onderzoekers stellen dat de enige mitigatie is om het micro-ops-cache helemaal uit te schakelen of om speculative execution uit te zetten, maar dat zou zoveel prestaties kosten dat het volgens de ontdekkers niet realistisch is. Wel zeggen de onderzoekers dat het erg moeilijk is de kwetsbaarheden in de praktijk uit te buiten.

De nieuwe kwetsbaarheden zijn immuun voor de hard- en softwarematige patches die destijds zijn uitgebracht voor Spectre, stellen de onderzoekers. Dat komt ook omdat de Spectre-patches niet altijd even goed hielpen omdat het gaat om hardwarematige problemen die ook met een microcodepatch niet zijn op te lossen. De onderzoekers hebben Intel en AMD ook op de hoogte gebracht van de nieuwe kwetsbaarheden, maar de bedrijven kunnen daar ook nu weinig aan doen.

Door Tijs Hofmans

Nieuwscoördinator

03-05-2021 • 13:52

72 Linkedin

Submitter: TheVivaldi

Reacties (72)

72
71
33
5
0
36
Wijzig sortering
Hebben de M1 chips van Apple daar dan ook last van?
Dat is wel een andere dan de hier gemelde exploit, voor de exploit in dit artikel lijkt de M1 niet getest te zijn, wat niet betekent niet kwetsbaar natuurlijk.

Arm wordt wel genoemd in het artikel, maar volgens mij verder niet getest.
https://www.cs.virginia.edu/venkat/papers/isca2021a.pdf
Er staat dat het volgens de onderzoekers zou moeten kunnen maar er staat niet of het ook getest is want ze hebben alleen Intel en Amd processoren gebruikt. Dus kan het dan ook echt of is er het vermoeden?
Daar gaan we weer. Hadden we enkele jaren geleden ook al niet zo'n kwetsbaarheid waarbij met een fix je processor in kracht moest inboeten om de boel weer veilig maken. Gaat dat nu weer gebeuren?
Ik heb de softwarematige mitigatie van Meltdown en Spectre uitgezet op mijn gaming PC. Niks belangrijks daarop. Waarom prestaties inleveren? Veel software zoals Chrome zijn zelfs zonder mitigatie al moeilijk uit te buiten omdat ze zelf code hebben om het moeilijker te maken. Heb het al jaren uitstaan en er is nog nooit wat gebeurd.

Deze aanval helemaal (omdat ze zelf zeggen dat het moeilijk uit te buiten is) moet zo gericht zijn dat het normale consumenten/gamers niks zal doen, en het lijkt me sterk of mitigatie nodig is voor deze doelgroep.

Veel software maakt gebruik van speculative execution. Dit staat in de meeste IDE's en compilers volgens mij standaard aan.

[Reactie gewijzigd door MrFax op 3 mei 2021 14:24]

Heb het al jaren uitstaan en er is nog nooit wat gebeurd.
Hoe weet je dat?

'er is nog nooit wat gebeurd', dat is niet meer relevant tegenwoordig toch? Ik neem aan dat je bedoeld dat je niks gemerkt hebt? Dat [je niks merkt] lijkt me ook de bedoeling [van de hacker] als er wel 'ooit iets gebeurd is'.


Edit: [..]

[Reactie gewijzigd door Peran op 3 mei 2021 16:14]

Dan had ik er toch uiteindelijk wat van gemerkt? Ik game er alleen op. Of er iets is gebeurd maakt ook niet veel uit. Ik ben in ieder geval geen deel van een botnet als je je dat afvraagt. :/
Zou je alsjeblieft willen delen hoe je dat merkt? Je hebt hier een primeur in handen wat zelfs Intel niet lukt. Dus hou ons niet langer in spanning en maak de wereld een stukje veiliger :+ En door je eerste opmerking doe je de tweede eigenlijk ook teniet.
1) Ik heb geen prestatieproblemen
2) M'n bankrekening is nog steeds niet leeggeplukt
3) Geen van mijn gameaccounts zijn gehackt

En je kan via Wireshark altijd je netwerk in de gaten houden.

En ik installeer geen onzin?

Je kan natuurlijk volledig paranoide zijn, maar vooralsnog is het maken van hacks voor Spectre of Meltdown financieel aantrekkelijk genoeg om het uit te gaan buiten bij ons gamers.

[Reactie gewijzigd door MrFax op 3 mei 2021 18:43]

En ik installeer geen onzin?
Dat hoef je ook niet te doen. Simpelweg tweakers.net bezoeken die een malafiede JavaScript laadt kan al voldoende zijn.

Het veel gehoorde argument dat iemand voorzichtig is met wat ie op z'n computer doet en dus geen patches nodig heeft slaat gewoon nergens op.
En? Als ik moest kiezen tussen betere performance en een matig risico op een gaming systeem, dan ga ik voor performance :P
En? Als ik moest kiezen tussen betere performance en een matig risico op een gaming systeem, dan ga ik voor performance :P
Dat is dus het domme aan dit geheel. Je neemt niet alleen risico voor jouw systeem. Als jouw systeem gecompromitteerd is kan deze gebruikt worden om PC's van andere mensen te infecteren of andere nare dingen te doen.

Het is net als seks zonder condoom. Je riskeert niet alleen je eigen gezondheid, maar ook die van anderen. Dit zou niet zo moeilijk moeten zijn om te begrijpen.
Wat een vergelijking? Spectre en Meltdown zijn voor het *aflezen* van data, niet het *schrijven* van data. Er is geen bewijs dat daadwerkelijk overnemen mogelijk is en of dat ook echt actief gebeurd. Daarnaast is het ook nog eens extreem moeilijk om daadwerkelijk het uitlezen van data mogelijk te maken. Vooral doelgerichte hacks zullen gebruik maken van dit soort lekken.

Zoals ik al zeg, waarom denk je dat het uberhaupt mogelijk is om uit te zetten? Risico vs performance. Ik gebruik de PC puur en alleen voor gamen, en mijn laptop voor alle andere zaken.

[Reactie gewijzigd door MrFax op 3 mei 2021 20:53]

Wat een vergelijking? Spectre en Meltdown zijn voor het *aflezen* van data, niet het *schrijven* van data.
Wat zou je kunnen doen met afgelezen data? Waarom zou dat toch ooit een probleem kunnen zijn?

Vraag je eens af. Als iemand data kan aflezen, hoe doen ze dat dan? Hebben die dan al een bepaalde mate van toegang tot jouw systeem? Zouden zij, met de juiste afgelezen data, nog meer rechten kunnen krijgen misschien?

Daarnaast, nogmaals. Dat jij jouw PC alleen voor gaming gebruikt betekend niet dat anderen er geen ander doel voor zouden kunnen hebben. En laten we wel wezen, ik weet 100% zeker dat jij jouw PC niet alleen voor alleen gaming gebruikt. Er is vrijwel niemand die strikt zo'n scheiding van taken handhaaft. Je zult vast wel eens een keer een browser openen of iets anders doen waarbij je data van Internet haalt en waarmee je jouw PC potentieel blootstelt aan malafide code. Al was het maar het updaten van je games waarvan jij niet kunt garanderen dat de binaries niet aangepast zijn. Of het installeren van een mod die later toch iets anders bleek te doen dan je dacht.

Hou toch op met die volharding in je naive denkwijze. Installeer updates en patch je systeem. Jouw ongepatchte systeem is een bedreiging voor de samenleving, zo simpel is het.
Dit is natuurlijk wel een erg overtrokken reactie. Precies wat @MrFax doet is gewoon pragmatisch met de situatie omgaan, daar is niks verkeerds mee. Straks komen ze achter z'n gameaccount wachtwoord, nou en? Dat is niet fijn voor NotCYF, maar zo snel ben je met spectre niet lid van een bot net hoor. Ja ze zouden heel misschien z'n admin password kunnen achterhalen als die dat intikt en z'n pc kunnen overnemen. Maar om dat voor elkaar te krijgen met spectre op een verder up to date pc... Ik zie het niet gebeuren als je geen gekke dingen doet. (En anders eigenlijk ook niet via spectre etc)
Je kan natuurlijk volledig paranoide zijn, maar vooralsnog is het maken van hacks voor Spectre of Meltdown financieel aantrekkelijk genoeg om het uit te gaan buiten bij ons gamers.
"Just because you're paranoid doesn't mean they aren't after you."

Of je een gamer bent is irrelevant. Er zijn genoeg incentives om een computer van Jan Modaal te 'pwnen'. Inzetten voor het minen van cryptovaluta, als bot in een DDoS netwerk, het harvesten van jouw credentials, etc. Dat er nu nog niets met je data gebeurd is, wil niet zeggen dat er niets gebeurd is.

En ja. Je kúnt je netwerkverkeer via Wireshark cappen. Maar doe je dat ook? Open-source kan ook geaudit worden. Maar zie Shellshock en Heartbleed.

Enfin, ontopic: je loopt hiermee wel een groter risico, voor jezelf maar ook voor anderen. Er zijn PoCs geweest, onder andere van Google, die tonen hoe triviaal het is om je geheugen te dumpen en buit te maken zonder dst je PC opstijgt - dat alles vanuit dd browser.
Zoals ik al zeg, waarom denk je dat het uberhaupt mogelijk is om uit te zetten? Risico vs performance. Ik gebruik de PC puur en alleen voor gamen, en mijn laptop voor alle andere zaken.
Het is ook mogelijk om Windows XP vandaag te installeren op die machine. Geeft ook meer performance dan Windows 10. Als jouw spellen compatible zijn, wat houd je tegen? Denk daar eens over na en pas die gedachte toe op je Win10 machine nu.

[Reactie gewijzigd door jurroen op 3 mei 2021 23:26]

Pardon, ik vraag me af waarom Tweakers nog denken 'dat je het wel merkt' terwijl de trend juist is dat men dit soort zaken een stuk beter kan verbergen.

Mijn computer is traag dus ik ben gehacked is niet meer van deze tijd, kort door de bocht.
Ik heb de softwarematige mitigatie van Meltdown en Spectre uitgezet op mijn gaming PC.
Hoe groot is het verschil in prestaties? Is dat enigszins merkbaar of meetbaar eigenlijk?
En vervolgvraag: hoe doe je dat?
Mitigatie blokkeren
Dat is maar deels mogelijk. Je kan de BIOS (die bevat uCode updates voor de CPU) terugdraaien naar een versie vóór die tijd en dat zou je niet moeten willen. Verder kan je een aantal OS updates en patches tegenhouden.

Voor Windows kan je bijvoorbeeld hier nalezen hoe dat moet, scroll even naar de grijze Microsoft blob en daar staan welke patches je kan disablen.

Maargoed, het is niet zonder reden dat deze beveligingsupdates er zijn gekomen, ik raad het dan ook ten zeerste af.

Of je PC er langzamer van word.
Feitelijk word de CPU's Branch Prediction tegengehouden door de mitigatie. Dit is een proces waarbij sommige taken al worden uitgevoerd en in de cache gezet, mocht die uitvoering later nodig zijn.

Als er 'goed gegokt' is, is de uitvoering klaar en word je PC er sneller van. Het kan echter ook zijn dat je je cache volstopt met bewerkingen die achteraf helemaal niet nodig blijken te zijn (branche delay).

Ik betwijfel ten zeerste of PC voor consumentengebruik hier merkbaar langzamer van word en de meeste huidige PC's zijn qua processorkracht meer dan snel genoeg.

[Reactie gewijzigd door vlaaing peerd op 3 mei 2021 15:00]

Het langzamer worden heeft ook te maken met de aanwezigheid, of niet, van hyperthreading bij Intel.
Dat is uit voorzorg (voorspelbaarheid) uitgezet middels de patches, bij veel CPU's.
Als je een CPU met 4 cores/4 threads hebt zul je weinig merken. Bij 4c/8t gaat dat opvallen.
Als branch prediction geen voordelen zou hebben voor de gewone consument zou een Pentium 4 Prescott met een pipeline van 29 stappen gewoon gewerkt kunnen hebben (hoe langer de pipeline, des te groter het belang van goede branch prediction).
Feitelijk word de CPU's Branch Prediction tegengehouden door de mitigatie.

Ik betwijfel ten zeerste of PC voor consumentengebruik hier merkbaar langzamer van word
Ja, dan stort de performance in elkaar. Dan ga je terug naar nivo's van het jaar 2000.

Branch Prediction is bijvoorbeeld essentieel voor elke for-loop. Daarbij springt de CPU herhaald terug van het einde van de loop naar het begin. Dit is typisch een bijna-perfecte predicted branch; alleen de laatste iteratie wordt niet goed voorspeld. Maar moderne CPU's hebben een branch predictor die dan wel de volgende keer de éérste loop-iteratie goed voorspelt.

En dit gaat dus niet alleen over expliciete for-loops in je code. Ook dingen als string copies zijn onder water een loop.
Hier ben ik ook wel geïnteresseerd naar :)
https://support.microsoft...e2-8f98-b632-0d96f30c8c8e

Voer dit in cmd.exe (in administrator modus)
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverride /t REG_DWORD /d 3 /f

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverrideMask /t REG_DWORD /d 3 /f
Daarnaast kan je ook de microcode-update terugdraaien, zoals hierboven gezegd is.

[Reactie gewijzigd door MrFax op 3 mei 2021 15:13]

Het is heel makkelijk te doen met een programma dat Inspectre heet, vooral voor oude cpu's, denk aan intel 2th en 3rd gen, is het aardig wat verschil in prestaties, denk aan ~ 10% in games.
Tja, maar of je 10% verschil echt merkt?
Hoop het wel, is dat niet hoeveel Intel de laatste paar generaties sneller is geworden?

Is dus een beetje als twijfelen of je een cpu upgrade merkt.
Het verschilt uiteraard per titel, hier een voorbeeld waarin het verschil in Gta 5 tussen spectre updates uitschakeld en spectre updates ingeschakeld best groot is:
https://www.youtube.com/watch?v=pbBFIJTBQd4 2:20

met de spectre updates aan 74fps gemiddeld, en met spectre updates uit 86 fps.
Ik denk het eerlijk gezegd wel, na de spectre/meltdown patch was mijn oude computer ineens een heel stuk trager. Games die ik voorheen zonder problemen draaide kon ik ineens niet meer op hoge Settings spelen. Zelfs het draaien van bijvoorbeeld PUBG en discord was al bijna geen doen meer.

Ik heb mijn PC maar een upgrade gegeven, maar ik merkte zeker een verschil. En nee het was geen degradering vd hardware die ervoor zorgde of een "rommelige" ssd. Clean installs hielpen niks. Het apparaat staat nu als servertje te dienen waar die nog prima geschikt voor is.
... Nou ja, ik heb nog een gtx970 (en good luck met upgraden, voorlopig...) dus geen adaptive sync (zonder peperduur g-sync scherm). 10% sneller zou me net effe wél betrekkelijk soepel lopend 60fps opleveren in AC:Odyssey, als ik zo terug denk (3770k). Ik zou zeker overwegen voor AC:V even tijdelijk zonder mitigations te draaien, dan... Maar inderdaad wel in een aparte installatie, en zonder überhaupt een browser te openen :P
Toevallig deze enkele weken nog eens getest en pc is ook puur voor gaming in gebruik.
Van simracing triple screen 2k schermen en vr tot shooters en adventures en open world games
had enkele cpu-z benchmarks en andere benchmarken laten lopen en er was echt geen verschill tussen met of zonder de spectre patch.
ook al die jaren nooit iets opgemerkt in hedendaags gebruik, simracing is hier zeer gevolg aan aangezien de AI de cpu enorm hard aanspreekt en nooit ingeboet dat ik minder AI cars op de baan heb staan
cpu is nu een dikke 3 jaar oud , 8700K op 4,8ghz
wil ik meer auto's op de baan word het zowiezo nieuwe cpu en zelfs dan twijfel ik ..
Kameraad heeft een 10850 op 4,8ghz, single tread is het zelfde als men 8700K
multicore is die wel pakken beter....
Maar je noemt hier nu een processor op die van nature al snel is en daar dus minder op beboet wordt dan oudere processors. De gehele 2000/3000/4000 serie is die spectre patch toch wel degelijk goed te voelen imho.
Begrijp je argument en draai hier ook nog een oude I7-3770 voor server toepassingen en ICT gerelateerde toepassingen en zelfs daar merk ik niets van, en jarenlang battlefield/simracing op gespeeld , en hierna pas naar de 8700k gegaan omdat het gewoon tijd werd, je merkt gewoon dat de ouder hardware het zowiezo niet meer "aankan"
als je nog op zo "oudere" generaties nieuwe games wilt spelen en dan het argument spectre gebruikt, die marge dat het trager word gaat niet zo groot zijn, tov het gevoel van ik heb een nieuwe pc nodig ...

de 4th gen draait zelfs ook nog steengoed, voorbeeld was dus ook die kameraad, tot eind dec 2020 draaide hij zij autocad/games/ontwerpen op met een 970gtx, vind zelfs tot vandaag dat hij amper verschil merkt in gewoon dagelijks gebruik en gaming

zowiezo zal er impact zijn en moet dit eens deftig worden aangepakt...maar ja we wille allemaal 4k en 8K gaming (massa media blabla) als is 2K meer al voldoende en moeten ze prestaties leveren en als ze dit allemaal gaan "fixen" wie weet hoeveel fps je dure pc eigenlijk maar tovert :)
Zoek maar op InSpectre.exe
Yup. De prestatieverliezen zijn dusdanig groot bij het uitschakelen van bepaalde kwetsbare functies dat ik betwijfel of Intel/AMD zoiets opnieuw wil doen.

Wat weegt zwaarder, de veiligheid van je klanten of de prestaties van je product? Zit niet echt een goede oplossing tussen.

Wordt dus weer een generatie cpu's wachten. Een pc bouwen was toch al haast onmogelijk (voor een redelijke prijs) gezien de gpu tekorten.
De vraag is of dit in de volgende generatie processoren wordt opgelost. Zowel Alder Lake als Zen4 zijn al ver in ontwikkeling en waarschijnlijk is het te laat om dit zonder al te veel prestatieverlies op te lossen. Zeker nu Intel en AMD weer in een IPC strijd zijn verwikkeld en de kwetsbaarheid misbruiken vrij moeilijk is (volgens de onderzoekers) lijkt me dat niet iets dat ze graag doen.
Compleet oplossen is misschien ook wel teveel gevraagd. Dit soort Spectre-achtige exploits zijn gebaseerd op statistische timing-analyses, en daardoor erg gevoelig voor ruis. Een beetje extra ruis in de cache introduceren door incidenteel eens een cache entry te droppen heeft nauwelijks invloed op de performance.
Het is niet zo zwart-wit alsje denkt.

Als je de overleggen met de ontwikkelaars van AWS terug leest, dan blijkt dat er heel veel haken en hogen aan deze aanval zitten. Ik de praktijk kun je er dus voor kiezen om zo'n mitigatie (?) niet in te zetten, als je maar op een andere manier bepaalde maatregelen trekt. Voor consumenten hardware is vaak eenvoudiger en goedkoper om gewoon het lek te dichten, maar AWS gebruikt dus alternatieve oplossingen zodat het hun niet zoveel rekenkracht kost. Wat voor een consument 5 seconden is op een jaar, is bij AWS al snel een miljoen dollars per dag.
Dat is waar "Spectre-achtige" op slaat (https://meltdownattack.com/)
Het klonk me helaas al bekend in de oren, bedankt voor de reactie.
En hoe "onveiig" is het dan?

Denk dat het allemaal wel meevalt, en dat als je maar lang genoeg focust op een onderdeel dat je altijd wel iets vindt.

Kijk lang naar een SATA controller en je zult zeker wat vinden.
Een SATA controller is iets goedkoper dan een high end processor. Plus vind ik dat je bij een processor enigszins mag verwachten dat er goed onderzoek word gedaan, maar misschien heb ik dat mis.
Het probleem is dat de processoren zo complex zijn dat je ze niet volledig kan testen in tijd. Zeker met predictive branching en SMT is het te complex
Als een bedrijf denkt dat het allemaal wel meevalt en het gaat fout wordt het op dit forum afgebrand....
Daar zit wat in ;-)
Jammer, dat gaat weer performance kosten dankzij de softwarematige fixes in OS'en :'( Draait er hier iemand Linux met mitigations=off? Is dat merkbaar qua performance?

[Reactie gewijzigd door thePiett op 3 mei 2021 14:07]

In Windows zijn de mitigaties ook uit te zetten. En ik merk degelijk verschil in performance op mijn i5-6600K. AMD heeft minder mitigaties nodig dus ik weet niet hoe merkbaar het daar is.

En de enige mitigatie die mogelijk is volgens de security experts is het uitzetten van de cache of gewoon SMT helemaal uitzetten. SMT uitzetten zal inderdaad tot grote prestatieverlies leiden

[Reactie gewijzigd door MrFax op 3 mei 2021 14:22]

Maar een i5-6600k ondersteunt toch helemaal geen SMT? Dat is een CPU uit het hart van het tijdperk waarin een quadcore genoeg was, en alleen de high-end SMT kreeg...
Je haalt twee dingen door elkaar heen. Je hebt de oude Spectre/Meltdown en je hebt de SMT-bugs. Als je geen SMT hebt dan is dit lek ook helemaal niet van toepassing.
weet je toevallig hoeveel sneller je i5-6600k is zonder de mitigaties? Ben wel benieuwd, ik draai ook nog de 6600k namelijk :P
SMT uitzetten is 10-20% performance verlies, dat zou ik niet groot noemen. Cache uitzetten is 90% performance verlies (10x trager), dát is groot.
Afhankelijk van de workload is dat zeker merkbaar ja. Bij zware, vooral vaak zakelijk georiënteerde workloads, kan dat best veel performance schelen. Voor de meeste consumenten workloads merk je er echter weinig van.

Zou ik jou bijvoorbeeld meerdere dezelfde systemen blind laten testen in het dagelijks gebruik (dus geen benchmarks / OSD's met performance gerelateerde metrics) met mitigations en zonder zal je het verschil in de regel niet opmerken.
Ik gebruik het op mijn Linux installaties waar ik audio mee doe. Voor mijn gevoel maakt het niet zo gek veel verschil, loop eerder tegen andere limieten aan. Daarnaast zijn er andere instellingen/aanpassingen die meer verschil maken (IRQ's threaden, CPU frequency scaling zoveel mogelijk voorkomen, audio interface op een vrijgespeelde USB port).
Ik draai diverse toolings op mijn laptopserver (4e generatie i5, SSD) en ik heb getest met en zonder mitigaties maar ik merk er in de praktijk weinig van op gebied van compilen, databases, en applicaties. Procentpunten, meer niet volgens mij.

Het helpt wellicht dat ik Linux draai en niet Windows, maar ik denk dat het echte probleem niet per se terug te zien is bij consumentenhardware. Als je een datacenter runt met honderdduizenden cores zal je hier een stuk meer last van hebben, denk ik.

Ik heb de mitigaties maar weer aangezet, die 5 seconden extra op een Linux kernel compile is het me de moeite niet waard mocht er echt een keer wat gebeuren.

Als ze inderdaad de hele micro-ops uitschakelen, ja dan ga je hier een hoop van merken. Dat zal denk ik niet snel gebeuren. Van wat ik begrepen heb, is de exploit alleen praktisch voor een programma dat met een ander afgeschermd programma wil communiceren. Dat kan voor het extraherenvvan informatie uit cloud servers een heel groot probleem zijn, natuurlijk, maar ik denk dat het risico voor consumenten niet realistisch groot genoeg is om er een hele grote patch aan vast te knopen.
Heb dat net gedaan, pc start sneller op, thanx voor de tip!
Wij zetten dit uit op onze CI build agents omdat die schaapjes allemaal in onze intern beheerde farm draaien en we onze ontwikkelaars erop (kunnen) vertrouwen dat ze geen Meltdown of Spectre proberen te doen d.m.v. onze C++ compiler (klinkt moeilijk) of in build omgeving scripts (dat laatste zou inderdaad wel doenbaar zijn). Wie dat toch probeert die zijn contract wordt gewoon niet verlengd en daarna bouwen we de build agent from scratch terug op he (bovendien kunnen ze toch al aan alles aan, wat er op zo'n build agent komt te staan - het is dus een nogal omslachtige methode om iets te gaan stelen).

Ik schat de performance winst hierdoor op zo'n kleine 8% (of minder). Merk wel op dat wij oa. een tmpfs (is een RAM disk, zeg maar) gebruiken om oa. de source code op te zetten zodat we tijdens het builden zo weinig mogelijk I/O overhead hebben, en dat het om C++ met Qt code gaat die de build agents bouwen. Ik geloof dat compileren van code relatief weinig syscalls in de kernel nodig heeft (behalve dan I/O) en dat het daarom minder verschil maakt (nuja, een tmpfs verandert niet de hoeveelheid syscalls, en dat is al wat er bij Meltdown/Spectre toe doet als ik het goed begrepen had).

Iets compileren hoeft maar de source code en headers in te lezen in RAM, en dan aan de slag met de CPU om te compileren. Loads die meer syscalls nodig hebben, zoals I/O, zijn bv. database queries e.d. (ik verwacht daar grotere verschillen).

[Reactie gewijzigd door freaxje op 4 mei 2021 15:18]

"It is really unclear how to solve this problem in a way that offers high performance to legacy hardware, but we have to make it work," Venkat said. "Securing the micro-op cache is an interesting line of research and one that we are considering."

https://www.sciencedaily..../2021/04/210430165903.htm
Bestaande patches helpen niet, maar de exploits zijn moeilijk uit te buiten.
Dit hoor ik iedere keer bij dit type kwetsbaarheid. Zijn er voor de vorige smaken Spectre & Meltdown ooit werkbare, makkelijk in te zetten, grootschalige toepasbare exploits uitgekomen? Ik heb een aantal PoC’s voorbij zien komen, maar heb nergens een verhaal voorbij zien komen met echte grootschalige impact. Het lijken vooral interessante onderzoeken te zijn die, terecht, wijzen op kwetsbaarheden die in toekomstige chips voorkomen moeten worden. De paniek die destijds bij de eerste smaak van Spectre & Meltdown is inmiddels ver te zoeken.
De paniek was omdat enerzijds alles geimpacteerd was, Windows, Linux, Apple, het maakte niet uit maar anderzijds ook dat een daadwerkelijke aanval in the wild bijna niet te detecteren valt.

Mogelijks was de reactie overroepen maar als je een mogelijks probleem tijdig kortsluit krijg je altijd dit soort reactie, zo erg was het nu toch niet?

Beeld je in dat we na de meerdere waarschuwingen ons deftig voorbereid hadden mocht zoiets als SARS uitbreken en dat de antivirale middelen klaar hadden liggen, dan was Corona 2 keer niets geweest en was de reactie nu, al die moeite, al dat belastingsgeld en dat voor een paar Chinezen die ziek zijn geworden, we hadden dat geld veel beter kunnen gebruiken.

En ja we waren gewaarschuwd, HIV alleen al zit aan 38 miljoen doden en is in 1920 overgesprongen op de mens om pas in 1980 door te breken als killer, 100 jaar verder en we hebben het nog altijd niet onder controle. En zo waren er wel nog een paar waarschuwingen die we genegeerd hebben.
Ik snap dat je hier de preventie paradox aanhaalt, maar dat was niet echt mijn punt. Ik was benieuwd of er daadwerkelijke exploits uit waren gekomen waar organisaties last van hebben gehad (grote infectiehaarden/ hoge besmettingsaantallen in jouw analogie).

Je moet inderdaad wel gewoon blijven patchen (vaccineren in jouw analogie) en onderzoek blijven doen om nieuwe smaken te vinden (varianten in jouw analogie).

[Reactie gewijzigd door Muncher op 3 mei 2021 14:45]

Binnen de analogie zou ik er vanuit gaan dat er gemene en serieuze lokale uitbraken zijn en dat er weinig zicht is op hoeveel dit precies gebeurd omdat de mutatie (payload, buiten de analogie) enkel bekend is en er weinig bekend is over de ziekte zelf~.

Iets anders gezegd: We weten veel over wat er hier ziek maakt en we weten weinig over hoe de ziekte zich verspreid.

Benieuwd naar reacties (buiten de analogie) O-)
De eerste ronde patches waren tegen problemen die daadwerkelijk veel impact hadden, denk aan encryptiesleutels stelen door malafide Javascript (moet wel even draaien, maar mensen laten nog wel eens websites op de achtergrond open). Daartegen zijn niet alleen de kernels van ieder besturingssysteem beschermd, er zijn ook microcodeupdates (die met software worden ingeladen) uitgekomen die de hardware verder beveiligen én alle browsers zijn gepatcht om zo'n exploit praktisch onmogelijk te maken zonder een tweede exploit. De reden dat we er niks over hebben gehoord is dat iedereen als de donder is gaan patchen toen er patches waren, een half jaar nadat het patchwerk begonnen was.

Voor consumenten zijn deze exploits nu van minimale impact. Consumenten draaien weinig code die derden zomaar kunnen injecteren die per se moet worden afgeschermd van de kernel, op Windows zijn er veel makkelijkere manieren om zoiets voor elkaar te krijgen. Voor cloudproviders zijn dit soort dingen een regelrechte ramp, want hun hele business is gebouwd op het snel, betrouwbaar en veilig draaien van andermans geïsoleerde code, de exacte combinatie van factoren die waar zo'n aanval perfect voor is.

Er zijn diverse papers geschreven over hoe je met wat trucs het voor elkaar kan krijgen om bij Amazon, Azure en Gcloud een VPS op dezelfde fysieke machine als een bepaald doelwit te draaien. Vanaf daar heb je dagen, weken, of maanden om de exploit zijn werk te laten doen. Langzaam maar zeker de SSH key en de root password uit memory exfilteren, dan in een keer inloggen, een bedrijf ransomwaren of afpersen, en je hebt genoeg verdiend om een jaar luxe te leven als je de politie weet te ontwijken.

De exploits zijn een gevaar voor journalisten, activisten, bedrijven in de cloud en de cloudproviders zelf. Als je daar niet onder valt, hoef je je doorgaans niet zo druk te maken over kleinere exploits als deze.
Goede uitleg, dank je!
Zijn dit soort hardware foutjes in een processors in de toekomst volledig te voor komen ?
Als je weet wat fout kan gaan kan je alles voorkomen.... Oftewel: nee. Deze fouten zullen niet meer optreden, maar er zullen ongetwijfeld weer andere dingen fout gaan.
uiteindelijk zal je altijd ergens een grens moeten trekken tussen wat veilig en bruikbaar is. schermen zijn ook inherent onveilig, want daar is zomaar info van af te lezen (al dan niet onder een bepaalde kijkhoek) :+
Ik vraag me af of de cpu's zonder SMT of HT dit probleem hebben.
Ik heb namelijk de 9700K... alleen 8 cores en geen HT of SMT
Betekent dit dan heel simpel dat ik safe ben?
Ik voel het al weer aankomen patches dat zoveel CPU kracht gaat vragen dat je liever het risico wilt nemen.

Ik heb op mijn oude computers al deze patches uitgeschakeld en gelukkig nog nooit problemen gehad. Nu moet is toegeven dat deze machines met Linux draaien en dat is veel minder gevoelig voor deze troep. Van deze computers heb ik ook nog een back-up.

De vraag die ik nog steeds stel, waarom word hier internationaal niet grootschalig tegen opgetreden, die gasten laten altijd sporen achten, tijd voor een grote groep digitale detectives.

Die gasten die hier achter zitten oppakken en jaren da bak in. Dit geld vooral voor die gasten die achter die ransomware aanvallen zitten.
Zolang je winst maakt met een simpel mailtje naar bol.com maak ik me hierover geen zorgen.
https://tweakers.net/nieu...over-naar-oplichters.html

[Reactie gewijzigd door Sic op 4 mei 2021 14:53]

Op dit item kan niet meer gereageerd worden.

Tweakers maakt gebruik van cookies

Tweakers plaatst functionele en analytische cookies voor het functioneren van de website en het verbeteren van de website-ervaring. Deze cookies zijn noodzakelijk. Om op Tweakers relevantere advertenties te tonen en om ingesloten content van derden te tonen (bijvoorbeeld video's), vragen we je toestemming. Via ingesloten content kunnen derde partijen diensten leveren en verbeteren, bezoekersstatistieken bijhouden, gepersonaliseerde content tonen, gerichte advertenties tonen en gebruikersprofielen opbouwen. Hiervoor worden apparaatgegevens, IP-adres, geolocatie en surfgedrag vastgelegd.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Toestemming beheren

Hieronder kun je per doeleinde of partij toestemming geven of intrekken. Meer informatie vind je in ons cookiebeleid.

Functioneel en analytisch

Deze cookies zijn noodzakelijk voor het functioneren van de website en het verbeteren van de website-ervaring. Klik op het informatie-icoon voor meer informatie. Meer details

janee

    Relevantere advertenties

    Dit beperkt het aantal keer dat dezelfde advertentie getoond wordt (frequency capping) en maakt het mogelijk om binnen Tweakers contextuele advertenties te tonen op basis van pagina's die je hebt bezocht. Meer details

    Tweakers genereert een willekeurige unieke code als identifier. Deze data wordt niet gedeeld met adverteerders of andere derde partijen en je kunt niet buiten Tweakers gevolgd worden. Indien je bent ingelogd, wordt deze identifier gekoppeld aan je account. Indien je niet bent ingelogd, wordt deze identifier gekoppeld aan je sessie die maximaal 4 maanden actief blijft. Je kunt deze toestemming te allen tijde intrekken.

    Ingesloten content van derden

    Deze cookies kunnen door derde partijen geplaatst worden via ingesloten content. Klik op het informatie-icoon voor meer informatie over de verwerkingsdoeleinden. Meer details

    janee