Hardware-Sicherheitslücken: Meltdown und Spectre: ehem. Intel-Bug

[towo]

Passt:

root@Defiant:/home/towo/test/security/spectre-meltdown-checker# ./spectre-meltdown-checker.sh
Spectre and Meltdown mitigation detection tool v0.33

Checking for vulnerabilities on current system
Kernel is Linux 4.15.0-towo.1-siduction-amd64 #1 SMP PREEMPT siduction 4.15-1 (2018-01-29) x86_64
CPU is Intel(R) Core(TM) i5-4670K CPU @ 3.40GHz

Hardware check
* Hardware support (CPU microcode) for mitigation techniques
* Indirect Branch Restricted Speculation (IBRS)
* SPEC_CTRL MSR is available: NO
* CPU indicates IBRS capability: NO
* Indirect Branch Prediction Barrier (IBPB)
* PRED_CMD MSR is available: NO
* CPU indicates IBPB capability: NO
* Single Thread Indirect Branch Predictors (STIBP)
* SPEC_CTRL MSR is available: NO
* CPU indicates STIBP capability: NO
* Enhanced IBRS (IBRS_ALL)
* CPU indicates ARCH_CAPABILITIES MSR availability: NO
* ARCH_CAPABILITIES MSR advertises IBRS_ALL capability: NO
* CPU explicitly indicates not being vulnerable to Meltdown (RDCL_NO): NO
* CPU microcode is known to cause stability problems: NO
* CPU vulnerability to the three speculative execution attacks variants
* Vulnerable to Variant 1: YES
* Vulnerable to Variant 2: YES
* Vulnerable to Variant 3: YES

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Mitigated according to the /sys interface: NO (kernel confirms your system is vulnerable)
> STATUS: VULNERABLE (Vulnerable)

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigated according to the /sys interface: YES (kernel confirms that the mitigation is active)
* Mitigation 1
* Kernel is compiled with IBRS/IBPB support: NO
* Currently enabled features
* IBRS enabled for Kernel space: NO
* IBRS enabled for User space: NO
* IBPB enabled: NO
* Mitigation 2
* Kernel compiled with retpoline option: YES
* Kernel compiled with a retpoline-aware compiler: YES (kernel reports full retpoline compilation)
* Retpoline enabled: YES
> STATUS: NOT VULNERABLE (Mitigation: Full generic retpoline)

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Mitigated according to the /sys interface: YES (kernel confirms that the mitigation is active)
* Kernel supports Page Table Isolation (PTI): YES
* PTI enabled and active: YES
* Running as a Xen PV DomU: NO
> STATUS: NOT VULNERABLE (Mitigation: PTI)

A false sense of security is worse than no security at all, see --disclaimer

[NAB]

Meinem (und deinem?) Verständnis nach greift IBPB nur bei Kontextwechseln.
Auf einem SMP-System könnte man allerdings auf fremde Cache-Inhalte zugreifen ohne dass dafür überhaupt ein Kontextwechsel nötig ist, weil eben zwei Prozese tatsächlich gleichzeitig auf dem selben Cache arbeiten können.

Ich habe das Spectre-Papier so verstanden, dass der Angreifer das Opfer "irgendwie" dazu bringen muss, vorher ausgewählten Code wiederholt auszuführen, um die Sprungsvorhersage zu trainieren. Mir fehlt gerade die Fantasie, um mir sämtliche dafür geeigneten Möglichkeiten zu überlegen, aber da der Angreifer nicht direkt in den Speicherbereich des Opfers springen darf, müsste da doch immer irgendeine Interprozesskommunikation inklusive Kontextwechsel stattfinden, oder? Eigentlich müsste es sogar immer ein Betriebssystemaufruf sein, also ein Kontextwechsel in den Kernel und zurück, oder?

Wie die Sprungvorhersage dabei genau implementiert ist, ist irrelevant.

Eben das halte ich für fraglich. Ich vermute, Implementierungsdetails könnten wichtig sein, um Sicherheitsaspekte beurteilen zu können.

Natürlich ist das letztendlich Intels Problem. Falls wir hier aber halbwegs qualifiziert diskutieren wollen wäre es schon schlau, zumindest zu versuchen zu verstehen, was da im Detail passiert, statt es wie eine Black Box zu behandeln.

Es ist eine Blackbox. Ich finde die Stelle leider nicht mehr, aber irgendwo sagen die Jungs von der TU Graz sehr klar, dass auch sie keine Ahnung haben, wie die betroffenen Intel-Prozessoren genau funktionieren. Sie sagen klar, dass sie nur eine Arbeitshypothese haben, die sich als tauglich herausgestellt hat, die tatsächliche Implementierung aber völlig anders aussehen könnte. Und das auch nur für die untersuchten Prozessoren. Und schon die untersuchten Prozessoren unterscheiden sich in Pipelinelänge, Größe der Sprungvorhersagetabelle und Timing-Verhalten. Darum gilt Spectre ja auch als etwas anspruchsvoller.

Um sich über "Implementierungsdetails" unterhalten zu können, müsste man sich erst mal für einen konkreten Prozessor entscheiden und dann versuchen, aus dem Hersteller die wirkliche Implementierung herauszukitzeln. Ich glaub nicht, dass sie die verraten werden ... "Geschäftsgeheimnisse". Die verraten ja eben nichts. Wenn du dir die Arbeiten der Sicherheitsforscher der letzten Jahre anguckst, dann siehst du, dass sehr viel von ihrer Arbeit darauf abzielt, überhaupt herauszubekommen, wie die Prozessoren funktionieren. Und wirklich gelaubt wird ihnen erst, wenn sie einen funktionierenden Exploit vorlegen. Intel und AMD arbeiten hier massiv mit "security by obscurity". (Die ARM-Pläne müssten doch eigentlich offenliegen, oder?)

Ein wichtiger Punkt ist z.B., dass zwei HT-Siblings sich eine Pipeline teilen.

Ist er das? Tun sie das (in hier relevanter Art)? Irgendeine Separierung muss es geben, sonst würden die "gemischten" Befehle zweier Prozesse die Sprungvorhersage durcheinanderbringen. Es könnte Spectre sogar erschweren, wenn Angreifer und Opfer sich zwei HT-Kerne teilen ... das dürfte das Timing durcheinanderbringen.

Im Rahmen eine Angriffs willst du das vielleicht schon, denn jeder Hüpfer bedeutet einen Kontextwechsel, der dir potenziell deinen Angriff kaputt machen könnte.

Umgekehrt wird ein Schuh draus ... jeder Kontextwechsel kann einen Hüpfer bedeuten. Der Kontextwechsel findet also so oder so statt.

Aber - ja - auch das wäre ein möglicher Ansatz. Im Kernel diskutieren sie schon darüber, KPTI für "vertrauenswürdige Prozesse" wieder auszuschalten. Ebenso kann man natürlich "nichtvertrauenswürdige Prozesse" auf ihren eigenen Prozessor setzen. Fragt sich nur, wann ein Prozess vertrauenswürdig guckt ...

