De aanloop naar Meltdown en Spectre

Wat gebeurde er achter de schermen?

Onthullingen op Black Hat

Er is al veel geschreven over Spectre en Meltdown, die aan het begin van dit jaar de kop opstaken na een wat gehaaste bekendmaking door verschillende bedrijven. Die hadden achter de schermen hard gewerkt om zo snel mogelijk met oplossingen te komen. Deze kwetsbaarheden, door sommigen aangeduid als de ernstigste van het afgelopen decennium, konden dan ook niet ontbreken op de jaarlijkse Black Hat-beveiligingsconferentie in Las Vegas. Maar liefst drie presentaties waren aan dit onderwerp gewijd. Dit artikel put uit deze presentaties, die voor een deel ingingen op wat aan de bekendmaking voorafging. Samen vormen ze een interessante kijk op wat zich achter de schermen afspeelde rondom deze spraakmakende ontdekkingen en de coördinatie die plaatsvond tussen een deel van de betrokkenen.

Een van de presentaties was een panelsessie met vertegenwoordigers van Google, Microsoft en Red Hat, geleid door iemand van het Cert van de Amerikaanse Carnegie Mellon-universiteit. Dat is inderdaad het Cert dat in eerste instantie schreef dat de enige tegenmaatregel tegen Spectre en Meltdown het 'vervangen van de cpu-hardware' was, maar daar later een genuanceerder advies van maakte. Uit de paneldiscussie komt een mogelijke reden voor het rigoureuze advies naar voren.

Vlnr: vertegenwoordigers van Red Hat, Microsoft, Google en het Cert

Google

Matt Linton, voorzien van roze hanekam en een korte broek met kistjes, is aanwezig om het perspectief van Google toe te lichten vanuit zijn positie als senior security engineer, ook wel chaos specialist. Het is niet gek dat hij de discussie aftrapt, aangezien Googles Project Zero nauw betrokken was bij de ontdekking van de kwetsbaarheden. De tijdlijn van het disclosureproces begon in juni 2017, toen de onderzoekers achter de ontdekking besloten om de cpu-fabrikanten in te lichten over hun bevindingen.

Linton: "Het is niet zo dat Project Zero-leden van tevoren Google inlichten over kwetsbaarheden die ze vinden. In dit geval was het zo dat Project Zero Intel inlichtte, met de mededeling dat Intel vervolgens ook Google moest inlichten. Door een miscommunicatie gebeurde dat echter niet meteen." Toen dat wel gebeurde, betrok Google senior medewerkers van verschillende afdelingen om de ernst en de gevolgen van de gevonden kwetsbaarheden vast te stellen. Volgens Linton werd er een hele tijd over en weer gecommuniceerd met Intel. "Er werden tot oktober voortdurend verschillende tegenmaatregelen tussen Google en Intel heen en weer gestuurd, maar die werden allemaal afgeschoten."

Op een gegeven moment vond een vergadering van alle betrokken spelers in de sector plaats. Op die vergadering kwam bijvoorbeeld Microsoft over de brug met een werkende proof-of-concept van een aanval vanuit de browser, vertelt Linton. Dat was het moment dat het Chrome-team erbij werd betrokken, waarvan een aantal leden toen al vijf jaar werkte aan de functie site isolation. Linton vroeg aan het Chrome-team hoe snel die functie klaar kon zijn, waarop een schatting van drie tot vier kwartalen werd gegeven om tot een bètarelease te komen. De embargodatum was op dat moment al vastgelegd op 9 januari en uiteindelijk lukte het dan ook om de bèta voor januari af te ronden.

Uiteindelijk zou het niet lukken om het embargo tot 9 januari vol te houden, omdat er voor die tijd al verschillende signalen waren die erop wezen dat achter de schermen aan iets groots werd gewerkt. Deze signalen werden uiteindelijk door The Register aan elkaar geknoopt. Op 2 januari verscheen vervolgens de eerste proof-of-concept van een werkende aanval, wat betekende dat het embargo moest worden opgeheven, omdat er gewoonweg niet langer kon worden gewacht. Dat gebeurde op 3 januari.

Microsoft

Microsoft, in het panel vertegenwoordigd door de leider van het security response team Eric Doerr, trok een expert aan in het proces om vast te stellen wat de impact van de lekken was. Die expert was Anders Fogh van het beveiligingsbedrijf G-Data. Doerr stelt dat het verhaal voor Microsoft eveneens in juni begon en dat eerst moest worden vastgesteld waarmee het bedrijf te maken had. "We keken eerst of het reproduceerbaar was op Windows Server en we kwamen er al snel achter dat het inderdaad om een real thing ging. Toen hebben we besloten er mensen van verschillende afdelingen bij te betrekken."

Hij vergelijkt het proces met het pellen van een ui, waarbij er steeds meer complexiteit bijkwam. Al snel werd duidelijk dat er binnen de producten van Microsoft grote veranderingen nodig waren, waardoor de deadline van januari ineens heel snel dichterbij kwam. Doerr uit zich positief over de bijeenkomst van de betrokken organisaties, die volgens hem in november 2017 werd gehouden. "Het is grappig om vast te stellen hoe zelden een dergelijke bijeenkomst plaatsvindt", zegt hij. "Ik was overweldigd door de samenwerking die tijdens de bijeenkomst plaatsvond, want wie deelt er nou mitigations voor kwetsbaarheden met zijn directe concurrenten?"

Hij noemt als voorbeeld dat Google een volledige tegenmaatregel genaamd retpoline uit de doeken deed. "Het was een omslagpunt, waarop de samenwerking met een enorme factor omhoogging", aldus Doerr. Aan het einde van zijn introductie voegt hij daaraan toe: "Ik wisselde in de laatste twee weken voor de publicatie meer berichten uit met mensen die aan oplossingen werkten, dan met mijn vrouw."

Red Hat

Voor Red Hat, vertegenwoordigd door Christopher Robinson, oftewel CRob, ging het iets anders. Hij werd in november gebeld dat hij een telefoontje van Intel zou krijgen. Voor hem was er dus veel minder tijd om in actie te komen. "We hadden nog een aanzienlijke hoeveelheid werk te verrichten." Hij onderstreept dat Red Hat een opensourcebedrijf is dat met veel externe mensen werkt. "Fun fact", voegt Robinson toe: "Niemand in open source hoort graag dat hij een bepaalde taak moet uitvoeren." Daarbij doelt hij erop dat mensen verschillende taken kregen toegewezen om patches door te voeren. "Op 3 januari, toen ik dacht nog een week te hebben om mijn documentatie te schrijven, kreeg ik een bericht met de vraag of ik klaar was om over een uur publiek te gaan."

