Intel spreekt tegen dat nieuwe SpectreRSB-aanvallen huidige bescherming omzeilen

Onderzoekers van de Universiteit van Californië hebben nieuwe Spectre-achtige aanvallen onder de naam SpectreRSB gepresenteerd. Bestaande tegenmaatregelen zouden die niet tegenhouden. Intel spreekt dat tegen en zegt dat er geen nieuwe maatregelen nodig zijn.

In hun recente paper schrijven de vier auteurs: "Geen van de bekende tegenmaatregelen zoals Retpoline en Intel-microcode zijn in staat om alle SpectreRSB-aanvallen tegen te houden." De naamgeving van de aanvallen betekent dat het gaat om Spectre-achtige technieken, waarmee het mogelijk is om gevoelige informatie uit te lezen. In plaats van zich te richten op de branch predictor van cpu's, richten de door de onderzoekers ontdekte varianten zich op de zogenaamde return stack buffer, oftewel rsb, die volgens de auteurs return addresses voorspelt. De onderzoekers presenteren zes verschillende varianten van SpectreRSB.

Overzicht uit de paper van aanvalsvarianten en tegenmaatregelen

In een reactie aan The Register laat Intel weten dat het van mening is dat 'SpectreRSB gerelateerd is aan branch target injection' en dat het verwacht dat bestaande maatregelen ook tegen de nieuwe varianten werken. Daarmee doelt Intel op de tweede variant van de Spectre-aanval, die begin dit jaar in de publiciteit kwam. Intel zegt dat het inmiddels al richtsnoeren voor ontwikkelaars heeft gepubliceerd in een whitepaper. De onderzoekers testten hun aanvallen op Intel-processors van de Skylake- en Haswell-generaties en vielen SGX-enclaves aan. Hoewel ze alleen Intel-systemen testten, hebben ze hun bevindingen ook gedeeld met ARM en AMD, omdat die eveneens gebruik zouden maken van return stack buffers.

De bevindingen van de onderzoekers komen boven op de eerdere ontdekkingen van Spectre-achtige aanvallen, waarvan het aantal gestaag blijft stijgen. Tweaker Squee heeft alle verschillende varianten onlangs in kaart gebracht, die ook hieronder in een tabel zijn weergegeven.

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

Reacties (48)

[Squee]

Ha, bedankt voor de referentie naar mijn overzichtje wat ik de vorige keer gemaakt had

Ik heb de paper van deze versie eens bekeken, en eigenlijk was het niet zo verwonderlijk dat je op een bepaalde manier de RSB (ook wel eens RAS genoemd - Return Address Stack - niet te verwarren met Reliability Availability Serviceability ) kan uitbuiten voor Spectre achtige patronen. Ik heb wel mijn twijfels of het in dit geval "nuttig" uitgebuit kan worden, en wellicht verklaart dat ook de reactie van Intel.

De RSB is in feite een specialistische branch predictor voor branches die een return van een functie zijn. Sommige architecturen hebben daar specifieke return instructies voor, en in andere architecturen is dat te herkennen aan een bepaald patroon (door de calling conventie/ABI is het dan bijvoorbeeld altijd een indirecte branch gebaseerd op een specifiek register). Wanneer een programma een functie call gaat maken, wordt het adres van de instructie daarna opgeslagen in de RSB. Wanneer er een bijbehorende return gedetecteerd wordt, wordt er in de RSB gekeken om te voorspellen waar de functie naar terug keert en verder gaat. De RSB in de processor probeert eigenlijk je functie call-stack te detecteren en bij te houden. Door juist te voorspellen waar je na een functie return terecht komt kan de processor continu speculatief vooruit blijven werken, zonder te wachten op de werkelijke waarde.

Nu gaat dit in 99% van de gevallen goed, behalve als je in exotische code zit die van stacks wisselt en/of return adressen verandert (zoals setjmp()/longjmp() calls voor userspace threads, of andere coroutine gein). De RSB heeft wel een gelimiteerde capaciteit; slechts 16 of 24 entries is vrij normaal. Als je dus code hebt die hele diepe functie-call stacks vaak op en af loopt, dan zal je RSB dat niet geheel kunnen dekken. Maar met 16-24 entries heb je er in ieder geval zat voor bijna alle SPECcpu2006 benchmarks

