Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Intel brengt stabiele Spectre-patches uit voor Skylake en werkt aan bètapatches

Intel heeft stabiele patches uitgebracht voor de tweede variant van Spectre. De patches zijn tot nu toe alleen beschikbaar voor Skylake-processors, maar Intel verzekert dat patches voor andere processors in de komende dagen zullen volgen.

De chipmaker meldt: "Eerder deze week hebben we productieversies van microcode-updates voor verschillende Skylake-platformen verspreid onder onze oem-klanten en partners en we verwachten hetzelfde voor andere platformen te doen in de komende dagen." Intel blijft daarnaast werken aan bètamicrocode voor andere cpu-generaties, zodat partners en klanten 'de kans hebben om uitgebreide tests door te voeren voordat de code klaar is voor productie'. Het bedrijf merkt op dat de updates in de meeste gevallen beschikbaar komen via firmware-updates.

Intel ondervond problemen met eerdere updates die het voor de tweede variant van Spectre had uitgebracht. In eerste instantie leken deze zich alleen voor te doen op Haswell- en Broadwell-chips, maar later bleken ook moderne generaties getroffen door onverwachte reboots. Vervolgens waarschuwde Intel zijn klanten en partners om updates op basis van tot aan dat moment uitgebrachte microcode niet uit te voeren, waarna verschillende fabrikanten hun updates terugtrokken. Datzelfde deed Microsoft later ook.

Ondanks de problemen zegt Intel in zijn huidige bericht dat het 'niet genoeg kan benadrukken hoe belangrijk het is om updates uit te voeren'. Het verwijst naar onderzoek dat stelt dat mensen vaak te lang wachten met het uitvoeren van updates nadat deze beschikbaar zijn. Intel wijst daarnaast op het verschijnsel dat er na de publicatie van een kwetsbaarheid afgeleiden van de originele exploit beschikbaar komen. Het spreekt de verwachting uit dat dit met Meltdown en Spectre niet anders zal zijn.

Door Sander van Voorst

Nieuwsredacteur

08-02-2018 • 11:50

89 Linkedin Google+

Reacties (89)

Wijzig sortering
Met deze tool kan je checken of je Windows systeem beschermd is: https://www.grc.com/inspectre.htm
Een tool van een link waarvan je de software maken niet kent. Dat is toch basis voor volgende potentiële veiligheidslekken. Zo'n tool zou ik alleen vertrouwen als die van Microsoft of Intel zelf kwam.
Gibson is een enorme flapdrol (zie zijn vlogs/podcasts), maar z'n software is echt wel te vertrouwen. Bovendien is een tooltje dat alleen even 't register uitleest en waarschijnlijk een databaseje met processor(generaties) bevat nou niet een whopping spannend geheel.

[Reactie gewijzigd door guillaume op 8 februari 2018 15:08]