Red Hat-uitlegvideo over Spectre en Meltdown

Wie mag er 'in de tent'?

Een van de vragen die tijdens de discussie aan bod komen, gaat erover hoe werd bepaald wie op de hoogte werd gebracht van de bevindingen van de onderzoekers. Volgens Red Hats Robinson kwam die afweging neer op de vraag of iemand aan een oplossing kan bijdragen. Doerr, van Microsoft, stelt dat het probleem is dat hoe meer mensen op de hoogte worden gesteld, hoe groter de kans wordt dat er iets uitlekt. "Het is eigenlijk waanzinnig dat dit zes maanden verborgen is gehouden", aldus Doerr. Volgens Googler Linton was het embargo in handen van de chipmakers. Dat betekent volgens hem dat er mensen waren die 'in de tent' hadden moeten zitten, maar er niet in zaten. "Google hanteerde het volgende criterium: onderhoud je een besturingssysteem, werk je aan een virtualization stack of aan drivers, dan hoor je erbij." Art Manion, senior vulnerability analyst voor het Amerikaanse Cert en panelleider, wil ook weten waarom hijzelf niet van tevoren werd ingelicht. Dat zou verklaren waarom het Cert met een zo rigoureus advies kwam op de dag dat het embargo werd opgeheven.

Een andere kwestie die aan bod komt, is de vraag waarom de Amerikaanse overheid niet werd ingelicht, terwijl dat wel gebeurde met Chinese bedrijven. Daarop reageert de Google-afgezant: "Dat is een heel moeilijk onderdeel van de puzzel, waarbij de vraag is of een entiteit op een betekenisvolle manier kan bijdragen." Hij zegt dat hij het bovendien niet eens is met de manier waarop dit gegeven onder meer op Twitter werd geframed. Daarmee doelt hij op de suggestie dat het inlichten van Chinese bedrijven, zoals Lenovo, gelijk zou staan aan het inlichten van de Chinese overheid. "Het was noodzakelijk om Lenovo op de hoogte te stellen, omdat het microcode-updates naar miljoenen mensen kon pushen." Op dat moment meldt zich iemand van Lenovo in het publiek, die stelt dat alles wat met Spectre en Meltdown te maken had vanuit de VS werd gecoördineerd met een team van ongeveer twaalf mensen, naast iemand in Japan voor ThinkPad. Lenovo zou op 30 november op de hoogte zijn gebracht.

Tot slot komt de vraag aan bod wat mensen anders hadden gedaan en wat ze hebben geleerd. Volgens Robinson is er in de tussentijd samengewerkt aan varianten van de oorspronkelijke kwetsbaarheden. Deze samenwerking verliep aanzienlijk beter, doordat nu duidelijk was wie met wie contact moest opnemen. Volgens Microsoft had de nauwe samenwerking veel eerder moeten beginnen.

Wat gaat nog komen?

Enkele ontdekkers van de lekken, Daniel Gruss, Moritz Lipp en Michael Schwarz van de universiteit van Graz, hebben tijdens Black Hat hun eigen presentatie over Meltdown, waarin ze in een soort rollenspel de werking ervan nader toelichten. Daarin delen ze onder meer mee dat ook de Exynos-soc in de Galaxy S7 van Samsung kwetsbaar was voor Meltdown en dat de Zuid-Koreaanse fabrikant in juli patches heeft uitgebracht. Ze verwachten bovendien dat er in de toekomst nog meer aanvallen gevonden zullen worden die gebruikmaken van prestatieoptimalisaties in processors. Gezien de varianten die tot nu toe voorbij zijn gekomen, hieronder weergegeven in een tabel, zitten de onderzoekers er waarschijnlijk niet naast.

Volgens hen moet er dan ook opnieuw worden nagedacht over processorontwerp, en moet er een betere balans tussen prestaties en veiligheid worden gecreëerd. "Denk daarbij bijvoorbeeld aan de auto-industrie. Daarin kregen we ook niet alsmaar snellere auto's, maar werd veiligheid belangrijker", illustreert een van hen. In hun afsluiting willen ze ook nog even het misverstand uit de wereld helpen dat Meltdown en Spectre side channel-aanvallen zijn. Hoewel ze van een dergelijk kanaal gebruikmaken voor transmissie, zou dat nog niet betekenen dat de hele aanval zo geclassificeerd zou moeten worden.

Spectre variant 1	Bounds check bypass, CVE-2017-5753
Spectre variant 1.1	Bounds check bypass on stores, CVE-2018-3693
Spectre variant 1.2	Read-only store
Spectre variant 2	Branch target injection, CVE-2017-5715
Meltdown (variant 3)	Rogue data cache load, CVE-2017-5754
Spectre variant 3a	Rogue system register read, CVE-2018-3640
Spectre variant 4	Speculative store bypass, CVE-2018-3639
Lazy FP restore	CVE-2018-3665
SpectreRSB	-

Reacties (66)

[killercow]

Gemiste kans, jullie vergeten dat onze eigen Nederlandse beveiligingsonderzoeker en tweaker @Verwijderd aan de hand van de signalen de eerste publieke proof on concept in elkaar heeft geklust, en dat in 3 dagen heeft gedaan. Dat was de proof of concept die uit kwam op 3 januari.

https://twitter.com/brainsmoke/status/948561799875502080

Ander werk van hem:
* nieuws: Onderzoekers presenteren exploit die geen lek in software nodig heeft
* nieuws: Student ontwikkelt virtuele machine tegen geheugen-exploits

[Reactie gewijzigd door killercow op 23 juli 2024 13:10]

[Verwijderd]

Spectre variant 1 = Intel, AMD, ARM.

De rest van de spectre varianten = Intel en ARM.

Meltdown = Intel only.

[wildhagen]

Spectre variant 1 = Intel, AMD, ARM.

De rest van de spectre varianten = Intel en ARM.

Volgens mij klopt dat laatste niet niet helemaal...

Zie reviews: Meltdown en Spectre - Drie weken later

Daarnaast zegt AMD dat ook de tweede variant van Spectre op zijn processors van toepassing is, maar dat een aanval moeilijk is uit te voeren

Ze melden hetzelfde ook op hun eigen site: https://www.amd.com/en/corporate/security-updates

