Intel wil alle Meltdown- en Spectre-patches voor eind januari uitbrengen

Intel heeft op de CES bekendgemaakt dat het al zijn Meltdown- en Spectre-patches voor het einde van deze maand wil uitbrengen voor cpu's van maximaal vijf jaar oud. Zoals de chipfabrikant eerder al bekend had gemaakt, krijgen 90 procent van die processors deze week nog patches.

Intel-ceo Brian Krzanich voegde daaraan toe dat de gevolgen van de patches 'zeer afhankelijk zijn van de uit te voeren workload', schrijft Engadget naar aanleiding van de presentatie. Daarmee refereerde hij aan de prestatievermindering die door de patches kan optreden. Hij raadde mensen verder aan om patches van besturingssystemen en systeemfabrikanten uit te blijven voeren en herhaalde het standpunt dat Intel niet op de hoogte is van misbruik van de gerelateerde lekken.

Naar aanleiding van de bekendmaking van Meltdown en Spectre hebben veel partijen updates uitgebracht. Apple kwam maandag met aanvullende patches in de vorm van iOS 11.2.2, een aanvullende update voor macOS 10.13.2 en Safari 11.0.2 voor de Sierra- en El Capitan-versies van zijn desktopbesturingssysteem.

Naar aanleiding van de patches van Microsoft meldden verschillende gebruikers van oudere AMD-processors in het weekend dat de updates het gevolg hadden dat hun systemen niet meer wilden opstarten. Microsoft is inmiddels van de problemen op de hoogte en heeft updatepagina's van informatie voorzien, zoals KB4056894 en KB4056892. Het bedrijf heeft updates naar problematische AMD-systemen op pauze gezet.

Reacties (178)

[Orama]

Is er een lijst met processen die onder die 90% vallen?
Mijn pc is 4/5 jaar oud en mijn processor is nieuw gekocht, maar die was al ff op de markt. (i7 2600K)

[Skating_vince]

Ik geloof er geen klap van dat 90% van de CPU's in omloop jonger zijn dan 4/5 jaar. Alsof mensen zo vaak een nieuwe PC kopen. Er is juist steeds in het nieuws dat de PC markt is ingestort. Bijna iedereen (geen gamers of IT'ers) die ik ken heeft laptops of pc's met een CPU van meer dan 5 jaar oud...

Hopelijk ziet Intel dit in en komen er patches tot verder terug. Ze zeggen zelf overigens dat 90% deze week een patch ontvangen. Hopelijk volgt de rest daarna alsnog!

[Vlizzjeffrey]

Inderdaad, de laatste 5 jaar zijn cpu's nauwlijks sneller geworden, dus voor weinig mensen reden voor een upgrade. het lijkt mij juist eerder het geval dat 90% van de cpu's ouder zijn dan 4/5 jaar, deze onzin verkondigen ze alleen maar om het minder erg te laten lijken.

[Nycrea]

Je begrijpt het verkeerd, zoals @dasiro ook zegt, ze bedoelen 90% van de modellen die uberhaupt patches krijgen, namelijk de processoren tot 5 jaar oud.

[morten]

"90 percent of recent processors affected by Meltdown/Spectre will see fixes this week"

90 procent van alle recente processors die getroffen zijn door Meltdown/Spectre zullen deze week een fix krijgen. Daarmee is de tekst een klein beetje anders dan "die uberhaupt een patch krijgen"

Zoals Cloud al aangeeft, kan de rest ook een patch krijgen, maar wat Intel doet is gewoon prioriteiten stellen. De meest actuele en daarmee mogelijk meest in gebruik zijnde chips krijgen eerst een patch.
Daarmee wordt niet gesteld dat 90 procent van de cpu's 4/5 jaar zijn.

[Skating_vince]

Ah, nog erger eigenlijk dus . De rest krijgt niet eens een update..

[Cloud]

Dat klopt volgens mij niet. De rest krijgt niet deze week een update, maar later dacht ik. Ik hoorde op de radio dat hij aangegeven had dat het voor de processoren die niet onder die 90% van de afgelopen 5 jaar vallen, de bedoeling is dat deze voor eind januari alsnog ook een patch krijgen.

Zoals het hier op Tweakers staat is het echter anders verwoord en lijken ze alleen processoren van maximaal 5 jaar oud te fixen, waarvan 90% in deze week. Ik vraag me af wat nu de waarheid is.

[Reactie gewijzigd door Cloud op 30 juli 2024 19:21]

[Terrestrial]

ben ik nu de enige die zich totaal niet druk maakt over deze lekken? Of je moet een publieke virtuele cloud omgeving aanbieden maar anders loop je eigenlijk nauwelijks tot geen risico, er zijn wel ergere dingen te verzinnen en die worden betiteld als standaard windows functionaliteit.

Waar ik me meer druk over maak is de achteruitgang in performance, als ik lees dat sommige cpu's tot 30% trager worden dan laat ze die patches maar houden zeker aangezien deze lekken voor 99,8% niet relevant zijn.

[Cloud]

Net als @Alucard maak ik me niet zo'n zorgen om performanceverlies. Tenzij je met heel dikke I/O bezig bent zal het wel los lopen. Cloud instanties echter, daar zul je er sneller last van kunnen krijgen want je met uiteraard niet de enige op die 'machine'. En doorgaans neem je zo'n virtualisatiedienst voor de schaalbaarheid en flinke kracht.

Puur speculatie:
Je zou bijna verwachten dat na de patch voor deze virtualisatiediensten, de prijzen die men hanteert bij een bepaalde garantie voor een bepaalde snelheid/workload, omhoog zouden kunnen gaan vanwege extra hardware vereisten. Omdat ze anders hun garanties m.b.t. snelheid niet meer waar kunnen maken. Of al dat soort klanten moeten dat performanceverlies ook accepteren.

Wat betreft de risico's:
Het feit dat één van de twee relatief eenvoudig met javascript in een enkele pagina gedaan kan worden vind ik wel verontrustend. Een aanval te maken die daadwerkelijk 'nuttig' resultaat oplevert lijkt het me al wat lastiger. Dat is vrij bewerkelijk maar het is wel degelijk te doen zonder verdere voorwaarden. Zolang de enige voorwaarde "javascript kunnen draaien" is - wat vrijwel elke browser gewoon doet - is er toch wel een aanmerkelijk risico. Als je dat vergelijkt met bijvoorbeeld MitM kwetsbaarheden waar iedereen ook van flipt, dan is dit een stuk eenvoudiger te doen dan de meeste MitM aanvallen.

Ik hoop dus wel degelijk op spoedige patches van zowel de microcode als de browsers.

[CamelKnight]

Wat betreft jouw speculatie: dat zou niet mogen. De klant zou dan de dupe worden van faalacties van Intel/AMD (waarvan ik me zomaar voor kan stellen dat die exploits er bewust ingestopt zijn voor b.v. de NSA). Als klant van een cloudleverancier zou ik verwachten, zelfs eisen, dat zij hun performance drop neerleggen bij Intel/AMD. Een verhoging van mijn abo zou ik niet accepteren; genoeg andere aanbieders op de markt.

[Cloud]

Hoewel ik je mening deel dat doorrekenen aan eindgebruikers niet zou mogen, zou ik niet absoluut zo ver willen gaan als 'exploits' zijn er bewust ingestopt t.b.v. de NSA. Om dat zonder enkele argumentatie te denken is echt volstrekt onzinnig, al is het wel populair tegenwoordig.

Je zou het bestaan nalatigheid kunnen noemen maar zelfs dat vind ik erg ver gaan. Zelfs als ze het al wisten, is de manier waarop je dit zou moeten misbruiken echt niet zo klip en klaar. Ik kan me best voorstellen dat ze dit voor de potentiële performancewinst hebben laten bestaan, als er toch geen manier bestond om het te misbruiken. Het misbruik leest immers niet eens letterlijk het beschermde geheugen maar het bestaan van informatie wordt afgeleid o.b.v. timings. Dat is verre van een overduidelijk lek. Wat mij betreft dus ook flink applaus voor Google Zero dat zij dit wel hebben weten te vinden en dat ze zelfs een manier gevonden hebben om dit te misbruiken. Een enorme prestatie in mijn ogen.

