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

'Patch voor ernstige Intel-bug verlaagt softwareprestaties aanzienlijk'

Er zijn aanwijzingen dat Intel-processors een bug hebben die toegang tot beschermd kernelgeheugen mogelijk maakt. De oplossing zou liggen in een page table isolation-patch, maar deze kan in ieder geval bij Linux tot flinke prestatievermindering bij bepaalde toepassingen leiden.

De kwetsbaarheid zou meerdere generaties van Intel-processors treffen en vereisen dat Windows, macOS en Linux lowlevel-patches doorvoeren. Die zouden een negatieve impact op de prestaties van 5 tot 30 procent hebben, afhankelijk van de toepassingen.

Linux 4.15-rc6, dat de patch bevat, in combinatie met een systeem met de Intel Core i7-8700K, laat bij benchmarks van Phoronix flinke prestatieverlagingen zien in FS-Mark-, Compile Bench- en PostgreSQL. Een gebruiker van de PostgreSQL-mailinglijst merkt hetzelfde op. Tests van Phoronix tonen geen prestatieverschil bij gaming met dezelfde Linux-versie. Applicaties die zich beperken tot user space zouden niet trager werken door de patch.

Intel heeft nog geen details over de bug gepubliceerd en beveiligingsbedrijven evenmin, maar onder andere op Reddit wordt opgemerkt dat een publicatie over een ernstige kwetsbaarheid op handen lijkt. Dat zou onder andere af te leiden zijn door activiteit in de Linux-gemeenschap.

Ontwikkelaars voor de Linux-kernel werken al een tijd aan zogenoemde Kaiser-patches. Die zijn begin december omgedoopt tot x86/kpti-patches, waarbij kpti staat voor kernel page table isolation. Kpti is een beveiligingstechniek om kernelgeheugen beter te scheiden van userland. Door de kernel zoveel mogelijk te unmappen uit pagetables moet er zo min mogelijk af te leiden zijn over de virtuele geheugenruimte voor de kernel.

Kpti maakt hiervoor een schaduwkopie van de page tables voor usergeheugen, met een minimaal deel voor kernelgeheugen. Bij het benaderen van de kernel via syscalls en interrupts schakelen de pagetables over naar de kopie voor de volledige kernel. Dit neemt tijd in beslag en de prestaties van alle toepassingen waarbij syscalls en interrupts spelen, lijden dan ook onder de techniek. Bij Intel-processors met ondersteuning voor Context IDentifiers, of pcid's, zou dit minder het geval zijn. Dit zijn Intel-processors vanaf de Haswell-generatie.

De patches zijn gemerged in Linux-kernel 4.15, met backporting naar kernelversie 4.14.10. De patches zijn in relatief korte tijd, drie maanden, doorgevoerd. Microsoft werkt aan vergelijkbare beveiliging als Kaiser voor Windows, waarbij Alex Ionescu, beveiligingsdeskundige en expert op het gebied van kernelontwikkeling, liet weten dat er half januari meer bekend zou worden gemaakt over de implementatie.

Het werk lijkt bedoeld om address space layout randomization weer veiliger te maken. Deze techniek moet voorkomen dat een aanvaller achter geheugenadressen kan komen. Aslr werkt door willekeurige locaties in het virtuele geheugen aan te wijzen waar programma's belangrijke componenten kwijt kunnen. In de afgelopen jaren zijn er kwetsbaarheden met betrekking tot aslr geconstateerd, onder andere door onderzoeksgroep softwarebeveiliging van de VU, begin vorig jaar. De ontwikkelaars van de Oostenrijkse TU Graz publiceerden hun eerste werk aan de Kaiser-patch als maatregel tegen sidechannelaanvallen die aslr omzeilen, en dan met name kernel address space layout randomization, of kaslr.

Het blog Python Sweetness en vervolgens The Register speculeren nu dat er met haast aan de patches gewerkt wordt omdat Intel-processors een ernstiger bug bevatten. Ook op LWN wordt opgemerkt dat de patches versneld lijken te worden doorgevoerd onder druk van een deadline. Bovendien meldt AMD's Tom Lendacky op de mailinglijst voor Linux-kernelontwikkeling dat de aanvallen waar kpti bescherming voor moet bieden, niet werken op AMD-processors. Hij maakt daarbij duidelijk dat AMD-chips geen 'speculatieve geheugenreferenties' ondersteunen die toegang bieden tot higher privileged data, bij het draaien in een modus met minder rechten. Als die toegang tenminste tot een page-error leidt. De kpti-patch heeft in zijn huidige vorm echter wel invloed op de prestaties bij AMD-systemen. AMD heeft verzocht page table isolation niet te activeren bij aanwezigheid van AMD-processors.

Intels cpu-pipeline maakt gebruik van speculative execution om de verwerking van data te kunnen versnellen en G-Data's Anders Fogh heeft afgelopen zomer doorbraken gemaakt bij het misbruiken hiervan voor sidechannelaanvallen. Hij slaagde er met zijn Core i3-5005U niet volledig in kernelgeheugen uit te lezen vanuit usermode, maar zijn resultaten toonden wel aan dat de implementatie zwakheden vertoonde en hij sprak van 'het openen van de doos van Pandora'.

Als de vermoedens over de bug kloppen, zou dit met name impact hebben op clouddiensten als Amazons EC2, Microsofts Azure en Googles Compute Engine. De kans bestaat dat het mogelijk is voor aanvallers om kernelgeheugen van virtuele machines te benaderen die op hetzelfde Intel-systeem draaien. Microsoft heeft onderhoud en een reboot aangekondigd voor virtuele machines op Azure. Dat moet op 10 januari gebeuren. Amazon heeft klanten ingelicht over een reboot van EC2-instances op 5 januari.

Update, 15.30: Passage over claims van AMD's Tom Lendacky is uitgebreid. De originele tekst noemde alleen dat AMD-processors geen speculatieve geheugenreferenties ondersteunen, wat onjuist is.