Dus Spectre variant 2 is ook op AMD van toepassing, iig onder bepaalde condities. Het risico is alleen iets lager omdat de exploit lastiger is.

[wildhagen]

Ik heb het over Spectre Variant 2, en jij komt met een quote over Spectre Variant 1.2, wat weer een heel andere variant is?

Waar staat dat ze kwetsbaar zijn voor Spectre Variant 2? Nou, gewoon, op hun eigen website?

While we believe it is difficult to exploit Variant 2 on AMD processors, we actively worked with our customers and partners to deploy the above described combination of operating system patches and microcode updates for AMD processors to further mitigate the risk.

Zie https://www.amd.com/en/corporate/security-updates

Tenzij jij bronnen hebt dat de eigen AMD-site niet klopt"

AMD is dus ook vulnerable voor Variant 2, hoewel de exploit ervan wel moeilijker is.

[Verwijderd]

Misverstand, dacht dacht je met Spectre 2 Spectre 1.2 bedoelde ( exploiting indirect branches ) welke niet werkt op AMD Maar dan nog klopt wat je quote niet geheel, Spectre 1 is dus niet geheel werkend op AMD, alleen Spectre 1.1

Mijn quote komt van je eigen link trouwens ( maar ja dus over Spectre 1.2 niet 2 ).

Spectre 2 is ook in de pdf die ik gelinkt heb werkend op AMD Ryzen ( en daarvoor dus ). In de Spectre pdf staat dan weer niet dat 1.2 niet werkt op AMD ( of ik kan het niet vinden ) maar op de pagina van AMD staat hij wel gemeld als niet toepasselijk om hun processoren.

edit: naar ik meen heeft het te maken met een andere implementatie van de branch predictor maar weet het niet zeker meer

[Reactie gewijzigd door Verwijderd op 23 juli 2024 13:10]

[Squee]

Misverstand, dacht dacht je met Spectre 2 Spectre 1.2 bedoelde ( exploiting indirect branches ) welke niet werkt op AMD Maar dan nog klopt wat je quote niet geheel, Spectre 1 is dus niet geheel werkend op AMD, alleen Spectre 1.1

Nee, Spectre variant 2 = 'Branch Target Injection' oftewel het beinvloeden van indirect branches. Variant 1.2 is een read-only speculative store (zie ook het overzichtje onderaan het artikel). Over variant 2 zegt AMD heel duidelijk op hun site:

GPZ Variant 2 (Branch Target Injection or Spectre) is applicable to AMD processors.

Dus ja, deze is van toepassing en kan werken op AMD processoren. Dat het erg lastig is om het werkend te krijgen staat daar los van; het gaat er om dat het niet onmogelijk is.

Spectre 2 is ook in de pdf die ik gelinkt heb werkend op AMD Ryzen ( en daarvoor dus ). In de Spectre pdf staat dan weer niet dat 1.2 niet werkt op AMD ( of ik kan het niet vinden ) maar op de pagina van AMD staat hij wel gemeld als niet toepasselijk om hun processoren.

In de originele Spectre PDF staat dat de onderzoekers het niet lukte om variant 2 werkend te krijgen op een AMD processor, maar dat sluit natuurlijk niet uit dat het onmogelijk is. ("dit werkt niet" is geen sluitend bewijs)

Een kleine anekdote ter illustratie; begin dit jaar heb ik nog een Spectre v2 PoC geschreven voor SPARC. Dit was met de complete micro-architectuur documentatie in de hand, de documenten geschreven door de processor designers met alle interne details van de processor - een document wat niet publiekelijk en zelfs niet onder NDA met klanten gedeeld wordt. Met deze details kon ik in ongeveer anderhalve dag laten zien dat bepaalde processoren vatbaar waren voor bepaalde patronen. Wat me wel snel duidelijk werd is dat het ontzettend moeilijk zou zijn om precies de juiste patronen te vinden als je niet alle interne details weet. Veel adressen worden op verschillende manieren gehashed op verschillende plaatsen bijvoorbeeld, wat het veel lastiger maakt om te voorspellen welke op dezelfde index zullen vallen.

Waar het uiteindelijk om ging, is dat we konden aantonen dat het niet onmogelijk was. Mensen met genoeg resources en geduld zouden met veel experimenteren en meten al deze patronen kunnen achterhalen of anderzijds reverse-engineeren, en dan zou het wel mogelijk kunnen worden om Spectre v2 betrouwbaar uit te buiten. Ik vermoed dat er bij AMD een vergelijkbare situatie is, en dat ze daarom zeggen:

Differences in AMD architecture mean there is a near zero risk of exploitation of this variant. Vulnerability to Variant 2 has not been demonstrated on AMD processors to date.

.. maar dat garandeert dus niet 100% veiligheid, want in de kern is een AMD processor wel vatbaar. Gewoon patchen dus

[Verwijderd]

7/13/18

This week, a sub-variant of the original, Google Project (GPZ) variant 1 / Spectre security vulnerability was disclosed by MIT. Consistent with variant 1, we believe this threat can be mitigated through the operating system (OS). AMD is working with the software ecosystem to mitigate variant 1.1 through operating system updates where necessary. We have not identified any AMD x86 products susceptible to the Variant 1.2 vulnerability in our analysis to-date. Please check with your OS provider for the latest information.

AMD has also updated related portions of the Software Techniques for Managing Speculation on AMD Processors whitepaper.

https://www.amd.com/en/corporate/security-updates

Ik benoem foutief exploiting indirect branches, dit is volgens mij niet Spectre 1.2 maar Spectre 2 welke inderdaan werkte op AMD.

*Ik was gisterenavond niet geheel wakker en heb nog steeds een knallende koppijn sorry voor de verwarring

[Reactie gewijzigd door Verwijderd op 23 juli 2024 13:10]

[Squee]

Spectre variant 1 = Intel, AMD, ARM.
De rest van de spectre varianten = Intel en ARM.
Meltdown = Intel only.

Dit lijstje is compleet onwaar, en ik zie wel vaker dit soort misinformatie in de comments hier op Tweakers helaas, vaak gepaard met een soort ongefundeerde conspiracy theory jegens Intel. Ik vind dat erg jammer, want het is echt niet zo dat AMD heilig is (wat hier geimpliceerd lijkt te worden); Spectre is een groot probleem voor de gehele microprocessor industrie.

