'Intel maakt patches voor 8 nieuwe Spectre-achtige lekken, waarvan 4 kritiek'

Intel werkt samen met OS-makers aan patches voor acht nieuwe cpu-lekken die lijken op Spectre, meldt het Duitse c't. Van de lekken, die samen Spectre-ng heten, zijn er vier 'kritiek'. Een van de lekken zou een eenvoudige aanval op een host vanuit een vm mogelijk maken.

Het Duitse blad meldt dat het beschikt over informatie over de Spectre-ng-lekken, die nu nog geheim zijn. Er zou 'geen twijfel' over bestaan dat het om echte kwetsbaarheden gaat, die inmiddels eigen CVE-kenmerken hebben gekregen. Technische details ontbreken, maar de scenario's voor aanvallen met behulp van de lekken zouden dezelfde zijn als bij Spectre. Een uitzondering is dat een van de nieuwe varianten een aanval vanuit een vm op een hostsysteem of een andere vm zeer eenvoudig maakt, claimt c't. Dat brengt onder meer risico's met zich mee bij shared hosting en soortgelijke constructies.

Op die manier zouden bijvoorbeeld privésleutels en andere gevoelige gegevens te stelen zijn. Dat kon met de originele Spectre-kwetsbaarheden ook al, maar doordat bepaalde voorkennis was vereist, was een dergelijke aanval moeilijk uit te voeren. Het is onduidelijk of AMD eveneens is getroffen. Een klein aantal ARM-processors zou in ieder geval met dezelfde kwetsbaarheden te maken hebben. Intel ontwikkelt sommige patches zelf en andere in samenwerking met de makers van besturingssystemen. De patches zouden in twee 'golven' naar buiten komen: één in mei en de andere in augustus.

Een van de kwetsbaarheden is weer gevonden door Googles Project Zero-beveiligingsteam, dat ook betrokken was bij de ontdekking van de eerdere varianten. De deadline voor een patch en de daaropvolgende openbaring door Project Zero ligt volgens c't op 7 mei. Het team hanteert zijn deadlines van negentig dagen meestal vrij strikt. Ook Microsoft zou zich voorbereiden op het uitbrengen van patches.

De details van de oorspronkelijke Spectre-kwetsbaarheden, waarvan twee varianten bestaan, kwamen oorspronkelijk begin dit jaar naar buiten, nadat Intel er al enige tijd van op de hoogte was. De cpu-lekken, waarvan Meltdown vrijwel alleen gevolgen heeft voor Intel-cpu's, maken het mogelijk om gevoelige informatie op een kwetsbaar systeem te achterhalen. Sindsdien is een complex patchproces op gang gekomen, waarbij patches in de vorm van besturingssysteemupdates en microcode naar buiten zijn gebracht. Intel werkt nog steeds aan patches.

Reacties (66)

Man, the rabbithole blijkt dieper dan gedacht.

Ik ben benieuwd hoeveel performancewinst, van de afgelopen jaren, dit weer teniet doet.

Ik zou toch liever iets inleveren op Performance om hier meer Veiligheid voor terug te krijgen, Dan teveel Performance en te weinig Veiligheid.

Dat wil iedereen uiteraard en dat staat ook niet ter discussie. Dat Intel zoveel fouten in de chips heeft zitten is wel een openbaring en je vraagt je af waarom zulke grote fouten nog in zulke gangbare cpu's zitten. Intel heeft gewoon zitten slapen.

Dat wil iedereen uiteraard en dat staat ook niet ter discussie. Dat Intel zoveel fouten in de chips heeft zitten is wel een openbaring en je vraagt je af waarom zulke grote fouten nog in zulke gangbare cpu's zitten. Intel heeft gewoon zitten slapen.

Het feit is dat er kwetsbaarheden worden aangetoond in algemeen geaccepteerde technieken in CPU design; dat is absoluut niet iets Intel specifieks. Natuurlijk ligt Intel wel onder het vergrootglas als marktleider, maar we weten nu dat eigenlijk alle moderne out-of-order core ontwerpen gevoelig zijn voor Spectre. Meltdown was iets uitzonderlijker, en had te maken met een bepaald soort optimalisatie die niet in elke architectuur toegepast wordt.