Door Olaf van Miltenburg

Nieuwsco÷rdinator

03-01-2018 • 11:36

152 Linkedin Google+

Submitter: RedShift

Reacties (152)

Wijzig sortering
De oplossing van de patch is blijkbaar om de page table om te wisselen en de TLB te flushen bij elke context switch; de TLB is de cache die in je processor core zit met de page table translations (virtual to physical adressen). Dat dit ten koste gaat van flink wat performance is niet zo gek; vele geheugen referenties na een context switch (ook al doe je maar een minieme syscall of interrupt service) zal weer een page table walk opleveren omdat de TLBs opnieuw gevuld moeten worden. Ik ga er overigens van uit dat het alleen een flush van de D-TLBs betreft.
Tom Lendacky op de mailinglijst voor Linux-kernelontwikkeling dat de aanvallen waar kpti bescherming voor moet bieden, niet werken op AMD-processors. Hij maakt daarbij duidelijk dat AMD-chips 'speculatieve geheugenreferenties' niet ondersteunen.
Dit statement is veel en veels te kort door de bocht overigens. Uiteraard ondersteunen AMD processors wel "speculatieve geheugenreferenties", anders zou je totaal niet in de buurt van Intel's single thread performance kunnen komen. Zodra je het adres van een load/store in de toekomst denkt te weten wil je meteen zorgen dat die cacheline naar je cache toekomt. Zo werkt een out-of-order processor core nou eenmaal, je gaat niet een voor een (in-order) wachten tot de vorige klaar is eer je de volgende issued. Dan zou je ook geen nut hebben voor meerdere load/store units in je core ;)

Wat mijn interpretatie is van wat AMD in ieder geval doet, afgaande op Tom Lendacky's post, is dat je nooit een geldige translatie kan krijgen op een speculatieve referentie met onvoldoende privilege level. Ik vraag me dan af hoe ze dat doen, aangezien je in het algemeen je TLB lookup en je L1 cache access in parallel doet (vandaar Virtually Indexed Physically Tagged) om tot een zo kort mogelijk load-to-use latency te komen (3 cycles op moderne OoO cores).

Bron: Ik heb zelf meegewerkt aan de Load/Store Unit van de laatste SPARC cores.

Edit: Ik ben overigens nog wat van het (overvloed aan) materiaal aan het doorlezen, dus hoop later een meer gedetailleerde analyse te kunnen maken.
Edit2: Nog een verduidelijking; de grote performance impact lijkt een combinatie te zijn van een TLB flush *en* het omwisselen van de page table.

[Reactie gewijzigd door Squee op 3 januari 2018 16:33]

Je zou een cache line invalidate doen op het moment the TLB de page fault detecteert, of de entry uit de TLB halen op moment dat het een page fault is. Beiden zorgen er voor dat je niet een complete flush hoeft te doen op een speculative access.
Je zou een cache line invalidate doen op het moment the TLB de page fault detecteert, of de entry uit de TLB halen op moment dat het een page fault is. Beiden zorgen er voor dat je niet een complete flush hoeft te doen op een speculative access.
Ik begrijp niet zo goed wat je bedoelt. Welke cache line wil je invalideren op een page fault? Het is sowieso belangrijk om page faults door TLB/tablewalk misses en page faults door privilege violations uit elkaar te houden. Wil je de bijbehorende cache line invalideren bij een privilege violation? Hij zou in ieder geval geflushed moeten worden indien je een write-back cache hebt, maar in principe zou het helemaal geen probleem moeten zijn dat hij in de cache staat - of niet. Ik zie ook niet wat die entry uit de TLB halen je zou opleveren.

Wat betreft speculative access en flushes... Je hoeft ook geen complete flush te doen op elke speculatieve access, maar alleen op een context switch. Als je het op elke speculatieve access een flush zou doen dan kan je net zo goed je processor gewoon gaan laten single-steppen :)

[Reactie gewijzigd door Squee op 3 januari 2018 19:18]

Ik bedoelde inderdaad speculative privileged access.
Wat ze lijken te willen voorkomen is dat data in L1 komt of dat je een TLB hit krijgt ook al levert het een pagefault op.
Intel flushed de hele TLB, waardoor het voor de software praktisch op lijkt alsof L1 leeg is aangezien een page walk vaak langer duurt.
AMD zou er voor kunnen kiezen om die TLB entry te invalidaten op het moment dat de pagefault gedetecteerd wordt. Of invalidate de cache index en je zorgt er zo voor dat je die data zo weer moet ophalen.
Intel heeft er blijkbaar voor gekozen om dit niet te doen aangezien je toch een pagefault krijgt en of de data nu wel of niet in L1 staat zou niet mogen uitmaken.
Nu lijkt het er op dat het dus wel uitmaakt en "ze" een manier gevonden hebben om toch bij deze data te komen.
Zo werkt een out-of-order processor core nou eenmaal, je gaat niet een voor een (in-order) wachten tot de vorige klaar is eer je de volgende issued. Dan zou je ook geen nut hebben voor meerdere load/store units in je core
Deze redenatie klopt niet helemaal. In-order execution impliceert geen in-order memory access. Neem bijvoorbeeld de PowerPC. Die doet geen OOE maar wel out of order memory access - eigenlijk precies het tegenovergestelde als hedendaagse x86 cpu's.

Instructies hoeven dan ook niet per se *klaar* te zijn voor in-order execution. Er kunnen best meerdere instructies op verschillende stages in de pipeline zitten.
Nice om zo een reactie te lezen ik wou dat ik je kon taggen met: "deze kerel is een processor engineer"
En ze trekken iedereen mee in bad:

"Based on the analysis to date, many types of computing devices — with many different vendors’ processors and operating systems — are susceptible to these exploits.
Intel is committed to product and customer security and is working closely with many other technology companies, including AMD, ARM Holdings and several operating system vendors, to develop an industry-wide approach to resolve this issue promptly and constructively.
"