Das hilft mMn nicht weiter, so lange diese Prozesse sich weiterhin die selben Cache-Register teilen, denn damit bleiben Zeitmessungen weiterhin möglich.

Cache-Angriffe bleiben natürlich weiterhin möglich, wie die ganzen letzten Jahre auch. Es ist ja nicht so, dass die Prozessoren vorher sicher waren. Der Vorteil von Spectre ist nur, dass du genau bestimmen kannst, wen du da bei was belauscht hast. Das reduziert das Rauschen beträchtlich.

(Rawhammer gibt's übrigens auch weiterhin. Inzwischen arbeiten sie an "Erkennungsroutinen". Sich danebenbenehmende Prozesse sollen also abgewürgt werden. Ähnliches wäre auch bei Spectre denkbar.)

Ich vermute, das Problem ist wie bei CPUs nicht der Treiber selbst sondern die bediente Hardware. Nvidia-GPUs könnten ebenso verwundbar für Meltdown sein wie Intel-CPUs. Vieleicht spekuliert Nouveau nicht, was Teil einer Erklärung für den Leistungsunterschied zwischen den Treibern sein könnte.

Spekulieren? Wirfst du gerade Intels Meltdown und Spectre in einen Hut und versuchst, das ganze Nvidia ans Bein zu binden?

Ich vermute eher, dass im Rahmen der Kerneländerungen gegen Meltdown auch sämtliche Treiber angepasst werden müssen, auch für ältere Kernel. Wenn das stimmt, müssten sich Besitzer von proprietärer Althardware zwischen Meltdown und Hardware entscheiden. Windows scheint auch betroffen:
https://www.reuters.com/article/us-cybe ... SKBN1EZ1E9
Und Nvidia hält sich für "immun".

[hikaru]

Ich habe das Spectre-Papier so verstanden, dass der Angreifer das Opfer "irgendwie" dazu bringen muss, vorher ausgewählten Code wiederholt auszuführen, um die Sprungsvorhersage zu trainieren.

Meinem Verständnis nach muss nur IRGENDWER ausgewählten Code ausführen, der in ein Register schreibt, in das auch das Opfer schreibt.
Wenn das ein anderer Thread (der Täter) ist, dann soll IBPB dafür sorgen, dass nicht der Täter Zeitmessungen auf dem Register durchführt, während dort Werte des Opfers drinstehen. Wichtig ist hier zu bedenken, dass es nicht darum geht, das Register tatsächlich auszulesen. Es sollen nur Zeitmessungen auf Ausleseoperationen gemacht werden. Wer die Zeit misst ist egal.
IBPB funktioniert bei streng sequenzieller Arbeitsweise (egal ob in- oder out of order), weil bei jedem Kontextwechsel das Register geleert werden kann. Bei SMP auf dem selben Cache(!) (also vermutlich insbesondere HT) geht das nicht, weil es mangels Sequenzialität keine Kontextwechsel zwischen Opfer und Täter gibt an denen IBPB ansetzen könnte.

Genau deshalb interessiere ich mich auch dafür, wie eine Sprungvorhersage implementiert ist, nicht nur dafür, was sie im Endeffekt erreichen soll, denn meinem Verständnis nach (das hier zugegebenermaßen ganz schön strapaziert wird) hängt der gerade geschilderte Angriff davon ab, ob mehrere Threads sich eine gemeinsame Sprungvorhersage teilen, was ich insbesondere bei HT für plausibel hielte.

Es ist eine Blackbox. Ich finde die Stelle leider nicht mehr, aber irgendwo sagen die Jungs von der TU Graz sehr klar, dass auch sie keine Ahnung haben, wie die betroffenen Intel-Prozessoren genau funktionieren.

das ist sicher richtig. Aber es hilft uns nicht, dass weit fähigere Leute als wir genauso wie das Schwein in's Uhrwerk schauen.
Fakt ist, dass sich eine bestimmte CPU auf eine bestimmte Weise verhält. Dieses Verhalten ist ausschlaggebend für die Risikobewertung. Wer über das Verhalten bescheid weiß und wer nicht, ändert an der Sachlage des Risikos nichts.

Ein wichtiger Punkt ist z.B., dass zwei HT-Siblings sich eine Pipeline teilen.

Ist er das? Tun sie das (in hier relevanter Art)? Irgendeine Separierung muss es geben, sonst würden die "gemischten" Befehle zweier Prozesse die Sprungvorhersage durcheinanderbringen.

Zwei HT-Kerne teilen sich eine Pipeline. Auf dieser Pipelne gibt es "replicated resources" (jeder HT-Sibling hat physisch seine Eigenen), "partitioned resources" (teilen sich beide, sind aber im Betrieb klar aufgeteilt) und "shared resources" (nutzen beide gemeinsam ohne Aufteilung).
Wir müssten nun also genau definieren über welchen Teil der Pipeline wir reden, um sagen zu können ob sie den betrachteten Teil teilen.

(Rawhammer gibt's übrigens auch weiterhin. Inzwischen arbeiten sie an "Erkennungsroutinen". Sich danebenbenehmende Prozesse sollen also abgewürgt werden. Ähnliches wäre auch bei Spectre denkbar.)

Irgendwo habe ich gelesen, dass LPDDR4 hardwareseitig immun gegen Rowhammer sei. Ich kenne allerdings keine Details, wie das erreicht wird oder warum das nur für LPDDR4 gilt.

Ich vermute, das Problem ist wie bei CPUs nicht der Treiber selbst sondern die bediente Hardware. Nvidia-GPUs könnten ebenso verwundbar für Meltdown sein wie Intel-CPUs. Vieleicht spekuliert Nouveau nicht, was Teil einer Erklärung für den Leistungsunterschied zwischen den Treibern sein könnte.

Spekulieren? Wirfst du gerade Intels Meltdown und Spectre in einen Hut und versuchst, das ganze Nvidia ans Bein zu binden?

Meltdown ist doch nur ein Spezialfall von Spectre, der sich in Angriffsvektor und Behandlung dadurch auszeichnet, dass ein Kontextwechsel nicht (nur) zwischen Prozessen auf gleicher Privilegebene passiert, sondern dass dabei die Privilegebene gewechselt wird. Oder sehe ich das falsch?

Ich vermute eher, dass im Rahmen der Kerneländerungen gegen Meltdown auch sämtliche Treiber angepasst werden müssen, auch für ältere Kernel. Wenn das stimmt, müssten sich Besitzer von proprietärer Althardware zwischen Meltdown und Hardware entscheiden.

Meinem Verständnisnach sollte das nicht so sein. KPTI funktioniert ja so, dass die Kernel Page Tables aus dem Cache entfernt werden, bevor ein Userspace-Prozess den Kern (und dessen Cache) benutzen darf. Dieser Löschvorgang ist unter Kontrolle des Kernels. Als Module geladene Treiber (egal ob proprietär oder nicht) haben auf diesen Vorgang keinen Einfluss, können den Kernel also nicht an der Löschung der KPT vor Übergabe an den Userspace hindern.
Falls meine Überlegungen zu IBPB und SMP zutreffen, dann wäre allerdings innerhalb des Kernelspace' ein Spectre-Angriff von einem Tätermodul auf andere Teile des Kernels möglich. So ein Tätermodul könnte wiederum eine herkömmliche Hintertür in den Userspace haben, den Schutz den KPTI liefern soll also umgehen.

[NAB]

Meinem Verständnis nach muss nur IRGENDWER ausgewählten Code ausführen, der in ein Register schreibt, in das auch das Opfer schreibt.

Muss er nur das? Ich weiß es nicht. Das Spectre-Papier hält sich da sehr zurück mit allgemeingültigen Aussagen über die praktische Anwendbarkeit. Auch der Beispielcode zeigt nur, wie ein Programm sich selber aushorchen kann.
Relevante Aussagen (mMn) dazu:

Spectre attacks induce a victim to speculatively perform
operations that would not occur during correct program
execution and which leak the victim’s confidential infor-
mation via a side channel to the adversary.

Das Opfer muss also selber den Code ausführen, der ihn in die Pfanne haut. Ich schließe daraus, dass irgendeine Prüfung der Speicherzugriffsberechtigungen doch greift.

During the second phase, the processor speculatively
executes instruction(s) that transfer confidential informa-
tion from the victim context into a microarchitectural
side channel.

Der Angriffscode muss also im Kontext des Opfers ausgeführt werden.

This may be triggered by having the at-
tacker request that the victim to perform an action (e.g.,
via a syscall, socket, file, etc.).

Das Opfer muss also gut fernsteuerbar sein, also irgendwie an- oder aufrufbar sein.

Andere Teile des Textes erwecken den Eindruck, dass ich nur die Sprungvorhersage trainieren müsste, dann ein X mit einem Wert außerhalb des legalen Wertebereiches übergebe, und schon kann ich den gesamten Speicher auch außerhalb meines Prozesses auslesen. Ganz so einfach kann's nicht sein. Zumindest nicht außerhalb des eigenen Prozesses.

Weiter unten finden sich weitere interessante Informationshäppchen:

Speculative execution was only observed when the
branch destination address was executable by the vic-
tim thread, so gadgets need to be present in the mem-
ory regions executable by the victim.

Die gesamte Sprungvorhersage findet also nicht immer statt, sondern nur unter bestimmten Umständen.

Du musst also erstens geeigneten Code finden der nicht nur ausnutzbar ist sondern auch Zugriff auf möglichst viel Speicher der Opfers gewährt und dann musst du das Opfer dazu bringen, in enger Synchronisation mir dir diesen Code immer wieder auszuführen und direkt danach die Reaktionsgeschwindigkeit des Caches messen.

In ihrer "Example Implementation on Windows" beschreiben sie das dann etwas anders. Ein Prozess wird ohne jegliche Synchronisation ausgehorcht. Dazu stellen sie Laborbedingungen her. Der einzige CPU-Kern, bestehend aus zwei HT-Kernen, wird zur Hälfte komplett von den Cache-Lausch-Prozessen eingenommen. Auf dem zweiten HT-Kern läuft der Sprungvorhersage-Trainer. Und der Sprungvorsage-Trainer weiß, wenn er gerade nicht läuft, dann läuft der anzugreifende Prozess. Hier hast du also den seltenen Luxus, den Cache die ganze Zeit überwachen zu können und genau zu wissen, wann der anzugreifende Prozess läuft. Es läuft nämlich nur ein einziger gutartiger Prozess auf dem System. Und du weißt auch genau, was dieser Prozess dann tut, nämlich ein Sleep(). Dadurch kannst du dir die Synchronisation sparen. Wie sie dem anzugreifenden Prozess dann eigene Registerwerte unterschieben, ganz ohne Funktionsaufrufe, verstehe ich dann aber nicht mehr so recht ...

Aber auch hier gibt es einen Kontextwechsel, zwischen Sprungvorhersage-Trainer und anzugreifendem Prozess.

Du brauchst also Kontextwechsel und du brauchst eine enge Synchronisation. Du musst das Opfer immer wieder dazu bringen, den ausgewählten Code in seinem Kontext auszuführen, nachdem du vorher die Sprungvorhersage zu einer falschen Entscheidung trainiert hast. Sicher kann das auch IRGENDEIN Prozess für dich machen, dann musst du den aber auch noch steuern und dich mit ihm synchronisieren.

Soweit zumindest mein bisheriges Verständnis. Ich lasse mich (in diesem Fall un-)gerne eines Besseren belehren.

denn meinem Verständnis nach [...] hängt der gerade geschilderte Angriff davon ab, ob mehrere Threads sich eine gemeinsame Sprungvorhersage teilen, was ich insbesondere bei HT für plausibel hielte.

Das musst du nicht "halten", es ist anscheinend so:

Tests, primarily on a Haswell-based Surface Pro 3, con-
firmed that code executing in one hyper-thread of Intel
x86 processors can mistrain the branch predictor for code
running on the same CPU in a different hyper-thread.

Wobei "mistrain" noch nicht bedeutet, dass es auch ausnutzbar ist. In ihrer "Example Implementation on Windows" geben sie sich ja etwas mehr Mühe, um zum Erfolg zu kommen. Da sind wieder Kontextwechsel nötig.

Aber es hilft uns nicht, dass weit fähigere Leute als wir genauso wie das Schwein in's Uhrwerk schauen.
Fakt ist, dass sich eine bestimmte CPU auf eine bestimmte Weise verhält. Dieses Verhalten ist ausschlaggebend für die Risikobewertung. Wer über das Verhalten bescheid weiß und wer nicht, ändert an der Sachlage des Risikos nichts.

Wir sind aber nur Schweine, die von außen auf die Uhr schauen und merken, dass sie falsch geht. Genauer gesagt merken wir, dass zig Uhren unterschiedlicher Hersteller falsch gehen. Dass da ein Uhrwerk drin ist, wissen wir nur, weil der Hersteller es uns gesagt hat. Bei der Risikobewertung müssen wir uns auch auf den Hersteller verlassen - unter dem Vorbehalt, dass wir ihn irgendwann der Lüge überführen. Sicherlich wäre es wünschenswerter wenn wir mehr wüssten ... aber aus meiner Sicht bleiben das fromme Wünsche und Spekulationen.

Irgendwo habe ich gelesen, dass LPDDR4 hardwareseitig immun gegen Rowhammer sei. Ich kenne allerdings keine Details, wie das erreicht wird oder warum das nur für LPDDR4 gilt.

Also das ging ungefähr so: "Oh. DDR3 ist anfällig gegen Rowhammer? Na, dann machen wir DDR4 besser!".
Und dann passierte das hier:
https://arstechnica.com/information-tec ... rowhammer/
Und dann hieß es "Oh, Mist, na wer konnte das schon ahnen. Aber dafür machen wir jetzt LPDDR4 besser!"
Und dann passierte das hier:
https://arxiv.org/pdf/1710.00551.pdf
Unter "Rowhammer Elimination Countermeasures." und "B. Rowhammer mitigations in hardware".

Meltdown ist doch nur ein Spezialfall von Spectre, der sich in Angriffsvektor und Behandlung dadurch auszeichnet, dass ein Kontextwechsel nicht (nur) zwischen Prozessen auf gleicher Privilegebene passiert, sondern dass dabei die Privilegebene gewechselt wird. Oder sehe ich das falsch?

Ich werd mich hüten, dass als falsch zu bezeichnen, so abstrakt wie du es ausgedrückt hast, aber aus meiner Sicht ist Meltdown eine völlig eigenständige Sicherheitslücke, die sich aus einem Fehler in Intels out-of-order execution ergibt. Sie hat so gar nichts mit der Sprungvorhersage zu tun, ist wesentlich besser verstanden, leichter ausnutzbar und leichter patchbar.

Falls meine Überlegungen zu IBPB und SMP zutreffen, dann wäre allerdings innerhalb des Kernelspace' ein Spectre-Angriff von einem Tätermodul auf andere Teile des Kernels möglich.

Unabhängig davon, ob deine Überlegungen stimmen, hast du Recht:
http://nvidia.custhelp.com/app/answers/detail/a_id/4611
Nvidia hält seine Treiber durch Meltdown nicht für angreifbar. Die Anpassungen zielen auf Spectre.
Wobei sie sich bei Linux etwas schwammig ausdrücken:

The Linux driver contains updates to maintain compatibility with recent Linux updates for this security issue.

Wobei das noch nicht meine Frage beantwortet, ob das nur Nvidias Treiber betrifft oder ob sämtliche Treiber für proprietäre Althardware angepasst werden müssen.

Alle anonymen Zitate von hier:
https://spectreattack.com/spectre.pdf

[hikaru]

Mein ganzes Hyperthreading-Geschwurbel zu Spectre kann ich abhaken. Manchmal reicht schon ein Blick in den Wikipedia-Artikel. [1] Da steht drin, dass der komplette Registersatz zu den "replicated resources" gehört.
Mein Szenario würde aber nur funktionieren, wenn zumindest die geheimnistragenden Teile davon zu den "shared resources" gehören würden.

Theoretisch wäre das selbe Szenario auch auf SMP im Allgemeinen mit mit shared L3-Cache anwendbar, aber auf der Ebene gibt es mangels gemeinsamer Pipelines der SMP-Cores keine kontextübergangsfreien Zugriffswechsel.

Wir sind aber nur Schweine, die von außen auf die Uhr schauen und merken, dass sie falsch geht. Genauer gesagt merken wir, dass zig Uhren unterschiedlicher Hersteller falsch gehen. Dass da ein Uhrwerk drin ist, wissen wir nur, weil der Hersteller es uns gesagt hat. Bei der Risikobewertung müssen wir uns auch auf den Hersteller verlassen - unter dem Vorbehalt, dass wir ihn irgendwann der Lüge überführen. Sicherlich wäre es wünschenswerter wenn wir mehr wüssten ... aber aus meiner Sicht bleiben das fromme Wünsche und Spekulationen.

Wir schauen hier aus verschiedenen Blickwinkeln auf das Thema. Du gehst vom vorhandenen Informationsstand aus, ich vom zur Beurteilung notwendigen Informationsstand. Die sind leider nicht deckungsgleich.

Also das ging ungefähr so: "Oh. DDR3 ist anfällig gegen Rowhammer? Na, dann machen wir DDR4 besser!".
Und dann passierte das hier:
https://arstechnica.com/information-tec ... rowhammer/
Und dann hieß es "Oh, Mist, na wer konnte das schon ahnen. Aber dafür machen wir jetzt LPDDR4 besser!"
Und dann passierte das hier:
https://arxiv.org/pdf/1710.00551.pdf
Unter "Rowhammer Elimination Countermeasures." und "B. Rowhammer mitigations in hardware".

Danke!

Meltdown ist doch nur ein Spezialfall von Spectre, der sich in Angriffsvektor und Behandlung dadurch auszeichnet, dass ein Kontextwechsel nicht (nur) zwischen Prozessen auf gleicher Privilegebene passiert, sondern dass dabei die Privilegebene gewechselt wird. Oder sehe ich das falsch?

Ich werd mich hüten, dass als falsch zu bezeichnen, so abstrakt wie du es ausgedrückt hast, aber aus meiner Sicht ist Meltdown eine völlig eigenständige Sicherheitslücke, die sich aus einem Fehler in Intels out-of-order execution ergibt. Sie hat so gar nichts mit der Sprungvorhersage zu tun, ist wesentlich besser verstanden, leichter ausnutzbar und leichter patchbar.

Es sind beides Sicherheitslücken, die sich aus einem Side-Channel-Angriff ergeben, der durch "Out Of Order Execution" möglich wird.
Auch bei Meltdown wird spekuliert. Es werden spekulativ Instruktionen ausgeführt, die nicht ausgeführt werden dürften, weil eine vorhergehende Instruktion eine Exception wirft. Man hätte es auch "branch prediction bypass" nennen können. Es ist eine Art Spectre v2 ("branch target injection") ohne den Injektionsteil, denn das was bei Spectre v2 injiziert wird, nämlich die fehlerhafte Sprungvorhersage, entsteht bei Meltdown ohne externen Eingriff, weil das "Opfer" bei Meltdown in Wahrheit ein Komplize des Angreifers ist.
Wie bei Spectre setzt der Angriff da an, die fehlerhaften Spekulationergebnisse zu entführen, diesmal aber nicht aus dem Opferspeicher in den Angreiferspeicher, sondern aus dem Kernelspace in den Userspace. Der Komplizenthread ist hier ein Taschendieb, der dem Kernel die Brieftasche stiehlt und an den Angreifer weitergibt, bevor der Kernel den Dieb mit einer Exception fassen kann.
Was Meltdown einerseits größere Durchschlagskraft gibt, es aber andererseits einfacher zu behandeln macht ist, dass hier zwingend ein Kontextwechsel zwischen Userspace und Kernelspace geschieht, vor dem via KPTI leicht das Geheimnis aus dem Cache entfernt werden kann. Es wird nicht der unbekannte Dieb aus der Menschenmenge entfernt, sondern die bekannte Brieftasche.


[1] https://de.wikipedia.org/wiki/Hyperthre ... tionsweise

[NAB]

Mein ganzes Hyperthreading-Geschwurbel zu Spectre kann ich abhaken.

Nein, du bist da schon auf einer heißen Spur. Hat nur nichts mit den Registern zu tun (genau wie Spectre eigentlich nichts mit den Registern zu tun hat). Man weiß nur nichts genaues, nur die Andeutungen aus dem Spectre-Papier. Und der wirkliche Vorteil von HT ist, dass du Dank Superskalarität wirklich den Cache permanent ohne Unterbrechungen belauschen kannst. Das ist aber nichts Neues, diese Sicherheitslücke ist seit Jahren bekannt.

Manchmal reicht schon ein Blick in den Wikipedia-Artikel. [1] Da steht drin, dass der komplette Registersatz zu den "replicated resources" gehört.

Mit Verlaub, das schrieb ich schon hier:
viewtopic.php?f=37&t=168134&start=225#p1162386
Anders ist ein eigener Rumpf-Kern auch schwer vorstellbar. Deine gesamte Vorstellung dieser "Pipeline" ist etwas falsch ... Superskalarität sorgt eben dafür, dass einzelne unterschiedliche Befehle wirklich gleichzeitig ausgeführt werden können, da wird wenn möglich eben nichts serialisiert. Daher kam überhaupt erst der Gedanke, dass man zwei Threads gleichzeitig ausführen könnte.

Nebenbei, fällt dir auf, dass die einzige vernünftige Quelle in deinem Wikipedia-Artikel von 2002 stammt? Wie HT jetzt implementiert ist, weiß man nicht so genau.

Wir schauen hier aus verschiedenen Blickwinkeln auf das Thema. Du gehst vom vorhandenen Informationsstand aus, ich vom zur Beurteilung notwendigen Informationsstand. Die sind leider nicht deckungsgleich.

Nunja ... ich beobachte seit vielen Jahren einen Mangel an "zur Beurteilung notwendigen Informationsständen". Auch bei Spectre mangelt es seit 20 Jahren an den notwendigen Informationsständen. Da habe ich wenig Hoffnung auf kurzfristige Besserung.

Es sind beides Sicherheitslücken, die sich aus einem Side-Channel-Angriff ergeben, der durch "Out Of Order Execution" möglich wird.

Fein. Wollen wir es noch weiter abstrahieren? Es gibt Spectre und Meltdown gar nicht. Die Out-of-order-execution und die branch prediction funktionieren genau so wie sie es sollen. Man hat nur neue Methoden gefunden, wie man mit Cache-Timing-Angriffen noch schneller an noch mehr Informationen kommen kann.

Unsere Systeme sind seit Jahren durch Cache-Timing-Angriffe bedroht, die Sicherheitsforscher warnen seit Jahren, und kein Schwein tut was dagegen.

In der "Example Implementation on Windows" umgehen sie übrigens auch ganz lässig ASLR ... scheint auch nichts zu bringen, außer ein paar Überstunden im Labor.

[dufty2]

Phoronix.com empfiehlt gerade den Vortrag von Jon Masters (Red Hat) von der FOSDEM 2018:
video: https://video.fosdem.org/2018/Janson/cl ... ynote.webm
slides: https://fosdem.org/2018/schedule/event/ ... eynote.pdf

[clue]

Und auch noch interessant wegen der Performancefrage:

https://www.phoronix.com/scan.php?page= ... .15-FX-Zen

AMD verliert durch Retpoline scheinbar keine Geschwindigkeit. Das deckt sich mit meinen eigenen Messungen wie bereits oben geschrieben.

[Nice]

Ich spreche sicher im Namen vieler hier "Passiv-Leser" wie mich:

Ich danke allen Thread-Teilnehmern für ihre interessanten und informativen Beiträge!

P.S.:
Sowas muß auch mal gepostet werden...
We can work it out!
https://www.youtube.com/watch?v=Qyclqo_AV2M

[NAB]

Inzwischen ist der "spectre-meltdown-checker" übrigens in Debian angekommen:
https://packages.debian.org/stretch-bac ... wn-checker
Für Stable/Stretch blöder Weise nur in den Backports. Wer keinen Bock hat, an seiner sources.list rumzubasteln, kann sich das Paket auch manuell herunterladen und installieren mit:
dpkg -i <Paketname>

[Nice]

Ich habe mir den checker mal heruntergeladen, installiert und in der bash gestartet: wie erwartet ist mein System "vulnerable".
Die Aktion hätte ich mir aber eigentlich auch ersparen können, weil das Ergebnis zu erwarten war.
Was imho einzig zählt ist die Frage, wann der neue gestählte Kernel in Stable eingespeist wird.

[dufty2]

Was imho einzig zählt ist die Frage, wann der neue gestählte Kernel in Stable eingespeist wird.

Falls es Dich interessiert, für stable gibt es ein "proposed-update" (4.9.80), welcher auch erfolgreich kompiliert wurde. Weiss aber nicht, ob das Kompilat (.deb) für die Allgemeinheit zugänglich ist oder nur für die debian-kernel-maintainer.

Bei 4.15. gab es einen "Grave-"bug (der aber nix mit spectre/meltdown zu tun hatte) und deshalb ist - vermute ich mal - zum Stocken gekommen für sid/testing.

[Nice]

Falls es Dich interessiert

Klar doch. Thx!

[NAB]

Falls es Dich interessiert, für stable gibt es ein "proposed-update" (4.9.80), welcher auch erfolgreich kompiliert wurde. Weiss aber nicht, ob das Kompilat (.deb) für die Allgemeinheit zugänglich ist oder nur für die debian-kernel-maintainer.

Doch, der ist über "proposed-updates" allgemein zugänglich, spiele ihn gerade ein:
Get:18 http://ftp.de.debian.org/debian stretch-proposed-updates/main amd64 linux-image-4.9.0-5-amd64 amd64 4.9.80-1

Erhältlich seit heute:
http://ftp.debian.org/debian/dists/stab ... d-updates/
auch wenn "linux_4.9.80-1_amd64.changes" was vom 4ten Februar erzählt.
Dadrin steht dann auch (unter anderem):

Code: Alles auswählen

     - bpf: prevent out-of-bounds speculation (mitigates Spectre#1 / CVE-2017-5753)
     - [x86] x86/spectre: Add boot time option to select Spectre v2 mitigation
     - [x86] x86/retpoline/crypto: Convert crypto assembler indirect jumps
     - [x86] x86/retpoline/entry: Convert entry assembler indirect jumps
     - [x86] x86/retpoline/ftrace: Convert ftrace assembler indirect jumps
     - [x86] x86/retpoline/hyperv: Convert assembler indirect jumps
     - [x86] x86/retpoline/xen: Convert Xen hypercall indirect jumps
     - [x86] x86/retpoline/checksum32: Convert assembler indirect jumps
     - [x86] x86/retpoline/irq32: Convert assembler indirect jumps
     - [x86] x86/retpoline: Fill return stack buffer on vmexit

[NAB]

Doch, der ist über "proposed-updates" allgemein zugänglich, spiele ihn gerade ein:
Get:18 http://ftp.de.debian.org/debian stretch-proposed-updates/main amd64 linux-image-4.9.0-5-amd64 amd64 4.9.80-1

Tja, das war wohl nix. Der spectre-meltdown-checker sagt, ich sei weiterhin gegen Variant 1 und Variant 2 verwundbar. Bei Variant 2 liegt's wohl daran, dass der Kernel auch mit einem Compiler kompiliert werden müsste, der Retpoline unterstützt, und das ist hier nicht der Fall (sagt das Script).

[towo]

Spectre zu patchen wird halt schwierig für Stable, weil der Kernel mit gcc-7.3 als Minimum benötigt wird.
Initialer Spectre_v1 Schutz ist im Moment nur in 4.15.2 und 4.14.18 verfügbar.

[NAB]

Und was hindert Debian, einen mit gcc 7.3 kompilierten 4.9er Kernel zur Verfügung zu stellen? Ja,schon klar, man kann ihn sich selber nicht mehr mit Stable kompilieren, das ist blöd. Aber Spectre ist auch blöd.

[dufty2]

Hier kommt hat alles zusammen

gcc-7.3 ist auch buggy, Teile der Pakete werden ja schon mit gcc-8 kompiliert.
Mit gcc-7.3 in stable würde man das Prinzip des "self hosting" verletzten, will man das?

Auf der anderen Seite:
* Spectre/Meltdown sind nicht die einzigen (security-)kernel-bugs,
es kommen - sagen wir mal - zweiwöchentlich neue hinzu, wenn man sich den security-tracker so anschaut.
* Die bugs gibt es seit über 20 Jahren, jetzt kommts auf 2 Monate hin oder her auch nicht mehr an

Eine bug-free-distri wird noch für lange Zeit ein Wunschtraum bleiben ...

[NAB]

Ja, ich sehe ja die Probleme ... aber wenn ich dich recht verstehe, hindert Debian nichts daran, einen dann halt mit gcc 8 kompilierten 4.9er Kernel für Stretch zur Verfügung zu stellen ... meinetwegen in stretch-backports non-free.

Ich hab bisher auch nichts davon gehört, dass Retpoline überhaupt auf gcc 6 gebackported werden soll. Mein unqualifiziertes Rumgestochere mit Google hat dann eben Folgendes ergeben:
https://lists.gt.net/linux/kernel/2874831

If I get positive feedbacks from kernel folks with my GCC 7 patches today, I
will submit my patches for GCC 8 today. After they are checked in, I will
backport them to GCC 7/6/5/4.9.

Also doch ... irgendwann ... vielleicht, falls ich das richtig einordne.

Heise weiß übrigens:

Die Entwicklung der Spectre-v2-Gegenmaßnahmen für den Linux-Kernel ist keineswegs abgeschlossen. Die Programmierer haben etwa bereits einige Änderungen vorgenommen, damit Retpoline auch auf Intel-Prozessoren der Skylake-Generation funktioniert; möglicherweise sind aber noch mehr Anpassungen nötig, damit der Schutz auf Intels modernen Prozessoren ausreichend funktioniert.

https://www.heise.de/ct/artikel/Kernel- ... 63549.html
Leider ohne Quelle.

Wenn das wirklich funktioniert, könnte man auch neuere Intel-Prozessoren ganz ohne Microcode-Update gegen Spectre-Angriffe auf den Kernel abdichten. Eh, also gegen Spectre-v2. Eh, was ist das überhaupt?

Google beschreibt unter "Variant 2" einen Ausbruch aus einer virtuellen Maschine mittels "indirect branch". Indirect branches werden im Spectre Papier nur als zusätzliche Spielwiese beschrieben, deren Ausnutzmöglichkeiten die Autoren nicht näher nachgehen. Google bricht hier nicht nur aus dem Kontext eines Prozesses aus (so wie es im Spectre Papier beschrieben wird) sondern durchbricht auch gleich die "domain Privilegien". Und was macht Retpoline nun?

Dazu die Sicht eines Compiler-Entwicklers auf Spectre und Retpoline:
https://reviews.llvm.org/D41723
Hier geht es nicht um "branch prediction" generell geht, sondern ausdrücklich um "indirect branches". Die führen zu: "this allows an attacker to leak data only accessible to a privileged domain (like the kernel) back into an unprivileged domain.". Retpoline verhindert nun nicht etwa "Spectre" sondern es verhindert, dass der Compiler "indirect branches" erzeugt. Spectre funktioniert also weiter. Der Angreifer findet nur keine "indirect branches" mehr, die er ausnutzen könnte. Dazu muss der Code nicht-angreifbar gemacht werden, also neu kompiliert werden.

Der Text beschreibt auch schön, dass dazu eigentlich jedes Programm neu kompiliert werden muss, das nicht angreifbar sein soll. Wenn der Kernel sich zukünftig also als "spectre-v2-geschützt" ausgibt, dann betrifft das einzig den Kernel.

Das, was im Spectre Papier beschrieben ist, nämlich der Angriff eines User-Space Prozesses auf einen anderen, ohne "indirect branches", funktioniert weiterhin. Auch wenn sämtliche User-Space-Programme mit Retpoline neu durchkompiliert werden. Man könnte also sagen, der Spectre-v2-Schutz schützt gar nicht gegen Spectre.

Und dann gibt es noch den Spectre-v1-Schutz. Nun beschreibt Google in "Variant 1" auch "nur" einen Übergriff vom User Space in den Kernel-Speicher, mittels selbstgebasteltem Angriffscode, der dank Berkeley Paket Filter mit Kernelprivilegien ausgeführt wird. Google nutzt hier den Überlauf eines Arrays, genau wie im Spectre Papier beschrieben. Die Schutzmaßnahmen scheinen gerade so auszusehen, dass die Kernelentwickler sämtliche angreifbaren Stellen im Kernel-Code suchen und abdichten, in mühsamer Handarbeit. Die Sache durchschaue ich noch nicht so ganz, aber ich lese da nur was vom Befehl "LFENCE":
https://newsroom.intel.com/wp-content/u ... annels.pdf
und der muss nach meinem Verständnis hinter jeder angreifbaren Programmzeile eingefügt werden. Danach muss natürlich auch neu kompiliert werden. Hier gibt's also das gleiche Problem wie bei "Retpoline".

Fazit: Wenn man denn laut "spectre-meltdown-checker" gegen "Spectre Variant 1" und "Spectre Variant 2" geschützt ist, ist man gar nicht gegen "Spectre" geschützt. Sämtliche Beispiele aus dem Spectre Papier funktionieren weiterhin.
(Ich wär froh, wenn mir das jemand ausreden könnte)

Ehm, war's das jetzt? Oder haben die noch was auf Lager? Ich hatte ja die Hoffnung, dass Intel noch was rausrückt, das bei jedem Kontextwechsel die Sprungvorhersage leerputzt oder den Kernelentwicklern was cooles einfällt ... aber ich seh da nix.

[dufty2]

Da Prinzip des "self hosting" ist schon wichtig, denn wenn ich - ich übertreib mal jetzt - einen
C-Compiler von Microsoft für meinen linux-kernel benötigen würde, dann wäre das jetzt - politisch gesehen - nicht so dolle. Ditto sind die *BSDler ja ganz scharf auf Clang/LLVM
Also wird man - solang es geht und der Aufwand sich in Grenzen hält - beim gcc-6 für stable bleiben.

Und außerdem, mein hardware vendor sagt, alle roger:

Code: Alles auswählen

# ./spectre-meltdown-checker.sh
Spectre and Meltdown mitigation detection tool v0.34+

Checking for vulnerabilities on current system
Kernel is Linux 4.15.0-rc8-amd64 #1 SMP Debian 4.15~rc8-1~exp1 (2018-01-15) x86_64
CPU is Intel(R) Atom(TM) CPU N450   @ 1.66GHz

Hardware check
* Hardware support (CPU microcode) for mitigation techniques
  * Indirect Branch Restricted Speculation (IBRS)
    * SPEC_CTRL MSR is available:  NO 
    * CPU indicates IBRS capability:  NO 
  * Indirect Branch Prediction Barrier (IBPB)
    * PRED_CMD MSR is available:  NO 
    * CPU indicates IBPB capability:  NO 
  * Single Thread Indirect Branch Predictors (STIBP)
    * SPEC_CTRL MSR is available:  NO 
    * CPU indicates STIBP capability:  NO 
  * Enhanced IBRS (IBRS_ALL)
    * CPU indicates ARCH_CAPABILITIES MSR availability:  NO 
    * ARCH_CAPABILITIES MSR advertises IBRS_ALL capability:  NO 
  * CPU explicitly indicates not being vulnerable to Meltdown (RDCL_NO):  NO 
  * CPU microcode is known to cause stability problems:  NO  (model 28 stepping 10 ucode 0x107)
* CPU vulnerability to the three speculative execution attacks variants
  * Vulnerable to Variant 1:  NO 
  * Vulnerable to Variant 2:  NO 
  * Vulnerable to Variant 3:  NO 

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Mitigated according to the /sys interface:  NO  (kernel confirms your system is vulnerable)
* Kernel has array_index_mask_nospec:  NO 
* Checking count of LFENCE instructions following a jump in kernel...  NO  (only 3 jump-then-lfence instructions found, should be >= 30 (heuristic))
> STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as not vulnerable)

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigated according to the /sys interface:  NO  (kernel confirms your system is vulnerable)
* Mitigation 1
  * Kernel is compiled with IBRS/IBPB support:  NO 
  * Currently enabled features
    * IBRS enabled for Kernel space:  NO 
    * IBRS enabled for User space:  NO 
    * IBPB enabled:  NO 
* Mitigation 2
  * Kernel compiled with retpoline option:  YES 
  * Kernel compiled with a retpoline-aware compiler:  NO  (kernel reports minimal retpoline compilation)
> STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as not vulnerable)

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Mitigated according to the /sys interface:  YES  (kernel confirms that the mitigation is active)
* Kernel supports Page Table Isolation (PTI):  YES 
* PTI enabled and active:  YES 
* Running as a Xen PV DomU:  NO 
> STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as not vulnerable)