Er zijn nu twee manieren om de RSB om de tuin te leiden; 1) door de return adressen op je stack te wijzigen, zodat je returns naar een ander adres gaan dan de RSB voorspelt (en er dus initieel verkeerd gespeculeerd wordt), of 2) door een RSB underflow te genereren omdat de RSB wrap-around is (maar wat sinds recente Skylake niet meer werkt). Het komt er op neer dat je de code die je aanvalt meer returns moet laten doen dan deze zelf waarden op de RSB heeft gezet met calls, zodat hij speculatief naar een adres gaat wat de aanvaller op de RSB heeft weten te plaatsen.

In situatie 1) kan je de speculatieve executie alleen terug leiden naar een adres in een functie die je eerder al hebt aangeroepen in dezelfde context, en om dit dan speculatief weer te doen vereist het dat je je stack kan aanpassen. Dergelijke aanvallen binnen dezelfde proces context zijn alleen interessant om een sandbox omgeving te ontsnappen (denk JavaScript), maar in dat geval zal je niet zomaar je stack kunnen aanpassen of de benodigde onbalans te creeeren in je callstack. Situatie 1) is niet toe te passen op system calls de kernel in omdat die geen onbalans zal hebben in zijn callstack en dus niet meer returns zal doen dan calls, om zo per ongeluk via een geprepareerde RSB entry speculatief naar een attacker controlled adres te gaan. Hun demonstratie in de paper is gebaseerd op een gemodificeerde kernel module om specifiek een dergelijke onbalans te creeeren. Situatie 2) heeft iets vergelijkbaars.

De grootste kans die je lijkt te hebben is tussen twee programmas; wanneer je een context switch doet nadat je adressen van gadgets in de RSB hebt weten te laden, en dan over te schakelen naar het aangevallen programma wat in een fase zit waar het van een diepe callstack returned en zo speculatief op je gadget uit komt. Het feit dat Intel zegt dat de huidige mitigations hier een oplossing voor bieden doet mij afvragen of hun BTB flush op context switch oplossing voor Spectre v2 ook wellicht de RSB reset.

[t link]

Wacht, dus intel verschuift de schuld naar de developers door nieuwe guidelines op te zetten? ik snap dit denk ik niet goed want dat klinkt een beetje als niet de verantwoordelijkheid willen nemen.

[Dennism]

Opzich is dit vrij simpel verwacht ik, zaken als Spectre vatbaarheden kunnen niet zomaar gefixed worden in huidige hardware. Dit moet op meerdere niveau's gebeuren, namelijk microcode (voor de CPU, dit komt van de CPU leverancier, bijvoorbeeld Intel), maar ook in het OS (bijv. Linus of Windows) en in veel gevallen kan het ook helpen applicaties aan te passen (bijvoorbeeld wat Google met Chrome gedaan heeft).

[t link]

Je kan wel checks inbouwen om te voorkomen dat programmeurs illegale handelingen uitvoeren. ja dit zal je hardware trager maken maar dat is nou juist de verantwoordelijkheid van intel, niet die van programmamakers.

[Dennism]

Voor bepaalde spectre aanvallen niet bij de huidige generaties CPU's, dat soort checks heeft o.a.Intel al met de microcode aanpassingen echter die aanpassingen doen niets zonder aanpassingen (patches van het OS), en aanpassingen in de software kunnen deze beveiligingen nog effectiever maken.

CPU's met hardware beveiliging tegen deze exploits gaan we van Intel, AMD en ook ARM pas eind dit jaar, begin volgend jaar zien. Tot dan zal het een interactie van microcode en software aanpassingen zijn. En zelf dan blijven software aanpassingen nodig, want de huidige generatie cpu's zal nog jaren en jaren in gebruik zijn.

[totaalgeenhard]

en aanpassingen in de software kunnen deze beveiligingen nog effectiever maken.

Je kunt niet over veilige hardware praten als het afhankelijk is van de software.

Niet iedereen kan zonder meer OS updaten.

Intel moet gewoon probleem echt oplossen zodat niemand met Intel CPU met dit probleem blijft zitten.

Ben niet de.enige die dat vind:

https://www.theverge.com/...own-class-action-lawsuits