Nee jij kent de software maker niet, wij wel hoor en we weten dat het een betrouwbare bron betreft.
Maar ik ken jou niet. Je hebt niet eens een mooi vinkje bij je naam ofzo. Dus een willekeurig 'persoon' zegt dat een willekeurige andere bron betrouwbaar is. :P
Terrestrial bedoelt eigenlijk dat een beetje tweaker GRC / Steve Gibson wel moet kennen.
Maar wellicht dat ook bij tweakers de generatiekloof zijn intrede doet...
Komt deze firmware patch ook beschikbaar via windows update of is een handmatige patch met een zelfstandige tool nodig?
Als het een CPU microcode update is, zal de UEFI/BIOS moeten worden bijgewerkt. https://sites.google.com/site/computertip/microcode
Voor windows systemen ja, de Linux kernel kan wel degelijk een firmware update uitvoeren tijdens het booten. Of daarna indien nodig.
De linux kernel doet geen firmware update. De Linux kernel vervangt tijdelijk de microcode terwijl het loopt. Dat is overigens ook precies wat de UEFI/BIOS update doet. In beide gevallen wordt de nieuwe microcode geïnjecteerd, er wordt nooit iets geflashed of weggeschreven in de processor.
OK dan wat uitgebreider:
Een CPU heeft over het algemeen geen Flash, alleen RAM en ROM. (Er zijn enkele CPU;s die een flashable SROM hebben, maar dat zijn geen Intel processoren (meer).)
De basis firmware zit hardgebakken op de CPU (ROM), en er kan een update geplaatst worden zodat
er andere Microcode geladen kan worden.
Voor de ondersteuning van allerlei hardware waarbij de drivers een stuk microcode in een device moeten laden is er ondersteuning gemaakt om dit enigszins geordend te laten verlopen. De actuele stand van zaken kan (op de meeste distro's) geinstaleerd worden als het Firmware package.
Onderdeel van dit firmware package is de AMD en Intel microcode. Onderdeel van de kernel is een device driver die snapt hoe op een AMD resp. Intel deze microcode op de CPU geactiveerd moet worden.
Tijdens het booten wordt deve CPU-"driver" geactiveerd die het zij een specifieke firmware file, of een autodiscover nav. CPU een passende firmware file opzoekt en activeert.

Voor de eingebruiker is er een "firmware" package, wat eigenlijk een collectie blobs is die in verschillende randapparatuur geladen moet worden. (In de meeste gevallen betreft het blobs voor WiFi adapters), vandaar dat ik de term firmware gebruik.
Voor jouw informatie er zijn ook CPU's die hun gehele microcode vanaf en floppy disk moesten (laten) inlezen (door een ioprocessor), echter zijn er nog maar weinig in productief gebruik.
Nog even een toevoeging. Onder een aantal Linux varianten kan je de gewoon een microcode update plaatsen in /etc/firmware. Deze wordt dan geladen in de "Early Boot" fase. Op het moment dat je daarna boot van een ander OS is deze microcode patch gewoon weer weg.

Daarom moet de "BIOS" of UEFI code worden aangepast bij veel systemen, zodat het OS onafhankelijk werkt. Deze moeten door de Moederboard fabrikanten beschikbaar gesteld worden via een separate BIOS Flash, of zoals bijvoorbeeld Lenovo doet, via Windows Update flashen, of Microsoft doet met zijn Surface producten, flashen van BIOS via Windows Update.

VMware ESX heeft de Microcode patches ook en die doet het zelfde als Linux. Er kunnen dus twee varianten zijn:
hard flash - via de BIOS/UEFI, OS onafhankelijk en bij iedere boot aanwezig
soft enabled - via OS en alleen tijdens gebruik van specifiek OS
Dat gebeurt alleen als CONFIG_MICROCODE_INTEL actief is.
(of CONFIG_MICROCODE_AMD voor AMD CPU's)

En er is nog de mogelijkheid om dit mat software tooling vanaf de commandline te doen. (zie Windows grc tools maar ook op Linux).

Als Uptrasoft manual methode.
Heb je je link wel gelezen? Daar wordt uitgelegt hoe microcode kan worden geupdate voor een ander OS zonder update van BIOS/UEFI.
Maar dat moet toch steeds bij het booten worden ingeladen lijkt me?
Nee hoor, dat kan gewoon terwijl je er mee werkt en de machine al dagen/weken loopt. Onder Linux eerst de nieuwe microcode naar /lib/firmware kopieren en dan dit commando uitvoeren:

echo 1 > /sys/devices/system/cpu/microcode/reload

Helemaal geen reboot nodig.
Klopt dat moet inderdaad. Biosen hebben vaak een firmware loader die de laatst bekende versie (voor de BIOS) aanbied.
Alleen moeten OEMs ze wel indienen, laten certificeren en de laatste keer dat MS microcode updates gereleased heeft die niet voor hun eigen producten waren is eenmalig jaren geleden gebeurd.
Onder Windows kun je het ook gewoon zelf inladen. Via een tool als bijv. deze https://labs.vmware.com/f...u-microcode-update-driver en de Microcode download van de Intel site zodra ze daar geplaatst worden ( https://downloadcenter.in...essor-Microcode-Data-File , er staat wel bij Linux Microcode datafile, maar de VMware tool kan daar gewoon mee om gaan )
Dat hoeft dan helemaal niet, dat is juist het handige van een microcode, die kan gewoon worden ingeladen tijdens het booten door het OS.

Het is echter wel zo dat je dit het liefste gewoon in zijn geheel gefixed wilt hebben, dus een BIOS/UEFI is wel wenselijk.
Nog beter zou zijn als Intel in één keer ook de MEI eruit sloopt, want die zit ook vol met lekken. Al vrees ik dat dit niet gebeurt. ;)
handig? Ik vind dat meer een enorme kwetsbaarheid op zichzelf. Wat houdt malware tegen om zich te nestelen in je CPU ?
UEFI hacks zijn op dit moment erg klein en zo eenvoudig is het niet.
In theorie zou je dit kunnen injecten in als UEFI-module, maar zoveel weet ik er niet vanaf, dus er zullen vast andere/beter methodes zijn. Verder wil je het kunnen lezen op OS niveau lijkt me.
Volgensmij moet je ook op dat niveau zitten, maar dat weet ik eerlijk gezegd niet.

Naar mijn meten bestaat er geen malware voor de CPU zelf, deze kwetsbaar is gericht op een bepaald gedeelte van de CPU uitlezen dat normaal niet geshared zou mogen zijn, maar dat nu dus via een omweg wel is.

Microcodes zijn ontzettend handig en veiliger dan een BIOS update (in theorie). Je hoeft geen nieuwe BIOS revisie te flashen en het kan worden uitgerold via het OS zelf (snelle uitrol, lage drempel voor consumenten, systeembeheerder hoeft geen 'honderden' handmatig te flashen).
Wel ben ik met je eens dat ik liever een nieuwe BIOS zie, al is het maar om ook kwetsbaarheden in andere (UEFI-)onderdelen te patchen.

[Reactie gewijzigd door foxgamer2019 op 8 februari 2018 13:40]

UEFI is gewoon FAT, en .efi bestanden zijn gewoon PE-executables.
Het is een soort van MS-DOS...
het alleen maar een kwestie van een niet te beveiligen disk formaat aan te passen.

Linux Magazine van Januari 2018 heeft een cover-artikel hierover, blz 14-19, hoe een UEFI exec te maken.
Met microcodes kun je werkelijk alle instructies die de CPU kent aanpassen.... van een add een move maken?... niet heel zinvol en bestl wel dure manier van emulatie...
maar als je de SYSENTER functie iets kan aanpassen zodat er geen kernel mode meer effectief is.... tja. dan is de hele beveiliging omzeep. Zeg niet dat het handiger of veiliger is dan een bios update. Het is van een andere orde een andere bedreiging...
Als je de firmware "handmatig" laad, zorg dan dat dit bij elke boot gedaan wordt. anders ben je na de volgende boot alles weer kwijt. Doordat Windows dit niet standaard doet, kun je OF een BIOS update doen, of na elke boot de microcode loader gebruiken.

(typo's aangepast).

[Reactie gewijzigd door tweaknico op 8 februari 2018 15:20]

Het is echter wel zo dat je dit het liefste gewoon in zijn geheel gefixed wilt hebben, dus een BIOS/UEFI is wel wenselijk.
Daarvoor zijn we echter afhankelijk van de producenten van de moederborden. Ik ben benieuwd in hoeverre die hun verantwoordelijkheid nemen en ook updates zullen uitbrengen voor systemen die "officieel" geen support meer krijgen. Ten slotte zitten deze kwetsbaarheden al een jaar of tien in de processors.
Ik ben benieuwd wat de uiteindelijke performance impacts is. Ik denk dat voor interne databaseservers bijvoorbeeld de patch wel eens ongewenst kan zijn en daarom voor vooral servers de patch misschien liever optioneel moet zijn. Voor Windows werkstations mag ik hopen dat deze standaard via windows update geinstaleerd wordt.
De performanceimpact van een patch zou geen reden moeten zijn om een kritiek lek niet te patchen.
Voor een afgeschermde interne databaseserver zijn de performance impacts van dit soort patches waarschijnlijk erg groot (in ieder geval bij de eerdere spectre+meltdown patch) en draait er geen code op de server die een risico vormt. Intel heeft zelf aangeraden om voor servers zelf te onderzoeken in hoeverre de risico's opwegen tegenover de performance. Zeker aangezien er dus malafide code uitgevoerd moet worden op de server zelf, iets wat niet op alle servers gebeurt. Vooral VM's en terminal servers waarin externe code draait (inclusief javascript van bijvoorbeeld het bezoeken van een website) zal je zeker moeten patchen.
Tuurlijk wel. Dit issue heeft specifiek op database servers enorm veel impact qua performance.

Dat terwijl een database server niet zo veel last heeft van dit issue qua security. Deze kwetsbaarheid exploiten 'door' een database heen lijkt mij heel erg lastig zo n iet onmogelijk.

Een database die onwerkbaar is en dus effectief plat is nog onwenselijker dan een database met een security issue.
Je doet nu een aanname over het threat-model...
nl. dat als een inbreker op een database server terecht komt als non-priv gebruiker dat het dan een doodlopende straat is...., dit lek gaat er juist over dat (met enig geduld, uren, geen dagen) het voor non-priv gebruikers niet toegankelijk geheugen (systeem buffers, kernel memory) juist uit te lezen is.

ie. je zou met wat moeite het ww. van de admin boven water kunnen trekken. De oplossing van het probleem is gevonden in het flushen van alle caches op het moment van usermode/kernel mode wissel,
en en dit zorgt voor alle vertraging, en voor het scheiden van pagetables voor usermode en kernel mode.
En dit zorgt ervoor dat er de nodige vertraging is als er data van usermode memory -> kernel mode memory moet of omgekeerd.

Bij gevirtualiseerde servers kan een willekeurige gebruiker (wel of geen admin) het geheugen van alle andere VM's uitlezen en ook van de Host. en via via dus admin op de host overnemen..., niet im miliseconden maar het is niet te voorkomen....

Dus kies je vergif... wil links om gehackt, rechtsom gehackt of vertraging?
Het probleem is dat je uiteindelijk wel moet patchen om een actueel, ondersteund systeem te hebben. Het skippen van een patch zorgt voor problemen. Zeker met Windows, waarmee alle maandupdates worden gebundeld.
Bij Windows en dan specifiek op de servers worden de (meltdown/spectre) patches standaard niet enabled, daarvoor moet achteraf een registerinstelling voor worden gewijzigd.
Maar niet als je database server op gevirtualiseerde hardware draait.
Dat is een puntje ja..
De patch heeft een grote impact op de I/O van de server, het is niet alleen voorbehouden voor databaseservers, al zullen deze servers wellicht het meeste hinder ondervinden door de intensieve I/O die zo'n server kan veroorzaken.

Vergeet niet dat niet alleen de database vatbaar is als je niet patcht, het is natuurlijk de hele server, al begrijp ik je wel dat je met het aanspreken van de database niet zomaar misbruik kan maken van deze beveilingsproblemen en dat je ook eerst een kwaadaardig stukje software op de server moeten krijgen en kunnen starten voordat je van deze beveiliginsproblemen misbruik kan maken.

Verder lijkt het mij verantwoordelijker om je servers ondanks de performanceimpact wel te updaten met deze patches en in geval van performanceproblemen te kijken naar mogelijke serverupgrades.
Ook vraag ik mij af als je server door deze patches echt onwerkbaar wordt of je server sowieso al niet tegen een maximaal acceptabele belasting aanliep, maar ik snap ook wel dat de performanceimpact van deze patches de server net over die streep kan halen dat ie teveel belast wordt.
Eens. Het is altijd een afweging van risico en kosten.
beide denk ik, microcode kan tijdens het opstarten geladen worden, maar als je daar onafhankelijk van wilt zijn moet je wel een firmware update doen
'niet genoeg kan benadrukken hoe belangrijk het is om updates uit te voeren'
En vervolgens hele generaties aan CPU's die nog alom gebruikt worden niet voorzien van updates 8)7 .

[Reactie gewijzigd door Tortelli op 8 februari 2018 11:54]

Intel verzekert dat patches voor andere processors in de komende dagen zullen volgen
FTFY:
En vervolgens hele generaties aan CPU's die nog alom gebruikt worden NOG niet voorzien van updates 8)7 .
Uit eerdere berichtgeving was op te maken dat die oudere cpu's (die nog veel gebruikt worden) zoals een i7 920 (mijn ouders gebruiken mijn oude nog altijd) en b.v. de 2500/2600k die vele tweakers nog toepassen niet geupdate zouden worden.

Bericht geving welke wel/niet geupdate worden is ook niet helemaal eenduidig overigens.

[Reactie gewijzigd door Tortelli op 8 februari 2018 12:39]

De lijst met CPU welke (in eerste instantie) microcode updates krijgen zijn toch gewoon bekend?
Zie:
https://security-center.i...SA-00088&languageid=en-fr
Dat zou betekenen dat b.v. Nehalem ook nog een update zou krijgen. Volgens mij werd die in de eerste berichtgeving niet genoemd, zou Intel erachter zijn gekomen dat het geen geweldig idee was.

Goeie link overigens!.
Via die link kwam ik op dit document uit, daar hebben ze het over Sandy Bridge en nieuwer. Ik denk dat oudere processoren dus geen update zullen krijgen, Sandy Bridge en Ivy Bridge wel maar niet voor variant #2.
Hier is een lijst van BIOS Updates voor de Meltdown en Spectre Patches.

https://www.bleepingcompu...down-and-spectre-patches/
Ik heb van de week een Pentium 4 uit bedrijf genomen die de afgelopen 10 jaar vrijwel onafgebroken firewall/webserver gespeeld heeft, en voor die tijd 8 jaar als kantoor PC in gebruik was.
De buitendienststelling was noodzakelijk omdat het koelblok van de CPU afviel, na al die jaren was een van de oortjes waarmee vastzat van aan het moederbord afgebroken.
Zonder dat issue zou het nu nog draaien....

In de laatste 10 jaar is het systeem 3 maal uitgeweest wegens een langer dan 15 minuten durende stroomstoring [ 2-5 uur ], en eenmaal om een van de gespiegelde schijven te vervangen [20 minuten].

Ik ben benieuwd of daar nog een nieuwe firmware voor uitkomt... anyway nu draait alles op AMD. Dit was de laatste Intel.

(hm. het is dat het systeem uitging door een temperatuur alarm, anders was Meltdown hier letterlijk).

[Reactie gewijzigd door tweaknico op 8 februari 2018 13:56]

Ik mag hopen dat de oude generatie processors ook een update krijgen. Ik zelf heb een 2600k op 4.8ghz lopen met in combinatie een gtx 1070.En ik draai alle games nog makkelijk op ultra settings en ik zie dan ook geen nut om te gaan upgraden na een nieuwere platform.(De ram prijzen zijn me te hoog) Ik wil zeker nog 1 tot 2 jaar met de 2600k gaan doen. Nou intel, ik ben benieuwd.

[Reactie gewijzigd door Jeroentjeeuh op 8 februari 2018 12:35]

Wat ik me nou afvraag is of als je schade oploopt door deze bug je die kunt verhalen op intel.
Dat is een goede. Maar als de 2600k geen update krijg ga ik even verhaal halen bij Intel. Hopen op een vergoeding of in die trend.
Schattig maar een kansloze missie. Ze lachen je recht in je gezicht uit en zeggen doodleuk dat ze die 2600k niet meer ondersteunen en daarmee is voor hun de kous af. Sowieso vind ik het al vreemd dat je denkt nog ergens recht op te hebben, je vergeet voor het gemak even dat je die CPU jaren (sinds 2011?) probleemloos hebt kunnen gebruiken.
probleemloos hebt kunnen gebruiken.
Wat dus nu niet meer het geval is. Of de cpu nou 7 jaar oud is of pas een jaar. Ze hebben me een product aangesmeerd die begin van de dag niet eens veilig was. En op dat punt kan ik al een klacht indienen. Maar natuurlijk gewoon hopen op een fix.
Het ding is afgeschreven dus er valt ook niks meer te vergoeden. Dat is nou eenmaal hoe het werkt, of je er blij mee bent of niet. Ik hoop ook op een oplossing voor mij 3e generatie cpu. Misschien komt die nog nadat de laatste generaties eerst gefixed zijn.
Dan heb ik nieuws voor je: alles wat je nu of in de toekomst koopt gaat ook fouten bevatten die al dan niet vroeger of later ontdekt zullen worden en in meer of mindere mate een impact hebben. Kijk bijvoorbeeld naar producten met cryptografische beveiliging (SSD's met hardwarematige encryptie om maar iets te noemen), misschien dat deze nu nog veilig te gebruiken zijn maar straks volledig irrelevant zijn op het moment kwantumcomputers een stuk gangbaarder zijn. Ga je dan ook terug naar de winkel om je geld terug te eisen van een product dat technisch achterhaalt is?
Ze hebben me een product aangesmeerd die begin van de dag niet eens veilig was
Intel heeft je helemaal niks aangesmeerd, zij verkopen geen CPU's aan particulieren.
Intel heeft je helemaal niks aangesmeerd, zij verkopen geen CPU's aan particulieren.
Onwaar.

Negeer even dat hun webshop error 500's uitspuugt als je een product kiest... ;)

Hiermee geef ik overigens niet aan dat Intel zeer oude CPU's zou moeten ondersteunen. Volgens mij geven ze echter wel microcode updates uit voor alle Core i3/i5/i7 generaties, waarbij de oudere CPU's wat langer moesten wachten.

[Reactie gewijzigd door The Zep Man op 8 februari 2018 13:23]

Nog steeds waar, die site geeft alleen maar links naar retailers waar je het product werkelijk kunt kopen.
I stand corrected. Dat kon ik toen niet zien door de error 500's. Goed opgemerkt!
Dan zou ik naar de verkoper stappen. Die is onder Nederlandse / EU wetgeving verantwoordelijk voor het product, niet de fabrikant, daar heb jij namelijk geen contractuele relatie mee.

Echter hebben diverse partijen al aangegeven dat hier onder EU wetgeving waarschijnlijk juridisch weinig te halen valt, ook bij de verkoper. Ik zou dus momenteel niet al te veel hoop hebben op een vergoeding of iets in die trant, maar wie weet wat er nog gebeurt in de toekomst
Denk je dat er nog een software industrie zou bestaan als schade door bugs door de software makers betaald zou moeten worden?
Maar bij CPU's worden vaak benchmark scores geprezen en actief gepromoot.
(mogelijk!) Haal je die scores nu niet meer, waardoor het product niet meer aan de verwachtingen voldoet.

Met software is toch hetzelfde. Als je eerst een functie wel had, en daarom dat pakket had gekocht. En die functie wordt zonder pardon verwijderd. Dan heeft het softwarebedrijf wel degelijk een probleem.
Maar er worden geen functies verwijderd. Ze worden aangepast. Of geheel niet aangeraakt.

Verder is een CPU van nu 6 of 7 jaar oud op (of over? volgens mij staat hier 5 jaar voor of zelfs minder) het randje gegaan van economische levensduur. Kun je dan redelijkerwijs nog verhalen? Ik denk het niet.

Wat Intel ermee doet maakt dan overigens ook niet zoveel meer uit; het is hetzelfde als de keuze om op een oud OS te blijven hangen. Er is nu officieel verklaard dat iets niet meer veilig is. Als dat zo blijft, dan is het toch aan de gebruiker om te upgraden als de economische levensduur verstreken is. Alternatief: als Intel de fix wél uitrolt en je verliest performance, heb je al helemaal geen poot om op te staan. Er zijn legio fixes en updates die impact op de performance hebben, dat is altijd al zo geweest, alleen nu is die wat beter zichtbaar vanwege de media aandacht.

Maar, wat onderaan de streep nog het zwaarst weegt lijkt me het volgende: ALLE CPUs worden hierdoor geraakt, het was dus niet redelijkerwijs te voorspellen dat dit ontwerp, dat breed is overgenomen als een soort 'best practice' een dergelijk lek zou veroorzaken - of wat meer waarschijnlijk: de gedachtengang was destijds in het ontwerpen geheel anders qua security en dus kreeg hogere prestatie meer gewicht. Vergeet niet: dit probleem is ontstaan in een tijd dat internet betrekkelijk nieuw was, en databeveiliging/koppelingen van data nog in de kinderschoenen stond.

[Reactie gewijzigd door Vayra op 8 februari 2018 12:58]

Er worden wel functies verwijderd, nl. het kunnen inbreken via het gat, maar dat wordt als positief ervaren. In een enkel geval gaat dat ook ten koste van wel gewenste functionaliteit. Cest la vie..

Ik denk dat het probleem niet in een keer ontstaan is maar door een combinatie van elementen...
1) speculative execution
2) High precision (wall clock) timekeeping.

Het laatste is het voor dit cache onderzoek waarbij op ns. schaal gemeten moet worden van belang.
ipv. speculative execution uit te zetten zou ook de clock meer onnauwkeurig kunnen worden gemaakt.
terug naar bv. ms. nauwkeurigheid. Dan is cache reading ook geen probleem. Alleen heb je snel ruzie met allerlei video en audio applicaties, of andere toepassingen waarbij een nauwkeurige clock wel nodig is..

Probleem is dat speculative execution makkelijker uitgezet kan worden dan een clock minder nauwkeurig gemaakt kan worden, omdat het laatste autonoom op een lager niveau in de chip gebeurd en meer een bijproduct is van het bijhouden van clockticks [in Ghz] sinds laatste uitlezen.
En als je wil zien hoe dit kan ontsporen dan moet je eens een VM aanmaken en de native drivers voor VirtualBox/VMware/HyperV oid NIET laden, dan is het op tijd laten lopen van de systeem klok een aardige uitdaging.

[Reactie gewijzigd door tweaknico op 8 februari 2018 13:48]

Als je schade oploopt als gevolg van deze bug, dan is de rest van je beveiliging verre van op orde ;)
En jij kan niet meer gamen als ze er geen patch voor uit zouden brengen? Ik vind dat mensen wel heel hysterisch doen over deze security flaw.
Ik zal der nog prima mee kunnen gamen maar dat is het niet. Het is nu volop in de media en hackers weten nu wat ze te doen staan. Laast staan als de 2600k geen update krijg en dan ? Ik voel me niet veilig. Dus ik moet maar gaan upgraden ? Nee, dat ga ik niet doen. Intel is hier gewoon aansprakelijk voor.