A false sense of security is worse than no security at all, see --disclaimer
#

also mach ich mir keinen Kopf

[clue]

Der Text beschreibt auch schön, dass dazu eigentlich jedes Programm neu kompiliert werden muss, das nicht angreifbar sein soll. Wenn der Kernel sich zukünftig also als "spectre-v2-geschützt" ausgibt, dann betrifft das einzig den Kernel.

Genau darüber habe ich mich auch die ganze Zeit über gewundert: Alle reden nur über den Kernel, vergessen dabei aber, dass es nicht ausreicht, ihn alleine zu härten, sondern eben auch ALLE anderen Programme: KDE, GNOME, Gimp, VLC, etc. samt allen Libraries.

Soll heißen, sobald die Specter/Meltdown patches in der GCC angekommen sind und zuverlässig funktioneren, dann müsste doch eigentlich Stable/OldStable/Testing/SID nochmals KOMPLETT neu durchkompiliert werden, oder etwa nicht? Alles andere wäre doch grob fahrlässig. Machen das RedHat und Suse nicht auch?

Das, was im Spectre Papier beschrieben ist, nämlich der Angriff eines User-Space Prozesses auf einen anderen, ohne "indirect branches", funktioniert weiterhin. Auch wenn sämtliche User-Space-Programme mit Retpoline neu durchkompiliert werden. Man könnte also sagen, der Spectre-v2-Schutz schützt gar nicht gegen Spectre.