[Dennism]

Het hele issue is dat je dit niet kan oplossen zonder een nieuw ontwerp, vandaar dat Intel en AMD bezig zijn de volgende generatie chips te voorzien van fixes voor de nu bekende issues in hardware. De huidige generaties zullen echter altijd microcode update en OS updates nodig blijven hebben.

Daarnaast is echter maar de vraag of fixes in hardware alle issues permanent oplossen. Onderzoekers verwachten dat dit mogelijk niet zal gebeuren en dat het zeet goed mogelijk is dat er nog veel meer varianten gevonden gaan worden. Het zal dus zeer in de verwachting liggen dat dit mogelijk "nooit" permanent opgelost zal worden in hardware en dat software geprogrammeerd zal moeten gaan worden met deze vormen van exploits in het achterhoofd.

Verder is dit geen Intel issue, Intel heeft er uiteraard last van, ARM, AMD, IBM Power maar ook Oracle Sparc zijn in meer of mindere mate vatbaar voor Spectre varianten. Dit is een industrie breed probleem dat ook door de gehele industrie opgelost zal moeten worden.

Laten we verder eerst maar eens de uitslagen van de rechtszaken afwachten, niet dat ik direct verwacht dat deze positief zullen uitvallen voor Intel en AMD (AMD heeft ook meerdere Class Actions tegen zich lopen vanwege Spectre), maar het is en blijft wel de USA waar om ieder wissewasje een Class action gestart kan worden. Ik had eigenlijk liever gezien dat hier in de EU wat zaken gestart zouden worden zodat de juridische verantwoordelijkheid van de CPU fabrikanten getest zou kunnen worden. Dit lijkt echter nog niet direct te gebeuren.

[totaalgeenhard]

Ik heb niets van AMD, IBM or Oracle SPARC, ik heb prive en zakelijk Intel CPU's en ik heb nu al last van server die gehacked worden waar ik niets tegen kan doen, terwijl Intel al lang van dit probleem wist en het mij niets zou verbazen dat binnen Intel met betrekking meltdown/spectre als Minix (IME) al vanaf het begin er van wisten maar het gewoon keuze is gemaakt om risico voor lief te nemen.

Als ik had een paar jaar terug hiervan had geweten had ik geen virtualisatie gekozen, immers OS op bare metal kan je hardenen.

Ondertussen wacht ik sinds dit publiekelijk is op structurele stappen van Intel, zodat ik beslissingen kan nemen over de te volgen migratie path (microcode/bios updates/kernel versies etc..).

[Dennism]

Dat je nu al "gehacked" zou worden en of dat aan spectre zal liggen laat ik even in het midden, volgens mij zijn er namelijk nog geen spectre exploits in het wild. Wat is trouwens gehacked worden? Een aantal van mijn public facing servers worden ook continu gehammered op bepaalde poorten met username / ww, maar dat vind ik bijvoorbeeld geen hacken. Daarnaast is er altijd wat aan te doen.

Ik zie ook niet direct was bare metal v.s. virtueel er mee te maken heeft, beide kan je hardenen, virtueel mogelijk zelfs nog wel meer dan bare metal, daar je virtueel kan hardenen op Hypervisor level en op guest OS level.

Verder moet je stoppen met wachten en stappen ondernemen. Intel heeft een keurige guidance met microcodes die uit zijn, 13 july nog aangepast: https://www.intel.com/con...ocode-update-guidance.pdf

Daar kun je exact zien welke microcodes in welk stadia van ontwikkeling zijn. Alle die de status "production" hebben zijn geleverd aan de hardware partners en zouden dus door de hardware partners beschikbaar gesteld moet worden aan kun klanten.

De stappen nu te nemen zijn:

1. Check de Intel Guidance (deze stap kan je eventueel overslaan, als je stap volgt, volg je in principe deze stap ook direct).
2. Zorg ervoor dat je servers / desktops / laptops altijd voorzien zijn van de laatste bios / uefi updates van de fabrikant (Dell, HP, Lenovo, SuperMicro, Asus e.d., welk merk je ook gebruikt), dit is de primaire wijze waarop nieuwe microcode je systeem binnen komt.
3. Mochten er geen nieuwe biossen uitkomen omdat de fabrikant de hardware niet meer support kan je ook de Microcode nog op andere manieren laden in bepaalde gevallen. Voor bepaalde Linux distributies kan je deze hier downloaden https://downloadcenter.in...ode-Data-File?product=873, Voor Windows heeft MS ook enkele downloads, o.a. https://support.microsoft...7/intel-microcode-updates voor Windows 10 en Server 2016 1709, https://support.microsoft...n-1803-and-windows-server voor Windows 10 en Server 2016 1803 en https://support.microsoft.com/en-us/help/4091664 voor Server 2016
4. Verdere OS support komt van je OS vendor al, bijvoorbeeld Red Hat en MS hebben hier zeer duidelijke KB artikelen voor. Zorg ervoor dat je OS altijd geupdate is. Draai je een Hypervisor als vSphere zorg dan dat deze ook volledig up-to-date is.
5. Kijk bij je Applicatie vendoren voor eventuele updates. Wanneer beschikbaar, installeer deze.

Verder kan je op huidige hardware totaal oplossing vinden van een vendor. Intel kan jou niet aangeven doe dit, en dit en dit omdat dit continu kan veranderen vanuit MS, Linux vendoren en zelfs software verdoren. Intel kan alleen advies / informatie geven over hun producten en en verder aangeven dat je het gebruikte OS en eventueel andere software in gebruik up-to-date moet houden
en dat doen ze gewoon duidelijk in het eerder gelinkte document en andere documentatie op hun website.

Straks wanneer de generaties komen met hardwarematige bescherming zal ook dat duidelijk gedocumenteerd worden. Maar ook dat zal niet betekenen dat je ineens je hardware, Hypervisor / (guest) OS en software niet meer up-to-date hoeft te houden. Dit zal ook dan gewoon noodzakelijk blijven.Want zelfs met hardware matige aanpassingen is de verwachting zeer groot dat er ook blijvende veranderingen zullen zijn in software architectuur om deze problemen zo goed mogelijk uit te bannen.

[Reactie gewijzigd door Dennism op 23 juli 2024 14:55]

[totaalgeenhard]

Dat je nu al "gehacked" zou worden en of dat aan spectre zal liggen laat ik even in het midden, volgens mij zijn er namelijk nog geen spectre exploits in het wild. Wat is trouwens gehacked worden? Een aantal van mijn public facing servers worden ook continu gehammered op bepaalde poorten met username / ww, maar dat vind ik bijvoorbeeld geen hacken. Daarnaast is er altijd wat aan te doen.

Lol, als je op basis van login/password gehacked kunt worden heb je helemaal geen security.
En rooten op die manier betekend dat je remote root zou toestaan wat al sinds vorige eeuw al slecht idee is.


Met betrekking rest van je reactie. Een workaround is geen structurele oplossing, indien microcode geen oplossing is voor nieuwe aanvalsvector ben je terug bij af, bovendien voor IME is geen oplossing en het is niet permanent uit te schakelen.

Misschien dat je oplossing leuk en aardig is voor als je 1 server hebt. Maar als je een paar honderd servers hebt met gemiddeld 10 VPS'en per server heb je een structurele oplossing nodig zodat je je investering in 3 tot 5 jaar ruimschoots kunt terug verdienen zonder daar naast regulier onderhoud overige onderhoud, outage en risico's aan hebt. Want uiteindelijk kost het gewoon tijd en dus geld en accepteren klanten niet dat ze gehacked worden of trager systeem terug krijgen maar wel telkens met downtime te maken krijgen.

Om dit moment kun je geen toekomstige investeringen plannen en migratie plan opstellen en met testen en ontwerpen van setup beginnen. (bij ons doorloop tijd tussen de 12 tot 24 maanden om nieuwe gefinetuned omgeving te ontwerpen).

Verder adviseer ik je eens dit te lezen:
https://lkml.org/lkml/2018/1/21/192

Doorlooptijd van stabiele kernels zijn (terecht) lang en zorgvuldig. Maar als je op dit moment geen kernel kunt gebruiken die je vrijwaart voor dit en IME dan heb je geen andere keus dan afwachten.

[Reactie gewijzigd door totaalgeenhard op 23 juli 2024 14:55]

[Dennism]