[Reactie gewijzigd door Jeroentjeeuh op 8 februari 2018 15:32]

Nou ik wens je heel veel succes met die zaak tegen Intel. Laat ons even weten wat de uitkomst is.

Maar goed, VZIW wordt alles tot aan Core2Duo gewoon gepatcht.
Maar is het na genoeg Patchen uiteindelijk ook definitief dicht of kan Meltdown en Spectre ook upgrades of patches krijgen zodat het spelletje opnieuw begint..

Als er geen zekerheid komt dat uiteindelijk Meltdown en Spectre gedicht wordt dan mogen de huidige processors wel vervangen worden zodra Refresh er komt en iedereen met fabrieks garantie zou moeten kunnen inruilen.
ik denk dat als meltdown of spectre een patch krijgt dat het dan anders genoemd zal worden, tenzij de patch hiertegen de exploits niet volledig patched.
Ah dank je mjz2cool :)

Het zal mij benieuwen en hopelijk komt er een definitieve oplossing voor anderen die nu van Sandy en Bulldozer tot Coffee en Ryzen gebruiken want ik wacht op Refresh van Coffee of Ryzen en dezen zullen wel dicht zijn maar anderen moeten Patchen...
Nu zijn dit patches en fixes voor oudere chips. Nu vraag ik me af, of de nog te ontwikkelen chips die het manco niet meer hebben de vertraging van 10% kunnen omzeilen.
nee, die zullen het manco de het komende jaar nog steeds mee krijgen.
Pas bij de CPU die vanaf nu nieuw ontworpen wordt kunnen mogelijk zaken meegenomen worden.... of Intel kan erop gokken dat de huidige maatregelen "afdoende" zijn.....
hoewel anderen dat betwijfelen.

