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

Alles rund um sicherheitsrelevante Fragen und Probleme.
clue
Beiträge: 943
Registriert: 08.07.2007 17:36:57

Re: Intel-Bug

Beitrag von clue » 26.01.2018 16:23:32

TomL hat geschrieben: ↑ zum Beitrag ↑
03.01.2018 15:44:07
Ich habe mir jetzt gerade mal sysbench installiert, mit dem Gedanken, dass ich irgendwann einen Vorher/Nachher-Vergleich anstellen kann.... oder um festzustellen, ob überhaupt was passiert ist. Die Ausgaben dieser beiden Befehle habe ich jetzt gesichert:

Code: Alles auswählen

sysbench --test=cpu --num-threads=4 run
sysbench --test=memory run
Kann man damit bei einem späteren Vergleich dann sinnvolle Erkenntnisse ableiten, ob der Patch wirklich was "kostet" und wieviel?

Also ich fand Deine Frage sehr interessant. Deswegen habe ich mehrere benchmarks mit der Phoronix-Suite http://www.phoronix-test-suite.com/ gemacht.

Das Ergebnis nach jeweils 3 Durchläufen (c-ray):

Keine messbaren Geschwindigkeitseinbußen nach update von Kernel 4.9.03 auf Kernel 4.9.05.

Falls Du Lust hast, kannst Du Dein System ganz einfach selber testen:

1. Dem obigen link folgend das Debian/Ubuntu-Paket für die test-suite runterladen.
2. Ich musste bei mir noch folgende Abhängigkeiten auflösen:

apt-file autoconf build-essential dpkg-dev g++ g++-6 gcc gcc-6 libapt-pkg-perl libasan3 libatomic1 libc-dev-bin libc6-dev libcc1-0 libcilkrts5 libdpkg-perl libexporter-tiny-perl libgcc-6-dev libitm1 liblist-moreutils-perl liblsan0 libmpx2 libregexp-assemble-perl libstdc++-6-dev libtsan0 libubsan0 linux-libc-dev make mesa-utils php-xml php7.0-xml php-cli php-common php7.0-cli
php7.0-common php7.0-json php7.0-opcache php7.0-readline

3. Dann die test-suite installieren.
4. Als normaler User kannst Du dann den Test ganz einfach laufen lassen:

phoronix-test-suite benchmark c-ray

4.1. Er lädt sich aus dem Internet dann eine winzige Datei für den c-ray test runter. Ich habe c-ray genommen, weil der die Prozessorleistung messen kann. Es gibt aber über 100 Tests. Die kannst Du Dir anzeigen lassen, indem Du

phoronix-test-suite list-available-tests


eingibst.

Würd mich mal interessieren, ob Du bei Dir irgendwelche Einbußen festellen kannst.
Offenbarung 13 erfüllt sich gerade vor unseren Augen, genießen wir also die letzten Jahre unserer Scheinfreiheit

Benutzeravatar
Par@noid
Beiträge: 244
Registriert: 09.11.2005 13:33:35
Lizenz eigener Beiträge: GNU Free Documentation License
Wohnort: Schwarzwald

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

Beitrag von Par@noid » 27.01.2018 18:33:03

kann ich mich mit VPN vor Spectre und Meltdown schützen ?

MfG Par@noid
Man hilft den Menschen nicht, wenn man für sie tut, was sie selbst tun können .....

Debian GNU/Linux Bookworm/sid 64-bit| GNOME Version 43 :THX:

DeletedUserReAsG

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

Beitrag von DeletedUserReAsG » 27.01.2018 18:35:49

Nein.

Benutzeravatar
Par@noid
Beiträge: 244
Registriert: 09.11.2005 13:33:35
Lizenz eigener Beiträge: GNU Free Documentation License
Wohnort: Schwarzwald

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

Beitrag von Par@noid » 28.01.2018 14:10:14

niemand hat geschrieben: ↑ zum Beitrag ↑
27.01.2018 18:35:49
Nein.
Vielen Dank :THX:

MfG Par@noid
Man hilft den Menschen nicht, wenn man für sie tut, was sie selbst tun können .....

Debian GNU/Linux Bookworm/sid 64-bit| GNOME Version 43 :THX:

Benutzeravatar
Par@noid
Beiträge: 244
Registriert: 09.11.2005 13:33:35
Lizenz eigener Beiträge: GNU Free Documentation License
Wohnort: Schwarzwald

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

Beitrag von Par@noid » 28.01.2018 18:05:02

Hab momentan kernel 4.15.0-amd64 installiert zum testen und leider bringt immer noch das gleiche Ergebnis :
Checking for vulnerabilities against running kernel Linux 4.15.0-rc8-amd64 #1 SMP Debian 4.15~rc8-1~exp1 (2018-01-15) x86_64
CPU is Intel(R) Core(TM) i5-7600K CPU @ 3.80GHz

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Checking whether we're safe 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'
* Checking whether we're safe according to the /sys interface: NO (kernel confirms your system is vulnerable)
> STATUS: VULNERABLE (Vulnerable: Minimal generic ASM retpoline)

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Checking whether we're safe according to the /sys interface: YES (kernel confirms that the mitigation is active)
> STATUS: NOT VULNERABLE (Mitigation: PTI)

MfG Par@noid
Man hilft den Menschen nicht, wenn man für sie tut, was sie selbst tun können .....

Debian GNU/Linux Bookworm/sid 64-bit| GNOME Version 43 :THX:

Benutzeravatar
ingo2
Beiträge: 1124
Registriert: 06.12.2007 18:25:36
Lizenz eigener Beiträge: GNU Free Documentation License
Wohnort: Wo der gute Riesling wächst

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

Beitrag von ingo2 » 28.01.2018 18:56:23

Womit wurde denn der Kernel kompiliert?

Momentan hat nur gcc8 die retpoline-patches, wird aber auf gcc7 zurückportiert und ist in 7.3 enthalten.
Ob Stretch je in den Genuß kommt? Für gcc6 hat noch niemand mit Backports begonnen.

NAB
Beiträge: 5501
Registriert: 06.03.2011 16:02:23
Lizenz eigener Beiträge: MIT Lizenz

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

Beitrag von NAB » 28.01.2018 20:45:48

Wenn ich das richtig verstanden habe, reicht ein Compiler mit Retpoline-Patches nicht. Der Kernel muss Retpoline auch nutzen.
Und das geht auch nur bis Haswell. Ab Skylake braucht's auch noch neuen Microcode.
Never change a broken system. It could be worse afterwards.

"No computer system can be absolutely secure." Intel Document Number: 336983-001

Benutzeravatar
hikaru
Moderator
Beiträge: 13559
Registriert: 09.04.2008 12:48:59

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

Beitrag von hikaru » 29.01.2018 10:31:15