Hui, das klingt ja wirklich nach DEM GAU! Bist Du Dir sicher, dass man Computersysteme mit betroffenen Prozessoren GAR NICHT absichern kann? Ich habe leider nicht genug Fachwissen, um das auch nur annähernd beurteilen zu können, sondern plappere auch nur das nach, was ich auf Heise und den dortigen Kommentaren so gelesen habe.

[hikaru]

Ehm, war's das jetzt? Oder haben die noch was auf Lager? Ich hatte ja die Hoffnung, dass Intel noch was rausrückt, das bei jedem Kontextwechsel die Sprungvorhersage leerputzt oder den Kernelentwicklern was cooles einfällt ... aber ich seh da nix.

Die Sprungvorhersage der CPU weiß gar nichts von diesen Kontextwechseln*, davon weiß nur der Kernel. Der Kernel wiederum weiß nichts von spekulierten Registerinhalten. Deshalb kannst du die Sprungvorhersage nicht bei Kontextwecheln leeren, denn es gibt keinen der alle nötigen Informationen hat um zu entscheiden, wann das nötig ist.
Es gibt hier einfach keinen Ansatz für eine globale Lösung. Das geht nur für konkrete Spezialfälle. Jede Anwendung muss selbst darauf achten, nicht mit sensiblen Daten zu spekulieren. Angesichts von weitgehend datenkontextignoranten Shared Libs ist das eine Sisyphosarbeit.