Vraag is of dit klopt, OF dat ze proberen FUD te creŰren zodat geen concurrent er voordeel uit zou kunnen halen.
Tweakers vergeet dat diezelfde patch, namelijk wel invloed heeft op AMD CPU's terwijl AMD CPU's niet kwetsbaar zijn voor zo'n aanval. De performance van AMD CPU's gaat hiermee onterecht naar beneden. Er wordt gesproken van 5% tot in meest extreme gevallen van 50% afhankelijk van workload. :X Lekkere patch dan ...

Er is een patch van amd uitgebracht welk de wijzigingen van Intels fix teniet doet.

Dat men niet zoekt naar een oplossing in waarin AMD CPU's namelijk niet worden geraakt.. :/

[Reactie gewijzigd door Jism op 3 januari 2018 12:02]

"Jij vergeet" dat degene die de patch uitrolt niet Intel is, maar (voornamelijk) Microsoft.

Niet om het goed te praten, want het blijft raar, maar ik vind er ook wel wat voor te zeggen dat Microsoft even mag checken of een PC een Intel CPU heeft voordat de patch word ge´nstalleerd, dat zij de boel maar klakkeloos naar iedereen uit blijken te rollen is niet echt Intel's schuld natuurlijk.
De performance nadeel is voor Linux kernel en niet voor Windows (die komt later). Dus Microsoft heeft hier geen invloed op en vooralsnog is het even afwachten wat voor invloed dit op Microsoft heeft.
Dit klopt niet, als het artikel op The Register klopt althans:
Meanwhile, Microsoft is expected to publicly introduce the necessary changes to its Windows operating system in an upcoming Patch Tuesday: these changes were seeded to beta testers running fast-ring Windows Insider builds in November and December.

Crucially, these updates to both Linux and Windows will incur a performance hit on Intel products. The effects are still being benchmarked, however we're looking at a ballpark figure of five to 30 per cent slow down, depending on the task and the processor model. More recent Intel chips have features – such as PCID – to reduce the performance hit. Your mileage may vary.

Similar operating systems, such as Apple's 64-bit macOS, will also need to be updated – the flaw is in the Intel x86-64 hardware, and it appears a microcode update can't address it. It has to be fixed in software at the OS level, or go buy a new processor without the design blunder.
Voor Windows geldt het dus ook, en ook Apple is van de partij met macOS.

[Reactie gewijzigd door Michali op 3 januari 2018 13:31]

Mijn reactie is op die van @olivierh die reageert op @Jism die het weer over AMD heeft en de Linux kernel. Ik denk dat je dat stukje gemist hebt. Het heeft invloed op alle systemen met een Intel CPU zonder verdere beveiliging, echter de reactie ging specifiek over AMD en de Linux kernel. De huidige implementatie in de RC van 4.15 heeft invloed op alle CPU's terwijl het niet zou mogen opgaan voor AMD CPU's (en die mag dus geen performance hit ondervinden).

[Reactie gewijzigd door servicedb op 3 januari 2018 13:35]