[...]


Lol, als je op basis van login/password gehacked kunt worden heb je helemaal geen security.
En rooten op die manier betekend dat je remote root zou toestaan wat al sinds vorige eeuw al slecht idee is.

Het is ook geen gehacked worden, maar ik zie in bijvoorbeeld VPN oplossingen in de logging constant inlog pogingen die uiteraard (er is 2 factor nodig) mislukken met generieke usernames. Dit is natuurlijk geen hacking, maar ik ken wel personen die vinden dat zoiets "gehacked worden" is. vandaar dat ik even zeker wil stellen wat jouw definitie van "gehacked worden" is.

Met betrekking rest van je reactie. Een workaround is geen structurele oplossing, indien microcode geen oplossing is voor nieuwe aanvalsvector ben je terug bij af, bovendien voor IME is geen oplossing en het is niet permanent uit te schakelen.

Misschien dat je oplossing leuk en aardig is voor als je 1 server hebt. Maar als je een paar honderd servers hebt met gemiddeld 10 VPS'en per server heb je een structurele oplossing nodig zodat je je investering in 3 tot 5 jaar ruimschoots kunt terug verdienen zonder daar naast regulier onderhoud overige onderhoud, outage en risico's aan hebt. Want uiteindelijk kost het gewoon tijd en dus geld en accepteren klanten niet dat ze gehacked worden of trager systeem terug krijgen maar wel telkens met downtime te maken krijgen.

Om dit moment kun je geen toekomstige investeringen plannen en migratie plan opstellen en met testen en ontwerpen van setup beginnen. (bij ons doorloop tijd tussen de 12 tot 24 maanden om nieuwe gefinetuned omgeving te ontwerpen).

Verder adviseer ik je eens dit te lezen:
https://lkml.org/lkml/2018/1/21/192

Doorlooptijd van stabiele kernels zijn (terecht) lang en zorgvuldig. Maar als je op dit moment geen kernel kunt gebruiken die je vrijwaart voor dit en IME dan heb je geen andere keus dan afwachten.

Het hele punt is dat je met huidige hardware geen structurele oplossing gaat krijgen, waarbij 1 vendor alles voor je kan vrijwaarden. En dat er ook zeker geen voorwaarde is dat dit in de toekomst wel zal gebeuren, want zoals eerder ook al aangeven, onderzoekers verwachten dat zelfs wanneer de nu bekende exploits in hardware opgelost zullen worden door bijvoorbeeld Intel of AMD er ook gewoon weer nieuwe varianten ontdekt kunnen worden die dan wederom via microcode en OS updates gefixed moeten worden. Om het even zo te zeggen "De geest is uit de fles" en een magische oplossing die alle problemen zonder impact weg zal toveren is er niet.

Ik voorzie niet direct een situatie waar er in de toekomst teruggegaan kan worden naar een situatie waarbij systemen niet up to date gehouden hoeven te worden qua Bios / Uefi / Hypervisor / OS en Guest OS minimaal. Dit was natuurlijk eigenlijk al jaren het geval, maar nu nog meer.

Verder zal het afwachten worden wat de volgende generaties van Intel en AMD gaan brengen en daarop zullen de keuzes voor komende platforms gebaseerd worden. Momenteel lijkt AMD minder geraakt te worden dan Intel. Momenteel kan je inderdaad geen niet nieuwe platforms designen en plannen die "Spectre" vrij zijn, maar de vraag zal zijn of dit ooit nog zal gebeuren of dat rekening houden met Spectre en aanverwanten onderdeel zal gaan worden van de "best practises". De tijd zal dat moeten gaan leren.

Dat LMKL artikel is trouwens ook wel zo oud als de weg naar rome, en voor zover ik weet allang achterhaald. Het was een leuke rant om te lezen destijds, maar voor zover ik weet in ieder geval nu allang niet meer relevant. De linux machines die wij draaien zal ook allang voorzien van Kernels die de nu bekende Spectre varianten afdichten.

[totaalgeenhard]

Welke distri draai je?

https://lore.kernel.org/patchwork/patch/967060/

[Dennism]

Ik bedoel uiteraard niet de varianten van gister Die hebben mogelijk nog een OS update nodig uiteraard

