News Spectre: Intels zukünftige CPUs sind nur optional sicher

[L0g4n]

Diese Attitüde die man zu diesem Thema oft sieht:

 

[yummycandy]

Dann könnte man z.B. einen Kern als "Low Performance, High Security" Kern definieren, auf dem dann der Browser etc. laufen.
Spiele usw. würden auf den restlichen 5 Kernen mit dem Feature laufen.

Das würde SMT ziemlich einschränken, weil der Scheduler die passenden Tasks nur auf die jeweiligen Cores und nicht auf alle verteilen kann.

 

[teufelernie]

Der bisherige Reaktionsverlauf des Herstellers Intels zeigt mir große Übereinstimmungen mit dem Umgang der VW-Dieselaffäre hier in Deutschland.

Während es rechtlich relativ leise um VW in DE & Co bliebe, haben sie in den USA tatsächlich einen VW Manager in den Knast gesteckt. Heutzutage scheut man davor zurück adäquate Maßnahmen bei Sicherheitsproblemen durchzuführen. Wenn Openssl aufs übelste kompromitiert wurde, sind alle damit hergestellten Zertifikate (und root-Zertifikate) zu tauschen.
Ist aber wenig bis garnicht passiert. Warum? Weil niemand dafür einen Plan in der Schublade hat. Wenn man Professionell sein möchte, hat man jedoch einen Plan in der Schublade zu haben.

tl;dr: Intel verhält sich hier extrem unprofessionell.
Den von mir sehr geachtete Torvalds agiert wie immer sehr impulsiv, scheint aber mit seinem unprofessionellen Kontrahenten folgendes vergessen zu haben:
Lege dich nie mit einem Idioten an, denn er zieht dich dann auf sein Niveau herunter und schlägt dich dann mit seiner Erfahrung.

Ich hoffe sehr auf einschläge Urteile aus den USA zu diesem Thema...

 

[Piktogramm]

[...]
Dann könnte man z.B. einen Kern als "Low Performance, High Security" Kern definieren, auf dem dann der Browser etc. laufen.
Spiele usw. würden auf den restlichen 5 Kernen mit dem Feature laufen.

Verkaufe das jetzt einem Cloudhoster (und seinen Kunden) mit deutlich über 10.000 Maschinen, dass die schönen VMs und Cloudanwendungen alle nur noch auf einem "Secure Core" laufen anstatt wie vorher auf +32 High Performance Cores. Das wird lustig!

Wenn du damit fertig bist erklärst du Herrn Torvalds, dass sein Betriebssystemkernel gefälligst CPU-Cluster zu unterstützen hat, die ein abweichendes Laufzeitverhalten / Speicherverwaltung an den Tag legen obwohl sie die selbe ISA haben.

Ich schick dir ein Kasten (guten) Bieres zu wenn du es schaffst

 

[Phear]

Was soll eigentlich immer dieses Intel/Amd Gebashe in solchen Threads? Seit Wochen sieht man nichts anderes mehr. Die AMD Fanboys posaunen raus, dass Intel nichts taugt und nur noch AMD gekauft wird und die Intel Fanboys verteidigen ihr gekauftes Produkt mit ihrem Leben. Wenn jetzt in Wochen/Monaten/Jahren rauskommt, dass AMD eine Sicherheitslücke hat, die Intel nur "theoretisch" besitzt, kann man eigentlich die Threads einfach umbenennen und in jedem Beitrag Intel und AMD tauschen.

Ob wohl einige merken, dass die sich seit Wochen nur im Kreis drehen? Man sieht auch immer dieselben Namen mit denselben Argumenten. Auch wenn es der xte Thread zu dem Thema ist

 

[benneq]

Wenn du damit fertig bist erklärst du Herrn Torvalds, dass sein Betriebssystemkernel gefälligst CPU-Cluster zu unterstützen hat, die ein abweichendes Laufzeitverhalten / Speicherverwaltung an den Tag legen obwohl sie die selbe ISA haben.

