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

[dufty2]

Die beiden Ansätze die du ansprichst helfen nur gegen Spectre Variante 2 (branch target injection: CVE-2017-5715), nicht gegen Variante 1 (bounds check bypass: CVE-2017-5753).

Yep, einfach mal das script-chen laufen lassen und schon ist mensch schlauer:

Code: Alles auswählen

# sh spectre-meltdown-checker.sh 
Spectre and Meltdown mitigation detection tool v0.27

Checking for vulnerabilities against live running kernel Linux 4.14.0-3-amd64 #1 SMP Debian 4.14.12-2 (2018-01-06) x86_64

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Checking count of LFENCE opcodes in kernel:  NO 
> STATUS:  VULNERABLE  (only 23 opcodes found, should be >= 70, heuristic to be improved when official patches become available)

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigation 1
*   Hardware (CPU microcode) support for mitigation:  NO 
*   Kernel support for IBRS:  NO 
*   IBRS enabled for Kernel space:  NO 
*   IBRS enabled for User space:  NO 
* Mitigation 2
*   Kernel compiled with retpoline option:  NO 
*   Kernel compiled with a retpoline-aware compiler:  NO 
> STATUS:  VULNERABLE  (IBRS hardware + kernel support OR kernel with retpoline are needed to mitigate the vulnerability)

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Kernel supports Page Table Isolation (PTI):  YES 
* PTI enabled and active:  YES 
> STATUS:  NOT VULNERABLE  (PTI mitigates the vulnerability)

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

Na ja, für einen Atom N450 passt's wohl auch nicht ganz, aber was soll's

[NAB]

Und diese Verträge sind so langanhaltend, dass Supermicro mit einem Prozess durchkäme, bevor ihre Verträge mit Intel über Nehalem auslaufen?
Anders sehe ich da nämlich keine Chance für Supermicro, denn die wären in dem Duell ganz klar der David.

Höm? In interne Verträge von Supermicro habe ich natürlich keinen Einblick, aber immerhin steht da "awaiting" und nicht "EOL". Aus irgendeinem Grund wollen sie also Support leisten und ich vermute keine philanthropischen Beweggründe. Und aus dem David kann schnell ein Goliath werden, wenn andere Firmen ihre Schäden bei Supermicro geltend machen und Supermicro diese an Intel weiterzureichen versucht ...

Die beiden Ansätze die du ansprichst helfen nur gegen Spectre Variante 2 (branch target injection: CVE-2017-5715), nicht gegen Variante 1 (bounds check bypass: CVE-2017-5753).
Variante 1 und 2 müssen auf verwundbarer Hardware in JEDEM Stück Software an JEDER potenziell gefährlichen Stelle behandelt werden. Genau das habe ich früher im Thread als Sisyphosarbeit bezeichnet und spätestens wenn da Begriffe wie "legacy" und "proprietär" in's Spiel kommen, dann sind wir uns wohl beide darüber einig, wie die Erfolgsaussichten sind.

Höm? Ich sprach einzig und alleine von den Chancen, ältere Prozessoren doch noch irgendwann wieder sicher betreiben zu können, also von der Hardware ... so als Kontrastprogramm zum "Möh, alles älter als Haswell muss in die Mülltonne". Nun kommst du mit der Software.

Ja, dass die Software an Spectre angepasst werden muss ist mir bekannt. Schlimm genug und blöd genug, ja. Ob das wirklich manuelle "Sisyphosarbeit" sein muss oder sich irgendwie automatisieren lässt, eventuell sogar bei proprietären Softwareschinken, das kann wohl im Moment noch niemand abschätzen. Aber ich wollte Spectre sicherlich nicht kleinreden.

[nudgegoonies]

Ich hatte es so verstanden, dass Intel nur CPUs der letzten 5 Jahre patched. Jetzt habe ich habe mir folgende Debianpakete mit den Microcodes von oldoldstable bis experimental für die Intel CPUs angesehen:

Code: Alles auswählen

intel-microcode_1.20150121.1
intel-microcode_3.20161104.1
intel-microcode_3.20170511.1
intel-microcode_3.20170707.1
intel-microcode_3.20171117.1
intel-microcode_3.20180108.1

Ich habe einen Q6600. Laut /proc/cpuinfo ist das family 6, model 15, stepping 11. In HEX also 06,0f,0b. Die Datei für meine CPU heißt also:

Code: Alles auswählen

/lib/firmware/intel-ucode/06-0f-0b

Alle Microcodes vor 2018 waren identisch:

Code: Alles auswählen

md5sum 06-0f-0b 
e19ab5b0f342fa6d14d3a48866eac6ed  06-0f-0b

Aber der von 8. Januar 2018:

Code: Alles auswählen

md5sum 06-0f-0b 
c2c4623aee49a3c35c39f66d01152098  06-0f-0b

Geschehen also doch noch Wunder, dass Intel eine 10 Jahre alte CPU patched? Ausprobiert habe ich das Paket noch nicht. Wenn, dann könnte ich über /proc/cpuinfo ja den Microcode Stand überprüfen. Vielleicht sollte ich damit aber auch warten, bis es wirklich in Stretch oder den Stretch Backports erscheint. Und wer weiß was noch kommt:
https://www.heise.de/newsticker/meldung ... 40326.html

[NAB]

https://www.heise.de/newsticker/meldung ... 40326.html

Ach du Scheiße ...

Hier übrigens die Originalaussage von Intel zu älteren Prozessoren:
https://newsroom.intel.com/news-release ... st-pledge/
"... as prioritized by our customers." ... so so. Wo darf man abstimmen?

AMD rührt sich inzwischen übrigens auch:
https://www.amd.com/en/corporate/speculative-execution
Da werden die Microcode Updates als "optional" bezeichnet weil sie wissen noch nicht so genau. Aber es sollen welche kommen.

[dufty2]

Ich habe einen Q6600. Laut /proc/cpuinfo ist das family 6, model 15, stepping 11. In HEX also 06,0f,0b. Die Datei für meine CPU heißt also:

Code: Alles auswählen

/lib/firmware/intel-ucode/06-0f-0b

Mmmh, also im source-file von Intel hat das ne andere md5sum:

Code: Alles auswählen

$ md5sum intel-ucode/06-0f-0b
4518fa18328a5c79ba6263ecd741b2c1  intel-ucode/06-0f-0b

Scheinbar wird das nochmals umgemodelt im .deb-file.

Falls ich es jetzt richtig interpretiert habe:

Code: Alles auswählen

$ grep 006fb changelog 
    sig 0x000006fb, pf_mask 0x20, 2010-10-03, rev 0x00ba, size 4096
    sig 0x000006fb, pf_mask 0x01, 2010-10-03, rev 0x00ba, size 4096
    sig 0x000006fb, pf_mask 0x04, 2010-10-03, rev 0x00bc, size 4096
    sig 0x000006fb, pf_mask 0x08, 2010-10-03, rev 0x00bb, size 4096
    sig 0x000006fb, pf_mask 0x10, 2010-10-03, rev 0x00ba, size 4096
    sig 0x000006fb, pf_mask 0x40, 2010-10-03, rev 0x00bc, size 4096
    sig 0x000006fb, pf_mask 0x80, 2010-10-03, rev 0x00ba, size 4096
    sig 0x000006fb, pf_mask 0x04, 2009-05-11, rev 0x00b9, size 4096
    sig 0x000006fb, pf_mask 0x08, 2009-04-28, rev 0x00b8, size 4096
    sig 0x000006fb, pf_mask 0x40, 2009-05-11, rev 0x00b9, size 4096
    sig 0x000006fb, pf_mask 0x80, 2007-07-13, rev 0x00b6, size 4096
    sig 0x000006fb, pf_mask 0x01, 2007-07-13, rev 0x00b6, size 4096
    sig 0x000006fb, pf_mask 0x04, 2007-08-06, rev 0x00b7, size 4096
    sig 0x000006fb, pf_mask 0x08, 2007-07-13, rev 0x00b6, size 4096
    sig 0x000006fb, pf_mask 0x10, 2007-07-13, rev 0x00b6, size 4096
    sig 0x000006fb, pf_mask 0x40, 2007-08-06, rev 0x00b7, size 4096

das scheint mir für einen Q6600 'ne passable history zu sein.
Da ist kein Update für 2018 zu sehen.

Kannst ja mal
# dmesg | grep microcode
posten

[nudgegoonies]