Oke, mijn fout, de reactie van Jism is dan een beetje onduidelijk, ik dacht dat zijn reactie over de bug an-sich ging, niet enkel over de Linux versie.
Grappig dat de patch weer alleen AMD cpu's uitsluit, als ze nu eens alleen Intel cpu's zouden insluiten (of is dat een vreemde gedachte?)
Je zou diegene waarvan je weet dat ze niet getroffen zijn moeten uitsluiten ipv enkel diegene waarvan je weet dat ze getroffen zijn in te sluiten. Stel je hebt een chip van een andere fabrikant dan Intel of AMD (er zijn er, ook al zijn ze niet populair) die dezelfde problemen heeft als de Intel. Dan zou jij deze gaan uitsluiten van de patch.
Omgekeerd wederom hetzelfde, als je een andere producent hebt die niet vatbaar is zou je die ook "benadelen".
Mijn inziens is het beter om te kijken wat er vatbaar is en je daar toe te beperken (en zodra er nieuwe Intel cpu's zijn die niet vatbaar zijn te zorgen dat deze ook gedetecteerd kunnen worden).
Op zich is het een goede redenering geweest om uit te gaan van kwetsbaarheid tenzij aangetoond dat het wel correct werkt.
Arm64 is ook gevoelig: https://lwn.net/Articles/740393/
Arm64 is ook gevoelig: https://lwn.net/Articles/740393/
Nee dat lijkt hier los van te staan. Waar je naar wijst is dat ze ook "KAISER" geimplementeerd hebben voor Arm64 om beter bestand te zijn tegen KASLR timing attacks. Waar het hier in dit nieuwsartikel om lijkt te gaan is dat ze bij verder onderzoek en/of de implementatie van KAISER een bepaalde Intel specifieke bug zijn tegen gekomen, waarvan de workaround nogal een flinke performance impact heeft.

Je kan ook niet stellen dat Arm64 "gevoelig" is, omdat het alleen maar een architectuur specificatie is. Zo kan je ook niet stellen dat "x86-64" gevoelig is, het gaat over specifieke micro-architecturele implementaties die gevoelig zijn, dus de individuele core-ontwerpen (blijkbaar veel van Intel, en niet die van AMD bijvoorbeeld). Bij Arm64 heb je veel verschillende ontwerpen die de architectuur implementeren; van elk afzonderlijk zou moeten worden vastgesteld of ze dergelijk gedrag vertonen of niet.

Als ik zo lees wat de ARM patch ongeveer doet, geeft dat wel een redelijk beeld. Standaard zijn de kernel adressen niet gemapped, en worden die ingeschakeld zodra je naar kernel mode gaat (door een syscall, interrupt, etc). Er is dan standaard maar een enkele kernel page gemapped die de informatie bevat om de rest van het kernel geheugen te mappen. Het lijkt er op dat Intel hier een specifieke microarchitecturele bug heeft, die naar ik vermoed met het omwisselen van de page tables te maken heeft, en wellicht informatie kan vrijgeven via een bepaald soort timing attack.

Wat ook wel interessant is aan die beschrijving is dat ze twee virtual memory contexten gebruiken en bij een syscall/interrupt deze omwisselen. Bij SPARC (in ieder geval sinds 64 bits SPARC v9, mid jaren 90), zat dat al in de architectuur specificatie. Zodra je naar privileged (kernel) mode gaat, gebruikt de MMU automatisch een ander context ID (en weer een ander in Hyperprivileged). Zo zou je dus nooit een (speculatieve) TLB hit kunnen hebben vanuit een minder privileged context.

Edit: verduidelijking toegevoegd over Arm64

[Reactie gewijzigd door Squee op 3 januari 2018 16:16]

Een vreemde redenering om rekening te houden met andere processors die hier mogelijk last van kunnen hebben. Het is een HW fout, en aangezien alle processorbakkers hun eigen ontwerp hebben zou het extreem toevallig zijn dat de concurrent er ook mee kampt. Of het is imitatie, en dat mag natuurlijk ook niet. Daarnaast, nu Intel op de hoogte is van de fout, kan het niet anders dat de lijst van getroffen processors eindig is of wordt. Gieltje heeft gewoon gelijk.
Het is een HW fout,
Voor zover ik het nu snap is het microcode, en dat is geen hardware.
Het probleem zit juist niet in de microcode, anders was het te patchen geweest.
Is er een manier om te bepalen of dit ook het geval is voor Windows?
Dat de Microsoft patch niet ook de AMD cpu's negatief benadeeld?

(Behalve dan achteraf te meten)
Waarom probeer je het niet uit?
De patches van Microsoft hiervoor zijn al in Nov/Dec naar de Windows Insider Fast-ring gepushed.
Wat een paniek "MUH AMD wordt onterecht benadeeld" weer meteen. De oplossing waar jij op doelt bestaat al in de vorm van die AMD-patch (die overigens niet alles teniet doet, alleen zorgt dat de bug-workaround niet wordt toegepast voor AMD-CPUs), alleen is die in de eerste kernelrelease met de pti-workaround (waar logischerwijs veel haast bij zat) nog niet meegenomen. Er is geen enkele reden om aan te nemen dat die patch niet gewoon in de volgende release meegenomen wordt.

[Reactie gewijzigd door wjvds op 3 januari 2018 12:12]

Zou je dan geld terug kunnen krijgen voor mijn nog geen jaar oude processor? Het presteert niet meer zoals voorheen.
Veel belangrijker: alle Macbooks (in relatieve getallen niet zo'n grote markt maar in absolute getallen de meest-voorkomende laptop modellen) bevatten Intel CPUs. Aangezien deze razendsnelle NVMe SSDs ( = veel IO) hebben worden deze dan ook buitensporig hard geraakt door een mitigation patch hiervoor. Hoe zou dat eerlijk opgelost kunnen worden? Apple gaat natuurlijk nooit al die Macbooks recallen, maar het lijkt me ook wat vreemd dat Apple een bak geld van Intel krijgt en vervolgens iedereen die een Macbook heeft gekocht korting op een volgende krijgt. En dan heb je weer gedoe met mensen die hem refurbished of tweedehands hebben gekocht. Vragen vragen..
Macs hebben blijkbaar praktisch geen last van dit probleem ivm "double map" en PCID sinds 10.13.2 (begin december). Het lijkt er dus op dat Apple de eerste grote vendor is die dit probleem verholpen heeft voor hun systemen.
The question on everyone's minds: Does MacOS fix the Intel #KPTI Issue? Why yes, yes it does. Say hello to the "Double Map" since 10.13.2 -- and with some surprises in 10.13.3 (under Developer NDA so can't talk/show you). cc @i0n1c @s1guza @patrickwardle
https://twitter.com/aionescu/status/948609809540046849

[Reactie gewijzigd door SidewalkSuper op 3 januari 2018 19:14]

Beetje late reactie, maar:
I have to report on IO: My favorite slide show app, Phoenix Slides, now takes twice as long to index ~3000 JPG/PNG/GIF files. I also notice that The Unarchiver takes nearly twice as long to unpack large 7z archives as it used to. All files on a 1TB Apple (Samsung) SSD.
https://twitter.com/kode54/status/950546662065188864

Ik ben overigens ook best wel pissig hierom. Volkswagen heeft vanwege het dieselschandaal destijds gewoon mensen hun auto verplicht terug moeten kopen. Ondertussen een maand verder, en ik hoor nog geen enkel soortgelijk geluid. Waarom dwingen Amerika en de EU hier Intel/Apple/OEMs niet toe? Lijkt me wel zo redelijk, helemaal met (zoals ik al eerder noemde) de prijzen van Macbooks..

[Reactie gewijzigd door Menubalk op 22 januari 2018 10:46]

Je product presteert nog hetzelfde als voorheen. Het is een kernel patch die je uiteraard niet hoeft uit te voeren. Met een oude kernel presteert je systeem hetzelfde als voorheen. Als een update van windows meer visuele effecten krijgt en daardoor trager wordt kun je ook niet zeggen dat je processor slechter is geworden.
Het basis principe is natuurlijk een enorm (nu nog mogelijk, tot de officiele verklaringen) veiligheidslek geen eigenschap is die een consument mag verwachten en dus non-conform is. Als de verkoper dit dan via de fabrikant netjes kan repareren zonder impact voor de consument is er uiteraard geen issue en is het product wel weer conform. Als dit echter niet netjes gerepareerd kan worden zonder impact voor de consument zie ik wel ruimte voor non-conformiteit.
Ik ga er even van uit dat je in de EU woont. Dan is de kans vrij klein.
Woon je in de USA, is de kans zeer groot.
Waarom zou dat in de EU vrij klein zijn, hier is juist de verkoper verantwoordelijk voor een conform product gedurende de levensduur van het product en deze is normaliter makkelijker aan te spreken dan een fabrikant. In theorie zou het hier dus vrij makkelijk moeten gaan als de bug inderdaad zo groot gaat zijn qua impact dat je de CPU als niet conform mag gaan zien.

De praktijk zal echter uiteraard lastiger worden daar (web)winkels in Nederland er vaak bekend om staan om bij non-conformiteit graag een loopje te nemen met de wet.

[Reactie gewijzigd door Dennism op 3 januari 2018 12:11]

VAG indachtig denk ik dat er niet veel zal gebeuren (tenzij de EC zin heeft om een Amerikaans bedrijf uit te knijpen).

Ik denk echter dat je geen poot hebt om op te staan, bij een auto koop je immers een bepaald model met X pk en Y uitstoot.
Bij een cpu koop je een type met X MB cache en Y GHz. Dit blijft allemaal ongewijzigd na de patch, enkel de prestatie is minder. Maar nergens in de specs staat hoe snel dat ding moet zijn...
Nou volgens mij worden cpu's van intel en AMD gewoon gepresenteerd met syntetische benchmarks op congressen ter demonstratie, en in de officiele specificaties staan wel de technieken waarin nu dat beveiligingslek zit. als die technologie word uitgeschakelt/omzeilt vanwege beveiligingsprobleem en ik daardoor performance verlies heb dan kan ik toch een aanspraak doen op performance verlies door slecht functionerende technologie?

[Reactie gewijzigd door t link op 3 januari 2018 13:00]

Als na een patch van de software van je motormanagement het vermogen met X pk terugloopt kan dat wÚl degelijk een reden zijn non-conformiteit te stellen. Sterker, dat is precies wat Dieselclaim gaat doen!
Vaak zelfs... Ik zie vooral de incidenten en gok aan de hand daarvan dat het veel vaker goed gaat maar wat weet ik.

Hoe dan ook, in dit geval heb je misschien wel een rechtszaak nodig om non-conformiteit aan te tonen. Het mankement kan immers met een patch worden verholpen dus moet aannemelijk gemaakt worden dat het product met patch nog steeds niet conform is.
Wat je hier in NL in ieder geval veel ziet, en dat zijn echt teveel gevallen om nog van incidenten te spreken is dat verkoper zich te veel achter de fabrikant verschuilen terwijl ze dat wettelijk gezien niet mogen. Werkt deze mee dan gaat in veel gevallen het beroep op non-conformiteit (in de volksmond garantie) erg makkelijk, werkt de fabrikant echter niet mee en gaat het daardoor de verkoper geld kosten dan zie je al heel snel dat een boel verkopers zich in allemaal bochten beginnen te wringen om maar geen garantie te hoeven verlenen.

Dat het vaker goed gaat dan niet daar twijfel ik ook niet aan, maar dat er veel winkeliers zijn die wanneer ze het in eigen bottomline gaan voelen een loopje nemen met de wetgeving is ook zeker een feit en helaas echt geen incident.

Verder zal inderdaad non-conformiteit aangetoond moeten worden, maar ik zie wel degelijk aanknopingspunten dat een beveiligingslek van deze orde (als alle geruchten waar zijn) ook na een patch van een 3de partij nog steeds best non-conform kan zijn. (als Intel het zelf zou fixen met een Microcode update zonder performance impact zou het wat anders zijn, maar dat schijnen ze volgens de geruchten niet te kunnen).

[Reactie gewijzigd door Dennism op 3 januari 2018 13:46]

WHAT THIS LIMITED WARRANTY DOES NOT COVER: • design defects or errors in the Product (Errata). Contact Intel for information on characterized errata
Gelukkig hebben we in de EU fatsoenlijke wetten voor consumenten, maar The Land of the Free kan het schudden.
Zowel in de VS als in de EU zijn er wetten die het mogelijk maken om te proberen die passage in de garantieverklaring onderuit te halen. Denk aan class action lawsuits en lemon laws respectievelijk het conformiteitsbeginsel.

Een kleinigheidje is wel dat de leverancier eerst het probleem mag proberen op te lossen. Door een patch uit te delen kan daar misschien aan voldaan zijn, dus dan moet je aantonen dat je last hebt van het snelheidsverlies.
In de reacties op phoronix wordt overigens gemeld dat momenteel deze fix voor ALLE x86 processoren wordt ge-enabled, dus ook AMD

Informatie over welke specifieke CPUs/architecturen zijn getroffen is er nog niet
Als de AMD patch die vanuit het artikel gelinkt wordt, in de Linux kernel komt, zal het niet voor AMD enabled worden: https://lkml.org/lkml/2017/12/27/2

+ if (c->x86_vendor != X86_VENDOR_AMD)
+ setup_force_cpu_bug(X86_BUG_CPU_INSECURE);
AMD zegt zelf dus dat dit probleem bij hen niet aan de orde is. Mogelijk zal er in de toekomst dus gekeken worden naar het platform, om gebaseerd daarop PTI te gebruiken of niet.

EDIT: ik zie dat AMD inderdaad al een patch heeft uitgebracht. Is dit iets dat nog doorgevoerd kan worden voor de uiteindelijke release van 4.15, of moeten we hiervoor wachten op 4.16?

[Reactie gewijzigd door jvnknvlgl op 3 januari 2018 11:56]

4.15 is nog niet definitief en het zou goed kunnen dat deze patch er door heen kan komen voor de 4.15 versie. Op dit moment zitten we op RC6 en meestal is RC7 de laatste waar eigenlijk geen grote wijzigingen meer in voor komen. Linus kan echter kiezen om dit te verruimen als het nodig is.

Overigens kan je met bijvb Ubuntu zelf kiezen (wel handmatig) welke versie je gebruikt. Voor AMD Epyc servers is versie 4.15 bijzonder interessant ivm de scheduler fix. Zie voor meer info Phoronix.

[Reactie gewijzigd door servicedb op 3 januari 2018 12:29]

Torvalds heeft al aangegeven dat er een RC8 gaat komen, vooral vanwege al het PTI-gebeuren dat net voor RC6 is toegevoegd. Wie weet dus.

http://lkml.iu.edu/hypermail/linux/kernel/1712.3/02898.html
Als je een AMD CPU hebt dan zou je release 4.15 over kunnen slaan als er geen andere grote issues zijn die in 4.15 worden opgelost en wachten op 4.16.
AMD had al een patch ingestuurd om het voor hun processors niet toe te passen.
Klopt, maar die is momenteel nog niet geaccepteerd
De lijst zou wel eens heel lang kunnen worden. Het probleem zit in de speculative execution. Intel processoren gebruiken dat al heel lang, sinds de Pentium Pro. In een worst case scenario zijn alle CPUs vanaf dan betroffen: dus Pentium II, III, 4, M en alle varianten van de Core series.
Volgens mij betreft het speculative loads, aanwezig sinds de core i series.
Gaat deze patch niet extreme veel impact hebben op Virtualizatie ? Als zelfs al de normale linuxkernel serieuze performance verlies aantoont, gaat dit dan niet een pak erger zijn met zaken zoals vSphere waar er bijna niets in userspace draait ? Om nog maar niet te spreken over alle userspace calls op guests die syscalls op de host genereren e.d. ?
Exact! En erger nog, Dit kan wel eens pijnlijke gevolgen hebben voor de prijs per instance voor bv AWS en Azure etc. Een virtualisatie machine kan nu een x-aantal instances draaien. Als de performance 30% inkakt betekend dit gewoon 30% minder capaciteit en moet men dit gaan compenseren met extra hardware. Kan men ook een gefixte cpu eisen?

Ik vraag me af, tuurlijk iedereen kan bij een nieuw product een klein foutje maken. Dat zie je bij auto's ook. Die moeten soms ook een software update krijgen. Maar als daar de performance met 30% door achteruitgaan zou niemand meer zon auto willen en zou iedereen de auto terugbrengen.
Ik hoop van niet net half jaar alle hosts vervangen op me werk. Kan met geen mogelijkheid uit gaan leggen aan de directeur dat de aangekochte spullen opeens net zo snel zijn als de 5 jaar oud andere spullen welke vervangen zijn want economisch afgeschreven. (gelukkig hebben we dan nog de 14 cores ipv 6 per socket :P welke dan nog enigszins voor een capaciteit uitbreiding zorgt.)
Dus 'overall' wint Intel de cpu race door verborgen onveiligheid.
Nee, want diezelfde Intel CPU's zonder bug zouden even snel geweest zijn. Het gaat niet over een shortcut om prestatiewinst te halen maar "gewoon" over een bug in het ontwerp.

Het is de workaround in de software die voor de grote vertraging zorgt, omdat de bug zelf niet meer kan rechtgezet worden.
Nee, want het is niet geheel onaannemelijk dat de overgeslagen check een performancewinst tot gevolg heeft gehad.
Dezelfde check op normale (niet-voorspelde) instructies is wel actief bij Intel processoren, en daar heeft het geen noemenswaardige impact op de prestatie. Als ik goed begrijp wat de workaround precies doet, dan kan ik mij hÚÚl goed voorstellen dat het juist die patch is die voor de zware impact op de prestatie zorgt.

Het lijkt me wel een mug doden met een bazooka (want in 99,99999% van de gevallen is er niets aan de hand), maar als dat de enige manier is om het lek te dichten, dan moet het maar. Die 0.00001% van de gevallen dat een malware door de mazen van het net probeert te glippen, kan grote gevolgen hebben.

(Het lijkt me ook geheel onaannemelijk dat Intel deze check bewust zou overslaan: zij weten ook wat de mogelijke impact is als dit uitkomt)

[Reactie gewijzigd door BigBangJoe op 3 januari 2018 15:36]

Mee eens :) Het is zeker de fix die nu voor de performancedegradatie zorgt. Ik denk alleen niet dat de opmerking van swel daarop sloeg.
Niet aannemelijk. Zo'n check kost geen cycles, het kost gewoon een klein stukje extra logica op de die. In verhouding tot het totale ontwerp welhaast verwaarloosbaar weinig ook, dus zelfs om de financiŰle besparing hoefden ze het niet te doen. Het is echt gewoon dom iets over het hoofd zien wat weinig geld en geen performance had gekost om te implementeren, maar als je het eenmaal vergeten bent hang je.