Geht sowas nicht eh schon? Diverse Android und iOS Geräte nutzen ja auch eine Art Big-Little-Architektur. Kann aber gut sein, dass es dort nur entweder schnell oder langsam gibt und keinen Mischbetrieb Hat zwar nicht wirklich was mit der Speicherverwaltung zu tun, aber es sollten ja trotzdem CPU Cluster sein.

 

[Herdware]

Richtig ist, "Design by morons" und da bezieht er sich auf das neue Interfaces welches die CPU zwischen "broken by design" und "fixed but slow" umschalten lässt. Wobei er die Aussage dann auch begründet

Ok. Ein "Moron" ist nur ein "Halbidiot". Das ist natürlich viel (50%?) besser.

Ohne die genauen Hintergründe zu kennen, kann ich nicht wirklich beurteilen, ob der Ansatz, den Intel mit diesem merkwürdigen, an-/abschaltbaren Hardwarefix verfolgt, (hald-)idiotisch ist, böswillig/betrügerisch, oder vielleicht das einzige, was auf die Schnelle technisch machbar war, ohne diesen Teil des CPU-Designs komplett zu überarbeiten. Vielleicht ist das ja nur eine Übergangslösung, bis es grundlegend überarbeitete CPUs gibt, die auch ohne Performanceeinbußen keine Sicherheitslücken mehr haben. Aber sowas kann halt erst in ein paar Jahren kommen.

Ich kann mir eher nicht vorstellen, dass Intel vor hat auf Dauer mit diesem Zustand zu leben. Die haben doch ein ganz eigenes Interesse daran, dass ihre CPUs möglichst schnell und sicher sind.

 

[SavageSkull]

Ich hätte schon gern mal eine Erklärung was "near zero risk" bedeutet und warum man optional ein Bios Update anbieten will und was das bei AMD für einen Einfluss auf die Leistung hat. Derzeit hat man die Wahl zwischen unsicher und unbekannt. Beides für mich als Kunde nicht besonders prickelnd.

 

[Schnitz]

Aber mit Aussagen wie

lehnt sich der gute Linus doch sehr weit aus dem Fenster (und aus seinem Wissensgebiet).

Er hat genug Ahnung von dem entsprechenden Bereich, sonst wäre er nicht der der als letztes jeden Patch absegnet. Er kann nicht etwas absegnen was er nicht versteht - und da ist er was das Verständnis von Hardware angeht mehr als versiert. Und mit ein wenig IT-Grundbildung kann man sich da schnell in diesen Bereich des CPU-Designs einlesen und kommt ebenfalls zu dem Schluss den Torvalds nennt, sicher kann man es netter umschreiben.

Hätte Linus Torwalds genug Ahnung von CPU-Design, um das zu beurteilen, würde er mit hoher Wahrscheinlichkeit als hochbezahlter Spezialist bei Intel oder einem anderen Branchenriesen arbeiten.

Wäre er ein Charakterloser Mensch könnten die Firmen ihn auch haben, aber kannst Du dir die Welt hinter dem Tellerrand vorstellen, in der ein Torvalds gar nicht für so eine Firma arbeiten will damit er weiterhin genug Zeit für sein Lebenswerk hat? Glaubst Du er will wie die meisten Kapitalisten-Zombies nur scheiße Reich werden? Nein, stell Dir vor der Mensch hat tatsächlich Ideale denen er treu ist.

Daher ist Dein Argument Kindergarten.

 

[Herdware]

Daher ist Dein Argument Kindergarten.

Kindergartenniveau ist es, Intels CPU-Designer mal eben als (Halb-)Idioten zu bezeichnen. Ich wette Linus selbst weiß das auch besser, denn er wird wohl einige der Intel-CPU-Entwickler von verschiedenen Gelegenheiten (Tagungen usw.) kennen. Ich gehe jede Wette ein, dass das keine Idioten sind, sondern zu den besten gehören, die es in der Branche gibt.