Ich sehe nach wie vor die Lösung nicht in der Spekulationstrennung von Prozess A und B, sondern in der Trennung von Spekulations- und Commitregistern. Noch nicht commitete Spekulationsergebnisse dürfen dann hardwaredesignbedingt außerhalb der Spekulation selbst nicht sichtbar sein sondern werden erst beim Commit in ein Commitregister sichtbar. Dafür brauchen wir aber neue Hardware.

Bist Du Dir sicher, dass man Computersysteme mit betroffenen Prozessoren GAR NICHT absichern kann?

Nicht mit vertretbarem Aufwand. Speculative Execution" ist auf aktuellen CPUs nicht prinzipiell abzusichern, sondern nur konkret für jeden einzelnen Spezialfall. Dabei wird zwangsläufig der eine oder andere Entwickler Fehler machen.
Eine Alternative wäre der komplette Verzicht auf Spekulation, was die CPU-Hersteller vermutlich per Microcode nachliefern könnten. Aber dann sind selbst unsere High-End-CPUs nur etwa 3x so schnell wie die knapp 10 Jahre alten In-Order-Atoms.


*) Wir sind hier wieder bei "Variante B" aus:
viewtopic.php?f=37&t=168134&start=225#p1162216

[NAB]

Soll heißen, sobald die Specter/Meltdown patches in der GCC angekommen sind und zuverlässig funktioneren, dann müsste doch eigentlich Stable/OldStable/Testing/SID nochmals KOMPLETT neu durchkompiliert werden, oder etwa nicht? Alles andere wäre doch grob fahrlässig. Machen das RedHat und Suse nicht auch?