Een goeie analogie voor de huidige situatie is wellicht dat flink wat jaren geleden onderzoekers (en hackers) aantoonden dat bepaalde algemeen geaccepteerde technieken in besturingssystemen niet veilig genoeg waren. Dingen zoals buffer overflow exploits, of return oriented programming, waar nu extra hardware en software oplossingen voor zijn bedacht zoals de Non-Execute bit en Address Space Layout Randomization. Dat waren ook kwetsbaarheden die niet specifiek voor een enkel besturingssysteem golden, omdat het een kwetsbaarheid was in algemeen geaccepteerde technieken. Alleen is het grote nadeel natuurlijk dat je hardware iets lastiger aanpast dan software

Het feit is dat er kwetsbaarheden worden aangetoond in algemeen geaccepteerde technieken in CPU design; dat is absoluut niet iets Intel specifieks.

Hoewel je strict genomen gelijk hebt, ligt het ergste van de impact van Meltdown en Spectre vrijwel volledig bij Intel. De impact van Spectre v1 en Spectre v2 is erg beperkt, zowel qua mogelijkheid tot exploitatie als de performance impact van patches. Wat betreft Meltdown zijn er maar drie fabrikanten getroffen (voor zover bekend):

ARM
Alleen de ARM Cortex A75 is getroffen - het aller-allernieuwste ontwerp van ARM dat wordt gebruikt in de nieuwste high-end telefoons (Galaxy S9 en telefoons met een Snapdragon 845). Op het moment dat Meltdown uitkwam kon je als consument echter geen hardware met een Cortex A75 kopen. Hierdoor konden softwaremitigaties in alle producten worden uitgerold (of dit echt gebeurd is is trouwens onduidelijk).

Apple
Bij Apple zijn alle out-of-order CPU's getroffen sinds de Apple A7 (iPhone 5S). Echter is het op iOS- en tvOS-apparaten wat moeilijk om onvertrouwde code te draaien. Daarnaast support Apple al deze telefoons nog, en heeft mitigaties uit kunnen rollend, waardoor de impact behoorlijk beperkt is. Er is tot op heden geen jailbreakmethode gevonden die gebruik maakt van Meltdown.

Voor zowel ARM als Apple geldt daarnaast dat de chips met name worden ingezet in mobiele use cases. De performance impact van Meltdown-mitigaties ligt met name in code die gebruik maakt van syscalls (voorbeelden: compilen van code, web servers), en op mobiele apparaten zijn er gewoon minder veel use cases die syscall heavy zijn.

Intel
Bij Intel wordt vermoed dat alle cpu's tot en met de Pentium Pro uit 1995 kwetsbaar zijn voor Meltdown. Met uitzondering van de eerste paar generaties Atom-chips zijn daarmee alle Intel x86-chips van de afgelopen 20+ jaar kwetsbaar. De software die op deze apparaten is extreem divers en kan niet altijd eenvoudig worden gepatcht. Daarnaast worden Intel-chips veel meer voor high-end, syscall heavy code ingezet, en zijn daardoor vatbaarder voor de negatieve performance impact. Daarbij moet ik wel de nuance aanbrengen dat software aangepast kan worden om beter om te gaan met de performance impact, zoals in de Linux-kernel ook duidelijk gebeurt.

Bovendien hebben IBM (POWER, PowerPC, z/Architecture), Sun/Oracle (SPARC), Fujitsu (SPARC) en AMD (x86, x86_64) tal van high performance processors uitgebracht de afgelopen 20 jaar die het Meltdown-probleem klaarblijkelijk niet hebben. Ironisch genoeg heeft Intel in de afgelopen 20 jaar zelf een architectuur uitgebracht - Itanium - die om specifieke redenen ook niet kwetsbaar is (ook niet voor Spectre). Spectre heeft iedereen last van, maar zoals gezegd is de impact daarvan beperkt.