Ich bezweifle nicht, dass Linus Torvalds sich in vielen Bereichen auskennt. Er hat sicher auch eine Menge Ahnung von CPU-Design. Aber ich kann mir wirklich nicht vorstellen, dass gegenüber seinem strahlenden Genie die gesamte Designabteilung von Intel wie sabbernde Trottel dasteht und es wirft umgekehrt nicht gerade ein gutes Licht auf ihn selbst, wenn er versucht das so darzustellen.

Torvalds hätte die selbe Aussage leicht viel weniger kindisch formulieren können. Wenn es nicht ganz ohne Profanitäten geht z.B. so:
"Das Design des Hardware Interface kommt mir idiotisch vor. (Nähere Begründung siehe unten.) Ich wüsste gerne was Intels Entwickler sich dabei gedacht haben."

Denn irgendwas anderes, als sich nur darauf zu konzentrieren weiter zu atmen, haben sich Intels unbestreitbar kompetente Designer garantiert dabei gedacht.

 

[darkcrawler]

Blöd nur das in dem AMD System jetzt das gleiche Problem besteht?

[ ] du hast dich vor deinem post informiert

 

[Piktogramm]

Geht sowas nicht eh schon? Diverse Android und iOS Geräte nutzen ja auch eine Art Big-Little-Architektur. Kann aber gut sein, dass es dort nur entweder schnell oder langsam gibt und keinen Mischbetrieb Hat zwar nicht wirklich was mit der Speicherverwaltung zu tun, aber es sollten ja trotzdem CPU Cluster sein.

Oar es gab da auch "witzige" Diskussionen, weil einige ARM Big/Little Implementationen aufgrund von abweichendem Verhalten der Caches und speziell deren Größe Probleme beim Wechsel bereiteten. So richtig positiv wurde das auch nicht aufgenommen, vor allem weil der "Fix" an der Stelle ist die betroffenen Caches vor einem Wechsel zu leeren mit entsprechendem Overhead. Sowas will man halt nicht, vor allem nicht weil irgendwann jeder CPU-Hersteller will, dass man Extrawürste für deren abweichendes Laufzeit- / Speicherverhalten baut.

 

[Asghan]

[ ] du hast dich vor deinem post informiert

[ ] du hast vor deinem Post den Thread gelesen und erkannt, dass er schon mehrfach darauf hingewiesen wurde

 

[Piktogramm]

Ok. Ein "Moron" ist nur ein "Halbidiot". Das ist natürlich viel (50%?) besser. [...]

Unschärfe von Sprache und Übersetzungen. "Moron" kann man auch als "Schwachsinniger" hernehmen und "made by morons" bezieht sich dann wohl auf eine Entwicklung von Schwansinnigen bzw. eine Entwicklung die schwachsinnig ist.

Ich kann mir eher nicht vorstellen, dass Intel vor hat auf Dauer mit diesem Zustand zu leben. Die haben doch ein ganz eigenes Interesse daran, dass ihre CPUs möglichst schnell und sicher sind.

Intel gibt nicht zu das es ein Bug ist. Intel gibt keine Aussagen wann/wie die Nichtbugs abgestellt sind. Intel reicht Patches ein die darauf hindeuten, dass das ganze versaut wird,

Erfahrungsgemäß werden Probleme die als solche geleugnet werden und für deren Abstellen es keine verbrieften Zusagen gibt verschleppt. Typischerweise verhält sich Intel auch anders, wenn sie vorhaben Fehler abzustellen. Normalerweise gibt es schnell und zuverlässig Patches die das Problem nachhaltig fixen. Wenn "schnell" nicht möglich ist gibt es hotfixes und Zusagen wann es die gescheiten Patches gibt.
Das liefert Intel gerade alles nicht. Das hat Geschmäckle

 

[darkcrawler]

[ ] du hast vor deinem Post den Thread gelesen und erkannt, dass er schon mehrfach darauf hingewiesen wurde

[ ] dass wäre sehr sinnvoll gewesen, alles zu lesen, wenn auf der ersten seite schon solche qualifizierten kommentare zu lesen sind, aber danke für den hinweis, ich komm drüber weg