Het laten verrekenen met Intel/AMD klinkt overigens stukje realistischer

[Terrestrial]

Je kunt Intel/AMD net zo veel de schuld geven als je wilt maar als jij denkt dat dit de laatste grote kwestbaarheid is in CPU's think again... Er zitten er nog honderen zo niet duizenden in en sommige zullen bekend worden en sommige ook niet. (wellicht door bijv de NSA of andere belanghebbende partijen)

Op zich zijn dit soort kwetsbaarheden geen ramp als het OS maar een stuk veiliger was en daar wringt de schoen.

[Verwijderd]

Moest ik de NSA zijn en wilde ik een backdoor op dat niveau van de CPU, dan dwong ik Intel om een microcode blob te laten signen die ik op m'n target zijn Windows PC laat installeren.

Deze bug is eigenlijk vrij omslachtig. Ik denk eerder dat we met een echte fuckup zitten. Een bug dus.

[PulsatingQuasar]

Het zijn niet alleen faal acties van Intel en AMD. Ook ARM en de Power procesoren zijn getroffen. Oftewel, alles. En dat komt doordat alle bedrijven 15 jaar lang allemaal hun processoren volgens een bepaalde architectuur hebben gemaakt. Deze materie is zo complex dat je niet zomaar even bedenkt wat er mis kan gaan. Dus ik ben niet van mening dat zij echt aansprakelijk zijn. Er zitten constant bugs in processoren die men al jarenlang software matig patcht( of via de BIOS of via het OS) alleen is de Spectre bug zo fundamenteel dat die niet alleen maar software matig is te patchen.

En als we het over prijs verhogingen hebben. Microsoft doet niet anders dan de prijs verhogen van Azure zonder uitleg waarom, dan hebben ze er nu een keer een goede reden voor. En als de impact toch zwaar is dan zal de prijs van alle cloud toko's omhoog gaan. Je trekt dan toch wel aan het kortste eind.

[cnieuweboer]

Kun je een voorbeeld geven van standaard windows functionaliteit, welke ergere risico's geeft dan een exploit die in javascript (dus elke willekeurige website) uitgevoerd kan worden, en complete toegang kan geven to zo'n beetje alles wat in je ram geheugen is opgeslagen (dus ook wachtwoorden ed.).

Over de performance impact maak ik me dan weer niet heel druk, die 30% verhalen gaan over heel specifieke workloads die een normale thuisgebruiker niet vaak tegenkomt.

[Terrestrial]

een javascript exploit heeft hier helemaal niks mee te maken want die kun je toch wel blokkeren zonder dat lek te fixen.

[cnieuweboer]

Meltdown exploit is in Javascript uit te voeren, het proof of concept is in Javascript gemaakt. Javascript is dus wel degelijk relevant.

Alle Javascript blokkeren die misbruik van meltdown probeert te maken, maar de kwetsbaarheid zelf niet oplossen, lijkt mij niet echt ideaal. Daarbij is Javascript alleen maar het makkelijkst te misbruiken voorbeeld.

[Armin]

beben ik nu de enige die zich totaal niet druk maakt over deze lekken? Of je moet een publieke virtuele cloud omgeving aanbieden maar anders loop je eigenlijk nauwelijks tot geen risico, er zijn wel ergere dingen te verzinnen en die worden betiteld als standaard windows functionaliteit.

Betreft Spectre heb je best gelijk, maar niet betreft Meltdown. Meltdown kan gebruikt worden om willekeurige kernel-memory te lezen. Dat betekent dat het makkelijk in een twee-staps aanval; gebruikt kan worden. Eén lek om uit de (browser) sandbox te komen, en dan is het raak en is alle sin kernel-space kwetsbaar. Ofwel bestaande exploits zoals die aan de lopende band gevonden worden, kunnen opeens zeer ernstig worden omdat ze niet langer tot user-space beperkt zijn.

De "paniek" is dus vooral om Meltdown, en niet Spectre. (Dat wil niet zeggen dat je Spectre gewoon ongepatched moet laten gaan.)

[Armin]

Dat klopt volgens mij niet. De rest krijgt niet deze week een update, maar later dacht ik. Ik hoorde op de radio dat hij aangegeven had dat het voor de processoren die niet onder die 90% van de afgelopen 5 jaar vallen, de bedoeling is dat deze voor eind januari alsnog ook een patch krijgen.

En volgens mij klopt zelfs dat niet.

Ik denk dat met meer is "er wordt een patch beschikbaar gesteld". Maar omdat in de praktijk micro-code updates via de BIOS/UEFI gaan, is het maar de vraag hoeveel systemen daarwerkelijk geupdate worden. Vele mensen updaten nooit de BIOS/UEFI.

Nu kunnen OS makers zelf ook de micro-code updaten, maar doen dat doorgaans niet omdat er kans is op imcompabiliteit met andere componenten in de BIOS/UEFI.

[Cloud]

Klopt op zich hoor. Goed punt wel, dat is niet de dagelijkse praktijk m.b.t. OS bouwers en microcode updates.

Ik heb er echter één opmerking bij; dit is een probleem van zo'n aard, dat ik vermoed dat OS bouwers deze microcode updates wel willen verspreiden voor de cpu fabrikanten. Je weet het uiteraard niet zeker maar dit is wel wat belangrijker dan een performance of simpele compatibiliteitsupdate natuurlijk En dat is wat gebruikelijk verspreid wordt middels die microcode updates.

[Verwijderd]

Heel goed.. En zo stimuleren ze dat het gros van de mensen / bedrijven een nieuwe pc / servers gaat kopen. Doet me een beetje aan het befaamde millennium bug denken. hoeveel geld er toen opnieuw in de it wereld is gepompt. en waarvoor. 1 januari 2000 liep gewoon nog alles. Dit is weer zoon op ten top markt manipulatie.

[BvdW1978]

Besef je dat alles op 1 januari 2000 misschien nog liep juist omdát er zoveel werk aan gedaan is? Ik weet wel dat als ik destijds op mijn handen was blijven zitten, er best een paar zaken op een niet zo fijne manier waren omgevallen in het bedrijf waar ik toen werkte.

[bilgy_no1]

Net als sommige mensen nu zeggen dat het gat in de ozonlaag is opgelost, dus waar was alle drukte nou om???

[rvl1980]

Ehhh wij hebben anders best wel wat y2k bugs uit software gehaald die de hele bedrijfsvoering overhoop hadden gegooid...

[dasiro]

waarschijnlijk 90% van de modellen. Vroeger had je 2 of 3 snelheden per generatie, nu heb je voor zowat elk mogelijk denkbaar segment een model of 6

[Verwijderd]

Alsof mensen zo vaak een nieuwe PC kopen. Er is juist steeds in het nieuws dat de PC markt is ingestort.

Nieuwe PC kopen doen veel mensen inderdaad niet heel vaak meer, maar ik durf zo te wedden dat het nog steeds gebeurd in een tijdsspanne van 4-5 jaar. Een paar jaar geleden was het nog zo dat je 1-2 jaar met een PC deed voordat je of stevig kon gaan updaten, of (vanwege nieuwe sockets, ddr versies, etc etc) opnieuw kon beginnen, tegenwoordig is het gewoon minder nodig, CPU's en GPU's van de laatste tijd zijn al lang en breed snel genoeg voor de doorsnee gebruiker, sockets blijven langer relevant, ddr is minder hard aan het vernieuwen, etc.

En uiteindelijk heeft een doorsnee gebruiker (buiten gamen) voorlopig nou eenmaal genoeg aan prestaties van een paar jaar geleden, voor faceboeken heb je geen octacore nodig