ELKE out of order processor zal potentieel vatbaar zijn voor Spectre v1 en v2, zelfs een 20 jaar oude DEC Alpha 21264. Het is een exploit die inhaakt op bepaalde algemeen geaccepteerde design patronen van out of order processoren, welke al 20 jaar aan Universiteiten geleerd worden. Het kan wel zo zijn dat afhankelijk van de parameters van een design, het meer of minder makkelijk uit te buiten zal zijn. Spectre v1/v2 is mogelijk in processoren van... Intel, AMD, ARM, Apple, Oracle, IBM, Qualcomm, Samsung, Cavium, Ampere... en ga zo maar door.

Meltdown/Spectre v3 was wel meer een microarchitecturele design fout, iets waar Intel een bepaalde shortcut implementeerde die te kort door de bocht bleek te zijn, en AMD deed dit niet. Dus ja, AMD is daar niet vatbaar gebleken, maar ook andere designs bleken hier last van te hebben zoals Apple en ARM (Cortex-A75), dus ook dat was zeker niet "Intel ony"

[Verwijderd]

Er is toch ook een Spectre variant ( 1.2 ) waar AMD niet vatbaar voor is ( exploiting indirect branches ).

Achtergrond info

Of is die research paper niet up to date?

edit: Achtergrond info van AMD welke stelt dat zij niet vatbaar zijn voor zover zij hebben kunnen vaststellen voor Spectre 1.2

Dus van de twee spectre aanvallen is AMD er vatbaar voor een.

*edit: Had moeten zijn, van de drie Spectre aanvallen is AMD er vatbaar voor twee ( 1.1 en 2 ).

Van de ZES is AMD er vatbaar voor vijf... sorry, ben er niet geheel bij vanavond

[Reactie gewijzigd door Verwijderd op 23 juli 2024 13:10]

[supersnathan94]

Er zijn meer dan 3 Spectre aanvallen hoor. Check het lijstje hierboven in het artikel nog maar eens.

[Verwijderd]

Het zijn er idd zes, vijf uit zes dus. Excuses ben er niet helemaal bij vanavond

[Squee]

Er is toch ook een Spectre variant ( 1.2 ) waar AMD niet vatbaar voor is ( exploiting indirect branches ).

Achtergrond info

Of is die research paper niet up to date?

edit: Achtergrond info van AMD welke stelt dat zij niet vatbaar zijn voor zover zij hebben kunnen vaststellen voor Spectre 1.2

Zoals ik hierboven al beschreef, je lijkt v2 en v1.2 door elkaar te halen:
Squee in 'reviews: De aanloop naar Meltdown en Spectre - Wat gebeurde er acht...

Maar om nog even in te haken op het niet vatbaar zijn voor variant 1.2, dat is opzich wel logisch. Variant 1.2 is een speculatieve store naar geheugen wat in de pagetables gemarkeerd als read-only is, waarvan in bepaalde gevallen deze speculatieve waarde geobserveerd kan worden door een load (maar architectureel gezien zou deze store nooit plaats vinden). Aangezien AMD processoren niet vatbaar zijn voor Meltdown/Spectre v3, blijkt al dat ze hun pagetable permissie check streng implementeren in hun Load/Store unit. Hierdoor zal waarschijnlijk ook vroeg worden gedetecteerd dat een variant 1.2 store naar een read-only locatie is, en deze waarde dan op 0 gezet worden, of compleet geannuleerd. Dat is zeker wel erg netjes van AMD dat ze dat goed gedaan hebben

Van de ZES is AMD er vatbaar voor vijf... sorry, ben er niet geheel bij vanavond

Maar er zijn inmiddels 9 verschillende varianten bekend zoals je kan zien onderaan het artikel. Volgens mij staat er nu alleen vast dat AMD niet vatbaar is voor v1.2 en v3 (Meltdown) en v3a. Dus in het ergste geval is het van de negen is AMD vatbaar voor zes, ik kon niet zo snel vinden of ze een reactie gepubliceerd hadden over SpectreRSB en Lazy FP restore, dus laten we voorlopig van het ergste uit gaan.

[edit:] typo

[Reactie gewijzigd door Squee op 23 juli 2024 13:10]

[totaalgeenhard]

Artikel begin veelbelovend een long read...

Maar eindigde voor mij in een deceptie.

Timelime van betrokken partijen zijn niet relevant zolang de grote boosdoener Intel niet in het verhaal voorkomt.

En zelfs vandaag blijkt uit niets dat Intel regie van dit verhaal naar zich getrokken heeft en aan meltdown vrije CPU werkt. AMD en Samsung ontwijken het ontwerp, echter AMD socket gaan lang mee dus CPU vervangen is mogelijk. Samsung heeft gehele omgeving van telefoon onder haar beheer en op geroote toestellen is risico te beheersen.

Wel gek dat deze mensen timelime als discussie nemen en niet zozeer wat Intel had kunnen doen.

[Dennism]

Zo gek is dat niet, voor zover ik kan zien in dit artikel en verder gaat dit panel juist over de "beleving" van dit hele verhaal vanuit deze software bedrijven. Dan is het vrij logisch dat Intel en de andere cpu fabrikanten wat minder aan bod komen aangezien juist Google, Microsoft, Red Hat en Cert juist hier hun verhaal willen doen en zich dus focussen op hun timeline en de issues waar zij tegenaan liepen.

Wel geven ze volgens mij allemaal aan continu in contact te zijn geweest met o.a. Intel. Verder denk ik niet dat het terecht is Intel "de grote boosdoener" te noemen, dit gaat veel en veel verder dan alleen Intel, dit is een industrie breed probleem. Dat jij (je werkgever) zoals je eerder al aangegeven hebt alleen Intel hebt doet daar niets aan af. Dat maakt het nog geen Intel only issue.

Ik weet ook eigenlijk niet wat jij verwacht dat Intel meer had kunnen doen dan dat ze gedaan hebben, ze hebben de noodzakelijke microcode met uitgebreide guidance uitgebracht vanaf de Nehalem / westmere generatie tot nu, dat is zo'n 10 aan cpu's, samen gewerkt met software ontwikkelaars en komen eind dit jaar met de Cascade Lake cpu's met "in silicon fixes", dit is in maart al op deze site behandeld zelfs en had je dus ook al kunnen weten nieuws: Intel brengt dit jaar cpu's uit die hardwarematig beschermd zijn tege... en is ook deze week weer naar voren gekomen: https://www.tomshardware...._lake-ice_lake,37574.html