En mogelijk krijgen ze een aanvaring met AMD..., als er iets gepatenteerd is in de methode die AMD toepast waardoor AMD nu niet getroffen is door een deel van de issues die Intel wel treffen.

Aanvulling:
(ik snap de 0 moderatie niet, ze hebben echt niet nieuwe maskers gemaakt voor de nu geproduceerde chipsets, en die maskers maken EN proefruns + testen duurt enige tijd nadat bv. de uCode fixes verzonnen zijn, of meer werk de hardware een redisign gehad heeft.)
En anderzijds gaat Intel echt niet de productie een halfjaar/jaar stilleggen tot alles op orde is.
Kortom voorlopig zullen er nog chips gemaakt worden MET fouten.

[Reactie gewijzigd door tweaknico op 9 februari 2018 14:33]

Nu heeft mijn NUC een BIOS update gehad voor de INTEL-SA-00088 kwetsbaarheid...het enige wat ik nu niet snap is dat ik daardoor kennelijk niet meer beschermd ben tegen meltdown (voor de microcode update was ik dit wel het geval namelijk)

https://afbeeldinguploaden.nl/image/Q4beG9m2

Of doet die microcode update ook iets waardoor softwarematige protectie tegen meltdown niet langer nodig is?

Registry settings;
FeatureSettingsOverride = 0
FeatureSettingsOverrideMask = 3