Komt nu de clue van het hele verhaal, verreweg de grootste afzetmarkt voor desktop machines is gamers, en die willen elkaar toch 'stiekem' steeds weer aftroeven met de nieuwste hardware, evenals hun vrienden die op console gamen (PC Master Race verhaal) of het echt 90% is weet ik niet en lijkt mij ook een beetje veel, maar ik durf wel te wedden dat 75% van de gebruikte pc's een cpu uit de laatste 5 jaar heeft.

[freedzed6]

ach maakt het uit, kans dat het misbruikt wordt is nihil. Ga er verder maar vanuit dat versie 2.0 al LANG uit is en hier heeft iedereen pas over 10 jaar een update. Kan de geheime dienst nog lekker even door hacken.

[fast-server]

Wanneer een processor precies geïntroduceerd is is op te zoeken op Intel Ark.
Jouw 2600K is 7 jaar geleden geïntroduceerd, als het maximaal 5 jaar is dan komt het neer dat alleen de ix-4xxx series en nieuwer binnenkort een patch krijgen.

[Blokker_1999]

Zal niet zozeer introductie datum zijn, mag hopen dat ze die 5 jaar toch echt op einde van de productie nemen. En dan val je nog net in de periode van 5 jaar.

[fast-server]

“Intel has already issued updates for the majority of processor products introduced within the past five years,” says an Intel spokesperson. “By the end of next week, Intel expects to have issued updates for more than 90 percent of processor products introduced within the past five years.”

[aadje93]

Een cpu die 3 jaar in productie is is op het einde niet ineens totaal anders qua architectuur.....

[TKroon]

Dat zou niet mooi zijn. Werk nog altijd met volle tevredenheid op een 2011 Mac Mini, met SSD en 16 GB RAM. Ik was voorlopig niet van plan om te upgraden. Hopelijk werkt Apple dan wel aan een fix als we het van Intel niet moeten hebben.

[3dfx]

Ik denk dat die mogelijk net buiten de boot valt:
CPU is namelijk geïntroduceerd in 1e kwartaal van 2011 (en van de markt gehaald in het eerste kwartaal van 2013).
Zie dit linkje.

[iceheart]

