Intel vraagt voorlopig patches voor cpu-lekken te stoppen op bepaalde systemen

Intel heeft in een nieuwe mededeling fabrikanten, softwaremakers en eindgebruikers aangeraden om de huidige versie van zijn Spectre-patches niet toe te passen op bepaalde systemen. Het zegt de oorzaak van de herstartproblemen te hebben gevonden.

Intel schrijft dat het de oorzaak van de herstartproblemen, die het gevolg waren van de patches, heeft kunnen achterhalen op Haswell- en Broadwell-systemen. Daarom raadt het aan om de huidige patches niet door te voeren op bepaalde systemen, waaronder ook systemen met nieuwere processors van bijvoorbeeld de Kaby Lake- en Skylake-generatie. Het volledige overzicht is te vinden in een lijst. Daarin staan de microcodeversies die niet toegepast dienen te worden en de versies die volgens Intel wel bruikbaar zijn.

Doordat de oorzaak nu bekend is, vraagt Intel zijn partners om de nieuwe code te testen om het uitbrengen van stabiele patches te versnellen. De chipmaker heeft gedurende het weekend een testversie onder zijn partners verspreid en wil de definitieve versie uitbrengen zodra de tests zijn afgerond. Voor gebruikers met getroffen systemen lijkt dit te betekenen dat het wachten is op nieuwe updates van fabrikanten, al schrijft Intel nog steeds dat het consumenten aanraadt om hun systemen up-to-date te houden.

In de eerdergenoemde lijst zegt Intel nog dat het met oem's aan een optie werkt om oudere maar stabiele microcode te gebruiken die mitigations voor de eerste Spectre-variant en Meltdown bevat, maar geen bescherming tegen de tweede Spectre-variant heeft. Dit is dan ook de variant die voor problemen zorgt. Onlangs meldde Intel dat het op de hoogte was van herstartproblemen op Broadwell- en Haswell-systemen, maar een week later bleken ook nieuwere cpu's geplaagd te worden door dezelfde verschijnselen. Uit de huidige communicatie komt niet duidelijk naar voren of Intel nu ook daarvan de oorzaak heeft achterhaald.

Reacties (70)

[Dennism]

Let er wel op dat dit alleen gaat over microcode updates (o.a. Bios / Uefi, Linux / Vmware installaties die deze bij het booten laden) / voor Spectre Variant 2 (CVE-2017-5715), hiervan komen ze met een nieuwe Microcode revisie. OS patches voor Spectre 1 en Meltdown (CVE-2017-5753 en CVE-2017-5754) of gecombineerde updates waar ook OS updates voor CVE-2017-5715 inzitten maar geen Microcode zouden gewoon geïnstalleerd moeten worden (tenzij je al wel de microcode geupdate hebt, en nog niet het OS, dan is het verstandig ook even te wachten met OS updates voor CVE-2017-5715).

O.a. de MS Windows patches komen niet met Microcode (tenzij je een surface hebt) en kun je dus veilig installeren zolang je wacht met het updaten van de Microcode tot Intels nieuwe revisie uit is.

[Reactie gewijzigd door Dennism op 22 juli 2024 19:55]

[tijgetje57]

De Windows patches zijn ook niet handig om te installeren. Als je een loadbalancer hebt en je wilt de sessie van een gebruiker schaduwen kan dat dus niet meer. In het geval waar ik zit de enige manier om gebruikers te ondersteunen.

Je patched je Windows laag, maar als je AV client niet up2date is of gekwalificeerd dan krijg je BSOD op je systemen.

Wij zijn met zijn allen aan het rennen, maar weten niet waar naartoe.

Je krijgt met de Meltdown snippets van data. Oftewel je hebt een shredder, papier is vernietigd. Je leegt de vuilnisbak van de shredder en er blijven wat snippets in zitten. Dat wil niet zeggen dat er meteen wachtwoorden of andere data gelekt is....

Als je de RDSH omgeving goed beveiligd dan loop je lang niet zoveel gevaar als dat anderen zeggen\beweren.

[Reactie gewijzigd door tijgetje57 op 22 juli 2024 19:55]

[EraYaN]