Tl;dr: Meltdown en Spectre zijn in theorie niet alleen een probleem van Intel, maar Intel ondervindt wel 99% van alle problemen die ermee gepaard gaan.

[Reactie gewijzigd door DCK op 3 mei 2018 17:44]

1 opmerking en 1 vraag:

IOS voert toch voortdurend externe, ongecontroleerde code uit met Javascript in de browser?

Hoe zit het met de impact van de patches op de prestaties van NVME-opslag? Ik heb gelezen dat daar voor gewone burgers de meeste impact zit, maar het is lastig echt duidelijke praktijktests te vinden van vóór en na.

De performance afname bij opslag zie je vooral in synthetische tests met use cases die totaal niet lijken op normaal "realworld" gebruik. Vandaar dat je in bepaalde tests een redelijk grote impact zal zien op storage gebied, maar dit in de praktijk amper zal merken.

Daar ben ik dus benieuwd naar. Precies hetzelfde zegt men ook over NVME in het algemeen. Andere bronnen spreken dat weer tegen en zeggen dat NVME wel degelijk merkbaar verschil kan maken bij bepaalde realistische taken voor burgers. Ik heb het idee dat er over al deze zaken nog geen communis opinio bestaat. Of ik kan die in elk geval niet goed vinden. Ik heb wel 15 verschillende bronnen met testen die allemaal tot andere conclusies komen.

Ik merk er in de praktijk weinig van, een systeem met een 850 Evo sata en een 960 NVME laat uiteraard in diverse tests een flinke performance winst zien. In de praktijk heb ik dat idee echter niet direct, het zijn eerder zeer subtiele verschillen. Programma's en spellen lijken iets sneller te laden, echter zijn de verschillen in mijn optiek zeer klein. Inloggen bij bijv. World of Warcraft, wat volgens mij een seconde of 20-30 duurt zit bijv. een minimaal verschil in, misschien een seconde. Echt merkbaar is het niet. Mogelijk dat het in bepaalde specifieke scenario's wel een meer merkbare winst kan brengen, maar waar HDD > SSD voor mij de grootste upgrade is geweest die ik denk ik ooit gedaan heb, is Sata SSD > NVME voor mij in ieder geval niet meer dan een gevoelsmatig zeer kleine qualitiy of life upgrade.

OK dank voor je indruk.

IOS voert toch voortdurend externe, ongecontroleerde code uit met Javascript in de browser?

Zeker. Ik had wat specifieker kunnen zijn, maar het is niet aangetoond dat Meltdown misbruikt kan worden via iets anders dan native gecompilede code. Sommige bronnen online claimen dit, maar als je doorklikt blijkt het altijd alleen om Spectre te gaan.

De reden dat nvme-opslag extra hard geraakt is, is omdat (AFAIK) alle opslag hard geraakt wordt. Schijfopslag gaat via syscalls, en met snelle nvme-opslag wordt je dus relatief veel meer geblokkeerd als je syscalls trager gaan. Maar je zou dit dus alleen met heel zwaar schijfgebruik moeten merken - ook specifieke use cases die je vooral op werkstations en servers tegenkomt. Misschien dat video editing wat merkbaar trager gaat op een iPad Pro.

Zoiets kan ik me inderdaad voorstellen. Ben ook benieuwd naar b.v. het laden van een level in een spel, of het opstarten van grote programma's zoals Photoshop of zo.

Issue is imho wel dat Meltdown vrij simpel gepatched kan worden. Er zijn "alleen" OS/software updates nodig om het nu te patchen, en volgens de geruchten is de "in silicon" permanente fix ook vrij simpel en zal deze een boel van het huidige mogelijke performance verlies weer terug draaien, terwijl ook beter geoptimaliseerde software het performance verlies flink tegen kan gaan. Al moet ik zeggen dat het mogelijk performance verlies een stuk minder lijkt te zijn dan in het begin gevreesd werd. In realworld consumenten / kantoor workloads zie ik eigenlijk geen enkel verschil, in diverse zakelijke virtualisatie scenario's (bedrijfs clusters van een gemiddeld bedrijf, met wat DC's, Applicatie servers, Fileserers Database servers en soms wat RDS en ondersteunende servers) over het algemeen 0-5% verlies in realworld workloads met zeer zelden een uitschieter naar boven bij extreem hoge I/O. In synthetics die specifiek worstcase scenario's testen m.b.t. tot het aantal syscalls zie je inderdaad meer verlies, maar in realworld scenario's zie ik dat in ieder geval niet terug.