Klopt op zich. Keerzijde: arch van Sandy bridge is niet heel erg anders dan Ivy bridge, zelfde moederborden ook, en IB ( de core i*-3*** reeks dus, voor oorspr. vraagsteller) valt wel binnen die periode. Lijkt me contraproductief om dan een maand of twee later voor dezelfde mobos nog een update uit te moeten brengen dus ik gok (en hoop, twee SB cpu's hier ) een beetje dat Intel SB toch wel meeneemt.

[CH4OS]

Het gaat terug naar processoren die Intel in 1995 begon te verkopen. Dat zijn dus de Pentiums. De i7 2600 is uitgebracht in 2013, dus die krijgt nog net de patch. Alles ouder dan dat dus niet meer.

[MiesvanderLippe]

Gelukkig weten ze er pas een half jaar vanaf. Klinkt een beetje als de manier waarop ik huiswerk maakte maar dan met een paar miljard risico. Het lijkt me niet meer dan terecht even teleurgesteld te zijn in Intel als mijn lerares Frans was in mij 😉

[CMD-Snake]

Gelukkig weten ze er pas een half jaar vanaf. Klinkt een beetje als de manier waarop ik huiswerk maakte maar dan met een paar miljard risico. Het lijkt me niet meer dan terecht even teleurgesteld te zijn in Intel als mijn lerares Frans was in mij

Ik denk dat jouw huiswerk Frans een stuk eenvoudiger is dan een CPU ontwerpen. Dat er soms flink wat tijd nodig is om een beveiligingsprobleem te analyseren is zo vreemd nog niet. Een goede analyse is nodig voordat je een fix kan bedenken en dan zal het ook genoeg tijd nemen om die fix te testen dat die weer geen onbedoelde effecten heeft.

Het stilhouden van grote problemen is ook vaak ter bescherming van het publiek, zodra een exploit bekend wordt zie je het misbruik ervan zeer snel stijgen.

[totaalgeenhard]

Probleem is dat patch probleem niet fixed.

Als beste man had gezegd dat na dit jaar geen CPU zal worden verkocht waar dit probleem inzit had hij iets nuttigs gezegd.

Maar OS vertrouwen om een hardware probleem op te lossen is als dubbelglas ipv enkelglas om weerbaarheid tegen inbrekers te vergroten....


Om Linus te herhalen, ze hebben nooit hun cpu's onderzocht.. en met IME ze hebben nooit huj chipsets onderzocht....

https://www.theregister.c...he_registers_annotations/

[fre0n]

en erger nog, ze blijven de probleem cpu's gewoon verkopen

[Cilph]

En dat terwijl Coffee Lake al zulke enorme leveringsproblemen heeft.

[tweaknico]

Er zijn CPU's die het probleem niet kennen....
EPIC architecturen doen per definitie niet aan Speculative Execution... Dus Itanium (en HPPA) systemen zijn Safe.
AXP (Alpha) processoren kunnen het wel, maar het is in de praktijk noot aangezet in firmware.
Met Risc systemen YMMV

(naast de antieke systemen die de huidige workload niet aankunnen).

[totaalgeenhard]

Z80 ook niet... maar op F16 na worden die nergens meer in productie gebruikt... (denk ik)

[tweaknico]

Ik weet dat er nog heel veel Itaniums en AXP's gebruikt worden.
Dat loopt in cd ~60.000 voor itaniums en vergelijkbare aantal voor AXP.
(nog steeds, het gaat dan voornamelijk om systemen waarover je in het nieuws niets wel horen)....

Besturing van kerncentrales, energiecentrales, grote databanken in health services, beurs-backoffice systemen etc., etc. Het soort van systemen dat 24*365.25 met 99.999% (of beter) uptime moet werken.

Ik meen dat F16 tegenwoordig voor een deel AXP op emulatoren op X86 draait omdat er ruimte voor een groter/beter boordkanon moest komen. (en het computer systeem daarvoor ruimte moest maken),

[Reactie gewijzigd door tweaknico op 30 juli 2024 19:21]

[Horatius]

Het is toch een beetje vreemd dat ze nu alle patches uitbrengen, dat hadden ze ook het afgelopen half jaar kunnen doen. Lijkt me sterk dat alle patches opeens in dezelfde maand klaar zijn, de een zal eenvoudiger zijn te fixen dan de ander.

Denk dat dit deels een PR stunt is van ‘kijk we werken er heel hard aan en krijgen zoveel mogelijk publiciteit door het nu uit te brengen.’

[CMD-Snake]

Het is toch een beetje vreemd dat ze nu alle patches uitbrengen, dat hadden ze ook het afgelopen half jaar kunnen doen. Lijkt me sterk dat alle patches opeens in dezelfde maand klaar zijn, de een zal eenvoudiger zijn te fixen dan de ander.

Een act van kijk eens hoe hard wij werken was ook in die tijd mogelijk. Ik denk eerder dat we nu pas fixes zien omdat het langer heeft geduurd om die te maken. Sommige patches kunnen maanden in ontwikkeling zijn voordat ze pas vrijgegeven worden.

Je ziet nu dat de patches van Windows voor Metldown/Spectre oudere AMD processoren ongelukkig treft waardoor computer niet meer kunnen starten. Dat is de reden waarom je ook de tijd moet nemen voor het maken van een patch. Stel dat zoiets op veel grotere schaal gebeurt.

[Calypso]

Op zich ben ik het helemaal met je eens, maar heb toch nog m'n twijfels dat er ook vandaag nog veel patches niet beschikbaar zijn - waar het probleem dan ligt (bij Intel, bij de OS ontwikkelaars of wie dan ook) dat laat ik even in het midden, maar het is vandaag 9 januari, de dag waarop eigenlijk het probleem wereldkundig zou zijn gemaakt.

Ubuntu heeft nog geen enkele patch beschikbaar. Vorige week werd nog gezegd dat men zich richtte op vandaag (9 januari) als release datum, maar als je nu naar de status gaat kijken dan is die "voor 1 van de 3 problemen zijn we aan het testen". Dan ben je dus gewoon laat. En of het dan komt doordat partij A partij B niks heeft laten weten maakt mij als "klant" weinig uit; het is wachten op de release van een kwaadaardige vorm van gebruik van deze lekken, en dus zorgt elke dag vertraging voor een groter risico.

[Aardedraadje]

Speculatie:

Denk meer dat het te maken heeft met het reverse engineeren van een exploit adhv de verschillen tussen systeembestanden na een patch. Door alle patches tegelijk uit te brengen, komt er niemand zonder patch te zitten terwijl er al een exploit bestaat. Ondertussen bestaat zo'n exploit al, dus kunnen getroffen partijen net zo goed vrijgeven wat ze al gepatched hebben.

[memoryeffect]

Is het niet zo dat Metldown en Spectre juist bekend zijn geworden omdat de fixes in de changelog van de linux-kernel te vinden waren? Dan is het dus niet zo gek dat ze de patches uitrollen vlak nadat de de exploits bekend zijn geworden.

[Zer0]

. Lijkt me sterk dat alle patches opeens in dezelfde maand klaar zijn, de een zal eenvoudiger zijn te fixen dan de ander.

Aangezien het op alle CPU's om dezelfde bugs gaat is het vrij logisch dat als je een oplossing voor de bug gevonden hebt de patches voor de verschillende cpu's snel achter elkaar klaar zijn.

[tweaknico]

Micro-code patchen op een CPU is toch een aanpassing van een iets andere orde dan normale software ontwikkeling. En het zullen met name de test trajecten zijn die tijd kosten. Het spul moet ook bug compatible zijn (met uitzondering van de beschreven patch).
En Speculative Execution uitzetten of heel anders implementeren...., tja dan zakt de perfomance merkbaar in.

[HADES2001]

dat is niet waar 9 januari was de algemene afgesproken datum dat alle patches zouden komen en dat alles publiekelijk naar buiten moest.
Zie ook de pagina van Ubuntu die de timeline uitlegt https://wiki.ubuntu.com/S...412-1711104300.1514903189
Alleen is de informatie vroegtijdig gelekt en schreeuwen alle nieuwssites moord en brand, de omvang van deze bug zorgt er gewoon voor dat dit tijd kost en als de informatie lek er niet was had iedereen vandaag patches en kwam er een simpel nieuwsartikel met "Bug in CPU verholpen die er al jaren in zat".

[Centauriprime]

Voor mijn laptop is er een BIOS update uitgekomen op 24 december welke de nieuwe MCU inlaadt.

https://support.hp.com/us...7357/swItemId/ob-202822-1

[DigitalExorcist]

In absolute zin zou het ontwerpen van een CPU ingewikkelder zijn dan Frans, maar vanuit het oogpunt van MiesvanderLippe als persoon wellicht niet; iederéén kent zijn (m/v) uitdagingen; een CPU ontwikkel je ook niet in je uppie maar doe je met duizenden mensen tegelijk. Een proefwerk Frans maak je in je eentje.

[Luchtbakker]

Hoe grotere mediaspectakel je er van maakt, hoe groter het risico. Of terwijl : als Intel het vanaf dag 1 het had gemeld, dan konden de gevolgen veel groter zijn voor alle partijen.

Nu heeft Intel in alle rust een Fix kunnen maken, zonder alle gedoe eromheen.

Ik vind dat Intel goed gehandeld heeft. Sommige dingen moet je gewoon niet zeggen tot het opgelost is.

[Frubelaar]

Dat is op zich juist. Maar ze hadden iedere patch afzonderlijk 'in het geheim' via Windows update kunnen verspreiden

[Isocadia]

Maar zoals vermeld heb je kans op forse prestatie vermindering door de patch. Hoe ga je zonder dat elke patch klaar is verklaren waarom een update met x% je prestaties verlaagd zonder te verklappen dat er zulke grote fouten zijn en dus de kans op misbruik van de exploit enorm te vergroten?

[fre0n]

apple krijgt voor dergelijke snelheidsvermindering een flink proces aan de broek. benieuwd of dit nu ook voor android socs gaat gebeuren

[aadje93]

Hoe wil je geheim een Windows update brengen die toevallig gelijk valt meet andere besturingssystemen?

[HADES2001]

Patch tuesday voor servers is redelijk normaal, tweede dinsdag van de maand. daar zal je niemand over horen

edit: eerste tweede sorry zat te slapen

[Reactie gewijzigd door HADES2001 op 30 juli 2024 19:21]

[Verwijderd]

Intel bepaalt niet of hun fix in een Windows Update komt. En waarom zou MS niets zeggen en de schuld op zich nemen?

“Hier is een mystery patch en oh ja je performance kan naar de klote gaan”

[wiseger]

En vervolgens vallen systemen uit, zoals bepaalde AMD modellen zodner dat de gebruiekrs wisten wat er gepatched werd. Dan kan MS ineens aansprakelijk gesteld worden, lijkt me ook niet de bedoeling. ze moeten dus wel communiceren wat ze gaan patchen voordat ze het uitrollen.

[Verwijderd]

Zoals wellicht vanavond na 1900H

[tweaknico]

Alleen is Windows niet het enige OS op Intel Chips....
Dus hoe hou je al die aanpassingen dan onder de pet, terwijl er op allerlei platforms vergelijkbare fixes moeten worden gedaan. (terwijl die CPU firmware aanpassingen best wel opvallen).

Er is niet zoiets als een "geheime update"... met name security researchers zullen alle updates uitpluizen en vervolgens zien dat CPU firmware aangepast wordt.

[Burns]

Om wat voor patches gaat dit dan? Zoals een driver, intelppm.sys?
Ik vind 5 jaar wel erg kort voor een CPU bug. Een intel i7 920 die voor mijn doel nog prima functioneert, is veel ouder.

[servicedb]

Het zijn microupdates voor processors. Deze moet je via een bios update binnenkrijgen, dus niet altijd is dit eenvoudig te patchen helaas...

[Reactie gewijzigd door servicedb op 30 juli 2024 19:21]

[The Zep Man]

Het zijn microuodates voor processors. Deze moet je via een bios update binnenmrijgen, dus niet altijd is dit eenvoudig te patchen helaas...

Nee. De BIOS bevat weliswaar micro-code en nieuwe BIOS versies bevatten mogelijk nieuwe micro-code, maar het besturingssysteem kan zelf nieuwe micro-code inladen tijdens het opstarten. Linux doet dit bijvoorbeeld, en macOS en Windows zullen dit ook wel doen. Een voorbeeld van micro-code bestanden die door Intel worden aangeboden.

Spectre en Meltdown hebben geen invloed op het opstartproces omdat er geen sprake is van gescheiden geheugenruimtes waar de grenzen van doorbroken kunnen worden. Volgens mede-tweaker Squee kan nieuwe micro-code de problemen van Spectre en Meltdown (deels) mitigeren.

[Reactie gewijzigd door The Zep Man op 30 juli 2024 19:21]

[EfBe]

Windows zullen dit ook wel doen

Nee windows doet dit niet, daarom staat in het KB artikel ook uitdrukkelijk dat er een microcode (of 'firmware' zoals ze zelf hip roepen) update nodig is van de device leverancier om het volledig te patchen. Je bent dus afhankelijk van een biosupdate. Als je met een al wat ouder moederbord zit, bv met een Z87 chipset, dan is het maar de vraag of je een biosupdate krijgt: die mobo's hebben meestal al jaren geleden hun laatste biosupdate gekregen. Ikzelf heb gigabyte gemailed vorige week hierom (zit met een ga-z87-d3h mobo) en ze konden me geen uitsluitsel geven nog of er een update kwam: ze legden de bal neer bij intel die moest over de brug komen met nieuwe microcode en dan gingen ze kijken of het wellicht mogelijk was.

[Steyn_E]

Gelukkig is het integreren van een microcode update van de UEFI meestal een koud kunstje, bovendien levert het vast publiciteit op als je als fabrikant nog 1 keer alle moederborden vanaf socket 1156 (1e generatie Core i) of zelfs 775 van een nieuw BIOS/UEFI voorziet. Al is dat eigenlijk maar een klein klusje.

[Wvdlinden1]

Hoe kom je erbij dat Windows dat niet doet? Windows voert al jaren microcode updates voor cpu's uit, gaat gewoon via Windows Update, de meeste cpu's worden vanzelf gepatched.

[EfBe]

Leg dan maar eens uit waarom er bij deze specifieke update toevalligerwijs wel een firmware/bios update nodig is? De patch die ze gemaakt hebben (met retpoline (push rax + ret)) werkt nl. maar half zonder firmware/microcode update en het zou dus veel makkelijker zijn geweest wanneer ze gewoon de firmware hadden meegeleverd (intel packt het al samen in 1 file, dus het is in theorie niet zo moeilijk).

[Wvdlinden1]

Niet in verdiept maar Microsoft en Intel hebben al heel vaak microcode updates gedaan via de Windows update. Misschien dat in dit specifieke geval een BIOS update vereist is of dat er andere redenen zijn. Maar als Linux het via een update kan fixen en Microsoft in het verleden microcode updates via de Windows update heeft doorgevoerd lijken mij andere zaken een hoofdrol te spelen in dit verhaal.

[DigitalExorcist]

Ja, ik klik op je link en krijg gelijk een .tgz file binnengeharkt. Lekker bezig ...

[The Zep Man]

De link bevat micro-code bestanden die door Intel worden aangeboden. Ik kan het niet helpen dat anderen maar raak klikken en hun browsers instellen op 1-click-start-download.

[DigitalExorcist]

Snap ik, maar volgens mij is dat op praktisch alle mobiele devices het geval

[RGAT]

Even kijken voordat je klikt helpt een hoop, zeker als je wel vaker een virus binnenharkt op deze manier

[DigitalExorcist]

Dat laatste niet gelukkig :-) maar behalve een mouseover die na een seconde of wat verraad dat het om een .tgz gaat (en geen artikel/website) zou een kleine heads-up wel fijn zijn.

