@
Seskahin: Ich habe deinen Post auch weder persönlich noch als Angriff verstanden, alles ok und meine Antwort war ebesowenig als Angriff oder Zurechtstutzen gemeint. Ich habe deinen Post gelesen und mir kamen dazu lediglich einige Gedanken, die ich einmal etwas ausführlicher dargelegt habe, mehr nicht.
Vielleicht noch EIN abschließender Gedanke von mir (
da das hier sonst zu einem Endlos-Thread wird)
"Amazon, Google ... [werden] Epyc CPU´s sehr detailliert untersucht haben, ob damit auch Sicherheitsrisiken eingekauft werden"
Die Arbeiten, die die Sicherheitsforscher hier leisten, sind nicht Bestandteil solcher Anschaffungsprozesse. Wenn man sich die Historie einiger Bugs ansieht, dann erkennt man da leicht einen Arbeitsaufwand von teilweise 6 bis 9 Monaten bis ein finales Papier veröffentlicht wird und in dieser Zeit wurde nur
ein sehr spezifisches, stark lokalisiertes Problem entdeckt, herausgearbeitet, falsifiziert und mit einem Proof-of-Concept nachvollziehbar gemacht. In der Zeit wären etwaige Anschaffungsüberlegungen bereits obsolet, da u. a. bereits neuere, bessere Hardware verfügbar ist, entweder vom selben Hersteller oder vom Konkurrenten. Beispielsweise sind den großen dreien (Microsoft, Amazon und Google) ja bis zum Super-Gau Mitte 2017 auch keine Gründe gegen Intel "eingefallen" und mit der Verfügbarkeit von Epyc/Naples sind bei AMD die Bestellungen ja auch nicht durch die Decke gegangen (und Intel wurde vor die Tür gesetzt). Epyc2/Rome wird AMDs Erfolg sicherlich fortsetzen, aber im Datacenter-Markt spielen deutlich mehr Faktoren eine Rolle (Plattform, Ökosystem, Herstellerzusagen und -verlässlichkeit, Vertragskonditionen, Zulieferer, u.v.m.) und man wird auch mit Epyc2 zweifelsfrei keinen extremen Umschwung hin zu AMD erleben. (Und bzgl. des Zeitfaktors wird es in den nächsten 36 Monaten voraussichtlich auch nicht einfacher, den AMD hatte mit Zen, Zen2 und dem schon in der Entwicklung befindlichen Zen3 eine zügige (Weiter)Entwicklung vorgelegt und Intel war in den letzten Monaten anscheinend auch nicht untätig, denn bei den Servern geht es mit Cooper Lake, Ice Lake und Sapphire Rapids nun Schlag auf Schlag weiter.)
@
Deridex: "Aber niemand kann vorher sagen, wie schlimm das jeweils sein wird." - Ich maße mir auch nicht an zu wissen, was man da in welchem Umfang finden würde. Bei solch komplexen Architekturen ist es nur recht unwahrscheinlich, dass da keine relevanten Fehler drin schlummern und man wurde ja schon fündig, so dass ein "fehlerfrei" hinfällig ist. Ein solches Attribut ist aber in der Regel grundsätzlich schwierig aufgrund der extremen Komplexität. (Ein hochaufgelöstes Foto vom Die eines 80386 kann man sich noch relativ gut ansehen und bekommt vielleicht einen vagen Eindruck ... jedoch ... die lediglich 275.000 Transistoren dieser CPU sind extrem weit weg von heutigen Architekturen, mal ganz abgesehen von fehlenden Merkmalen wie superskalarer Arbeitsweise, Out-of-order und Speculative Execution, die uns heute so viel Freude bereiten, dem einen so, dem anderen so.)
Zu den Zen-Bugs findest du u. a. hier etwas:
cnet. Die meisten Angriffsvektoren benötigen administrative Privilegien, die jedoch durchaus zuvor mit einer Malware erlangt werden können. Der Kritizität tut das jedoch keinen Abbruch, denn gerade die Secure Processor-relevanten Vektoren sind übel, denn dieser läuft komplett parallel und jenseits der Kontrolle der CPU und wenn sich hier erst mal etwas eingenistet hat, ist Hopfen und Malz verloren. (Die Handhabung und Veröffentlichung von CTS-Labs war in diesem Kontext jedoch fragwürdig.)
Bezüglich AMDs Secure Processor waren das aber auch nicht die ersten Bugs. Beispielsweise im September 2017 präsentierten Sicherheitsforscher einen Angriff auf die ARM TrustZone mittels Stromsparfunktionen, die es ermöglichte geschützte Daten auszulesen, die eigentlich selbst vor Angreifern mit root-Rechten sicher sein sollten. (
Der Security Processor verwendet einen ARM Cortex-A5 mit TrustZone.) Cfir Cohen vom Google Cloud Security Team hatte ebenfalls im September AMD über eine Verwundbarkeit in ihrem TPM-Modul informiert. Ein neues BIOS mitsamt Patch wurde im Dezember von AMD bereitgestellt und bot u. a. die Möglichkeit Teilfunktionen des SP abzuschalten (wobei AMD dieses Vorgehen zu der Zeit jedoch nicht weiter erklärte).
(Vergleichbare Probleme hat aber auch Intel immer wieder, die für die Management Engine zuletzt einen Intel Quark-Prozessor verwendeten, eine kleine x86-CPU mit P54C-Befehlssatz. Beispielsweise Intels AMT (in vPro-Systemen) verfügt durch die ME über einen Hardware-basierten out-of-band Kommunikationskanal über das Ethernet-Interface, der nicht auf ein laufendes Betriebssystem wie Windows oder Linux angewiesen ist. Der Kanal ist unabhängig vom Power-State des PCs und ebenso unabhängig von weiteren Hardware-Komponenten wie bspw. HDDs und dem Hauptspeicher ... was natürlich auch das Interesse von Sicherheitsforschern und zwielichtigen Gestalten erklärt.)