Skrivet av Ratatosk:
Fixades inte detta i höstas?
Finns flera även hos AMD. Just detta nämndes första gången 6:e januari i år, ser ut att vara samma typ av grundläggande problem som den bug som hittades i Intels motsvarighet våren/sommaren 2017.
Skrivet av Traumklang:
Visst är det bra att dessa säkerhetsbrister upptäcks, men frågan återstår:
Hur i helvete har detta inte upptäckts tidigare?
Frågan är inte om det finns buggar som orsakar säkerhetsproblem. Den stora frågan är hur bra/dåligt olika företag hanterar problemen när det väl inträffar.
Saker som Intels Management Engine och AMDs Secure Processor tekniker har absolut sina risker när man hittar buggar i dessa. Men finns buggar i alla system, vi använder t.ex. kreditkort allt mer trots att det finns massor med säkerhetshål där.
Man måste alltid väga risk mot värde, så länge värdet av något är högre än kostnaden som olika brister i systemet har så finns det liksom inte så mycket att fundera på: totalt sett är värdet positivt.
För saker som IME/ACP skiljer sig nog värdet rätt mycket mellan olika organisationer, det gäller faktiskt det mesta. Så det enda man bör kräva är möjligheten för varje organisation att välja om de vill använda en finess eller ej.
För konsumenter lär det vara ytterst få fall där IME/ACP har positiv värde vs risk. Artikeln borde dock trycka på att vPro är något som nästan aldrig existerar på konsumentmoderkort (samma gäller AMDs motsvarighet), så problemet som beskrivs i artikeln är i praktiken irrelevant för "vanliga" konsumenter.
Bjarne Stroustrup (C++ skapare) var väldigt träffsäker när han sa
"There are only two kinds of programming languages: those people always complain about, and those nobody uses."
Det gäller inte bara programmeringsspråk, det gäller nog i princip alla produkter. D.v.s. det finns produkter folk gnäller om, sedan har vi de ingen använder...
Moderna datorsystem är komplexa, därför kommer det alltid finnas buggar, därför kommer man alltid hitta nya säkerhetsproblem och andra typer av buggar i de system som många använder.
Skrivet av anon5930:
Nog finns känslan av att dessa attackvägar skulle kunna ha skapats för övervakning. Management Engines problematik pekar lite åt detta hållet. Nog blev det fart snabbt när detta tillslut läckte ut. Och sen att fler problem rapporteras i snabb takt.
Kan vara ren slump men lösningen Intel gjort som möjliggör Meltdown känns det ändå som ett designval för att öka prestanda med nackdelen att säkerheten minskas.
Är de uppfattningen jag fått med. Ingen bugg eller liknande utan ett designval (främst) Intel valt för att öka prestanda men med nackdelen av lägre säkerhet. Huruvida denna säkerhetsbrist även avsiktligt använts för övervakning är en bra fråga.
De som vill köra Coreboot och kämpar med att få bort Management Engine kanske inte är så paranoida som de ofta kan uppfattas vara.
Meltdown är helt klart en konsekvens av jakten på prestanda, Intel, Apple och IBM är alla drabbade av Meltdown i sina bäst presterande kretsar (som alla har högre IPC än Zen). Till och med ARM är drabbad av Meltdown i sin bäst presterande krets, så knappast något som kan anses vara främst ett designval från Intels sida.
Samma sak gäller ju Spectre, det är en ren konsekvens av prestandaoptimeringar. ARM har ju en hel serie kretsar som inte är påverkade av vare sig Spectre eller Meltdown, det är deras billigaste och minst prestandaoptimerade serie Cortex A.
Vänd på frågan lite, hade du hellre suttit med orginal Pentium nivå prestandamässigt jämfört med att man som nu jagat prestanda som man efter ~20 år inser är mottaglig för side-channel attacker?
Jag tror inte den långsiktiga lösningen på detta är att ta bort spekulativ exikvering, IPC blir värdelöst utan detta. Istället bör man göra observationen att det mesta av en dators tillstånd kan läcka då det egentligen saknar värde. Det tillstånd som är känsligt måste självklart skyddas, här kanske den enda vettiga lösningen är att isolera detta tillstånd och bara processa det med teknik som 100 % prioriterar säkerhet över prestanda.
D.v.s. vi behöver något åt IME/ASE hållet i varje CPU