Wat betreft de diverse Spectre varianten is dat een stuk lastiger, deze hebben (vaak) OS updates gecombineerd met microcode updates nodig om volledig gepatched te worden. Ze zijn lastiger te exploiten, maar ook veel lastiger om volledig uit te bannen en daarmee imho mogelijk wel een (veel) groter toekomstig risico dan Meltdown. Zeker ook omdat de verwachting is dat er nog (veel) meer varianten van Spectre op zullen duiken in de toekomst.

Je ziet bijv. nu al dat veel fabrikanten nog niet eens updates hebben uitgebracht voor Haswell moederborden, laat staan voor Ivy, Sandy e.d. waar Intel allang updates voor uitgebracht heeft. AMD geeft ook aan microcode updates uit gebracht te hebben, maar volgens mij ook nog niet beschikbaar in het "wild" van de moederbord fabrikanten. Nu kan je dan uiteraard wel met een Tool als de VMwqare microcode update driver of de MS patch uit de Catalog je eigen systeem patchen totdat een fabrikant eindelijk met een bios update komt als je een Intel CPU hebt (als ze dat al ooit doen). Maar veel gebruikers zullen dat nooit doen. AMD levert echter de benodigde microcode alleen uit aan moederbord fabrikanten en OEMs waardoor je daar van afhankelijk bent en niet eens zelf kan patchen zou je dat willen.

En daar zit imho wel het gevaar is, zeker met de verwachting van enkele experts dat het exploiten van Spectre varianten nu nog lastig is, maar dat dit mogelijk in de toekomst een stuk makkelijker gaat worden. Ik krijg echt het idee dat een boel systemen nooit gepatcht zal gaan worden voor Spectre V1 / V2 en nieuwere varianten ook al zijn de updates beschikbaar vanuit Intel en AMD.

[Reactie gewijzigd door Dennism op 3 mei 2018 18:55]

Is dat zo?
Het is dankzei de "fouten" dat ze zoveel performance meer hebben dan vergelijkbare AMD systemen. Voor de aanvallen waarbij de patches performance kosten, zijn AMD systemen niet vatbaar. en leverd Intel tot bijna 20% in. Het is echt geen grote stap om dan te stellen dat Intel alleen maar dankzei deze "fouten" zoveel winst heeft kunnen pakken: want performance kroon.

Wie zegt mij dat Intel dit niet bewust heeft gedaan om zo het marktaandeel AMD te verkleinen? Dat soort truukjes hebben ze vaker gedaan. Hou er rekening mee dat ze dat ook soort van verplicht zijn naar de aandeelhouders: winstmaximalisatie.

Dat is best mogelijk wat je zegt, maar ze lopen wel een goed stuk imago schade op bij de kenners. Ik zeg bewust kenners, want het grote publiek, als ze het al horen, weten A: niet waar men het over heeft en B: merken ze het prestatie verschil toch niet. Dus ja, het is een goede theorie in mjin ogen.

Spectre werkt zowel op Intel cpu's als AMD alsook sommige ARM cpu's. Zeggen dat dit weer een truk is van de evil, monopoly corp Intel is wel zeer kort door de bocht en lichtjes tinfoil hat.

dat zei ik dus ook niet.... Ik zei dat de bug waarvan de patch 20% peformance impact heeft ( en dat is meltdown) niet werkt op AMD. Over de andere bugs ( spectre ) heb ik het niet gehad. Deze hadden dan ook geen performance impact.

Als ik het mij goed herinder is de reden dat deze bug niet werkt op AMD, omdat dat stukje geheugen/cache per thread encrypted is bij AMD.