NAB hat geschrieben: ↑ zum Beitrag ↑
26.01.2018 15:56:45
Mir ist nicht klar, worauf du hier hinaus willst. Ich wollte nur ein anschauliches Beispiel für Kontextwechsel bringen.
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.
NAB hat geschrieben: ↑ zum Beitrag ↑
26.01.2018 15:56:45
Stelle es dir als große Tabelle vor, in der Code-Schnipsel mit einem bedingten Sprung gespeichert werden, und in der letzten Zeile, wohin dieser Sprung das letzte mal geführt hat. Und dazu eine Vergleichseinheit, die den aktuell anliegenden Code mit sämtlichen Tabellenspalten gleichzeitig vergleicht um herauszufinden, wohin der aktuell anliegende Sprung das letzte mal geführt hat. Während der Prozessor nichts zu tun hat, weil er auf das Ergebnis der Bedingung wartet, rechnest du an dieser Stelle schon mal weiter ... auf dem echten Prozessor (du hast ja keinen anderen). Und auf den echten Registern. Dazu wird der Zustand der Register vorher gesichert (Backup). Wenn der Prozessor später herausbekommt, dass die Sprungvorhersage Blödsinn erzählt hat, dann stellt er den alten Zustand wieder her (Backup wird wieder eingespielt) und bessert die Tabelle der Sprungvorhersage nach. Dann ärgert er sich kurz, richtet sein Krönchen und macht weiter im Text.
Soweit ist mir die Sache klar, das sagt aber nur etwas darüber aus, was die Sprungvorhersage macht, nicht was sie ist.
NAB hat geschrieben: ↑ zum Beitrag ↑
26.01.2018 15:56:45
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.
NAB hat geschrieben: ↑ zum Beitrag ↑
26.01.2018 15:56:45
Was du da beschreibst, ist eine "Pipeline".
Ja.
NAB hat geschrieben: ↑ zum Beitrag ↑
26.01.2018 15:56:45
Danach haben sie "superskalar" erfunden. Und dann dachten sie sich, hey, wenn wir eh schon mehrere Befehle gleichzeitig ausführen können, dann fehlt nicht mehr viel und wir können so tun als seien wir mehrere Prozessoren. Das ist ein zusätzlicher echter Kern, echte Hardware, keine "virtuelle". Naja, es ist der Rumpf eines Kernes, bestehend aus eigener Befehlspipeline und eigenen Registern. Die restliche Ausführungslogik teilt er sich mit dem anderen Kern. Also ist es doch kein echter Kern, wie wollen wir es nennen? So'n bisschen Kern? HT-Kern? Simultaneous-Mulitithreading-Doppel-Kern? Egal. Im Kontext wäre interessant, welche Teile der Sprungvorhersage die beiden sich teilen, und das weiß ich nicht. Muss ich auch nicht wissen. Das ist Intels Problem, wie sie das zurechtbiegen.
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.
Ein wichtiger Punkt ist z.B., dass zwei HT-Siblings sich eine Pipeline teilen. Deshalb ist auch mein Autovergleich (im Rahmen der üblichen Untauglichkeit solcher Vergleiche) passend, weil eben nicht einfach davon ausgegangen werden kann, dass zwei Siblings tatsächlich voneinander getrennte Register benutzen. Zumindest kann ich das mit meinem derzeitigen Wissensstand nicht, denn ich weiß nicht welche Register repliziert, welche partitioniert und welche geteilt werden.
NAB hat geschrieben: ↑ zum Beitrag ↑
26.01.2018 15:56:45
Du willst gar nicht verhindern, dass die Prozesse umherhüpfen.
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.
NAB hat geschrieben: ↑ zum Beitrag ↑
26.01.2018 15:56:45
Man könnte einfach eine Sprungvorhersagetabelle pro Prozess einführen, das wäre eine "complete barrier for branch prediction".
Das hilft mMn nicht weiter, so lange diese Prozesse sich weiterhin die selben Cache-Register teilen, denn damit bleiben Zeitmessungen weiterhin möglich. Und jedem Prozess seine eigenen physischen Register zu geben halte ich für praktisch unmöglich, wenn man bedenkt, dass Prozesse in die Zehntausender gehen können.
NAB hat geschrieben: ↑ zum Beitrag ↑
26.01.2018 15:56:45
P.S.: Da taucht doch grad wieder Meltdown auf meinem Radar auf:
https://security-tracker.debian.org/tra ... -2017-5754
Zumindest der proprietäre Nvidia-Grafiktreiber scheint auch betroffen zu sein. Wie mag es mit anderen proprietären oder Kernel-fremden Treibern stehen?
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.

Benutzeravatar
MSfree
Beiträge: 10686
Registriert: 25.09.2007 19:59:30

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

Beitrag von MSfree » 29.01.2018 11:19:58

hikaru hat geschrieben: ↑ zum Beitrag ↑
29.01.2018 10:31:15
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.
Der L1-Caches ist immer einem bestimmten CPU-Kern zugeordnet und kann von einem zweiten Prozeß, der auf einem anderen Kern läuft, nicht gelesen werden.

Beim L2-Cache sind oft 2 Kerne einem L2-Block zugeordnet. Zwei Prozesse könnten sich also gegenseitig in die Karten schauen, wenn sie auf zwei Kernen laufen, die den selben Cache-Block verwenden.