Neu durchkompilieren reicht eben nicht. Das würde nur "Retpoline" einfügen, was eben gegen die Ausnutzung von "indirect branches" hilft, also gegen "Variant 2". Gegen "Variant 1" hat Intel nur "LFENCE" anzubieten, und um das zu nutzen, müssten sämtliche Programme UMGESCHRIEBEN werden (und danach natürlich auch neu durchkompiliert werden). Richtig, Red Hat müsste eigentlich das gleiche Problem haben.

Gennau das macht mir ja Gedanken. Soweit ich verstehe, gibt es bisher keine Methode, um LFENCE automatisch "sinnvoll" einzufügen - darum dauert die Absicherung des Kernels gegen "Variant 1" ja so lange. Und wenn jetzt z.B. KDE anfängt, LFENCE in seine neuste Software einzuarbeiten ... ob die das wohl allen Ernstes noch zurückportieren? Oder soll Debian das zurückportieren? Da wäre eigentlich ein neues Debian-Release fällig ... oder ne andere Strategie, um mit der Situation umzugehen.

Bist Du Dir sicher, dass man Computersysteme mit betroffenen Prozessoren GAR NICHT absichern kann?

Ich zitiere hier mal Intel: "No computer system can be absolutely secure."

sondern plappere auch nur das nach, was ich auf Heise und den dortigen Kommentaren so gelesen habe.