Als je diep in het motorblok ÚÚn boutje vergeten bent te bevestigen en je komt daar pas achter nadat het blok weer in de auto hangt en je het boutje op de werkbank ziet liggen heeft dat je niks gespaard, niks opgeleverd, maar hoogstwaarschijnlijk wel een niet (netjes) te gebruiken of af te leveren auto opgeleverd. Net zoiets :)
Hij maakt daarbij duidelijk dat AMD-chips 'speculatieve geheugenreferenties' niet ondersteunen.
Laten we van een bug even een feature maken :?

AMD staat dit gewoon bewust vanuit het design niet toe, in tegenstelling tot zoals het nu lijkt, Intel.
Het is een zodanig riskante feature dat AMD em (naar nu blijkt terecht) heeft geskipped... Intel heeft nu een bug te pakken, en ik ben benieuwd of nu iedereen naar AMD overstapt als die een whopping 30% performance-winst krijgen (tot de volgende Intel-CPU, met Management Engine 2.0)
AMD heeft geen feature overgeslagen, het is eerder Intel die dat doet. Ook AMD processoren speculeren over verdere instructies om zo nu en dan wat tijdswinst te pakken. Het verschil tussen Intel en AMD hierin is dat AMD controleert of geheugen dat tijdens dat proces benaderd wordt wel benaderd mag worden. Intel doet dit niet.