Kan goed zijn dat er iets encrypted is, wat uiteraard extra cpu tijd met zich meebrengt, maar voorlopig vind ik zelf enkel "architectural differences" als uitleg van AMD. Ik was benieuwd hoe jij dat zonder bronnen of bewijs kon ombuigen naar "Intel deed dit met voorbedachte rade om AMD uit de markt te drukken". Dat vind ik nog steeds kort door de bocht.

Edit: door het feit dat ook ARM als platform getroffen wordt, is dit helemaal geen Intel vs AMD ding.

[Reactie gewijzigd door MrFancyPantss op 3 mei 2018 15:42]

Ik beweer dat dus ook helemaal niet. Ik zeg alleen dat het een kleine stap is om zoiets te kunnen stellen.

Verder zeg ik dat het track record van Intel aangaande AMD de markt uit drukken nou niet echt goed te noemen is ( dit is een vast gesteld feit ).

En als laatste stel ik een vraag: Wie zegt mij dat Intel het dit keer niet ook zo gedaan heeft.

Behalve dat ik zeg dat ik het een kleine stap vind, beweer ik helemaal niks, benoem ik een feit, en stel ik een vraag. Daarna leg jij ( sry, dit kan echt niet anders dan op de persoon ) mij in de mond dat ik beweer dat Intel dat doet. Ik vroeg het me alleen af. wezenlijk verschil.

Ja akkoord, maar je bericht is voor interpretatie vatbaar. Als je uitzoekt hoe Meltdown juist werkt vind ik dat persoonlijk nu niet de eerste conclusie. 't is een redelijk complexe en omslachtige manier om protected memory te lezen, die al sinds Intel cpu's van 1985 mogelijk is. Dat de exploit pas recent werd ontdekt lijkt me nu niet in de richting te wijzen die je aanhaalt in je eerste bericht, maar het is zeker goed om daarover na te denken en dat in acht te nemen.

Zou dit wellicht ook letterlijk met performance te maken hebben? Dat Intel wat shortcuts heeft genomen om een hogere performance te krijgen ten koste van veiligheid?

Ja, Linus Tech Tips heeft een Tech Quickie over Spectre en Meltdown. Misschien eens interessant om te kijken. Dit zijn exploits op een soort van instructie-caching van de cpu. Over de jaren heen is de cpu geoptimaliseerd op dit vlak en zeer goed geworden in het "raden" wat de volgende instructie zal zijn die die moet uitvoeren en kan deze dan cachen. Dit is een vrij logische optimalisatie waar nu dus exploits voor bekend worden.

Dit is niet enkel Intel, ik geloof dat Intel enkel door Meltdown wordt getroffen en zowel AMD als Intel door Spectre.

Edit: hier is het filmpje https://www.youtube.com/watch?v=NArwG6yaWJ8, een aanrader om te kijken als je een idee wil krijgen van hoe en waarom die exploits nu pas boven komen. De exploits zelf zijn vrij ingenieus imo.

[Reactie gewijzigd door MrFancyPantss op 3 mei 2018 15:19]

Thanks! Ik kijk sinds kort Linus zijn video’s maar deze had ik nog niet gezien.

Leek mij een goede video, geschikt voor een breed publiek hij legt het simpel en duidelijk uit zonder zaken te verdraaien door ze te simpel voor te stellen. Zo snappen de casual hardware enthousiasten en andere IT-minded mensen ten minste wat er gebeurt. Kudos to you Linus

Linus en z'n team zijn daar goed in, zeker in hun TechQuicky video's. Maar ook in andere reviews houden ze de eindgebruiker in het oog, die moet het snappen.

Niet helemaal hetzelfde maar ook zeker interessant zijn LGR en The 8-bit Guy. Veel videos over oude tech en games. Ik ben zelf pas rond de Pentium 2's ingestapt maar vind al die oude PC en gameconsoles super fascinerend. Zonder ooit een Commodore64 te hebben aangeraakt heb ik door die video's het idee dat ik er mee overweg zou kunnen, mocht ik er ooit een tegen komen.

[Reactie gewijzigd door lepel op 3 mei 2018 18:56]