Ich habe das neue Paket jetzt mal ausprobiert. Was auch immer sich am File geändert hat, die Microcode Version, die /proc/cpuinfo meldet ist gleich geblieben. Vielleicht nur anders signiert?

P.S.
Hier wird diskutiert, ob die Regression die Probleme verursacht bei Linux gar nicht auftreten kann: https://bugs.debian.org/cgi-bin/bugrepo ... bug=886998

[dufty2]

Ich habe das neue Paket jetzt mal ausprobiert. Was auch immer sich am File geändert hat, die Microcode Version, die /proc/cpuinfo meldet ist gleich geblieben. Vielleicht nur anders signiert?

Wäre ganz nett, wenn Du die Ausgabe von

Code: Alles auswählen

# dmesg | grep microcode

posten würdest, Dann könnte man sehen, ob mein Signaturgerate (sig 0x000006fb) richtig war (oder nicht.) und wann das letzte microcode-update erfolgt ist (2010-10-03).

Hier wird diskutiert, ob die Regression die Probleme verursacht bei Linux gar nicht auftreten kann: https://bugs.debian.org/cgi-bin/bugrepo ... bug=886998

Der neue sid-Kernel (4.14.12-2) verursacht auf jeden Fall Probleme, deswegen ist er auch bis jetzt noch nicht in testing gelandet,
vgl. auch https://tracker.debian.org/pkg/linux

[Ellison]

@Ellison:
Da die 100Hz den 10ms in Kernel 2.4 entsprechen, kannst du dir den Sarge-Test eigentlich sparen. Was der Sempron mit aktuellem Kernel zum Thema Spectre sagt, wäre vielleicht trotzdem interessant.

Hätte ich gerne gestern abend ausgiebig testen wollen, aber der Rechner verweigert seinen Dienst. Stand wohl zu lange auf dem Dachboden herum. Zuckt nicht mal. Das Netzteil funktioniert. Geht dann eben zum E-Schrott.

[dufty2]

So, sid hat jetzt den 4.14.13-1 und damit heisst es nicht mehr "cpu_insecure", sondern

Code: Alles auswählen

$ cat /proc/cpuinfo | grep -m 1 bugs
bugs		: cpu_meltdown

Lt. dem Phoronix-Artikel [1] soll in 4.14.14 dann "Retpoline" (für Spectre Variant 2) landen.
Da sind wir mal gespannt
Vgl. auch https://git.kernel.org/pub/scm/linux/ke ... nux-4.14.y

[1] https://www.phoronix.com/scan.php?page= ... -Retpoline

[ingo2]

Sieht so aus, als wenn Intel auch versucht hätte, die Firmware von Sandy-Bridge un Ivy-Bridge zu patchen. Offenbar gibt es aber dann Probleme mit häufigeren Reboots:
https://www.reuters.com/article/us-cybe ... SKBN1F7087
Da werden wohl wegen Fehlern NMI's vom Watchdog ausgelöst.

Wenn man das mal etwas überdenkt, könnte es doch sein, daß die angeblichen Firmware-Fehler bewußt eingeführt wurden, um die Stabilität der CPU's zu gewährleisten - d.h. indirekt einen Designfehler zu kaschieren. Oder eine höhere Taktfrequenz stabil zu erzielen, oder? Später hat man dann gemerkt, daß das Ganze einen Geschwindigfkeitsvorteil bringt und es dann so belassen hat?

EDIT:
Hier noch ein Link zum Thema:
http://www.zdnet.de/88323551/intel-rebo ... c45b8b479d

[NAB]

Wenn man das mal etwas überdenkt, könnte es doch sein, daß die angeblichen Firmware-Fehler bewußt eingeführt wurden, um die Stabilität der CPU's zu gewährleisten - d.h. indirekt einen Designfehler zu kaschieren. Oder eine höhere Taktfrequenz stabil zu erzielen, oder? Später hat man dann gemerkt, daß das Ganze einen Geschwindigfkeitsvorteil bringt und es dann so belassen hat?

Das geht in der Presse immer wieder durcheinander, aber die Microcode-Patches dienen vorallem dazu "Spectre" zu beheben. "Meltdown" lässt sich rein in Software patchen.