Als je daadwerkelijk deze sidechannel gebruikte om een sessie te schaduwen (bedenk wel dat de snelheid echt verschrikkelijk traag is), dan is er iets heel goed mis met je software of je procedures, als dat een benodigde functie is, waarom kan de software dit zelf dan niet? Daarbij gaat de schaduw bandbreedte omhoog van enkele kilobits naar gewoon de memory bandwidth lijkt me toch een stuk wenselijker.

Daarbij installeert de update niet eens als je een slechte/karige AV hebt. De meeste grote jongens zullen er nu wel zijn, als ze dat nog niet zijn is het tijd om te switchen van vendor, want ze geven schijnbaar erg weinig om hun klanten.

[tijgetje57]

De sidechannel in 2012 R2 werkt erg goed en is beslist niet traag.

Al onze RDSH servers staan volledig op SSD op een dedicated vmware omgeving. Wij hebben published apps draaien. Binnen die zorg applicatie is het niet mogelijk om je scherm te delen. Helaas...

Daarom is het nodig.

[EraYaN]

Nouja dan wisten jullie natuurlijk dat jullie processen slecht waren en dat het een keer ophield, dus ik hoop dat jullie daar dan ook al over nagedacht hebben hoe dat op te lossen (schiet de vendor eens aan bijvoorbeeld). Het gebruik van een side-channel exploit in productie, het moet niet gekker worden.

[tijgetje57]

Ach de processen zijn niet slecht, de software is slecht en daar hebben wij een manier omheen gemaakt met passen en meten. Die voldeed prima tot er een patch kwam die het shadowen van sessies onmogelijk maakt. Het shadowen van sessies doe ik al jaren. En het heeft altijd excellent gewerkt.

Hopelijk komt er gauw weer een patch die het mogelijk maakt om het weer te gebruiken.
Anders lijkt het net weer op server 2012 waar het niet kon, gelukkig hebben wij die brakke editie overgeslagen.

De applicatie wordt hopelijk met enkele maanden uitgefaseerd, daarmee komt er een einde aan deze era van werken.

[Rutix]

Maar zoals @EraYaN al zegt en jij ook nog onderstreept was de manier van shadowen een houtje touwtje ding om ergens omheen te werken omdat de software crap was. Dan moet je de vendor van die software daarop aanspreken en zo nodig had je in die tijd dat het dus al werkte moeten kijken naar een andere vendor of het laten fixen.

[tijgetje57]

Makkelijker gezegd dan gedaan, de oplossing was goed. Je maakt gebruik van de middelen die je tot je beschikking hebt om je werk goed te kunnen doen.

Dit soort patches slaan nergens op om features te breken.

Sterker vanuit Intel, waar het startte met het Meltdown gedonder, hebben ze al gezegd dat wij massaal moeten stoppen om te patchen. AMD brick je met de updates en met Intel heb je grote kans op performance degradatie en reboots van je hosts.

[Rutix]

Nee omdat iets werkt betekent nog niet dat de oplossing goed is. De hele manier zoals jij beschrijft hoe het is gegaan is vaak de situatie die ik aantref als organisaties met de handen in hun haar zitten als het op een gegeven moment niet meer werkt. Ze bedenken een oplossing die tijdelijk moet zijn maar ipv de tijd die ze hebben (bijvoorbeeld in jou woorden jaren) te gebruiken om voor een goede oplossing te gaan die ook toekomst vast is. Gebeurt er vervolgens niks. En krijg je situaties zoals dit. Er is blijkbaar niks zo permanent als een tijdelijke oplossing.

Daarnaast "Dit soort patches slaan nergens op om features te breken." is natuurlijk onzin. Als je als eigenaar van je product meer waarde hecht aan een security issue dan kun je prima een feature kapot laten gaan.

De performance degradatie was al helemaal vanaf begin bekend en is inherent aan de oplossing. Je moet even begrijpen dat dit zo'n ingrijpend en de impact van dit beveiligings issue zo groot was, dat iedereen heeft geracet om de lekken te dichten zodat ze het daarna kunnen finetunen. Je kunt er natuurlijk ook voor kiezen om helemaal niet te patchen maar dat is gewoon onverantwoord.

[Reactie gewijzigd door Rutix op 22 juli 2024 19:55]

[tijgetje57]

De applicatie betreft een published app, er is geen interactieve logon.

Daarom ideaal als je de sessie kan shadowen, dit omdat je dan rechtstreeks in de applicatie met de gebruiker mee kan kijken.