Voor ouwe tech kijk ik naar http://www.techmoan.com/; geen computers, maar nixie-buizen, cassette's en lp's, en dat soort dingen.

Da's pas ouwe tech

Die had ik er bijna bij gezet! Ik ken hem pas sinds kort (door The 8-bit Guy) maar heb nog niet heel erg veel van zijn video's gezien. Ik moet wel zeggen dat ik echt van zijn intro en outro hou.

Achja, als je vanuit de Linux community naar Intel kijkt dan zijn er al langer problemen bij Intel. Uiteindelijk is zweigen in sommige gevallen goedkoper dan een degelijk product maken.

Nouja... er was toch al een tijdje commentaar op de Intel Management Engine. Diverse security specialisten waarschuwden toen al dat er nog veel meer issues verstopt konden zitten in de microcode van Intel maar daar was domweg geen zicht op.
Dat deze doom scenario denkers achteraf gelijk hadden... tja.

Dat lijkt me redelijk gegeven, wat me meer interesseert is dat het de laatste tijd niet zomaar even het aantal GHZ opschroeven is om performance erbij te krijgen. Vandaar het hele: minder GHZ maar meer CPU cores idee in huidige CPUs.

Zijn hier al dingen voor geschreven trouwens? Ik lees veel over de kwetsbaarheden, maar op de "Total Meltdown" screwup van MS na, heb ik nog niets gezien.

@TTLCrazy precies, je stelt het even scherper.

[Reactie gewijzigd door Sandor_Clegane op 3 mei 2018 10:48]

Voor een desktop of infra wel. Maar verder ligt dat natuurlijk helemaal aan het scenario.

Als derden geen code kunnen uitvoeren op de machine heb je liever performance. Denk bijvoorbeeld aan (super)computing clusters of mining rigs. Of een cluster als google search.

Het is geen aanval om code uit te voeren dacht ik, maar eerder om gegevens uit RAM te kunnen lezen waar je normaal geen access toe zou mogen hebben.

Ja, maar je moet code kunnen uitvoeren om het RAM uit te kunnen lezen via Spectre/Meltdown. Dus ook deze kwetsbaarheid is niet te misbruiken zonder dat je code kunt uitvoeren. Het hoeft echter geen code op hoog beveiligingsniveau te zijn: ik geloof dat het ook al met Javascript in de browser had gekund, voordat browser-makers daar in januari beperkingen op zetten.

logisch, aangezien spectre en meltdown code is maar daar zijn dan weer 1001 andere exploits voor idd

Ik meende dat Basseke NL dacht aan een scenario waarbij er geen browser gedraaid wordt en alleen maar vertrouwde programma's, zoals een onderzoekscomputer bij een wetenschappelijk instituut of zo. Maar goed, ik geloof dat we elkaar wel begrijpen.

Ik liever niet, mijn laptop met i7-4500u gebruik ik alleen in de universiteit. Persoonlijke data staat er niet op, zou liever de optie willen om de performantie terug te krijgen. Want het is echt niet meer te doen met de Meltdown patch.

Echt? Ik merk amper verschil.

Dan is er toch ergens iets verkeerd gegaan. Ik heb een wat oudere laptop liggen met die CPU, nauwelijks meetbaar verschil na de patches.

Op mijn laptop van lang geleden, die was al zo langzaam, dat ik geen last had van DoubleSpace om mijn hdd te "vergroten".

Waar heb je het überhaupt over? Ik heb het over een laptop met dezelfde cpu (en dus waarschijnlijk vrijwel identieke verdere specs in dit geval) als die in de post waar ik op reageer, die blijkbaar andere resultaten haalt.
Props dat je doublespace nog kent, maar verder gaat je reactie niet echt ergens over ben ik bang.

Ik bedoelde, dat je oudere laptop waarschijnlijk al trager is, dat je een paar % vertraging door deze patch niet opmerkt.
Had er over heen gelezen dat je de zelfde CPU hebt.

Bij wat voor taken merk je vooral verschil? Ik heb gelezen dat het vooral merkbaar is bij intensief gebruik van NVME?