Der L3-Cache ist für alle Kerne zugänglich und somit potentiell das schwächste Glied. Allerdings werden vom L3 nur Daten geholt, wenn sie nicht schon im L2 liegen.

Die Frage ist hier also, wie gezielt ein bestimmter Schadprozeß sich auf einen CPU-Kern lagern kann, um Daten abzugreifen, die im L2 des Partnerkerns liegen. Eigentlich sollte ja der Betriebssystemkern die Zuteilung der CPU-Kerne regeln.

Benutzeravatar
hikaru
Moderator
Beiträge: 13559
Registriert: 09.04.2008 12:48:59

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

Beitrag von hikaru » 29.01.2018 11:27:48

MSfree hat geschrieben: ↑ zum Beitrag ↑
29.01.2018 11:19:58
Der L1-Caches ist immer einem bestimmten CPU-Kern zugeordnet und kann von einem zweiten Prozeß, der auf einem anderen Kern läuft, nicht gelesen werden.
Gilt das auch für HT-Siblings?

Benutzeravatar
ingo2
Beiträge: 1124
Registriert: 06.12.2007 18:25:36
Lizenz eigener Beiträge: GNU Free Documentation License
Wohnort: Wo der gute Riesling wächst

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

Beitrag von ingo2 » 29.01.2018 12:02:12

Hier mal ganz neue Töne von Intel im Interview mit Tom's Hardware:
http://www.tomshardware.com/news/intel- ... 36405.html
Krzanich later said the company would begin to ship products with "in-silicon" fixes for the vulnerabilities this year.
Da bin ich mal mächtig gespannt, ob das wahr wird?

Benutzeravatar
MSfree
Beiträge: 10686
Registriert: 25.09.2007 19:59:30

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

Beitrag von MSfree » 29.01.2018 12:06:28

hikaru hat geschrieben: ↑ zum Beitrag ↑
29.01.2018 11:27:48
Gilt das auch für HT-Siblings?
Oha, da hast du mich erwischt. :facepalm:

Prinzipiell könnte natürlich ein Prozeß via HT auf dem selben Kern laufen wie der, den du angreifen willst, hätte also auch Zugriff auf den selben L1.

Die CPU-Designer haben auf jeden Fall nun einiges an Hausaufgaben zu machen, um solche Fälle gegeneinander abzudichten.

Hauptspeicherverschlüsselung ist jedenfalls keine Lösung. Wenn man die Verschlüsselung bis in den L1 hinein zieht, muß vor jedem L1-Zugriff der Inhalt entschlüsselt werden, was viel zu langsam wäre.

Meinem Verständnis nach müßte man den Speicherschutz, der verhindert, daß fremde Prozesse auf Datenbereiche zugreifen können, die ihnen nicht gehören, bis in den L1 führen. Dann dürfte meinem Verständnis nach auch ein HT-Sibling nicht unerlaubt auf Speicherbereiche eines anderen Prozesses zugreifen

dufty2
Beiträge: 1709
Registriert: 22.12.2013 16:41:16

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

Beitrag von dufty2 » 29.01.2018 15:58:29

ingo2 hat geschrieben: ↑ zum Beitrag ↑
28.01.2018 18:56:23
Womit wurde denn der Kernel kompiliert?

Momentan hat nur gcc8 die retpoline-patches, wird aber auf gcc7 zurückportiert und ist in 7.3 enthalten.
Ob Stretch je in den Genuß kommt? Für gcc6 hat noch niemand mit Backports begonnen.
Falls ich es richtig ge-grep-t habe:

Code: Alles auswählen

# strings /boot/vmlinuz-4.15.0-rc8-amd64 | grep gcc
4.15.0-rc8-amd64 (debian-kernel@lists.debian.org) (gcc version 7.2.0 (Debian 7.2.0-19)) #1 SMP Debian 4.15~rc8-1~exp1 (2018-01-15)
gcc 7.3 ist seit ein paar Tagen bereits in sid,
weiss aber nicht, ab wann dann auch die Pakete damit kompiliert werden.