[Dennism]

Ik kan me inderdaad goed voorstellen dat RDS shadowing hierdoor getroffen zou kunnen zijn daar je eigenlijk ingrijpt op een ander proces. Gelukkig hebben wij andere vormen van shadowing (wij shadowen de o.a. de thinclients met de HP management software) en impact dit ons niet. Maar het zou voor mij denk ik ook geen reden zijn om niet te patchen, zeker daar MS juist RDS hosts als extra kwetsbaar ziet voor deze vunerabilities. https://portal.msrc.micro...idance/advisory/ADV180002 (O.a. FAQ punt 1).

AV mag echter geen issue zijn, tenzij je zelf de update geforceerd installeert door zelf de registry te zetten zal deze in principe alleen geïnstalleerd worden als je AV developer via een geupdate / gecertificeerde versie een bepaalde registry key zet. Zie bijv: https://support.microsoft.com/nl-nl/help/4056890 (Server 2016 KB).

[Reactie gewijzigd door Dennism op 22 juli 2024 19:55]

[tijgetje57]

Die ken ik ook, de VNC client.

Echter wij hebben medewerkers op veel locaties en teamviewer werkt ook niet op alle locaties i.v.m. local policies.

Met een RDSH published app was dit de ideale methode.

[KillerAce_NL]

Shadowen van RDSH is vanaf 2012 al brak en er is verklaard dat dit ook niet gefixed zou worden (oa. dual monitor issues etc). Gebruik remote assistance. Echetr ik denk dat het een specifiek probleem voor jullie is, anders waren er al 1000en forum post van xenapp/rdsh gebruikers.

[tijgetje57]

In 2012 zat het niet in. 2012 R2 had het pas weer erin zitten.

Daarom zijn heel veel bedrijven ook niet overgestapt van 2008 R2 naar 2012, maar naar 2012 R2.

[GiLuX]

toch geestig dat hele gedoe rond deze 'lekken' terwijl 99% van de wereld rustig met ACPI/firmware draait op zijn pc/hardware die vol kan zitten met trojans/spyware/malware zonder dat we dat weten en het hele OS kwetsbaar is zonder dat we het zelfs maar kunnen toetsen.

linus thorvalds:

Modern PCs are horrible. ACPI is a complete design disaster in every way. But we're kind of stuck with it. If any Intel people are listening to this and you had anything to do with ACPI, shoot yourself now, before you reproduce.

mark shuttleworth:

If you read the catalogue of spy tools and digital weaponry provided to us by Edward Snowden, you’ll see that firmware on your device is the NSA’s best friend. Your biggest mistake might be to assume that the NSA is the only institution abusing this position of trust – in fact, it’s reasonable to assume that all firmware is a cesspool of insecurity courtesy of incompetence of the worst degree from manufacturers, and competence of the highest degree from a very wide range of such agencies.
...
Arguing for ACPI on your next-generation device is arguing for a trojan horse of monumental proportions to be installed in your living room and in your data centre. I’ve been to Troy, there is not much left.

gelukkig werkt google aan een compleet nieuwe implementatie genaamd NERF maar tot die tijd denk ik dat je je meer druk moet maken om ACPI (/UEFI/firmware in general) dan deze twee cpu lekken als het op security aankomt.

[Reactie gewijzigd door GiLuX op 22 juli 2024 19:55]

[tijgetje57]

Als je virussen gaat schrijven in machinetaal/aansturing is de hele wereld economie binnen een week kapot.

[The Zep Man]

Voor gebruikers met getroffen systemen lijkt dit te betekenen dat het wachten is op nieuwe bios-updates van moederbordfabrikanten, al schrijft Intel nog steeds dat het consumenten aanraadt om hun systemen up-to-date te houden.

Het is niet nodig om een BIOS update uit te voeren om microcode updates te installeren. Deze worden namelijk (ook) door het besturingssysteem tijdens het opstarten ingeladen. Het is handig als het in de BIOS zit, maar het risico van een BIOS update is hoger dan een update van het besturingssysteem.

Het herstartprobleem is ook niet zo groot als dat het lijkt. Zoals het artikel al hint zullen besturingssysteembakkers nieuwe microcode updates in nieuwe OS updates uitbrengen. Daarmee is dit probleem ook opgelost. Het enige (kleine) risico dat er tot dat moment is, is dat het systeem herstart tijdens een update. Dat risico is echter makkelijker te mitigeren dan een gebrickte computer door een afgebroken BIOS update.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 19:55]