[Reactie gewijzigd door RJWvdH op 8 februari 2018 16:38]

Ik denk dat Microsoft bepaalde uCode versies controleert (en dat is veranderd) om niet meer problemen te veroorzaken bij niet compatible uCode.
Meltdown ontstaat omdat de (Intel) hardware pas beoordeeld of je ergens MAG kijken/schrijven (compatible accessmode in Pagetable) NADAT de instructie al speculatief is uitgevoerd. (dus via een cache probe is data te achterhalen). dat is niet veranderd. [ nieuw HW design ]

De mitigatie tegen meltdown is dat er twee pagetables op na gehouden worden, 1 voor usermode access en een voor kernelmode. en een TLB flush tijdens usermode/kernel mode switch. Voor Intel is dat noodzakelijk. AMD heeft geen niet dit probleem (eerst check of access mag in Pagetable, daarna speculative exec als het mag, dus ook caches worden niet gevuld).
Ik snap er geen bal meer van...en bij Intel ook niet volgens mij...die verwijzen me weer door naar Microsoft |:(
Hopelijk verspreid CentOS deze nieuwe patches dan ook gewoon via hun OS, wel zo makkelijk :). De vorige patch is al enkele weken teruggetrokken..
Dat was omdat de patch op sommige systemen meer kapot maakte dan repareerde...
Ik krijg elke dag random freezes (windows 10), en volgens mij heb ik echt alles geprobeerd om ervan af te komen.
Ik ga zaterdag toch maar compleet opnieuw windows installeren, wordt er gek van.
Dat gaat niet echt helpen voor dit issue....
je krijgt dezelfde updates aangeleverd na installatie [ dus ook dezelfde uCode indien van toepassing ], dan wel fixes...

Zonder Windows 10 had je nog de keus om niet te patchen....
Moet ik nu wachten tot mijn MSI moederbord een nieuwe BIOS update krijgt? Of kan ik deze patch ook zelf op een of andere manier doorvoeren? Bij BIOS updates changelogs zie ik namelijk wel geregeld "microcode updates" staan.

Jammer dat het artikel hier geen duidelijkheid over geeft.
"Het bedrijf merkt op dat de updates in de meeste gevallen beschikbaar komen via firmware-updates."

Firmware updates van wat? Is een BIOS update een "firmware update"?

Op dit item kan niet meer gereageerd worden.


Apple iPhone XS Red Dead Redemption 2 LG W7 Google Pixel 3 XL OnePlus 6T FIFA 19 Samsung Galaxy S10 Google Pixel 3

Tweakers vormt samen met Tweakers Elect, Hardware.Info, Autotrack, Nationale Vacaturebank en Intermediair de Persgroep Online Services B.V.
Alle rechten voorbehouden © 1998 - 2018 Hosting door True