Benutzeravatar
ingo2
Beiträge: 1124
Registriert: 06.12.2007 18:25:36
Lizenz eigener Beiträge: GNU Free Documentation License
Wohnort: Wo der gute Riesling wächst

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

Beitrag von ingo2 » 29.01.2018 16:32:32

dufty2 hat geschrieben: ↑ zum Beitrag ↑
29.01.2018 15:58:29
gcc 7.3 ist seit ein paar Tagen bereits in sid,
weiss aber nicht, ab wann dann auch die Pakete damit kompiliert werden.
Also, noch etwas Geduld, dann weden bestimmt auch die retpoline-Funktionen in den Kernel Einzug halten.
Und mit Glück gibt's dann einen Backport-Kernel damit - ich weiß allerdings nicht, ob das in Stretch dann mit unterschiedlichen Kompilerversionen rund läuft?

Benutzeravatar
Par@noid
Beiträge: 244
Registriert: 09.11.2005 13:33:35
Lizenz eigener Beiträge: GNU Free Documentation License
Wohnort: Schwarzwald

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

Beitrag von Par@noid » 29.01.2018 17:03:50

ingo2 hat geschrieben: ↑ zum Beitrag ↑
29.01.2018 16:32:32
dufty2 hat geschrieben: ↑ zum Beitrag ↑
29.01.2018 15:58:29
gcc 7.3 ist seit ein paar Tagen bereits in sid,
weiss aber nicht, ab wann dann auch die Pakete damit kompiliert werden.
Also, noch etwas Geduld, dann weden bestimmt auch die retpoline-Funktionen in den Kernel Einzug halten.
Und mit Glück gibt's dann einen Backport-Kernel damit - ich weiß allerdings nicht, ob das in Stretch dann mit unterschiedlichen Kompilerversionen rund läuft?
GCC 7.3 mit Retpoline-Patches erschienen

Nachdem vor rund zwei Wochen Retpoline-Unterstützung zunächst im Code für GCC 8 landete, ist nun der erwartete Backport in GCC 7.3 erschienen.

https://www.pro-linux.de/news/1/25542/g ... ienen.html

MfG Par@noid
Man hilft den Menschen nicht, wenn man für sie tut, was sie selbst tun können .....

Debian GNU/Linux Bookworm/sid 64-bit| GNOME Version 43 :THX:

Benutzeravatar
towo
Beiträge: 4403
Registriert: 27.02.2007 19:49:44
Lizenz eigener Beiträge: GNU Free Documentation License

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

Beitrag von towo » 29.01.2018 17:31:50

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
Beiträge: 5501
Registriert: 06.03.2011 16:02:23
Lizenz eigener Beiträge: MIT Lizenz

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

Beitrag von NAB » 29.01.2018 17:45:19

hikaru hat geschrieben: ↑ zum Beitrag ↑
29.01.2018 10:31:15
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?
hikaru hat geschrieben: ↑ zum Beitrag ↑
29.01.2018 10:31:15
NAB hat geschrieben: ↑ zum Beitrag ↑
26.01.2018 15:56:45
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.
hikaru hat geschrieben: ↑ zum Beitrag ↑
29.01.2018 10:31:15
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?)
hikaru hat geschrieben: ↑ zum Beitrag ↑
29.01.2018 10:31:15
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.
hikaru hat geschrieben: ↑ zum Beitrag ↑
29.01.2018 10:31:15
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 ...
hikaru hat geschrieben: ↑ zum Beitrag ↑
29.01.2018 10:31:15
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.)
hikaru hat geschrieben: ↑ zum Beitrag ↑
29.01.2018 10:31:15
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".
Never change a broken system. It could be worse afterwards.

"No computer system can be absolutely secure." Intel Document Number: 336983-001

Benutzeravatar
hikaru
Moderator
Beiträge: 13559
Registriert: 09.04.2008 12:48:59

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

Beitrag von hikaru » 30.01.2018 13:11:30