[Mic2000]

Dus als ik je goed begrijp zijn de updates van Intel aanwezig in de updates van Windows en hoef ik dus geen speciale software van intel zelf te downloaden?

[The Zep Man]

Precies. Hetzelfde voor veel Linux distributies (de welbekende 'intel-ucode' packages).

Je processor zelf bevat microcode, maar die kan nooit geactualiseerd worden ('hard-coded'). Wat het BIOS en/of het besturingssysteem kan doen is nieuwe microcode aanbieden die de processor kan gebruiken in plaats van de ingebouwde microcode, in ieder geval tot de eerstvolgende reboot.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 19:55]

[Dennism]

Voor zover ik kan vinden niet, MS lijkt alleen Microcode voor de surface via Windows update te distribueren. Bij de overige patches geven ze juist aan dat extra microcode updates vanuit de fabrikant moeten komen voor Spectre 2 (CVE-2017-5715), zie o.a. de Warning in dit document: https://support.microsoft...hannel-vulnerabilities-in

Warning

Customers who only install the Windows January 2018 security updates will not receive the benefit of all known protections against the vulnerabilities. In addition to installing the January security updates, a processor microcode, or firmware, update is required. This should be available through your device manufacturer.


Note Surface customers will receive a microcode update via Windows update.

[The Zep Man]

Voor zover ik kan vinden niet, MS lijkt alleen Microcode voor de surface via Windows update te distribueren.

Het werkelijke antwoord is subtieler. Zie bijvoorbeeld dit (microcode updates voor servers) en dit (ook voor clients, en oudere besturingssystemen dan dat draaien op de Surface).

Het kan zijn dat Microsoft deze update (nog) niet wilt doorvoeren door de mogelijke negatieve invloed op de systeemprestaties.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 19:55]

[Dennism]

Bij de server guidance hetzelfde: https://support.microsoft...the-speculative-execution

In addition to installing the January security update, a processor microcode update is required. This should be available through your OEM.

en

Q2: How can I tell whether I have the correct version of the CPU microcode?

A2: The microcode is delivered through a firmware update. Consult with your OEM about the firmware version that has the appropriate update for your CPU.

Ik weet dat MS in het verleden wel Microcode updates gepushed heeft via Windows update, maar voor deze Microcode updates lijken ze dat expliciet (nog) niet te willen doen, behalve surface hardware (uiteraard omdat ze daar zelf de OEM zijn). Het kan inderdaad goed zijn dat dit komt vanwege de performance impact, of omdat ze (terecht zo blijkt) nog niet overtuigd zijn van de stabiliteit van deze Microcode update of mogelijk omdat er in deze afspraken gemaakt zijn over deze distributie. Gezien het een industrie breed issue is zou dat ook nog een optie kunnen zijn.

[Reactie gewijzigd door Dennism op 22 juli 2024 19:55]

[Mic2000]

Aah thanks voor de uitleg! In geen enkel artikel is mij dat duidelijk naar voren gekomen, noch waar ik de juiste updates installeer, met veel zoekwerk leek het te zijn dat ik alleen Windows updates moest installeren en het daarmee voldoende zou zijn, maar niet wetende dat het gaat om microcode en dat er hard-coded niks kan veranderen. Mogelijk in de toekomst dus ook de Bios update als ik weet dat dit stabiel draait. Thanks nogmaals voor de uitleg!

[Reactie gewijzigd door Mic2000 op 22 juli 2024 19:55]

[halfgaar]

Let wel, intel-ucode staat standaard niet geïnstalleerd, en komt ook niet automatisch mee als beveiligingsupdate.

Let ook op dat het je bootprocedure aanpast. Hij chain-load van ucode lader naar de kernel.

[ShellGhost]

Waarom is dat? De meeste bios'en hebben een fallback mechanisme waar gebruik van gemaakt kan worden als het mis gaat. Daarbij kan het met sec updates binnen een OS net zo fout gaan als met een bios update.

[The Zep Man]

Waarom is dat? De meeste bios'en hebben een fallback mechanisme waar gebruik van gemaakt kan worden als het mis gaat.