Da Specte nun so ziemlich alle Hersteller betrifft, glaube ich nicht an eine "bewusste Einführung". Dazu hätten sich alle Hersteller verschwören müssen. Der Wettbewerbsvorteil für AMD oder ARM wäre gewaltig gewesen ... "Hey, Intel ist schneller ... aber bei uns kriegt ihr die sicheren CPUs!"

[towo]

https://www.deskmodder.de/blog/2018/01/ ... -meltdown/

[towo]

Da antworte ich mir mal selbst, ist ein Hoax.

https://react-etc.net/entry/skyfall-and ... rabilities

[ingo2]

Da Specte nun so ziemlich alle Hersteller betrifft, glaube ich nicht an eine "bewusste Einführung".

Nur bei Intel (und einigen ARM-CPUs, so glaube ich mich zu erinnern) ist es möglich, aus der gewonnenen Information eine "privilege escalation" zu erreichen - und da ist AMD definitiv außen vor.

[NAB]

Nur bei Intel (und einigen ARM-CPUs, so glaube ich mich zu erinnern) ist es möglich, aus der gewonnenen Information eine "privilege escalation" zu erreichen - und da ist AMD definitiv außen vor.

AMD sieht das nicht so "definitiv":
viewtopic.php?f=37&t=168134&start=210#p1160470

[hikaru]

Wenn man das mal etwas überdenkt, könnte es doch sein, daß die angeblichen Firmware-Fehler bewußt eingeführt wurden, um die Stabilität der CPU's zu gewährleisten - d.h. indirekt einen Designfehler zu kaschieren. Oder eine höhere Taktfrequenz stabil zu erzielen, oder? Später hat man dann gemerkt, daß das Ganze einen Geschwindigfkeitsvorteil bringt und es dann so belassen hat?

Das glaube ich nicht.
Ohne mich auf irgendeine Quelle stützen zu können vermute ich das Problem im Zusammenspiel der gepatchten CPUs mit Intels Management Engine. Intel-Systeme haben einen Watchdog, der eine Signatur der ME überprüft und wenn deren Richtigkeit nicht bestätigt werden kann, dann wird das System vom Watchdog automatisch nach einer halben Stunde ausgeschaltet (oder rebootet?). Deshalb konnten die Entwickler des ME-Cleaners die ME auch nicht vollständig entfernen, sondern lediglich so weit entkernen, dass sie zumindest dem Watchdog noch die Signatur bestätigen kann.
Ob die Signatur nach jedem Boot nur einmal bestätigt wird oder ob das immer wieder geschieht weiß ich nicht. Falls Letzteres der Fall ist, dann könnte ich mir vorstellen, dass die Microcode-Updates das CPU-Verhalten derart ändern, dass die Signaturbestätigung nicht mehr zuverlässig funktioniert, was in der Folge zu scheinbar zufälligen Reboots führen könnte.

Lose im Zuammenhang damit würde mich interessieren, ob es möglicherweise Wechselwirkungen zwischen den Microcode-Updates und dem ME-Cleaner geben könnte.

Unabhängig von diesen Vermutungen fixen (lösen) die Microcode-Updates auch keine Firmware-Fehler, sondern sie sollen Hardwarefehler behandeln (abschwächen).
Wenn man das mal auf medizinische Begriffe ummünzt, dann leiden die betroffenen CPUs an einer (absichtlich oder zumindest fahrlässig beigefügten) Behinderung, die es ihnen verwährt, sicher ihren alltäglichen Aufgaben nachzugehen. All die Gegenmaßnahmen (KPTI, Retpoline, Microcodes) sind keine Heilung für die Behinderung selbst, sondern Versuche, die Symptome der Behinderung in den Griff zu bekommen (Prothesen, Medikamente, etc.).

[ingo2]

Oha,
jetzt hat Intel sein Microcode Update 3.20180108.1 gegen Spectre2 wieder zurückgezogen - offenbar wegen der Reboots.

Das Changelog dazu sagt:

intel-microcode (3.20180108.1+really20171117.1) unstable; urgency=critical