Overigens heeft de Intel ME er ook niets mee te maken?

[Reactie gewijzigd door Glashelder op 3 januari 2018 12:02]

AMD laat alleen speculaties toe naar adressen met hetzelfde of een lagere beveiliging. Intel doet dat niet, en daardoor moet dat nu softwarematig opgelost worden, ten koste van performance. Of het speculeren naar kernelspace performance-winst oplevert weet ik niet, maar het zou me weinig verbazen.

De ME heeft hier inderdaad niets mee te maken, maar vormt in mijn ogen ook een beveiligingsrisico, dat nog los aangepakt moet worden. Echter vermoed ik dat Intel hier nu vaart achter zet, zodat hun volgende CPU-lijn van geen van beide (bekende) issues last heeft.
De management engine zelf is ook al een beveiligingsrisico. Er is een reden dat er her en der mensen zijn die hard aan het werk zijn om de ME in zijn geheel uit te schakelen.
Klopt helemaal.

Een AMD-medewerker gaf deze hint voor de oorzaak:
AMD processors are not subject to the types of attacks that the kernel
page table isolation feature protects against. The AMD microarchitecture
does not allow memory references, including speculative references, that
access higher privileged data when running in a lesser privileged mode
when that access would result in a page fault.

Bron
Klinkt als een verstandige overweging, om geen toegang tot geheugenplaatsen met hoog privilege vanuit processen met laag privilege toe te staan. Dan vraag ik me af waarom Intel dat wel doet. Shortcut?
Yep, een shortcut. Is normaal gesproken geen probleem aangezien het een speculative load betreft, als de commit optreedt wordt direct de exception handler aangeroepen. Alleen vermoed ik dat de data in de registers op dat moment stale is.
Bedoel je dat 'ie dan in de registers blijft staan, maar dan onbeschermd? Dan is er niet goed over nagedacht.
Het blijkt om de cache line te gaan. Hoe ze die vervolgens uitlezen weet ik niet.
Kun je geen harde tik op je pc processor geven zodat de cache stuk gaat? Probleem opgelost. Harwarematig!
Voordat men schreeuwt dat dit geen invloed heeft op gamers, let op dat DirectX icm Windows veel meer syscalls gebruiken dan Linux en OpenGL dus wellicht wel merkbaar verlies hebben.
Het alleen beetje jammer dat er 1 regel in de inleiding staat over mogelijke windows/MacOS, maar vervolgens het gehele artikel uitsluitend over Linux gaat. Al vraag ik me af hoe performance verlies zit bij DX tov de verliezen die ze halen op benchmarks van compile en postgre, er wordt daarna namelijk wel aangegeven dat ze geen verliezen zien bij gameprestaties.
Behalve dat MS aan een vergelijkbare patch werkt is er nog niks geweten, voor linux kan je de patch al gewoon downloaden en zelf compileren.