Het OS heeft een fallback mechanisme. Het BIOS doet daar niets mee. Dit wordt geïnitieerd vanuit de bootloader.

Daarbij kan het met sec updates binnen een OS net zo fout gaan als met een bios update.

Met OS security updates die fout gaan heb je geen brick, maar mogelijk alleen een besturingssysteem dat niet meer opstart. Via de recoveryfunctie kan je veelal de laatste updateronde ongedaan maken.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 19:55]

[DarkBlaze]

Euh, de meeste moderne biossen hebben wel een recovery mechanisme of een 2e bios.

[The Zep Man]

Euh, de meeste moderne biossen hebben wel een recovery mechanisme of een 2e bios.

Sommige moederborden hebben een dual BIOS, maar het valt tegen hoe toch een BIOS verkloot kan worden. Soms is er een low-level recovery methode. Het gebruik daarvan zal altijd meer moeite kosten dan het herstellen van een slechte besturingssysteemupdate.

Als een organisatie +10.000 computers heeft, reken er dan maar niet op dat BIOS updates uitgevoerd worden als het probleem dat zo'n update oplost ook op OS niveau volledig gemitigeerd kan worden.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 19:55]

[DarkBlaze]

[...]
Het OS heeft een fallback mechanisme. Het BIOS doet daar niets mee. Dit wordt geïnitieerd vanuit de bootloader.


[...]
Met OS security updates die fout gaan heb je geen brick, maar mogelijk alleen een besturingssysteem dat niet meer opstart. Via de recoveryfunctie kan je veelal de laatste updateronde ongedaan maken.

Hier schrijf je het toch echt alsof alleen het OS dit heeft

Overigens heb ik in die paar jaren dat ik in de pc winkel stond nooit een gebrickte BIOS gehad. Wel eens gehad dat door een bug in de BIOS ik hem moest herstellen vanaf de 2e BIOS en dat duurde wel geteld nog geen 5 minuten een Windows recovery duurt langer hoor

[Reactie gewijzigd door DarkBlaze op 22 juli 2024 19:55]

[tijgetje57]

Vind het zo en zo onzinnig om alleen het OS te patchen omdat er een gat in de CPU zit qua beveiliging...

[Mopperman]

Bios updates worden vaak dan ook vanuit het OS uitgevoerd/ingeladen. Het voordeel hiervan is, wat ik zie bij bijv. dell, dat de PC bij een herstart de bios update pas installeerd.

Het voordeel hiervan is dat je, met een software deployment tool, heel envoudig al die bios updates buiten werktijd kan uitvoeren. Hier doen we dat ook op deze manier en de enige die we horen zijn af en toe eens een laptopgebruiker dat zn laptop raar opstart....

[aadje93]

Toch kon mijn w10 na de 'update' zelfs Recovery niet meer doen en werd het gewoon een schone verse installatie (die al wat langer op de planning stond)

[AmigaWolf]

Ik heb nog nooit problemen gehad met een BIOS update, en heb er al heel wat gedaan, en als je het in de BIOS zelf doe de BIOS update is de kans dat er wat fout gaat al helemaal klein.

Nee heb liever een BIOS update dan een Windows update, maar die zal ik jammer genoeg niet krijgen voor mijn Z97 MB en Q87 MB, alleen de nieuwere moederborden vanaf H110 krijgen die BIOS update.

Hier kan je zien of jouw MB een BIOS update krijgt: https://www.bleepingcompu...down-and-spectre-patches/

[Reactie gewijzigd door AmigaWolf op 22 juli 2024 19:55]

[duqu]

Thanks, ik heb het aangepast!

[Tortelli]

Ik vraag me af welke recente CPU's geen last hebben van het herstart probleem?.

Ben overigens wat afwachtend met updaten vanwege deze problemen, daarnaast is er nog geen bios update voor mijn Z97/4790k......

[Reactie gewijzigd door Tortelli op 22 juli 2024 19:55]

[Dennism]

Het is heel random, en schijnbaar vrij willekeurig. Ik had voordat de Bios/UEFI terug getrokken waren door o.a. Dell en HPE en VMware adviseerde de stoppen met de uitrol terug getrokken waren bijv. al wat servers geupdate (en ook mijn eigen laptop als test voor verdere uitrol bij client machines) en ben nog geen reboot tegen gekomen.