nebenbei nutzen offensichtlich die mehrfachen hinweise nix, weil diese alternativen fakten stets von neuem gepostet werden, ergo kann man das offensichtlich nicht oft genug wiederholen

 

[Iscaran]

Ich finde die Antwortmail von Woodhouse aufschlußreich:
http://lkml.iu.edu/hypermail/linux/kernel/1801.2/05282.html

Ich denke es geht hier wohl darum dass Intel für Skylake und neuer "performantere" Patches umsetzen möchte...

Das ganze hat wohl damit zu tun dass die Retpoline-Mitigation die für ALLE CPUs bis auf Skylake+ funktioniert ab Skylake durch noch weitergehende "Architektur-Optimierungen" ausgehebelt wird. Wodurch man die "Worst-Case" Implentiereung IBRS auf Skylake+ erzwingen müsste. Was dann wirklich einschlägt wie eine Handbremse.

Aber so ganz kann ich der technischen Diskussion nicht folgen - daher warte ich mal bis jemand versierteres in der Lage ist das etwas "zusammenzufassen für Dummies".

@AMD ist weniger "exploitbar": Eine der Haupt-Ursache für die "leichte" Exploitbarkeit ist die unvollständige Adressreferenzierung in Intels Branch Target Buffer (BTB). Dies lässt es zu dass man bei einem Spectre Angriff der erfolgreich über die Spekulative Ausführung Code Ausführung gelaufen ist dann gleichzeitig 2^12 Bits an Adressen anspringen kann um diese Auszulesen/selektieren/whatever.
@AMD erlaubt ein erfolgreicher Spekulativer Spectre Angriff aufgrund stets vollständiger Adressreferenzierung im BTB nur den Zielsprung auf genau 2^1 Bits an Zieladressen.

EDIT der vollständigkeit halber: link zu stackoverflow
"The indirect branch predictor of Intel CPUs only uses the lowermost 12 bits of the source instruction, thus it is easy to poison all 2^12 possible prediction histories with user-controlled memory addresses. These can then, when the indirect jump is predicted within the kernel, be speculatively executed with kernel privileges. Using the cache-timing side-channel, you can thus leak arbitrary kernel memory."

Meine "interpretation" des ganzen mag evtl. in einigen technischen Aspekten nicht ganz richtig sein - aber der Kern der Sache ist die unterschiedliche Adresshandhabung @Intel die die Angreifbarkeit via Spectre "wesentlich leichter" macht. (ca. 2^1 zu 2^12 fach leichter oder so)

 

[Piktogramm]

Ein Nerdbienchen für Iscaran

 

[Lefzensabber]

Ob wohl einige merken, dass die sich seit Wochen nur im Kreis drehen? Man sieht auch immer dieselben Namen mit denselben Argumenten. Auch wenn es der xte Thread zu dem Thema ist

Aber ehrlich, wie Boxer die den Gong nicht hören.

 

[AAS]

Oho, er teilt mal wieder ordentlich aus

Er hat auch recht, er war schliesslich auch mal bei Transmeta als Entwickler tätig.
Der Mann weiss wo von er redet.

Hier übriegens der Original Post in der Mailing-List
https://lkml.org/lkml/2018/1/21/192

 

[ChrisMK72]

und was das bei AMD für einen Einfluss auf die Leistung hat. Derzeit hat man die Wahl zwischen unsicher und unbekannt. Beides für mich als Kunde nicht besonders prickelnd.

Wäre schön, wenn da vor dem Release der 2000er Ryzen was bekannt wird.

Als Gamer kann ich dann aufgrund neuer Infos und Benchmarks mit allen aktuellen patches und bios updates neu entscheiden.

Anfänglich sagten Gerüchte AMD wäre gar nicht betroffen, dann von 1 Version, jetzt wollen sie 2 Sachen patchen.

Der User hängt in einer "bitte warten" Schleife.
Mal gespannt, wie der Stand der Dinge in 1-3 Monaten ist.