Er moet echter wel rekening gehouden worden met het feit dat het ontwikkelen van een CPU generatie enige tijd duurt en een redelijke periode voordat je ze in de winkel ziet het ontwerp al "Final" is, daardoor is het niet onaannemelijk dat mogelijk niet alle varianten gefixed zijn "in silicon", Meltdown, Spectre V1 en V2 lijken zekerheidjes daar dit de initieel bekend geraakte varianten zijn, maar voor de varianten van afgelopen mei bijvoorbeeld zal het afwachten zijn.

[Reactie gewijzigd door Dennism op 23 juli 2024 13:10]

[totaalgeenhard]

Intel heeft CPU niet grpatched met de microcode maar voorzien van een workarounds die naast dat je ze ongedaan kunt maken ook geen oplossing blijken te zijn.

http://www.eenewseurope.c...cover-new-vulnerabilities

Ik neem je opmerking over patch in OS niet serieus. Je kunt geen hardware gebrek oplossing met software ze moeten cpu's vervangen.

Gezien de eenvoud van aanval heeft Intel geen dubbeltje uitgegeven aan audit en kennelijk niemand in huis die dit heeft kunnen vinden.

Ik denk dat dat moeilijk te geloven is en dat men dit al heel lang wisten en bewust onder de pet is gehouden. Security by obscurity.

Om maar te zwijgen over IME.

Intel wist al bijna een jaar van het probleem, doordat ze er expliciet op gewezen zijn, voordat het openbaar werd en toch had men niets voorbereid.

Intel houd er een Apple tactiek erop na ontkennen en stilhouden totdat ze veroordeeld worden of een regering iets eist en dan doen als of ze veel coulance en klant vriendelijkheid kennen.

Intel zou inruil moeten aanbieden nieuwe moederbord + CPU die hardwarematig probleemloos zijn. Waarbij IME (fysiek) uitgeschakeld kan worden.

Eventueel 10% bijbetalen per jaar. 2018 - "jaar aanschaf"

Er lopen vele processen tegen Intel misschien daar iets uitkomt.

Waarom zou je accepteren dat prestaties van je auto minder worden als achteraf blijkt dat er een probleem in je hardware zit?

[Dennism]

Intel heeft CPU niet grpatched met de microcode maar voorzien van een workarounds die naast dat je ze ongedaan kunt maken ook geen oplossing blijken te zijn.

http://www.eenewseurope.c...cover-new-vulnerabilities

Ze zijn wel degelijk gepatched via microcode, en ja, uiteraard is dat ongedaan te maken. Ze kunnen immers een fysieke CPU niet meer fysiek aanpassen. Dat zal zoals ik hierboven al aangeef pas vanaf de volgende generatie (Cascade Lake) gaan gebeuren. Al zal de kans groot zijn dat ook daar microcode updates en / of software patches nodig gaan zijn, voor zaken die ontdekt zijn nadat het ontwerp "Final" is gegaan. zoals de door jou geposte link.

Dat er verdere lekken gevonden zouden worden was eigenlijk direct al voorspelt door de diverse onderzoekers. CPU's in het algemeen en aangezien Intel veruit de grootste is binnen de datacenter markt, vooral Intel zijn nu zeer populair onder de onderzoekers. Ik zou dan ook niet verwachten dat dit de laatste zaken zijn die gevonden zullen worden.

Ik neem je opmerking over patch in OS niet serieus. Je kunt geen hardware gebrek oplossing met software ze moeten cpu's vervangen.

Of je het wel of niet serieus neemt moet je uiteraard zelf bepalen, de realiteit is echter dat de huidige CPU's alleen met microcode en/of software updates gepatched kunnen worden (Meltdown en Spectre V1 is via software, Spectre V2 microcode en software). Ze kunnen geen CPU's vervangen, want er zijn geen cpu's die het momenteel niet hebben. En de realiteit is ook dat er onderzoekers zijn die verwachten dat dit "nooit" zal ophouden en dat ook in nieuwe generaties cpu's er issues gevonden gaan zullen worden die tot er een nieuwe generatie uitkomt met microcode en / of software gepatched zullen moeten worden. Ik zie het in ieder geval wel gebeuren dat in het kader van securtity het patches van de gebruikte OSén, de gebruikte software alsmede het up-to-date houden van firmware nog belangrijker gaat worden dan het al was.

Gezien de eenvoud van aanval heeft Intel geen dubbeltje uitgegeven aan audit en kennelijk niemand in huis die dit heeft kunnen vinden.

Ik denk dat dat moeilijk te geloven is en dat men dit al heel lang wisten en bewust onder de pet is gehouden. Security by obscurity.

Dat is dan van toepassing op de gehele industrie, zie bijvoorbeeld deze post van @Squee Squee in 'reviews: De aanloop naar Meltdown en Spectre - Wat gebeurde er acht... en de lijst van getroffen cpu fabrikanten hij aanhaalt.

ELKE out of order processor zal potentieel vatbaar zijn voor Spectre v1 en v2, zelfs een 20 jaar oude DEC Alpha 21264. Het is een exploit die inhaakt op bepaalde algemeen geaccepteerde design patronen van out of order processoren, welke al 20 jaar aan Universiteiten geleerd worden. Het kan wel zo zijn dat afhankelijk van de parameters van een design, het meer of minder makkelijk uit te buiten zal zijn. Spectre v1/v2 is mogelijk in processoren van... Intel, AMD, ARM, Apple, Oracle, IBM, Qualcomm, Samsung, Cavium, Ampere... en ga zo maar door.

Ik ga niet zeggen dat het niet zo is, maar het lijkt mij zeer onwaarschijnlijk dat de gehele industrie van CPU fabrikanten dit jaren onder de pet heeft kunnen houden zonder dat het uitgelekt is. Een van de ontdekkers van deze bugs uit het Project Zero team van Google vind het al ongelooflijk dat ze het 6 maand onder embargo hebben kunnen houden, jaren lang lijkt me dan toch wel erg moeilijk voor een hele rits aan fabrikanten.

Intel wist al bijna een jaar van het probleem, doordat ze er expliciet op gewezen zijn, voordat het openbaar werd en toch had men niets voorbereid.

30 juni tot begin januari is bij mij een half jaar, maar goed, niets voorbereid is natuurlijk onzin, zie alleen dit panel al waarin zelfs aangegeven wordt dat er constant overleg geweest is tussen o.a. Intel en Google, Die partijen zijn een half jaar "vol gas" bezig geweest, misschien dat het allemaal net wat gecompliceerder is dan je denkt.