Genau das wundert mich ja auch. Alle reden nur noch darüber, wie gut sich Linux und Windows patchen lassen und wann Intel endlich mit den Microcodes in die Hufe kommt. Darüber, was "Spectre" eigentlich bewirkt, redet gar keiner mehr, auch nicht die "Fachpresse". Das Problem ist, dass es auch nur die drei CVEs gibt - Variant 1 bis 3 - und alle drei beschreiben Übergriffe in den Kernel-Speicher. Und genau die werden zur Zeit auch nur gefixt. Eigentlich müsste für jedes angreifbare Programm (alle?) eine eigene CVE auftauchen. Ich krieg ja langsam auch das Gefühl, dass ich irgendwas falsch verstanden habe und "die anderen" Recht haben ... es sieht mir nur nicht so aus.

Die Sprungvorhersage der CPU weiß gar nichts von diesen Kontextwechseln*, davon weiß nur der Kernel. Der Kernel wiederum weiß nichts von spekulierten Registerinhalten. Deshalb kannst du die Sprungvorhersage nicht bei Kontextwecheln leeren, denn es gibt keinen der alle nötigen Informationen hat um zu entscheiden, wann das nötig ist.

Richtig. Aber der Kernel weiß von den Kontextwechseln. Wenn Intel ihm ein Mittel in die Hand gibt, die Sprungvorhersagetabelle bei jedem Kontextwechsel leerzuputzen, würde das nach meinem Verständnis Spectre im Keim ersticken. Sicherlich gäbe das einen hässlichen Performance impact. Den haben wir aber eh schon, ganz ohne dass auch nur ein einziges Userspace-Programm abgesichert worden wäre. Benchmarks zu einem Apache mit Retpoline und LFENCE gibt's noch gar nicht.