NAB hat geschrieben: ↑ zum Beitrag ↑
29.01.2018 17:45:19
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.
NAB hat geschrieben: ↑ zum Beitrag ↑
29.01.2018 17:45:19
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.
NAB hat geschrieben: ↑ zum Beitrag ↑
29.01.2018 17:45:19
hikaru hat geschrieben: ↑ zum Beitrag ↑
29.01.2018 10:31:15
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.
NAB hat geschrieben: ↑ zum Beitrag ↑
29.01.2018 17:45:19
(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.
NAB hat geschrieben: ↑ zum Beitrag ↑
29.01.2018 17:45:19
hikaru hat geschrieben: ↑ zum Beitrag ↑
29.01.2018 10:31:15
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?
NAB hat geschrieben: ↑ zum Beitrag ↑
29.01.2018 17:45:19
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
Beiträge: 5501
Registriert: 06.03.2011 16:02:23
Lizenz eigener Beiträge: MIT Lizenz

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

Beitrag von NAB » 30.01.2018 23:23:57

hikaru hat geschrieben: ↑ zum Beitrag ↑
30.01.2018 13:11:30
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.
hikaru hat geschrieben: ↑ zum Beitrag ↑
30.01.2018 13:11:30
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.
hikaru hat geschrieben: ↑ zum Beitrag ↑
30.01.2018 13:11:30
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.
hikaru hat geschrieben: ↑ zum Beitrag ↑
30.01.2018 13:11:30
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".
hikaru hat geschrieben: ↑ zum Beitrag ↑
30.01.2018 13:11:30
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.
hikaru hat geschrieben: ↑ zum Beitrag ↑
30.01.2018 13:11:30
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
Never change a broken system. It could be worse afterwards.

"No computer system can be absolutely secure." Intel Document Number: 336983-001

Benutzeravatar
hikaru
Moderator
Beiträge: 13559
Registriert: 09.04.2008 12:48:59

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

Beitrag von hikaru » 31.01.2018 18:24:10

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.
NAB hat geschrieben: ↑ zum Beitrag ↑
30.01.2018 23:23:57
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.
NAB hat geschrieben: ↑ zum Beitrag ↑
30.01.2018 23:23:57
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!
NAB hat geschrieben: ↑ zum Beitrag ↑
30.01.2018 23:23:57
hikaru hat geschrieben: ↑ zum Beitrag ↑
30.01.2018 13:11:30
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
Beiträge: 5501
Registriert: 06.03.2011 16:02:23
Lizenz eigener Beiträge: MIT Lizenz

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

Beitrag von NAB » 31.01.2018 19:33:20

hikaru hat geschrieben: ↑ zum Beitrag ↑
31.01.2018 18:24:10
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.
hikaru hat geschrieben: ↑ zum Beitrag ↑
31.01.2018 18:24:10
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.
hikaru hat geschrieben: ↑ zum Beitrag ↑
31.01.2018 18:24:10
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.
hikaru hat geschrieben: ↑ zum Beitrag ↑
31.01.2018 18:24:10
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.
Never change a broken system. It could be worse afterwards.

"No computer system can be absolutely secure." Intel Document Number: 336983-001

dufty2
Beiträge: 1709
Registriert: 22.12.2013 16:41:16

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

Beitrag von dufty2 » 05.02.2018 15:34:57

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
Beiträge: 943
Registriert: 08.07.2007 17:36:57

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

Beitrag von clue » 09.02.2018 12:53:11

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.
Offenbarung 13 erfüllt sich gerade vor unseren Augen, genießen wir also die letzten Jahre unserer Scheinfreiheit

Nice
Beiträge: 416
Registriert: 14.06.2017 19:36:20

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

Beitrag von Nice » 09.02.2018 13:06:27

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

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

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

NAB
Beiträge: 5501
Registriert: 06.03.2011 16:02:23
Lizenz eigener Beiträge: MIT Lizenz

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

Beitrag von NAB » 09.02.2018 17:07:21

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>
Never change a broken system. It could be worse afterwards.

"No computer system can be absolutely secure." Intel Document Number: 336983-001

Antworten