Intel houd er een Apple tactiek erop na ontkennen en stilhouden

Daar lijkt hier totaal geen sprake van te zijn, Intel en de andere partijen wisten precies wanneer het embargo zou vervallen (9 januari), doordat het iets eerder bekend geworden is, is dat 3 januari geworden.

Ik vind zelf ook een boel dingen van Intel, maar ik kan ze hier toch niet echt de schuld in de schoenen schuiven. Ze hebben eigenlijk hele proces voor hun eigen (Intels) doen zelfs naar mijn mening vrij open gecommuniceerd en alles informatie m.b.t. microcode releases netjes gedocumenteerd.

En begrijp me niet verkeerd trouwens, ik baal ook als een stekker van dit hele probleem en de extra tijd die het me kost en de mogelijke implicatie's voor de toekomst. Ik had ook liever gezien dat het nooit gebeurt zou zijn. Ik zie alleen geen enkel heil in een kruistocht tegen Intel inzake Meltdown en Spectre daar het een industrie breed probleem is en een oplossing gaat al dat gerant ook niet bieden.helaas.

Op dit moment hebben we het helaas er maar mee te doen, en we moeten maar zien wat de toekomst zal gaan brengen. Van de rechtszaken verwacht ik trouwens niet zo veel, volgens mij hebben in ieder geval Intel, AMD en ARM rechtszaken tegen zich lopen. Maar wat ik er van begrijp hebben ze zich alle 3 juridisch vrij goed ingedekt. En als er al wat uitkomt, zal het zo als eigen alle Class Actions hier in Europa wel weer niet van toepassing zijn.

[Reactie gewijzigd door Dennism op 23 juli 2024 13:10]

[Dennism]

Ik zie niet in wat het niet toepasselijk van 1 variant te maken heeft met het feit of de gehele chip industrie al dan niet al jaren wist kwetsbaarheden als Spectre en Meltdown zoals gesuggereerd in de post boven mij, daar gaat stukje tekst namelijk over. Niet over het feit of alle vendoren even vatbaar zijn of niet, want daarvan is algemeen bekend dat AMD niet vatbaar is enkele varianten.

[Reactie gewijzigd door Dennism op 23 juli 2024 13:10]

[Verwijderd]

En ik reageer niet op jouw gehele schrijven maar op een specifieke opmerking die je maakt.

En dat 'algemeen bekend', tja AMD is dus vatbaar voor vijf van de zes Spectre varianten, niet voor Meltdown en ik weet niet of ze vatbaar zijn voor Lazy FP Restore. Die 'enkele varianten', dat zijn er dus twee. Minimaal aantal om van 'enkele' te spreken nietwaar.

Verder is het niet zo onwaarschijnlijk dat men hier nog niet van af wist, of in ieder geval dat men als men er al een vermoeden van had, dat het te onwaarschijnlijk werd geacht dat het in het 'wild' een probleem zou kunnen vormen ( aka dat er een werkbare exploit voor zou komen ). Denk eigenlijk het laatste, niet het eerste.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 13:10]

[Dennism]

Die specifieke opmerking (juist het deel dat je quote) gaat echter niet over het specifiek vatbaar zijn van een vendor zijn en al helemaal niet over eventuele varianten, maar over het feit of ik het aannemelijk vind dat de gehele chipindustrie (dus Intel, AMD, ARM, Apple, Sansung, Oracle, IBM noem ze allemaal maar op) al jaren wisten van het bestaan van dit soort beveiligingsrisico's en daar dus niet pas 30 juni door Google's project zero van op de hoogte gebracht zijn.

Ik zeg met "ik zal niet zeggen dat het niet zo is" dat ik mijn hand niet in het vuur ga steken voor Intel, AMD, ARM, Apple, Sansung, Oracle, IBM noem ze allemaal maar op dat ze niet al jaren wisten dat dit soort risico's in hun cpu's zitten, maar dat ik dat wel onwaarschijnlijk acht daar het zeer lastig zal zijn om binnen als die bedrijven iedereen zo ver te krijgen dat er niemand uit de school klapt.

Om toch even op je punt te reageren, volgens eigen zeggen is AMD niet vatbaar voor Meltdown, Spectre 1.2 en Spectre 3a, dat zouden er dus minimaal 3 zijn. Zie ook : https://www.amd.com/en/corporate/security-updates

[Reactie gewijzigd door Dennism op 23 juli 2024 13:10]

[Verwijderd]

3a ook nog, moet niet reageren als ik niet helemaal 'helder' ben Meltdown was natuurlijk algemeen bekend, maar dacht dat het 'maar' twee van de Spectre varianten waren welke niet werkten op AMD.

En over het uit de school klappen. het mogen dan wel grote bedrijven zijn ik neem aan dat a> het aantal personen dat genoeg kennis had om het te vermoeden / weten vrij klein was en b> dat het onder deze mensen toch ook niet onaannemelijk is om te verwachten dat 'men' er van uit ging dat de kans dat er ooit een werkbare exploit voor bedacht cq. gemaakt zou worden niet opwoog tegen de winst die behaald is met de geïmplementeerde risico's. Mijn vraag is meer of deze 'men' alleen de ontwerpers waren of toch ook management. Management kan ik mij niet voorstellen dat dit niet eerder uitgelekt zou zijn, mijn gedachte is dus ontwerpers op zijn hoogst, en dat deze 'gewoon' dit risico niet zo hoog hadden ingeschat.

edit: en ik claim dus ook niet dat ik verwacht dat ontwerpers van al deze fabrikanten het risico wel onderkenden maar niet hoog genoeg ingeschat hadden, dat hoeft volgens mij niet ( er wordt toch ook wel een beetje leentje-buur gespeeld met principiële zaken, het wiel niet opnieuw uitvinden zal ook opgegaan zijn ).

[Reactie gewijzigd door Verwijderd op 23 juli 2024 13:10]

[i-chat]

journalistiek is hier anders niet terzake, dit hele artiekel begint vanuit het oogpunt van blackhat. daar wordt een en ander gesteld, waaronder de moeilijkheid van het oplossen van problemen als spectre.

Intel is hier niet eens relevant omdat zei verantwoordelijk zijn voor de hardware fixes die later komen tot die tijd moeten bedrijven als redhat mircosoft en google (en hun hardwarepartners) software bedenken om het probleem tijdelijk af te plakken met de bekende ductape-methode.