[Neko Koneko]

Als iets random is, is het inderdaad willekeurig

[Dennism]

Lol slaap nog niet uit, even aangepast.

[Verwijderd]

Hoe weet je dat? Een server is waarschijnlijk in 5 seconden opnieuw opgestart. Dat is (denk ik) moeilijk voor monitoring systemen om te signaleren.

[Dennism]

Een fysieke server (bijv. vSphere host) start echt niet in 5 seconden op, maak daar eerder maar een paar minuten van, als het niet langer is. Een lege VM kun je inderdaad mits de onderliggende storage snel genoeg is (bijv. all flash) in een paar seconden starten, maar bij een fysieke host met al zijn checks en het inladen van bijv. vSphere zelf gaat je dat echt lukken. En als je monitoring niet merkt dat in zo'n geval de host en de bovenliggende VM's downgaan (tenzij je iets als Fault tolerance gebruikt) dan is er toch echt iets mis met je monitoring.

[GillisB]

Ik stel me ook enkele vragen... (Alsook eigenaar van een 4790K)
Devil's Canyon (4790K & 4690K) is niet vermeld op de lijst van Intel... ??
IJdele hoop zeker om te denken dat die geen last hebben van al die toestanden...

[Tortelli]

Hebben ze wel helaas.

[tijgetje57]

Maar je bent vrij om het niet te installeren.

[HKLM_]

" Intel nog dat het aan een stabiele patch werkt die mitigations voor de eerste Spectre-variant en Meltdown bevat, maar geen bescherming tegen de tweede Spectre-variant heeft. "

Hoelang weten ze niet al van dit lek Het zal vast niet makkelijk zijn om dit te fixen maar volgens mij hebben ze dit onder de pet willen houden.

[Dennism]

Dat staat er niet voor zover ik kan zien, alleen dat ze een terugval aanbieden naar een oudere microcode die deze reboot issues niet heeft, maar dus ook geen specte 2 mitigations heeft.

Uit Intels lijst (https://newsroom.intel.co...ocode-update-guidance.pdf)

For those concerned about system stability while we finalize the updated solutions, we are also working with our OEM partners on the option to utilize a previous version of microcode that does not display these issues, but removes the Variant 2 (Spectre) mitigations. This would be delivered via a BIOS update, and would not impact mitigations for Variant 1 (Spectre) and Variant 3 (Meltdown).

[mysterieworld]

heb die twee patches forceert uitstaan, vind het wel goed geweest

vertraging is duidelijk te merken bij een laptop bijvoorbeeld die met een 640m LE al soms moeite heeft met bepaalde games. Was het spel al bijna niet speelbaar, is het met deze patch waar ik overgist niet om gevraagt hebt al helemaal niet meer mogelijk. Ik gebruikte al een I7 3610QM

Via deze tool en of via register wijzing, kun je het uitschakelen.

https://www.grc.com/inspectre.htm

Deze onderste werkt ook voor AMD.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management]
"FeatureSettingsOverrideMask"=dword:00000003
"FeatureSettingsOverride"=dword:00000003

[Reactie gewijzigd door mysterieworld op 22 juli 2024 19:55]

[croiky]

Dank voor info en link. Leuk om te zien dat dhr. Gibson nog steeds on top of things is

[Chuk]

Kunnen ze in de patch zelf geen extra check toevoegen die naar de requirements kijkt en dan een waarschuwing geeft of het al dan niet voor problemen kan zorgen? Ik vrees dat 90% van de mensen die al manueel een update gaat uitvoeren, er weinig over dit nieuws gaan weten...

[Titan_Fox]

Mijn Dell 7370 (Core-m7 6Y75) met meest recente BIOS (01-2018) heeft zowel met Windows 10 als Linux Mint incidenteel shutdowns tijdens het opstarten - nét voordat de desktop zou moeten verschijnen.

[nullbyte]

Intel "experience what's inside" krijgt ineens een wat negatievere connotatie.

[AOC]

Gelukkig heb ik geen herstartproblemen. Wat ik wel ervaar is enorme traagheid na het updaten van windows op beide pc's (Win7 en 10). Nadat de pc is opgestart lijkt de pc nog een kwartier bezig te zijn met iets. Browsen gaat ook enorm langzaam.