[Reactie gewijzigd door DigitalExorcist op 30 juli 2024 19:21]

[Broodje_Aap]

Dus als ik het goed begrijp wordt je zowel door Windows, als een bios update "gepatched"?

[servicedb]

Om helemaal gepatched te zijn heb je helaas wel beiden nodig. Dit is de officiële aanbeveling vanuit oa SuperMicro. Als je maar één van de twee hebt dan is het probleem helaas nog steeds niet opgelost.

[Armin]

Linux doet dit bijvoorbeeld, en macOS en Windows zullen dit ook wel doen. Een voorbeeld van micro-code bestanden die door Intel worden aangeboden.

Windows kan dit ook, en doet dit bijvoorbeeld bij de Surface lijn, maar niet noodzakelijk bij 3rd party. Immers er is een kans op incompatibiliteit met andere elementen in de BIOS/EUFI software. Besef dat dat tegenwoordig ook al bijna een mini-OS is.

Dus in de praktijk is het vaak: geen BIOS-update = geen microcode-update.

[vectormatic]

die 920 wordt ook wel gepatched, maar later deze maand, lijkt me ook niet meer dan logisch dat ze het recente spul eerst doen, daarvan zijn er het meeste in actief gebruik

[D11]

Aan de hand waarvan trek je deze conclusie?

[TheAnimaL]

Het overgrote deel van server parken bestaat uit machines met recente cpu's, denk aan de Amazon's, Google's, Microsoft's en andere groten op deze aard kloot. Vooral hun compute platforms maken gebruik van technieken ( containers ) welke extra 'eng' zijn icm Meltdown en Spectre. Je wilt niet weten hoeveel bedrijven en overheidsinstellingen afhankelijk zijn van aws, gcp en azure.

Overigens zullen patches voor oudere processoren later volgen, zoals staat geschreven in de tekst.

[Master FX]

i7 920. Precies ook de CPU in mijn nog prima functionerende desktop. Geen krachtpatser meer, maar kan er nog mee uit de voeten. Toch maar upgraden dan of is het een aanvaardbaar risico...

[JohanNL]

Ik denk zelf dat het wel meevalt qua risico voor een gewone thuis desktop pc, maar wil je toch van dit risico af zou ik niet upgraden naar de huidige nieuwste cpu's maar wachten totdat er cpu's uitkomen die dit probleem in eerste instantie helemaal niet hebben.

[Steyn_E]

Voorlopig heeft upgraden geen zin (of je moet overstappen op Ryzen), Coffee Lake is net zo kwetsbaar als elke andere Intel processor. Ik ga er in ieder geval vanuit dat jouw generatie (iets later dan deze update) ook gewoon de softwarematige patches krijgt. De hardwarematige aanpassing kan hoe dan ook nog niet klaar zijn voordat er een nieuwe generatie geïntroduceerd wordt. Mogelijk zelfs pas bij de generatie daarna.

[Master FX]

Ryzen is volgens mij ook niet veilig:
Het artikel van spectreattack.com stelt het volgende:

"We have empirically verified the vulnerability
of several Intel processors to Spectre attacks, including
Ivy Bridge, Haswell and Skylake based processors.
We have also verified the attack’s applicability
to AMD Ryzen CPUs. Finally, we have also successfully
mounted Spectre attacks on several Samsung and
Qualcomm processors (which use an ARM architecture)
found in popular mobile phones."

[NBK]

Als je nu een nieuwe CPU in je systeem stopt zit daar nog steeds deze bug in. Je krijgt dus een snellere nieuwe CPU die na de patch hopelijk nog sneller is dan je oude maar niemand kan iets garanderen.
Ik denk dat ik wacht met patchen tot ik ergens lees dat er actieve exploids op de markt verschijnen. En dat ik ASAP een nieuw systeem ga kopen met een CPU waar deze bug niet in zit.

P.S.
Even voor de duidelijkheid. Mijn systeem is al oud en ik was al aan het kijken voor wat nieuws. Ik ga dus niet wat nieuws kopen vanwege deze bug maar ik stel het kopen van een nieuw systeem uit tot de bug is gefixed.

edit;
Groot probleem is wel dat ik voor dit oude systeem eigenlijk ook nog een doel had. Mijn Windows 10 licentie zit immers toch gekoppeld aan dit moederbord dus ik kon er redelijk eenvoudig een nieuwe bestemming aan geven. Dat gaat nu niet helemaal meer op.

[Reactie gewijzigd door NBK op 30 juli 2024 19:21]

[Master FX]

Er zouden volgens de verschillende partijen geen merkbare verschillen mogen optreden.

[StelioKontos]

Je stelt het kopen 1 tot een paar jaar uit? VOor een bug die geen performance impact heeft voor bijvoorbeeld gamen, en max een paar procent voor andere workloads?

[NBK]

Microsoft is helemaal niet zo positief over de impact van deze patches en geeft voor servers zelfs het advies om een afweging te maken tussen de kans dat er onveilige code op de server komt te draaien en het verlies in performance. Nu ook op tweakers

Ze weten al een half jaar van het bestaan van de bug en bovendien lijden ze momenteel aardig imago schade dus ik verwacht niet dat het meer dan een jaar gaat duren voor deze bug is opgelost.
Bovendien game ik niet en draai veel virtuele machines. Als er iets is waar je geen geheugen lekken bij wil hebben is het een virtuele machine.
Gelukkig draait hier bijna alles op AMD dus alleen last van Spectre. En dus PC's die mogelijk niet meer booten na een Windows update...