In het artikel komt ook duidelijk naar voren dat dit precendent schept omdat dit wellicht de eerste keer is in de geschiedenis dat de 3 grootste concurenten gezamelijk aan oplossingen voor een bug hebben gewerkt. Wanneer er dan gezegd wordt dat ze daarbij extra problemen ondervonden omdat bepaalde personen niet mee konden werken, is dat eerder een situatieschets dan een aanval op intel. en is wederhoor dus ook helemaal niet nodig. Als intel dan toch wil reageren op zulke opmerkingen is dat prima. maar nog steeds nauwelijks relevant.

[Origin64]

Ik vind het eerder een aanval dan een situatieschets. Lekker makkelijk roepen als het niet jouw IP is.

[Verwijderd]

Exact dit. Had koffie klaar staan. Wat ik overigens ook nog steeds niet gezien heb is een benchmarkoverzicht van ongepatchte pc's tot de laatste patches. Komt dat nog langs, Tweakers?

[totaalgeenhard]

IME en dit verhaal is al maanden heel schimmig en ik zie maar geen kritische verhalen over de voortgang.

Verhalen over hoe drie concurrenten moesten samenwerken lees ik liever over 3 jaar in e.a. overview boek met best practises.

Ik verwijt auteur niets overigens.

Als blackhat over beleid gaat tegenwoordig zal het snel verleden tijd zijn.

[Reactie gewijzigd door totaalgeenhard op 23 juli 2024 13:10]

[PPie]

Timelime van betrokken partijen zijn niet relevant zolang de grote boosdoener Intel niet in het verhaal voorkomt.

Het is niet alleen Intel, maar deze wordt zeker wel in het stuk genoemd?
Het is een algemeen probleem waar verschillende processor implementaties gevoelig voor zijn. Ook laatste Apple's Ax processoren, Samsungs Exynos (dit staat ook in het stuk), AMD's en nieuwste ARM varianten zijn gevoelig voor deze problemen.

[totaalgeenhard]

Maar die anderen zijn voor mij en velen met mij niet relevant.

Bovendien kun jij me een link geven naar PoC of beschrijving van PoC testen?

Want alles wat ik.heb gelezen is dat alleen op Intel met succes 3 generaties in 1 jaar van het zelfde probleem bestaat. En elke keer ontkende Intel.

[PPie]

Maar die anderen zijn voor mij en velen met mij niet relevant.

Waarom niet? Je lijkt Intel te bashen (die in dit artikel in alinea 3 genoemd wordt, trouwens), maar je bent niet geïnteresseerd in andere architecturen? Apart.

Bovendien kun jij me een link geven naar PoC of beschrijving van PoC testen?

Want alles wat ik.heb gelezen is dat alleen op Intel met succes 3 generaties in 1 jaar van het zelfde probleem bestaat. En elke keer ontkende Intel.

In de eerste link (Spectre variant 1) staan AMD en ARM genoemd.
Apple heeft patches voor macOS en iOS geleverd, dus blijkbaar zijn niet alleen de Intel maar ook de Ax processoren vatbaar.
ARM heeft er een developer note over gemaakt.
In het artikel staat dat de Exynos uit de Galaxy S7 vatbaar is.
Waarom denk je dan nog steeds dat Intel de enige is die vatbaar is?

[robvanwijk]

En zelfs vandaag blijkt uit niets dat Intel regie van dit verhaal naar zich getrokken heeft en aan meltdown vrije CPU werkt.

Uiteraard werken ze daaraan, maar dat kost tijd. Bij software kun je de fix toevoegen, opnieuw compilen en de nieuwe versie uitbrengen. Dat is bij hardware simpelweg geen optie.

Zelfs al zou het een triviale fix zijn ("oeps, één transistor vergeten; die even toevoegen en beginnen met productie van het nieuwe model") dan nog kost het maanden voordat de eerste gecorrigeerde chips van de band rollen. En voor de duidelijkheid, deze fixes zijn absoluut niet triviaal.

Deze ontwerpfout zit heel erg diep in de architectuur, daar kun je niet zomaar gaan lopen sleutelen. Ja, ik weet dat het (in theorie) lekker simpel klinkt, maar op dit niveau heeft alles invloed op alles. Zie het maar als "we hoeven slechts één domino om te gooien, dat kan toch niet moeilijk zijn?"; wel als het de bedoeling is dat alle andere steentjes blijven staan. Vroeger gebruikte Intel het ""tick-tock model": om en om een nieuw proces ("kleinere transistors") en een nieuwe architectuur. Toentertijd zouden ze relatief snel een volledige fix hebben kunnen uitbrengen. Vandaag de dag is het echter "tick-tock-refresh1-refresh2" of iets dergelijks. Het is zeer onwaarschijnlijk dat dit probleem voor de volledige 100% in hardware kan worden opgelost tot de eerstvolgende echt nieuwe architectuur.

de grote boosdoener Intel

Als je het woord "boosdoener" gebruikt suggereer je dat Intel dit probleem opzettelijk heeft gecreëerd. Dat is volkomen absurd. Ja, ze zijn de "schuldige" (het was hun fout), maar ze zijn niet de "dader" (er was geen kwade opzet). Het mag een subtiel verschil zijn, ik vind het wel een belangrijk verschil.

[totaalgeenhard]

Ze hebben de waarschijnlijk al bij het ontwerp geweten.

Security by obscurity.

Zie ook hoe IME verhaal is gelopen en ook niet is opgelost.

Het enige mooie aan dit verhaal en zeker als Claes actions verkeerd uit pakken voor Intel dat alle IC producenten bekende fouten eruit gaan halen en actief hun ontwerp gaan reviewen.

[robvanwijk]

Ze hebben de waarschijnlijk al bij het ontwerp geweten.

Was het aluminiumfolie in de aanbieding!?

Gigantisch probleem 1: Er is werkelijk absoluut nul bewijs voor die claim.
Gigantisch probleem 2: Wat zouden ze hier in vredesnaam mee winnen?
Gigantisch probleem 3: Welke chips denk je dat er in Intel's eigen computers zitten? Als jouw theorie klopt dan hebben ze willens en wetens een gapende backdoor in hun eigen machines gecreëerd, die misbruikt kan worden door iedereen die de truc ontdekt.
Nog veel groter probleem 4: Stel dat Intel om de een of andere onbegrijpelijke reden opzettelijk besloten heeft om deze fout opzettelijk te maken... hoe verklaard dat dan precies het feit dat chips van onder andere ARM en AMD ook kwetsbaar zijn voor sommige varianten?