Maar die machines draaien RHEL voorzien van alle updates en guidelines van Red Hat inzake Spectre / Meltdown

[Reactie gewijzigd door Dennism op 23 juli 2024 14:55]

[totaalgeenhard]

rhel es/centos is niet realtime :-)
testen jullie niets zelf voordat je kernel gaat upgraden.

[Dennism]

Wat bedoel je met realtime? Waarschijnlijk iets anders dan ik denk, want realtime OS patching heb ik nog nooit gezien

Uiteraard testen wij alles, updates gaan een hele "teststraat" door, net als iedere andere update trouwens voor andere OS'sen / applicaties en firmware trouwens. Maar we zorgen wel dat we niet veel achterlopen. alle updates die beschikbaar komen gaan z.s.m. het test proces in.

Misschien enigzins ongelukkig geformuleerd in de vorige, maar ik bedoel dat ze voorzien zijn van alle updates (dus echt alle updates en niet alleen zaken betrekking hebbende op spectre) en daarnaast alle guidelines van Red Hat omtrent Spectre vanuit de Red Hat documentatie inzake Spectre.

[Reactie gewijzigd door Dennism op 23 juli 2024 14:55]

[t link]

dat klopt volgens mij gewoon niet, je hebt gewoon een instructieset die die intel chip aanspreektl, de microcode kan via dat illegale instructies detecteren softwarematig. daar hoeft een derde niks voor te doen. of denk ik er nou veel te simpel over?

[MSalters]

Het detecteren van programma's (boven het nivo van losse instructies) is een berucht moeilijk probleem. Virusscanners moeten het doen, maar die kunnen het iets langzamer doen dan in real-time terwijl de instructies worden uitgevoerd. En microcode is bovendien veel simpeler dan hele virusscanners.

[Reactie gewijzigd door MSalters op 23 juli 2024 14:55]

[t link]

Hmm daar zal wel wat in zitten denk ik. blijft interresante materie, maar erg complex.

[Annihlator]

Ik denk dat de crux ligt in dat je dit niet zomaar met terugwerkende kracht kan doen; waarschijnlijk zijn de instructies dan ook meer bedoeld als mitigatie bij die gevallen (ben echter niet up to date in de materie, dus dit is maar mijn aanname.)

[hooibergje]

Yep, dat ios zeker waar, maar als fabrikant mag je best toegeven als je product een fout bevat, in plaats van mooi weer blijven spelen. Het wekt meer vertrouwens dat ze een fout toegeven en die fixen, ook al is dat moeilijk, en ook al is het pas vanaf de volgende generatie processors, dan blijven doen alsof er niks aan de hand is, terwijl hun kaartenhuis in elkaar stort.

[Dennism]

Volgens mij geven alle CPU fabrikanten die fouten ook gewoon toe in hun documentatie. Zowel Intel als AMD en ook ARM hebben voor zover ik weet zeer nette documentatie waarin dit allemaal beschreven is met de bijbehorende CVE's. Zowel Intel en AMD hebben ook al aangegeven in komende generaties hardware matige fixes door te voeren.

[xorpd]

Genaamd errata, enkelvoud erratum.

[latka]

De echte fix zit op hardware/microcode niveau en is volledig voor intel. De workarounds op OS en applicatie niveau zijn gemaakt omdat Intel niet kan leveren (en zeker niet met tig generaties harware op de markt). Ze verpakken het mooi, maar de speculative execution is alleen mooi als alles op je machine gecontroleerd is (dus geen VMs met vreemde zaken erop en geen unsigned Javascript code van derden erop draaien) maar in de huidige wereld waarin security gebaseerd is op een unbreakable sandbox die lek blijkt te zijn is het wachten op lek na lek totdat Intel echt een oplossing maakt. Ga er maar vanuit dat die er komt de vraag is alleen hoeveel performance we in moeten leveren.

[Dennism]

Dat klopt, zie ook mijn post hierboven. Maar zelf nieuwe generaties van Intel, AMD en ARM met hardware fixes maken software fixes niet overbodig, de huidige vatbare generaties zullen namelijk nog jaren en jaren in gebruik zijn.