Het is dus wel ergens normaal dat er op de linux implementatie gefocust wordt ipv de nog niet (publiek) beschikbare windows (of OSX) versie.
ipv de nog niet (publiek) beschikbare windows (of OSX) versie.
Volgens Alex Ionescu (Uit de OP) is het al gefixt in macOS 10.13.2.
Die update is 6 december 2017 gereleased.
Phoronix is immers een Linux website.
En dat is T.net dan ook? Leuk dat hun bron toevallig een Linux site is, maar wat heb ik aan nieuws als het nieuws maar 20% van het 'totale' probleem is?
Omdat er over de Microsoft kant nog niets bekend is gemaakt vanuit microsoft, want Embargo (tot 13:00 vanmiddag).
De Linux wereld is een stuk opener, omdat wij kunnen meekijken in de source van de kernel.
Microsoft heeft ondertussen ook een KB artikel online staan:

https://support.microsoft...e-speculative-execution-s

en een advisory:

https://portal.msrc.micro...idance/advisory/ADV180002

Hierin wordt aangegeven dat er prestatie verlies zal zijn maar nog niet duidelijk hoeveel. Vooral bij Hyper-v omgevingen. Azure server en desktops krijgen 10 januari kennelijk een reboot om het probleem te "verhelpen".
Het beveiligingsprobleem is voor gamers veel minder urgent, dus niet die patch toepassen zou een optie kunnen zijn.
Ik denk niet dat Windows je die optie gaat geven.
Als ik het zo lees is het een kwestie van de applicaties die vertragen aanpassen om gewoon in de user space van het geheugen te werken. Rottig klusje, maar wel te doen.
Alternatief is AMD hardware er onder te leggen.
Totdat men ook AMD processoren serieus onder de loep gaat leggen en daar bugs in vindt. Waarschijnlijk is de enige reden dat dit nog niet gebeurt is het verwaarloosbare marktaandeel van AMD in de professionele markt.

Er komen wel weer nieuwe patches uit zometeen, zonder negatieve bijwerkingen.
Elke moderne x86 CPU heeft tientallen bugs, komt omdat ze zo complex zijn. Echter is het bijna altijd wel fixbaar via microcode updates en heeft het normaal gesproken eigenlijk geen invloed op de prestaties. Een enkele keer heeft het echter wel zeer ernstige gevolgen en is het niet simpel oplosbaar.

Bijvoorbeeld zoals de TLB bug in de eerste Phenom of de Atom C2000 serie.
Is het bekend waarom in dit geval geen microcode update kan worden uitgevoerd?
Schijnbaar nog niet. Maar dit is een zeer ernstige bug en als je zeker wil weten dat zoveel mogelijk mensen de patch krijgen lijkt mij dit toch wel de beste manier. Microcode updates komen bijvoorbeeld via BIOS/UEFI updates, maar deze worden lang niet altijd ge´nstalleerd en zeker niet binnen een kort termijn.

Wil je er dus zeker van zijn dat een zeer ernstige bug als deze gepatcht wordt. Is het het beste dat je dat via het OS doet, dus via Windows Update, Kernel van Linux of via updates van Apple. Daarmee bereik je verreweg de grootste groep. Ook omdat veel producten al zou oud zijn dat de moederbord fabrikant helemaal geen BIOS/UEFI upgrade meer wil uitbrengen. En de kans is natuurlijk sowieso klein dat die updates dan alsnog worden ge´nstalleerd.