[Reactie gewijzigd door NBK op 30 juli 2024 19:21]

[Cilph]

Ik dacht dat Meltdown juist niet te fixen was met microcode?

[mindcrash]

De Microcode update is niet bedoelt voor Meltdown maar voor Spectre. Intel schijnt een manier te hebben gevonden om de branch predictor (waar de bug in zit) uit te schakelen. Dat gebeurt dus met die microcode update.

Echter de branch predictor zorgt bij bepaalde workloads voor een behoorlijke performance winst en die valt dus na de microcode update volledig weg.

Dus nogmaals:

Meltdown heeft te maken met een issue in de wijze waarop geheugen allocatie plaatsvind en iets waar AMD processoren volgens AMD niet vatbaar voor zijn, omdat zij een veiligere wijze van allocatie toepassen dan Intel. Meltdown wordt via een OS update aangepakt (bijvoorbeeld de onlangs gepubliceerde Windows update en de nieuwe KPTI feature in de Linux kernel codebase).

Spectre heeft te maken met een issue in branch prediction en AMD heeft aangegeven dat AMD processoren hierbij wel vatbaar zijn voor tenminste een van de twee beschreven variaties van de Spectre hack, welke consequenties dit heeft voor AMD processoren is op dit moment nog niet echt duidelijk. Bij Intel processoren wordt Spectre via bovengenoemde Microcode update aangepakt.

[Reactie gewijzigd door mindcrash op 30 juli 2024 19:21]

[tweaknico]

Meltdown heeft te maken met dat in Intel CPU's de security evaluatie pas in retirement fase van een instructie (laatste stap) wordt gedaan. Dus een usermode proces kan gewoon de Kernel memory lezen als speculative execution pad, als het achteraf niet mag (of een ander pad bewandeld wordt) is de data niet direct bereikbaar, maar dit past de TLB's, caches etc. aan. Aan de hand daarvan kan er meer data bepaald worden.

Het wordt hier goed beschreven: https://xenbits.xen.org/xsa/advisory-254.html
(XEN advisory). als SP3, "Rogue data access"

[Cilph]

Sorry ze gaan de branch predictor in zn geheel uitschakelen? Dat is een absurde impact!

[mindcrash]

Waarom denk je dat Brian Krzanich al zijn niet contractueel gebonden Intel opties heeft verkocht?

[Cilph]

De dag voordat Intel kwam met een statement stuurde ik dit al rond. Zal wel te maken hebben met belasting, maar ik liet mensen wel weten dat ze beter hun Intel aandelen konden verkopen

[wjvds]

Bron van het uitschakelen van branch prediction? Branch prediction is wel een heel fundamentele eigenschap van moderne CPUs en ik geloof nooit dat ze dat helemaal uit gaan zetten.

[mindcrash]

Heb overigens net gelezen dat AMD pas een Microcode update voor Ryzen CPU's heeft uitgebracht die branch jump buffers uitschakeld (de tweede Spectre variant).

Dat terzijde:

Voor Intel CPU's is het echter noodzakelijk om in de predictor zowel branching (voor de eerste Spectre variant) als branch jump buffers (voor de tweede Spectre variant) uit te schakelen.

Echter: Aangezien het schijnbaar niet zo heel simpel is om te rotzooien met de branch predictor op Intel CPUs had een engineer gezien de scope van de issues op HN aangegeven dat ze bij Intel een hack hadden gevonden om branch prediction op de CPUs geheel uit te schakelen en daarop ook besloten hebben Spectre via die weg op te lossen en dat via een microcode update als "fix" aan te bieden.

Zou wel het enorme performanceverlies op Intel CPUs na de microcode update verklaren.

[Reactie gewijzigd door mindcrash op 30 juli 2024 19:21]

[wjvds]

Nogmaals: bron? En het enorme performanceverlies op Intel CPUs? Bij mijn weten is er alleen voor Meltdown een klein performanceverlies bij system calls?

[mindcrash]

Bron? Als je de paper over Spectre leest kun je zelf ook wel concluderen dat de oplossing as-is het hardwarematig geheel (of gedeeltelijk - wat AMD dus schijnbaar kan in Ryzen) van de branch predictor in huidige CPUs is.

En Intel's branch predictor schijnt dus - lees wel: schijnt - een stuk inflexibeler te zijn qua ontwerp te zijn dan die van AMD. Logisch, want zo'n branch predictor is technisch gezien niet zo'n heel eenvoudig stukje techniek. Dus vandaar dat die hardware engineer toen al concludeerde dat Intel's enige -veilige- optie feitelijk is om het hele ding uit te schakelen.

[Reactie gewijzigd door mindcrash op 30 juli 2024 19:21]

[wjvds]

Ik ben het niet met je oneens dat de branch predictor de zwakke plek voor Spectre is, maar ik geloof simpelweg niet dat ze zoveel performance willen opofferen voor een redelijk beperkt veiligheidsprobleem (alleen geheugen binnen dezelfde applicatie kunnen uitlezen in het ergste geval maar meestal niet te exploiteren). Daarom zou ik graag een bron van Intel willen zien waarin ze aangeven dat dit daadwerkelijk hun "oplossing" is.

[xorpd]

Geen bron op zulke boude statements? Volgens mij ben jij een paniekzaaier.

[mindcrash]

Dank je. Wees jij maar in ieder geval blij met je Zen processor waarin maar slechts een klein deel van de branch predictor wordt aangepast (waardoor de performance hit een stuk kleiner is):

Add microcode_amd_fam17h.bin (bsc#1068032 CVE-2017-5715)This new firmware disables branch prediction on AMD family 17h processor to mitigate a attack on the branch predictor that could lead to information disclosure from e.g. kernel memory (bsc#1068032 CVE-2017-5715)

Er staat inderdaad "disables branch prediction", maar volgens AMD klopt dit niet en gaat het om een gedeeltelijke aanpassing. Slordige communicatiefout.

(Wat er precies is aangepast wordt niet gemeld, trouwens).

[Reactie gewijzigd door mindcrash op 30 juli 2024 19:21]

[Cilph]

Indien het waar is dat ze branch prediction uitschakelen kan iedere eerstejaars tech. informatica student je wel vertellen dat dit een massale impact heeft.

[Armin]

De Microcode update is niet bedoelt voor Meltdown maar voor Spectre. Intel schijnt een manier te hebben gevonden om de branch predictor (waar de bug in zit) uit te schakelen. Dat gebeurt dus met die microcode update.

Er zijn twee potentiele reden om micro-code updates te doen.

1) Meltdown heeft te maken had met de out-of-order execution logica en dus kan men potentieel die logica updaten. Ik weet echter niet of Intel dat doet.

UPDATE: Na enig lezen lijkt het erop dat de micro-code update enkel voor Spectre v2 is.

2) De branch predictor kwestie is Spectre. Voor Sectre moet je complexere fixen maken, en als onderdeel van die fix kan het zijn dat men gebruikt maakt van eigenschappen in micro-code. Zo kent Spectre variant 2 een potentiele fix, waar je - en sorry dat het technisch is - een zogenoemde 'indirect branch prediction barrier' zet, die ervoor zorgt dat de branch predictor logica niet langer 'springt' van trusted naar untrusted addressen. Op AMD gebeurde dit vanzelf al vaak, vandaar dat dat die minder - doch niet geheel onkwetsbaar - waren.

De branch predictor wordt dus niet uitgezet zoals sommige vreesden. Maar wordt enkel geblokeerd bij de overgang van trusted naar untrusted geheugen ruimten. Zolang je binnen hetzelfde domein blijft blijft alles werken als vanouds.

Helaas verhelpt dit enkel één van beide varianten van Spectre, en zoals gezegd kan het zijn dat er toch micro-code update nodig zijn.