En zelfs van CPU's met hardwarematige aanpassingen is het nog maar de vraag of dat het issue gaat oplossen. Diverse onderzoekers verwachten dat er nog meer varianten gevonden kunnen gaan worden naarmate de tijd zal vorderen waarvoor dan mogelijk ook weer nieuwe hardware aanpassingen nodig zijn (die pas weer minimaal een generatie later zullen volgen). De verwachtring is dus zeker dat de samenwerking tussen CPU fabrikanten, OS developers en software dev's hier erg belangrijk gaat zijn de komende jaren.

[MSalters]

De huidige generatie vatbare hardware zal relatief snel vervangen worden voor de meest high-profile toepassingen. Dat maakt een malware aanval economisch onrendabel. Spectre aanvallen is niet simpel, je hebt hooggekwalificeerde hackers nodig. Om dat te rechtvaardigen heb je high-value targets nodig. En die kunnen zich als eerste die nieuwe hardware veroorloven.

[Dennism]

Ik vraag me dat toch ten zeerste af, als je ziet wat voor oude meuk er nu soms nog bij bijvoorbeeld banken draait, zelfs voor mission critical zaken, dan vraag ik me echt af of deze hardware echt snel vervangen zal gaan worden. Daarnaast, Spectre aanvallen zijn nu betrekkelijk lastig uit te voeren, wie zegt dat dit over een maand, een half jaar of een jaar nog steeds zo zal zijn.

Ik hoop dat het zal gebeuren, maar ik heb er persoonlijk een hard hoofd in.

[Reactie gewijzigd door Dennism op 23 juli 2024 14:55]

[mbb]

Voorlopig lijkt het geen probleem voor intel te zijn: (Periode=1 year, in %)
Intel aandeelkoers tov vorig jaar: +50% https://www.marketwatch.com/investing/stock/intc
AMD +25% https://www.marketwatch.c...ck/amd?mod=MW_story_quote

[RJWvdH]

Spectre variant 4 = CVE-2018-3639

[Loggedinasroot]

In een laat Intel weten dat het van mening is dat 'SpectreRSB gerelateerd is aan branch target injection' en dat het verwacht dat bestaande maatregelen ook tegen de nieuwe varianten werken.

Dit kunnen de onderzoekers toch zo laten zien/al hebben laten zien?

[mjl]

Wat zijn richtsnoeren?

Daarmee doelt Intel op de tweede variant van de Spectre-aanval, die begin dit jaar in de publiciteit kwam. Intel zegt dat het inmiddels al richtsnoeren voor ontwikkelaars heeft gepubliceerd in een whitepaper.

[Dennism]

richtlijnen, guidelines, leidraden daar moet je het zoeken in deze betekenis.

[Orion64]

Nog meer bugs... Tijd voor een heel nieuwe architectuur, van scratch af aan. En dan graag ook een vertigvoudiging van de ipc.

[Fiander]

En hoe moeten ze dat doen?
een hogere IPC ( instructes per Klokpuls ) betekend OF een nog complexere scheduler met nog meer out of order berekeningen OF meer cores. Ontwikkelaars hebben nu al moeite om de huidige 8 vol te krijgen.

het gemakkelijkste wat ze nu kunnen doen, is de volledige 8, 16 en 32 bit spul uit de cpu slopen, en daarmee inderdaad niet meer backwards compatible te zijn, en dan de vrijgekomen instructie codes gebruiken om de meest gebruikte instructies een kortere code te geven, waarnee die gemakkelijker gedecodeerd kan worden, je versimpeld de decoder dus.

[xorpd]

Er is een ondergrens aan het aantal kloktikken per instructie, zoals 1 kloktik voor een add en 3 kloktikken voor een mul, en een bovengrens aan de mate van parallelliseerbaarheid. Ook extreem goed parallelliseerbare algoritmes zoals FFT lopen tegen bovengrenzen aan, zoals het memory subsystem en het TDP.

Aangezien de instruction prefetcher en decoder ontkoppeld zijn van de pipeline zal een nieuw decodeerschema geen snelheidswinst geven, maar wel zuiniger zijn.

[Orion64]

Hoe ze dat moeten doen? Wellicht een alternatief voor de transistor zoals bijvoorbeeld quantumcomputers pogen te doen met bijvoorbeeld acht mogelijke toestanden als kleinste eenheid? De parallelle verwerkingssnelheid neemt dan astronomisch toe.