De kans dat het zonder prestatieverlies kan worden opgelost via een microcode update lijkt mij trouwens ook onmogelijk, daarmee is dit dus gewoon de meest logische manier van patchen.

[Reactie gewijzigd door -The_Mask- op 3 januari 2018 14:25]

Microcode updates kunnen ook via het OS gedistribueerd worden. Debian/Ubuntu heeft hier bv. een package voor genaamd 'intel-microcode'. Hiervoor moet je overigens wel de non-free repo toevoegen ivm. licentieperikelen.
Duidelijk verhaal, maar volgens mij is het OS ook in staat om een micro-update uit te voeren. Ik heb namelijk weleens dergelijke updates voor Linux en Windows gezien.

Update: Hardware.info legt duidelijk uit waarom het een OS update betreft:
https://nl.hardware.info/...gt-prestaties-aanzienlijk

Hopelijk komt er ook een optie/update die het "speculeren over toekomstige instructies" uitschakelt op Intel processoren. Aangezien de bug niet optreed bij AMD processoren omdat ze deze functionaliteit niet zouden hebben.

Hopelijk valt de performance impact in de praktijk mee, of komt er een terugroep actie vanuit Intel (i.i.g. voor CPU's die nog garantie hebben (jonger dan 2/3 jaar).

[Reactie gewijzigd door Gijs007 op 3 januari 2018 14:45]

Ik denk dat je dat kunt vergeten. Intel heeft ook geen terugroepactie gedaan van de Intel Atom C2000 CPU's die massaal stuk gingen door een fout in het ontwerp. Alleen sommige fabrikanten die de Intel Atom C2000 serie in hun producten hebben verwerkt hebben een terugroepactie gedaan, maar ook niet allemaal omdat ze niet bij Intel konden aankloppen naar mijn weten.
Klopt maar in 1994 heeft Intel bij de Pentium FDIV bug hebben wel een terugroepactie gehad.

De Intel Atom C2000 zijn niet los te koop, dus wellicht dat de serie/populariteit en algehele imago schade ook een rol speelt in het wel of niet terugroepen van CPU's.
Hopelijk komt er ook een optie/update die het "speculeren over toekomstige instructies" uitschakelt op Intel processoren. Aangezien de bug niet optreed bij AMD processoren omdat ze deze functionaliteit niet zouden hebben.
Het nieuwsbericht is op dit punt een beetje onduidelijk, want AMD-processoren hebben deze functionaliteit wel degelijk, maar (uiteraard) met een andere implementatie die dit probleem niet kent. De reden dat moderne CPU's dit doen is simpel: het levert veel performance op om 'vooruit te denken' en later pas te bedenken of het een goede gok was, zeker als het gaat om trage operaties als toegang tot het geheugen. Dit uitschakelen kan wel eens meer performance kosten dan de huidige oplossing in software.
Microcode updates kunnen ook via het updates van het besturingssysteem ge´nstalleerd worden, van Microsoft is bekend dat ze dit doen.
De bug is nog te nieuw, even geduld aub.
Waar baseer je dit on godsnaam op? Een functie in de processor heeft een bug die niet gerepareerd kan worden (simpel gezegd). De oplossing is om deze functie niet te gebruiken, waardoor system calls erg traag worden (er ie een context switch extra nodig die allerlei caches trasht). (Een andere oplossing is de machine te vervangen door een AMD machine :D)

Dit gaat een hele grote impact hebben. Het betekent bv dat cloud providers al hun host machines (met Intel hardware) moeten herstarten, waarna de capaciteit met 10-30% afneemt. Dat betekent dat meer servers nodig zijn, en ook meer energie.

Bedrijven die bare metal draaien zullen zelf alle servers moeten patchen en rebooten.
Bedrijven die bare metal draaien zullen zelf alle servers moeten patchen en rebooten.
Een cloud provider MOET dit echt doen. Een bedrijf met eigen hardware niet. Als zij compleet ge´soleerd draaien kan men het risico op de koop toe nemen en voor de performance kiezen. Een cloud provider wil niet in het nieuws komen dat partij X partij Y en Z om zeep geholpen heeft.
Inderdaad. Voor de meeste organisaties zullen waarschijnlijk alleen de DMZ machines een update moeten krijgen
Je kunt de patch ook niet installeren. Het is niet zo dat er al een werkende exploit is.
Ook AMD heeft in het recente verleden last gehad van bugs in hun CPU's. Even zoeken levert al snel de volgende resultaten:

https://hothardware.com/n...are-ryzen-smt-bug-and-fix
http://www.zdnet.com/article/amd-owns-up-to-cpu-bug/

Echter die bugs zijn een stuk minder kritiek dan deze van Intel.
Je klinkt alsof dat uberhaupt mogelijk is in veel gevallen. IO vereist nou eenmaal syscalls.
gewoon in de user space [...] te werken
Volgens mij is dit in lang niet alle gevallen mogelijk. Als een applicatie een netwerk socket nodig heeft of vergelijkbare I/O operaties moet doen vindt altijd een tijdelijke hand-off plaats naar kernel space zodat de kernel deze resource aan kan maken voor de applicatie. Er zijn dus wel degelijk scenario's te bedenken waarin dit geen oplossing biedt en het vertragende "kernel page table isolation" nodig is.
Het spijtige is, dat voor oudere programma's een dergelijke update niet zal worden gemaakt.

Nu zullen oudere programma's minder rekenkracht nodig hebben, maar tot 30% verminderde prestaties blijft jammer.

Op dit item kan niet meer gereageerd worden.


Apple iPhone XS Red Dead Redemption 2 LG W7 Google Pixel 3 XL OnePlus 6T (6GB ram) 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