Ik heb me nog niet verdiept - als die informatie uberhaupt beschikbaar is - in wat nu precies in de micro-code update van Intel zit. (UPDATE: Na enig lezen lijkt het erop dat de micro-code update enkel voor Spectre v2 is.)

[Reactie gewijzigd door Armin op 30 juli 2024 19:21]

[Blokker_1999]

Meltdown en Spectre zijn niet volledig op te lossen met microcde updates, dat wil niet zeggen dat ze het probleem niet gedeeltelijk kunnen oplossen.

[Stoney3K]

Deze updates zijn dan ook een softwarematige workaround en niet een oplossing voor het probleem. Dat is ook de reden van de vermindering in performance.

[.oisyn]

Dat is ook de reden van de vermindering in performance.

Voor Meltdown, Spectre is eigenlijk niet echt te patchen met software op OS niveau (maar is tevens ook minder gevaarlijk omdat het alleen data binnen het eigen proces kan lezen, wat natuurlijk vooral sandboxed omgevingen treft zoals een browser, en die applicaties zijn individueel wel weer te patchen). Dit zijn overigens microcode updates.

[Reactie gewijzigd door .oisyn op 30 juli 2024 19:21]

[tweaknico]

Als mitigatie (voor linux) wordt nu de kernel in een eigen set pagetables gezet. Hierdoor zal er meer overhead zijn vanwege de TLB invalidation die nu bij elke mode switch van en naar ring 0 moet plaatsvinden. Maar is kernel memory niet meer uit te lezen dmv. TLB collisions.

Voor kritieke stukken code zullen aparte call/return sequences gebruikt moeten worden die ervoor zorgen dat branch prediction effectief geen prefetch doet buiten bekende paden.

( het gaat dan met name om indirecte calls ): https://support.google.com/faqs/answer/7625886 (google faq)

[.oisyn]

Als mitigatie (voor linux) wordt nu de kernel in een eigen set pagetables

Dan heb je het dus over Meltdown. Spectre is ongeveer hetzelfde, maar dan binnen het eigen proces. Natuurlijk kan een proces sowieso al zijn eigen data lezen, vandaar dat het vooral applicaties treft die sandboxed 3rd party code runnen, zoals Javascript in een browser.

Voor Spectre moet je meer denken aan application-layer oplossingen, zoals fences tussen array bounds check en daadwerkelijke access (zodat de CPU de access niet al speculatief gaat uitvoeren), of simpelweg fuzzing van high resolution timers (zodat in Javascript niet meer betrouwbaar is te meten of een read een cacheline hit of niet)

[Reactie gewijzigd door .oisyn op 30 juli 2024 19:21]

[tweaknico]

Het probleem is dat als kernel memory gemapt is de data ook in TLB's geldig is.
Door Kernel memory niet meer te mappen in de usermode pagetables kun je ook de NO-readable data niet meer indirect lezen.

Alleen voor spectre is het ook mogelijk om vanuit een privileged proces in een VM guest de gehele host uit te lezen.

Dat is wat dit interessant maakt:
https://googleprojectzero...ged-memory-with-side.html

Aanvulling: voor deze aanvallen is een nauwkeurige timing noodzakelijk door met timing te gaan rotzooien zal de aanval veel lastiger worden. Alleen zullen niet alle workloads met een grove timing kunnen werken.

[Reactie gewijzigd door tweaknico op 30 juli 2024 19:21]

[Jaded]

Spectre alleen binnen het eigen proces? Heb je daar een bron van? Ik dacht dat Spectre ook daarbuiten kon treden, maar kan me ook vergist hebben in Meltdown. Veel sites rapen het samen.

[.oisyn]

Dat heb ik van wikipedia:

quote: https://en.wikipedia.org/..._(security_vulnerability)

The basic difference between Spectre and Meltdown is that Spectre can be used to manipulate a process into revealing its own data. On the other hand, Meltdown can be used to read privileged memory in a process's address space which even the process itself would normally be unable to access (on some unprotected OS's this includes data belonging to the kernel or other processes).

Maar dat wil natuurlijk niet zeggen dat dat ook de waarheid is. Het artikel van Google dat tweaknico hierboven geeft doet daarentegen weer vermoeden dat Spectre ook gebruikt kan worden voor data buiten je eigen privileges. Ik vind het lastig om er echt eenduidige in-depth informatie over te vinden.

Hoe dan ook, het lezen buiten de eigen address space is op OS niveau te voorkomen door de pages te unmappen, wat potentieel duur is (je moet de TLB flushen, wat cache misses tot gevolg heeft). Oplossingen binnen het proces kan het OS weinig aan doen (afgezien van CPU microcode patchen natuurlijk, maar dat zie ik niet als OS oplossing), daarvoor zal het proces zelf gepatcht moeten worden om daar tegen te waken.

.edit: het Meltdown paper zegt:

Meltdown is distinct from the Spectre Attacks in several ways, notably that Spectre requires tailoring to the victim process’s software environment, but applies more broadly to CPUs and is not mitigated by KAISER

KAISER refereert naar Kernel page table isolation. Dat doet dus weer vermoeden wat wat Wikipedia zegt klopt (die halen dit paper dan ook weer als bron aan, dus dat is niet zo gek).

[Reactie gewijzigd door .oisyn op 30 juli 2024 19:21]

[mindcrash]

Het artikel van Google dat tweaknico hierboven geeft doet daarentegen weer vermoeden dat Spectre ook gebruikt kan worden voor data buiten je eigen privileges. Ik vind het lastig om er echt eenduidige in-depth informatie over te vinden.

Klopt. Bijvoorbeeld:

During the second phase, the processor speculatively executes instruction(s) that transfer confidential information from the victim context into a microarchitectural side channel. This may be triggered by having the attacker request that the victim to perform an action (e.g., via a syscall, socket, file, etc.).

En

Speculative execution of this gadget with attacker-controlled ebx and edi allows an adversary to read the victim’s memory.

Uit de paper van de betrokken researchers. Erg interessant leesvoer

[Reactie gewijzigd door mindcrash op 30 juli 2024 19:21]

[Armin]

Spectre alleen binnen het eigen proces? Heb je daar een bron van? Ik dacht dat Spectre ook daarbuiten kon treden, maar kan me ook vergist hebben in Meltdown. Veel sites rapen het samen.

Spectre kan ook buiten het eigen process, maar blijft wel beperkt tot user-space. Ook zijn er twee varianten. Vandaar de verwarring denk ik.

Meltdown werkt enkel in Intel en een nog niet uitgebrachte ARM core, maar is makkelijk te misbruiken omdat het een directe fout in de out-of-order executie logica van de betrokken CPU's is. Je kunt hiermee kernel-memory lezen.

Sectre is een security-loophole in de branch-predictor en dus heb je twee varianten: eentje waar je speculatief naar een andere branch springt waar je data leest die je niet mag lezen, en eentje waar je juist niet sprint en data leest die je niet mag lezen. Moeilijk te misbruiken, doch ook hier iets makkelijker in Intel/ARM dan AMD, maar ook lastiger te repareren in software en hardware/micro-code. Je kunt hiermee user-space geheugen van een andere thread lezen, of zelfs potentieel ander process.

[Cilph]

Dat zijn de OS patches. Dit komt direct van Intel.

[Enchantress]

Dit bericht komt ook van Intel zelf dus neem het met een korrel zout.

[pipodeclown74]

En hoe zit het met gratis vervanging? Als je een auto koopt en de remleiding of etc. Werkt niet goed door een bug wordt ie teruggehaald en vervangen in de fabriek, dat zou hier ook moeten gebeuren vindt ikzelf waarom moet ik prestatieverlies aanvaarden door een fout van een ontwerp?

[pannalicour]

Dit heet de Darwin evolutie. Of te wel survival of the fittest. Bug in cpu van Intel maar Intel is zo sterk en rijk dat ze tegen de zwakkeren (consument) gewoon hun middelvinger kunnen opsteken

[michaelboon82]