[Fiander]

en jij kunt daarin programmeren?want dat is toch echt het grootste probleem bij quantum computers.

Aan een huidige computer kun vragen: wat is 1 x 5 en het antwoord is dan 5. een quantum computer is voor bepaalde toepassingen echt ontzettend snel, maar voor de simpelere dingen rekend hij als een pentium 60.

[Orion64]

Ik denk dat wanneer de hardware gemeengoed wordt er uiteindelijk 'makkelijke' programmeertalen zullen ontstaan, net als bij de huidige digitale computers het geval is geweest. Dan zullen ook dit soort problemen zoals jij schetst opgelost worden, de geschetste problematiek is gebrek aan kennis, niet gebrek aan mogelijkheden, niet inherent aan het platform.

[latka]

Ik ben bang dat dat tegenvalt. Zie het probleem bij many-core cpu's: ik Ken geen taal die automatisch problem en paralleliseert om hier gebruik van te maken behalve in trivial niche gebieden. Quantum is nog erger: mensen snappen er niets van en van een algoritme een quantum versie maken lukt ook niet eenvoudig. Er zijn talen die het mogelijk maken beter gebruik te maken van die soort platformen. Een voorbeelden is SQL: je geeft niet een specifiek algoritme aan alleen de vorm/inhoud van de gewenste oplossing. Dit staat haaks op de afgelopen tig jaar aan IT en zal lastig tractie vinden.

[MSalters]

Als we 't hebben over een 64 qubits pchip, dan bedoelen we niet iets als een 64 bits Core i7. Nee, dan bedoelen we echt een chip die 64 qubits in totaal heeft. Niet de miljarden transistoren van een i7. En weet je? Daar zijn we nu net. Google heeft 72 qubits aangekondigd - alweer, 72 qubits in totaal.

Om je een idee te geven : 291311 is het hoogste getal wat in priemgetallen ontbonden is door quantumcomputers. (523 x 557). Dat kan een Intel 4004 ook nog wel.

[Orion64]

Tijd voor een nieuw type computer dan. Als het verhaal toentertijd omtrent de Van der Sloot compressie waar is zijn er misschien nog wel onontdekte mogelijkheden die nu al praktisch toepasbaar zouden zijn in de binaire wereld.

[Reactie gewijzigd door Orion64 op 23 juli 2024 14:55]

[royb3]

Goed idee, noem het een Risc.

[RoestVrijStaal]

Welnee, je moet het kind niet met het badwater weg te gooien.

De oorzaak van de problemen zit in de trucjes die het gedrag van wat de CPU moet gaan voorspellen (zoals predictive branching) waardoor de CPU sneller wordt anders wel snel aanvoelt.

Als de CPU makers hun CPU's van al dat franje ontdoen, zijn hun CPU'S misschien wel "dommer" en trager, maar wel veiliger.

[latka]

Gewoon een 6502 op 2Ghz.

[latka]

Met al die spectre achtige aanvallen: kunnen we nu gewoon de cloud weer gaan sluiten en gewoon gaan doen ?

[apronk]

Hahaha, prachtig! Ben het volledig met je eens.

[hooibergje]

En alsof de cloud een ranzige kroeg op de hoek is waar je de keuringsdienst van waren op af kan sturen De halve wereld draait intussen op cloud computing.

[RoestVrijStaal]

Wat zou dat helpen dan?

Ik dacht eerder weer terug te gaan naar de tijd dat nog alles modulair en vervangbaar was en niet alles in een CPU, moederbord of soc gebakken zit.

Bug in de hardware? Vervang het boosdoende chipje en prik een verbeterde erin.

Beter voor het milieu ook. Nu mag je zowat hele pc's weg gooien want de nieuwe cpu met de fix zal vast niet compatibel zijn met je huidige moederbord.

[latka]

Vroegah draaide je applicaties van verschillende beveiligingsniveaus niet op 1 apparaat (zeg maar je firewall, virusscanner e-mail server en VPN accespoint en de remote desktop van de secretaresse). Met de cloud wel en we roepen dat het veilig is want aparte vms. Dat is dus niet zo. Daarom: ga eerst weer eens denken voordat je iets in de cloud gooit.