Draaien van VM's en IntelliJ.

IntelliJ? Hoezo gebruikt dat dan veel resources? VM's kan ik me voorstellen.

Van 4770K naar Pentium 3 performance

Hm ben benieuwd hoeveel man daadwerkelijk zijn pc heeft gepatcht aangezien er ook een bios update nodig is. Zelf dit pas afgelopen weekend gedaan.

En hoe doet apple dit? Kunnen zijn via een appstore update ook een Firmware update forcen?

Apple kan gewoon een update voor macOS releasen? En evt. microcode updates kunnen ook in een macOS update komen, dan kan de microcode simpelweg ingeladen worden tijdens het bootproces.

Firmware-updates komen gewoon met de andere updates mee. Dat gaat volautomatisch en je merkt er eigenlijk nauwelijks iets van.

Hm ben benieuwd hoeveel man daadwerkelijk zijn pc heeft gepatcht aangezien er ook een bios update nodig is.

Een BIOS update is niet nodig. Microcode kan voor x86 ook door het OS ingeladen worden, wat vaak wordt gedaan door de boot loader/de opstartende kernel.

[Reactie gewijzigd door The Zep Man op 3 mei 2018 11:05]

BTW: New Side-Channel Attack on Directional Branch Predictor
http://www.cs.ucr.edu/~nael/pubs/asplos18.pdf
https://arstechnica.com/g...ranch-prediction-attacks/

Die was hier op Tweakers ook al langs gekomen
nieuws: Intel: recent BranchScope-sidechannel op cpu's vereist geen nieuwe pa...

BranchScope kon ik eigenlijk niet zo serieus nemen, en vond ik nogal ver gezocht dat je daar echt veel nuttige informatie mee kon afleiden. Ja er werd wel wat informatie gelekt, maar het was zeker geen high-bandwidth sidechannel attack zoals de originele Meltdown en Spectre v1/v2. Ik ga er niet van uit dat het onderdeel is van een van de 'lekken' die hier aangehaald worden.

[Reactie gewijzigd door Squee op 3 mei 2018 11:58]

Het pijnlijke aan de hele zaak is dat de Itanium-processor hier allemaal geen last van heeft dank zij haar EPIC architectuur.

Huh, ik zie nu pas dat AMD Intel nog een trap na geeft (EPYC), haha.

Oei, ik ging er eigenlijk toch wel vanuit dat het hele probleem verholpen was d.m.v. patches totdat iemand de patch weet te omzeilen / kraken.
Nu blijkt er toch nog wel meer aan de hand te zijn.

Wat een heerlijke naiviteit.:)
In feite heb je gewoon een processor die je het beste in de vuilnisbak kan gooien, ware het dat er niets beters voorhanden is.

Wanneer komt t.net met een performancevergelijking voor en na de (huidige en nieuwe) patches bij Intel? Op Anandtech was er een hoop gedoe over bij de lancering van de nieuwe AMD Zen processoren. Ik zou graag wat meer gegevens er van willen zien.

Je hebt tegenwoordig al minstens een I9 processor op je moederbord nodig om uiteindelijk nog de rekenkracht van een Pentium 4tje over te houden, na alle patches, advertenties, spam, virusscanners, vpn kanalen en wat allemaal nog meer nodig is, om je computer een beetje veilig te houden .....

In principe zijn er heel veel side channel attacks te bedenken, dit was nog maar het topje van de ijsberg. Maar waarschijnlijk niet met zo'n hoge bandbreedte (SNR) als we met Spectre en Meltdown gezien hebben, en dus in de praktijk niet zo gevaarlijk. Mooie kans wel voor PhD studenten om papers te schrijven.

is het CVE-2018-10689?

Nee, dat is een buffer overflow, geen hardware design error.

Volgens mij zijn de daadwerkelijke CVE nummers nog niet gepubliceerd. Afgaand op wat ik op de website van intel lees hebben ze al een blok CVE nummers gereserveerd. Of dit moet voor iets compleet ongerelateerds zijn.

Als ze nu eens de slimme jongens van Datapoint konden vragen.