Ik dacht echt even dat je wilde zeggen dat als de remleiding van de auto niet werkt dat dit de darwin evolutie zou zijn; natuurlijke selectie

Maar even los van hoe Intel hierop reageerde....wat kunnen ze anders doen? Een vervangende chip gaat niet want ze hebben het allemaal. Het enige dat je dan kunt doen is iedereen hun aankoopbedrag van de CPU teruggeven omdat het een ondeugdelijk product is. Maar je zit dan met je mobo en koeler, om van de OEM systemen nog maar te zwijgen. En alle CPUs van de afgelopen 5 jaar terugnemen??

Nee dan is Intel in 1 keer failliet dus er is geen andere oplossing dan patchen. We kunnen alleen maar hopen dat ze over een paar maanden een patch hebben die geen invloed heeft op de prestaties.

[pannalicour]

Nee wat ik eigenlijk wilde zeggen is, ook al span je een rechtzaak tegen Intel, Intel vindt toch een manier om niet aansprakelijk te zijn.

[Jelledenkik]

Wauw... Ik ben even met stomheid geslagen.

Dit zou dus betekenen dat mijn I7-3770K (Q2 2012, dus 5.5/6 jaar), welke op het moment overclocked op 4.3 nog meer dan goed mee kan met de huidige I7-serie geen update krijgt, en ik deze dus i.v.m. veiligheidsrisico's zou moeten vervangen? Dit zou mijn volgende keuze voor Intel echt een stuk kleiner maken om eerlijk te zijn.....

EDIT: Ik denk dat ik het verkeerd heb gelezen, deze maand 90% en daarna de rest?

[Reactie gewijzigd door Jelledenkik op 30 juli 2024 19:21]

[borft]

mwah, de Linuxkernel heeft een workaround die gewoon voor alle cpu's werkt (voor Meltdown that is), ongeacht de leeftijd. Lijkt me dat dat ook voor de andere grotere besturingssystemen geldt.

Wat betreft Spectre, volgens mij is die lastig te fixen. Ben ook benieuwd hoe Intel dat voor zich ziet

[TepelStreeltje]

Mjah, de andere keuze is AMD, en die is ook niet echt goed bezig geloof ik...

Hoop ook dat ze na komende maand de 5 jaar en oudere cpu's onder handen nemen.

[hotabibber]

Hoe worden die patches aangeboden? Via de Windows/ Apple updates of moeten de mensen deze gaan down via de Intel site?

En waarom maar patchen tot processoren van 5 jaar oud? Ken genoeg pc's die ouder dan 5 jaar zijn en perfect werken, moeten deze mensen dan uit veiligheidsoverwegingen een nieuwe PC kopen met een AMD processor erin? Gezien het feit dat Intel nu toch wel een slechte naam heeft gekregen met dit beleid, is toch iets wat ik niet zo maar blijf steunen.

[Blokker_1999]

Patches zullen via het update mechanisme van je OS komen.

En waarom tot 5 jaar terug? Omdat het economisch niet verantwoord is veel verder terug te gaan. Ja, er zullen inderdaad nog een hoop oudere systemen in gebruik zijn, maar op het totaal aantal systemen in gebruik is dat een redelijk klein aandeel. Zeker in de bedrijfswereld waar systemen op 3 tot 5 jaar afgeschreven worden.

Dat wil niet zeggen dat de verschillende patches geen invloed gaan hebben. Het betekend alleen dat er geen microcode updates meer zullen komen voor die specifieke producten.

[TIGER79]

Zeker in de bedrijfswereld waar systemen op 3 tot 5 jaar afgeschreven worden.

Dat terwijl er genoeg hoofd en kritieke systemen juist op oudere hardware (en software) draaien, denk aan banken, defensie, zorg(instellingen), gemeentes enz enz...
Die investeren over het algemeen een enkele grote bedrag wat vervolgens 5 a 10 jaar mee gaat... Daarom dat er dus nu ook zoveel verouderde systemen zijn, en ja je komt nog met regelmaat core 2 duo's tegen overal die onderhand 10 jaar oud zijn....

[hotabibber]

Precies wat ik dus bedoel.
Ik was bezig om voor mij zelf een nieuwe PC aan te gaan schaffen, maar ga nu toch sterk overwegen om een AMD te gaan nemen in plaats van een Intel I 7 processor.

[EgMaf]

Dan is dit nu en goede reden om ok die systemen eindelijk weer bij te brengen.

[TIGER79]

dat heb je dus met budgetten : die zijn niet a la minute aanwezig en beschikbaar... Want die zijn dan niet begroot van tevoren...
Dus verwachten dat er opeens duizenden nieuwe pc's (of erger nog servers) aangeschaft worden met publiekelijk geld is simpelweg niet realistisch en zo werkt het ook niet...

[PolarBear]

Zeker in de bedrijfswereld waar systemen op 3 tot 5 jaar afgeschreven worden.

Afschrijven heeft niets met de levensduur van een product te maken. Afschrijven is een boekhoudkundige actie die voor geschreven wordt door wet- en regelgeving. https://www.belastingdien...ijving/wat_is_afschrijven

Zeker voor workstations die als veredelde thin client worden gebruikt is upgraden na 3 jaar zeker niet noodzakelijk.

[Verwijderd]

Na die afschrijvingsperiode wordt het bedrijfsmatig juist interessant: dan gaat je compute OPEX flink omlaag en dus de operationele marge omhoog.

[raro007]

De gaten waren vorige jaar Julie of juni gemeld toch?
En komen pas over 9 maanden met een patch?

[Daniel_Elessar]

Is het raar dat zoiets complex tijd vraagt? Ze moeten het eerst goed analyseren, dan een fix bedenken en zeer goed testen om te zien dat er verder niks “stuk” gaat. Nee dan is een half jaar echt niet veel tijd.

[Verwijderd]

In hoeveel tijd had jij het gekund?

[wiseger]

Als CEO van een miljarden bedrijf met praktisch een ongelimiteerd budget, denk wel sneller eerlijk gezegd echter dat komt omdat ik ervoor zou kiezen alles op alles te zetten mijn klanten veilig te houden. Ze hebben op mijn merk vertrouwd, en dat vertrouwen zou ik niet willen beschadigen.

Mocht ik de omzet en winst cijfers ook heel erg belangrijk vinden dus geen vertraging op willen lopen met de roadmap van mijn nieuwe modellen, dan zou het tijdspad ongeveer gelijk kunnen zijn aan wat Intel hanteerd.

[Wilke]

Zijn de problemen zonder deze microcode patches niet op OS-niveau op te lossen?

Want ik heb een i5 die zeker ouder dan 5 jaar is en nog prima voldoet, zelfs voor gamen.

Als dat echt het geval gaat zijn kan AMD met zekerheid een nieuwe Ryzen-klant tegemoet zien.

[Reactie gewijzigd door Wilke op 30 juli 2024 19:21]

[mensoc]

Ik heb hetzelfde sentiment als jij, alleen heeft de AMD Ryzen ook last van de Spectre "bug".
Het zou zo maar kunnen dat wij voortaan nieuwe systemen van AMD gaan voorzien aangezien de bron van deze ellende bij Intel ligt, maar Ryzen is op dit moment ook niet veilig.
Ik verwacht pas volgend jaar op zn vroegst chips te zien zonder deze ellende.

[mindcrash]

Intel-ceo Brian Krzanich voegde daaraan toe dat de gevolgen van de patches 'zeer afhankelijk zijn van de uit te voeren workload'

Maar de gevolgen zijn blijkbaar dusdanig ernstig dat Intel-ceo Brian Krzanich even voordat het Meltdown en Spectre nieuws echt viral ging al zijn boventallige INTC opties, lees: alles dan wat hij volgens zijn arbeidscontract moet aanhouden, heeft verkocht.

Of gewoon toeval. Maar bij dit soort acties geloof ik niet echt in toeval.