Und der arme Apache müsste Retpoline und LFENCE dann sinnlos bei JEDEM Durchlauf durchführen, egal ob gerade ein Kontextwechsel stattgefunden hat oder nicht.

Eine Alternative wäre der komplette Verzicht auf Spekulation, was die CPU-Hersteller vermutlich per Microcode nachliefern könnten. Aber dann sind selbst unsere High-End-CPUs nur etwa 3x so schnell wie die knapp 10 Jahre alten In-Order-Atoms.

Du übertreibst. "out of order execution" ist was anderes als "speculative execution" und das ist noch mal was anderes als "branch prediction". Nebenbei sollen wir nun genau das machen ... wer sicher gehen will, muss hinter jedem "if" ein LFENCE einfügen, um die speculative execution auszuschalten (sagt Intel). Wer sicheren Code schreiben will, tut also genau das. Ansonsten muss er spekulieren, ob sein Code sich mit Spectre ausnutzen lässt. Da wird die "speculative execution" dann vom Prozessor auf den Programmierer verlagert

(Nebenbei geht das Spectre Papier noch weiter ... unter "Variations" finden sich Vorschläge, die ganz ohne "bounds check" und "indirect branches" auskommen)

[hikaru]

Aber der Kernel weiß von den Kontextwechseln. Wenn Intel ihm ein Mittel in die Hand gibt, die Sprungvorhersagetabelle bei jedem Kontextwechsel leerzuputzen, würde das nach meinem Verständnis Spectre im Keim ersticken.

Kraft meiner profunden Glaskugelei vermute ich, dass das technisch mit aktuellen CPUs nicht geht. Ich bezweifle, dass sich einer CPU die dafür nicht designt ist per Microcode ein entsprechendes Signal an den Kernel beibringen lässt.
Und selbst wenn es ginge, hätte das Leeren der Sprungvorhersage bei jedem Kontextwechsel teils gigantische zusätzliche(!)Auswirkungen auf die Performance die wohl den Kunden nicht vermittelbar wären, denn auf einem Out-Of-Order-System gibt es ziemlich viele Kontextwechsel wenn das Szenario passt.

Du übertreibst. "out of order execution" ist was anderes als "speculative execution"

Speculative Execution ist eine auf der Hand liegende Erweiterung des ursprünglichen Tomasulo-Algorithmus', welcher die Grundlage für Out-of-Order-Execution ist.
Du wirst wenige (keine?) real existierende CPUs finden, die zwar Out-of-Order können aber keine Speculative Execution. Und ich bezweifle ebenfalls, dass du der Sprungvorhersage einer existierenden CPU per Microcode Speculative Execution abtrainieren kannst, ohne ihr auch Out-of-Order-Execution zu nehmen.
Aber da sind wir wieder an dem Punkt, dass keiner von uns beiden eine Ahnung hat, was eine Sprungvorhersage genau ist und wie sie im Detail funktioniert.

[clue]

Tja, also wenn sich die Dinge nun mal so verhalten, wie es gerade scheint, bleiben wohl nur folgende Möglichkeiten:

1. Variante 1: Die Angriffsflächen für Spectre zu minimieren, was das Auffinden der größten Einfallstore beinhaltet (network-stack, browser, Apache, Office, etc.)

2. Variante 2: Die Hersteller in die Produkthaftung nehmen. Wird sich aber wohl nie durchsetzen lassen, wegen 2 Jahre Gewährleistung und too big to fail, inklusive schweren Koffern, mit denen die Entscheider weltweit wohl bedrückt werden werden.

3. Variante 3: Auf die (hoffentlich) bereinigten Folge-Generationen warten, die dafür dann aber andere Schweinereien enthalten wie PSP/ME (also ein Computer in Deinem Computer, den Du aber niemals nicht kontrollieren kannst, aber der dafür Dich, sprich der NSA feuchten Träume). Jedenfalls sollte man sich wohl schleunigst mit Intel/AMD Aktien eindecken, bevor der run auf die neuen, "sichereren" Prozessorgenerationen beginnt.

Irgendwie gefallen mir alle 3 Varianten nicht so recht ....