[computerjunky]

ik snap niet waarom jij denkt dat intel de regie naar zicht toe moet trekken of waar jij vandaan haalt dat intel niet aan een cpu zonder de lek werkt.
Dit probleem is veel groter als intel alleen dus ieder bedrijf moet zijn ding doen en dit intern oplossen.
Wij weten helemaal niet wat er achter de deuren bij intel speelt en of de komende generatie het probleem opgelost heeft of niet.

[totaalgeenhard]

Ze me reactie hierboven.

Voor mij en velen anderen is iets anders dan Intel niet relevant.

Voor zover ik weet is al 3 generaties van dit probleem alleen middel PoC bewezen op Intel en niets anders.

[cbravo2]

Klopt. Het achterliggende probleem is dat de execution en/of data van een meer gepriviligeerde protection ring zichtbaar/waarneembaar/meetbaar is vanuit een lager protection ring.

Allerlei optimalisatie mechanismes, zoals out of order execution, predictive branch execution bleken hier kwetsbaar voor.

Je kunt je zelfs afvragen of protection rings het beste idee is. Want ook binnen protection rings moeten dingen geheim blijven (je wilt bijv. niet dat je browser bij je email data kan maar dat zit wel op hetzelfde protection ring).

Wat ik me nog afvraag is of de meest basal optimalisatie, cache, ook kwetsbaar kan zijn.

[pruik6]

Hoe update je een Intel cpu met firmware, om de cpu te beveiligen?
Kan het niet vinden op de Intel site of waar dan ook.

Heeft iemand voor mij een link voor een tutorial?

[keranoz]

Het is aan de ontwikkelaar van het OS om de workaround te implementeren. In het geval van Microsoft is dit al lang gebeurd. Deze update heb je hoogstwaarschijnlijk al lang binnen.

[Reactie gewijzigd door keranoz op 23 juli 2024 13:10]

[pruik6]

Okay dankje, ik dacht dat ik hoorde dat er ook firmware update zou komen van Intel.
Misschien heb ik me vergist

[SoundByte]

Wat als je je computer airgapped houdt of alleen binnen een thuisnetwerk aan het internet hangt achter een goede router?

[Dennism]

Airgapped zou geen issue mogen zijn, wel zorgen dat er geen anderen dan jij op die machine kunnen komen en processen uit kunnen voeren.

in netwerk (al dan niet mer internet) voorzichtiger zijn. Minimaal zorgen dat je browsers up-to-date zijn, zorgen dat er geen onbekende processen draaien of gedraaid kunnen worden. best practise uiteraars gewoon zorgen dat OS, Software en eventuele firmware up-to-date is en de guidance van de fabrikanten / developers volgen.

[Reactie gewijzigd door Dennism op 23 juli 2024 13:10]

[SoundByte]

Hoe waarschijnlijk zou het zijn. Dat deze ernstige beveiligingslekken expres werden ingebakken in chips voor veiligheidsdiensten?

[keranoz]

Dat zou betekenen dat ze zelf ook deze lekken in hun systemen hebben zitten toch? Lijkt me niet iets dat je wil als inlichtingen/veiligheids- dienst?

[RJWvdH]

@duqu
Spectre variant 4 = CVE-2018-3639 en NIET CVE-2018-36340

[kodak]

Volgens Googler Linton was het embargo in handen van de chipmakers. Dat betekent volgens hem dat er mensen waren die 'in de tent' hadden moeten zitten, maar er niet in zaten. "Google hanteerde het volgende criterium: onderhoud je een besturingssysteem, werk je aan een virtualization stack of aan drivers, dan hoor je erbij."

Dit is een wazige uitspraak. Hoe lag het embargo in handen van de chipmakers? De onderzoekers ontdekken security fouten en hebben controle over het vrijgeven van informatie. Die beslissen wie ze informeren en welke voorwaarden er gelden. Wie ze informeren kunnen andere belangen hebben en daar kan je dan met elkaar over in discussie. Tenzij de onderzoekers hun controle en verantwoordelijkheid weg hebben gegeven lijkt het me onzin dat het embargo in handen van de chipmakers lag.

Het criterium van Google verschilt vervolgens dan op wie betrokken zou moeten zijn.

Het wekt de indruk dat er geen overeenstemming was over wie waar over ging.

[Reactie gewijzigd door kodak op 23 juli 2024 13:10]

[Grimm]

Wat ik mis in het artikel is hoe Intel probeert aan damage control te doen:

https://www.theregister.c.../intel_spectre_fix_linux/

[LEX63]

Hoe kan ik die Meltdown en Spectre beveiliging update van Microsoft verwijderen. Mijn 4e gen I7 notebook is een stuk trager geworden de ventilator draait continu op hogere snelheid.

Ik wil van deze update af. Dan neem ik het risico maar als de boel plat gaat. bij gebruik van een simpel programma dan loop de notebook tegen de 100% te hikken dit is ook niet gezond.

Als iemand een link heeft graag.

[Reactie gewijzigd door LEX63 op 23 juli 2024 13:10]

[Dennism]

Er even vanuit gaande dat je Windows bedoelt: https://support.microsoft...hannel-vulnerabilities-in daar staan registry settings om de fixes te beheren (aan en uit te zetten).

Ik zou er echter niet direct vanuit gaan dat de problemen die jij hebt hieraan gerelateerd zijn, ik heb redelijk wat laptops en desktops gepatched tot nu en geen enkele laat vergelijkbare problemen zien als die jij hebt.

Ik zou eerder als ik jou was eens een volledige herinstallatie doen van de laatste windows versie met de laatste drivers e.d. Die issues die jij aangeeft te hebben lijken eerder op een vervuilde windows installatie dan op een meltdown / spectre issue.

[LEX63]

De installatie is 4 maanden oud. Ik heb de originele harddisk kan daar zo een kloon van maken. Ik weet niet of dit het probleem oplost. Ik zal vandaag alle data eraf kopiëren en een kloon van de originele harddisk naar mijn SSD maken.

[LEX63]

Bedankt voor de link en de tip.

[Verwijderd]

Hiermee kan je de Meltdown patch uitschakelen als dat nodig is https://www.grc.com/inspectre.htm

[LEX63]

Bedankt voor de tip.

[SoundByte]

Er bestaan appjes zoals *notebookfancontrol*. Wel zelf letten op wat de max. werktemp van je proc is.

[Reactie gewijzigd door SoundByte op 23 juli 2024 13:10]