* Revert to release 20171117, as per Intel instructions issued to
the public in 2018-01-22 (closes: #886998)
* This effectively removes IBRS/IBPB/STIPB microcode support for
Spectre variant 2 mitigation.

-- Henrique de Moraes Holschuh <email address hidden> Mon, 22 Jan 2018 23:01:59 -0200

und die Aussage vom Maintainer dazu:
https://mail-archive.com/debian-bugs-di ... 78175.html

Und Debian schmeißt das wieder aus Testing raus!

Bei der Gelegenheit mal eine Frage:
Speichert die CPU etwa die Firmware in einem, nichtflüchtigen Speicher?
Nur dann macht eigentlich das Verfahren von Debian mit der Bezeichnung 3.20180108.1+really20171117.1 für den Downgrade wirklich Sinn?

[towo]

Speichert die CPU etwa die Firmware in einem, nichtflüchtigen Speicher?

Nein, die wird gar nicht gespeichert, sondern zu einem frühen zeitpunkt geladen.

Nur dann macht eigentlich das Verfahren von Debian mit der Bezeichnung 3.20180108.1+really20171117.1 für den Downgrade wirklich Sinn?

Ja, viele anderen Möglichkeiten der Versionierung gibts hier nicht.

[NAB]

"Downgrades" sind bei Debian nicht wirklich vorgesehen, darum muss der Downgrade als Upgrade verpackt werden.

Die Microcodes alleine helfen aber eh nicht, solange die Kernelpatches nicht fertig sind. Und da geht's grad hoch her:
Englisch:
https://www.theregister.co.uk/2018/01/2 ... fix_linux/
Deutsch:
https://www.computerbase.de/2018-01/lin ... h-garbage/

(Heise hat leider mal wieder keinen Durchblick)

Und wenn ich das richtig sehe, sind sämtliche Gegenmaßnahmen gegen Spectre im Kernel bisher darauf ausgerichtet, eine "privilege escalation" zu verhindern, also dass User-Code in den Kernel-Speicher gucken kann. Nach meinem Verständnis ist Spectre selber danach weiterhin sperrangelweit offen.

Edit:
Inzwischen sehe ich das hoffentlich noch richtiger, nachdem ich mir den Beitrag des Intel-Entwicklers durchgelesen habe:
http://lkml.iu.edu/hypermail/linux/kern ... 05282.html

One new feature (IBPB) is a complete barrier for branch prediction.
After frobbing this, no branch targets learned earlier are going to be
used. It's kind of expensive (order of magnitude ~4000 cycles).

Even with IBRS, the CPU cannot tell the difference between different
userspace processes, and between different VM guests. So in addition to
IBRS to protect the kernel, we need the full IBPB barrier on context
switch and vmexit. And maybe STIBP while they're running.

Ich verstehe das so, dass IBPB bei jedem Wechsel zwischen zwei Prozessen die Sprungvorhersage leerputzt und damit einen Spectre-Angriff eines Prozesses auf einen anderen auch im Userspace unmöglich macht.

Nun müsste es nur noch funktionieren ... also ohne dass die Prozessoren dabei abstürzen.

Damit bliebe nur noch, dass ein Prozess sich selber angreift, also das bekannte Javascript-im-Browser-Beispiel. Ob ein Prozess auch intern IBPB einsetzen könnte, um die Sprungvorhersage zu putzen, ist mir unklar.

Übrigens:

The new microcode from Intel and AMD adds three new features.

Er geht davon aus, dass AMD und Intel hier die gleichen Microcode-Änderungen bringen ... scheinen also beide gleich betroffen zu sein.

[hikaru]

Ich verstehe das so, dass IBPB bei jedem Wechsel zwischen zwei Prozessen die Sprungvorhersage leerputzt und damit einen Spectre-Angriff eines Prozesses auf einen anderen auch im Userspace unmöglich macht.

Ich glaube nicht, dass das zuverlässig funktionieren würde. Zusätzlich zur Sprungvorhersage müsste man auch den CPU-Cache löschen (zumindest Teile davon). Das würde wohl auf einer alten CPU funktionieren, die noch kein SMP kann (bis Pentium-3-Single-Core), aber alles was mehrere Kerne (mit Shared Cache) hat oder Hyperthreading kann, kann mehrere Threads oder Prozesse wirklich gleichzeitig ausführen und diese Threads haben Zugriff auf identische Cache-Bereiche (bei HT immer, bei Multicore i.d.R. zumindest im L3-Cache). Von so einem Parallelthread könnte man einen Side-Channel-Angriff auf einen anderen Thread ausführen. Und da hat man keine Chance, den Cache von Thread A zuverlässig zu löschen bevor Thread B auf ihn zugreift.

[ingo2]

Das Durcheinander mit der Interpretation der ganzen Affäre bezüglich Intel und Spectre und den Versuchen, das zu flicken verstehe ich als Nicht-Fachmann mit den 3 CVE's so:

Die Aufteilung erfolgt in den Diskussionen aus Sicht des Angriifsweges. Da erfolgen die Angriffe in Spectre 1 und Spectre 2 auf verschiedenen Wegen über den L3-Cache.

Was den User aber letzlich angeht, ist die Auswirkung auf die betroffenen "Daten".
Bei den anderen CPU-Herstellern (außer Intel) mit OoO-Architektur sind die oben genannten Angriffswege auch möglich. Vielleicht gibt es sogar noch weitere unentdeckte Wege. Allerdings sind da die Angriffe auf die Daten eines einzelnen Threasds beschränkt. Bei Intel dagegen funktioniert die Trennung zwischen Kernelspace und Userspace nicht (privilege escalation) und deshalb sind auf den verschiedenen Angriffswegen auch Kernelfunktionen zugänglich.

Was Intel da probiert mit Firmware-Flicken um den Software-Entwickleren neue Befehle anzudrehen, soll wohl nur von ihrem eigentlichem Problen/Fehler ablenken, da dies nur mit neuem Design zu beheben ist - also "snake oil".
EDIT:
Und dazu gehört dann auch "Meltdown". Auch das ist mit dem Kernel-Patch nicht gefixt, nur gelindert, denn es wird damit nach wie vor noch der für den Prozess erforderliche Teil der Kernel Page Table eingeblendet, nur nicht die komplette.

[NAB]

Ich verstehe das so, dass IBPB bei jedem Wechsel zwischen zwei Prozessen die Sprungvorhersage leerputzt

Ich glaube nicht, dass das zuverlässig funktionieren würde. Zusätzlich zur Sprungvorhersage müsste man auch den CPU-Cache löschen

Also Angriffe auf den CPU-Cache gibt es schon länger, da Mischen die Jungs von der TU Graz auch kräftig mit. Bisher war es aber nicht möglich, da zuverlässig an fremde Daten zu kommen.

Der Trick von Spectre basiert doch gerade darauf, dass die Sprungvorhersage trainiert wird und die Vorhersehbarkeit dieses Trainings genutzt wird, um eben zuverlässig an fremde Daten zu kommen. Wenn man die Sprungvorhersage nun vor jedem Kontextwechsel ent-trainiert, sind wir wieder bei den üblichen Unsicherheiten des CPU-Caches, die seit Jahren bekannt sind.

Das Durcheinander mit der Interpretation der ganzen Affäre bezüglich Intel und Spectre und den Versuchen, das zu flicken verstehe ich als Nicht-Fachmann mit den 3 CVE's so:

Die Aufteilung erfolgt in den Diskussionen aus Sicht des Angriifsweges. Da erfolgen die Angriffe in Spectre 1 und Spectre 2 auf verschiedenen Wegen über den L3-Cache.

Meiner Meinung nach ist das mit den "3 CVE's" ziemlich unglücklich gelaufen. Es gibt kein "Spectre 1" und "Spectre 2".

Die Jungs von der TU Graz haben zwei Angriffsmechanismen veröffentlicht: Meltdown und Spectre. Insbesondere für Spectre zählen sie dabei eine ganze Menge möglicher Angriffswege auf, die sie offensichtlich nicht alle getestet haben. Sie haben vorallem versucht, die Mechanismen zu beschreiben und nicht so genau probiert, was man damit alles anstellen kann. Das sind halt Forscher und "klassische Wissenschaftler". Darauf, dass man mit Spectre eine "privilige escalation" erreichen könnte, sind sie gar nicht gekommen.

Google hingegen hat drei konkrete Angriffe veröffentlicht, wie man eine "privilige escalation" erreichen kann: Variante 1 bis 3. Das sind Varianten von "privilige escalation" und nicht Varianten der Angriffsmechanismen. Zwei davon nutzen den Mechanismus von Spectre, der dritte den Mechanismus von Meltdown.

AMD ist von Spectre übrigens genau so betroffen wie Intel. Nur hört man von AMD fast nichts, während bei Intel langsam durchschimmert, welche (hässlichen) Gegenmaßnahmen bei welcher Prozessorgeneration notwendig wären.

Meltdown hingegen ist eigentlich schon durch. Alle Systeme sind gepatcht, laufen jetzt langsamer ... und wir gehen mal wieder davon aus, dass es jetzt sicher ist, bis wieder jemand das Gegenteil beweist.

[ingo2]

Meltdown hingegen ist eigentlich schon durch. Alle Systeme sind gepatcht, laufen jetzt langsamer ... und wir gehen mal wieder davon aus, dass es jetzt sicher ist, bis wieder jemand das Gegenteil beweist.

Das einzige, was gemacht wurde, ist doch dass nicht mehr der gesamte Adressraum des Kernels dauerhaft im Speicher gehalten wird, sondern nur noch die unbedingt notwendigen Teile/Funktionen, welche die laufenden Anwenduingen jeweils benötigen. Und diese können nach wie vor mit den beschiebenen Techniken mißbraucht werden. Grund ist die in Intel-CPUs fehlende "page table isolation".

Deshalb meine Wertung: notdürftig geflickt, aber nicht gefixt.

[NAB]

Deshalb meine Wertung: notdürftig geflickt, aber nicht gefixt.

Ja, richtig, "fixen" kann Intel das auch nicht, ohne die Prozessoren auszutauschen, sonst hätten sie das längst getan. Was wir jetzt haben, ist ein hässlicher und langsamer Workaround im Kernel. Wie unsicher der ist, muss sich erst zeigen.

[hikaru]

Der Trick von Spectre basiert doch gerade darauf, dass die Sprungvorhersage trainiert wird und die Vorhersehbarkeit dieses Trainings genutzt wird, um eben zuverlässig an fremde Daten zu kommen. Wenn man die Sprungvorhersage nun vor jedem Kontextwechsel ent-trainiert, sind wir wieder bei den üblichen Unsicherheiten des CPU-Caches, die seit Jahren bekannt sind.

Ich glaube der Knackpunkt ist hier das Wort "Kontextwechsel".

Mir scheint, wir haben hier zwei verschiedene Deutungen des Begriffs:
A: Wechsel der CPU zwischen privilegiertem und unprivilegiertem CPU-Modus oder andersrum. Das ist im Wesentlichen das Meltdown-Szenario und sollte (hoffentlich) inzwischen kalter Kaffee sein.
B: Wechsel der CPU zwischen zwei Prozessen, ohne dabei einen Kontextwechel gemäß A durchzuführen. Das wäre die Art von zeitscheibenweisem "Multiprozessing" die schon der 80486 und Vorgänger konnten.

Variante A ist wohl die geläufigere Verwendung des Begriffs, ich glaube aber, du meinst hier Variante B.

Wenn ich das richtig sehe, dann braucht man für einen IBPB-Angriff allerdings auf einem SMP-System weder A noch B.
Dazu folgendes Szenario:
1. Wir sorgen dafür, dass zwei Threads oder Prozesse tatsächlich parallel abgearbeitet werden. Wichtig ist dabei, dass sie sich den selben Cache teilen.
2. Prozess I erzeugt rechtmäßig irgendein Geheimnis (z.B. Passwortabfrage) und legt es im Cache ab.
3. Prozess II erzeugt gleichzeitig ein IBP-Konstrukt, dessen Ergebnis von dem in durch Prozess I verwendeten Cache-Register abhängt (z.B. durch den im Spectre-Paper gezeigten Beispielcode mit dem Array-Überlauf nach einem Fehltraining der EIGENEN Sprungvorhersage).
4. Nun misst Prozess II nach dem bekannten Muster die Zugriffszeit auf eben dieses Geheimnisregister und legt das Ergebnis irgendwo abholbar ab, bevor seine eigene fehlerhafte Sprungvorhersage abgewürgt und enttrainiert wird.

Auf dem ganzen Weg wird nicht ein einziger Kontextwechsel vollzogen, weder nach Variante A noch nach Variante B. Wichtig ist nur, dass Prozess II versucht auf das Geheimnisregister zuzugreifen, nachdem Prozess I dort das Geheimnis abgelegt hat. Diese Reihenfolge könnte man vielleicht sogar durch eine Interprozesskommunikation sicherstellen.