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

Alles rund um sicherheitsrelevante Fragen und Probleme.
Benutzeravatar
towo
Beiträge: 3144
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 » 09.02.2018 22:15:59

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
Beiträge: 5502
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 23:26:35

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.
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: 1459
Registriert: 22.12.2013 16:41:16

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

Beitrag von dufty2 » 10.02.2018 06:05:59

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
Beiträge: 5502
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 » 11.02.2018 04:25:07

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.
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: 1459
Registriert: 22.12.2013 16:41:16

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

Beitrag von dufty2 » 11.02.2018 07:13:31

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

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

Beitrag von clue » 12.02.2018 10:43:28

NAB hat geschrieben: ↑ zum Beitrag ↑
11.02.2018 04:25:07
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?
NAB hat geschrieben: ↑ zum Beitrag ↑
11.02.2018 04:25:07
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.
Offenbarung 13 erfüllt sich gerade vor unseren Augen, genießen wir also die letzten Jahre unserer Scheinfreiheit

Benutzeravatar
hikaru
Beiträge: 9608
Registriert: 09.04.2008 12:48:59

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

Beitrag von hikaru » 12.02.2018 11:52:05

NAB hat geschrieben: ↑ zum Beitrag ↑
11.02.2018 04:25:07
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.

clue hat geschrieben: ↑ zum Beitrag ↑
12.02.2018 10:43:28
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
Beiträge: 5502
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 » 12.02.2018 18:42:23

clue hat geschrieben: ↑ zum Beitrag ↑
12.02.2018 10:43:28
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.
clue hat geschrieben: ↑ zum Beitrag ↑
12.02.2018 10:43:28
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."
clue hat geschrieben: ↑ zum Beitrag ↑
12.02.2018 10:43:28
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.
hikaru hat geschrieben: ↑ zum Beitrag ↑
12.02.2018 11:52:05
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.
hikaru hat geschrieben: ↑ zum Beitrag ↑
12.02.2018 11:52:05
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 :mrgreen:

(Nebenbei geht das Spectre Papier noch weiter ... unter "Variations" finden sich Vorschläge, die ganz ohne "bounds check" und "indirect branches" auskommen)
Never change a broken system. It could be worse afterwards.

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

Benutzeravatar
hikaru
Beiträge: 9608
Registriert: 09.04.2008 12:48:59

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

Beitrag von hikaru » 13.02.2018 10:58:54

NAB hat geschrieben: ↑ zum Beitrag ↑
12.02.2018 18:42:23
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.
NAB hat geschrieben: ↑ zum Beitrag ↑
12.02.2018 18:42:23
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
Beiträge: 943
Registriert: 08.07.2007 17:36:57

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

Beitrag von clue » 13.02.2018 11:54:35

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

NAB
Beiträge: 5502
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 » 13.02.2018 19:32:16

hikaru hat geschrieben: ↑ zum Beitrag ↑
13.02.2018 10:58:54
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.
Jaaa ... hikaru ... ehm ... und wie war noch mal die Alternative?

Schau dir die Arbeitsanweisung von Intel noch mal genau an. Und die "Ausblicke" aus dem Spectre-Papier. Du darfst als Programmierer jetzt selber entscheiden, ob das "if," das du gerade geschrieben hast, sich wohl mit Spectre ausnutzen lässt oder nicht. Im Zweifelsfall haust du ein "LFENCE" dahinter. Was machst du also?

Das gilt übrigens auch für jedes "for" und "while". Wie Entwickler von Hochsprachen damit umgehen wollen, ist mir auch noch völlig unklar.
hikaru hat geschrieben: ↑ zum Beitrag ↑
13.02.2018 10:58:54
Du wirst wenige (keine?) real existierende CPUs finden, die zwar Out-of-Order können aber keine Speculative Execution.
Nunja ... Risc-V verkneift sich zumindest Speicherzugriffe bei der "speculative execution":
https://riscv.org/2018/01/more-secure-world-risc-v-isa/
clue hat geschrieben: ↑ zum Beitrag ↑
13.02.2018 11:54:35
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.)
Das schönste Einfallstor dürften die Myriaden an Bibliotheken sein, die Linux und Windows so mitbringen ...
clue hat geschrieben: ↑ zum Beitrag ↑
13.02.2018 11:54:35
2. Variante 2: Die Hersteller in die Produkthaftung nehmen.
Für eine "Haftung" musst du einen (finanziellen) "Schaden" vorweisen können. Und nun weise mal nach, dass dir deine Daten ausgerechnet durch Spectre abhanden gekommen sind und welcher finanzielle Schaden dir dadurch entstanden ist. Der einzige bezifferbare Schaden wäre, dass dein Rechner zukünftig langsamer läuft ... darum ist es Intel ja so wichtig, dass die "Fixes" sich im Betriebssystem befinden und abschaltbar sind. So können sie immer noch sagen "Tja, liegt an der Software, die du einsetzt. Schalt's halt ab und lasse nur vertrauenswürdige Software laufen".
Never change a broken system. It could be worse afterwards.

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

Benutzeravatar
hikaru
Beiträge: 9608
Registriert: 09.04.2008 12:48:59

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

Beitrag von hikaru » 13.02.2018 23:39:12

NAB hat geschrieben: ↑ zum Beitrag ↑
13.02.2018 19:32:16
Jaaa ... hikaru ... ehm ... und wie war noch mal die Alternative?
Rechner wegschmeißen und bis 2020/21 im Wald Holz hacken! ;)
Akzeptiere die bittere Wahrheit: Aktuelle Hardware ist irreparabel kaputt. Klar müssen wir uns damit noch so lange durchwurschteln, bis wir irgendwas besseres haben, denn wenn alle von uns IT-Fuzzis die nächsten drei Jahre in den Wald ziehen dann haben wir am Ende keinen Wald mehr und die Hälfte unserer Zunft kann hinterher nur noch Fünffingersystem tippen.
Aber die Finger in die Ohren zu stecken und laut "LALALA" zu rufen macht die Sache nicht besser (und auf Dauer heiser). KPTI, Retpoline, lfence und was da sonst noch alles kommen mag sind eben letztendlich nur hässliche Krücken mit deren Hilfe wir versuchen, ein eigentlich nicht mehr fahrtüchtiges Auto doch noch bis zur nächsten Ausfahrt zu schleppen, aber es sind keine Lösungen um die Reise fortzusetzen.

Wir müssen wieder dahin kommen, Hardware als sicher ("safe", nicht "secure") annehmen zu dürfen, denn in Software werden wir abgesehen von Spezialfällen Hardwaredefekte nie abfangen können. Keine Ahnung ob das möglich ist, ich bin zumindest skeptisch.
NAB hat geschrieben: ↑ zum Beitrag ↑
13.02.2018 19:32:16
Nunja ... Risc-V verkneift sich zumindest Speicherzugriffe bei der "speculative execution":
https://riscv.org/2018/01/more-secure-world-risc-v-isa/
Und nun prüfe das bitte nochmal gegen "real existierend" ab!
Mag sein, dass du mit RISC-V einen Wecker bauen kannst oder vielleicht einen kleinen Server, aber es gibt auch andere Szenarien in denen du aktuell nicht an einem System mit unsicherer Speculative Execution vorbei kommst.

NAB
Beiträge: 5502
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 » 14.02.2018 04:02:28

hikaru hat geschrieben: ↑ zum Beitrag ↑
13.02.2018 23:39:12
Rechner wegschmeißen und bis 2020/21 im Wald Holz hacken! ;)
Akzeptiere die bittere Wahrheit: Aktuelle Hardware ist irreparabel kaputt.
Akzeptiere du doch bitte die bittere Wahrheit: was du "aktuell" nennst, ist schon seit gut 10 Jahren kaputt. Und nein, ich meine nicht nur Spectre ... hier ein Artikel von 2015:
https://danluu.com/cpu-bugs/
Und für Englischverweigerer eine deutschsprachige Zusammenfassung:
https://www.golem.de/news/cpu-bugs-erra ... 28640.html
Ich hab grad versucht, eine Liste aller Intel Errata zu finden. Ich find keine. Aber hier ein Beispiel aus der "guten alten Zeit":
https://www.geek.com/images/geeknews/20 ... __full.gif
Wir haben hier nur einen besonders schönen Fehler, der sich über fast alle CPUs erstreckt.
hikaru hat geschrieben: ↑ zum Beitrag ↑
13.02.2018 23:39:12
Wir müssen wieder dahin kommen, Hardware als sicher ("safe", nicht "secure") annehmen zu dürfen, denn in Software werden wir abgesehen von Spezialfällen Hardwaredefekte nie abfangen können.
Und du träumst jetzt von einer "heilen" CPU bis 2021? Öhm ... joa ... bestimmt ...

Guck mal hier:
http://www.elektroniknet.de/design-elek ... 50544.html
die untere Hälfte der ersten Seite. Wir verdanken die Misere den verzweifelten Versuchen von AMD und Intel, ihre Single-Thread-Leistung möglichst hoch zu halten. Das ist ihre einzige Chance, sich in ihrem schrumpfenden Markt die ARM-Konkurrenz vom Leibe zu halten. Und nun darfst du raten, ob die zukünftig lieber einen noch schnelleren und noch unsicheren oder lieber einen langsameren und sichereren Chip rausbringen werden.
(Seite 2 ist auch spannend. Google baut jetzt Prozessoren? Aha?)

Hast du verfolgt, wie Intel bisher mit CPU-Fehlern umgegangen ist? Ach ja ... totschweigen:
https://www.extremetech.com/computing/2 ... ufacturers
Ich vermute, die werden sich erst mal in Ruhe angucken, wie die Sache mit KPTI, LFENCE und Retpoline läuft und wie das bei den Kunden und bei den Sicherheitsforschern ankommt. Dann werden sie sich überlegen, ob und wie sie zukünftige Prozessoren überhaupt nachbessern. Der durchschnittliche Kunde hat sich nämlich eh schon längst daran gewöhnt, dass dauernd irgendwas kaputt ist und in Software nachgebessert werden muss. Aus meiner Sicht ist das einzig Interessante, welchen Performance Impact das haben wird. Und das wird massiv von der eingesetzten Software abhängen. Und auf die hat Intel nur begrenzten Einfluss. Wie fein für Intel!
hikaru hat geschrieben: ↑ zum Beitrag ↑
13.02.2018 23:39:12
Und nun prüfe das bitte nochmal gegen "real existierend" ab!
Upps, verzeihung, du hast Recht! Ich hab überlesen, dass die ersten echten Chips erst "vielleicht" Mitte des Jahres erhältlich sein werden. (Woher stammt dann nur der Benchmark, den ich gefunden habe?)
Never change a broken system. It could be worse afterwards.

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

Benutzeravatar
Par@noid
Beiträge: 210
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 » 14.02.2018 13:51:46

Info zu heutigen selbstgebackenen Kernel 4.15.3 und 4.16.0-rc1 :

Spectre and Meltdown mitigation detection tool v0.34

Checking for vulnerabilities on current system
Kernel is Linux 4.16.0-rc1 #1 SMP Wed Feb 14 12:34:01 CET 2018 x86_64
CPU is Intel(R) Core(TM) i5-7600K CPU @ 3.80GHz

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 158 stepping 9 ucode 0x5e)
* 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: YES (kernel confirms that the mitigation is active)
* Kernel has array_index_mask_nospec: YES (1 occurence(s) found of 64 bits array_index_mask_nospec())
> STATUS: NOT VULNERABLE (Mitigation: __user pointer sanitization)

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: NO
> 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

############

Spectre and Meltdown mitigation detection tool v0.34

Checking for vulnerabilities on current system
Kernel is Linux 4.15.3 #1 SMP Wed Feb 14 14:06:48 CET 2018 x86_64
CPU is Intel(R) Core(TM) i5-7600K CPU @ 3.80GHz

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 158 stepping 9 ucode 0x5e)
* 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: YES (kernel confirms that the mitigation is active)
* Kernel has array_index_mask_nospec: YES (1 occurence(s) found of 64 bits array_index_mask_nospec())
> STATUS: NOT VULNERABLE (Mitigation: __user pointer sanitization)

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: NO
> 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



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



Debian GNU/Linux ..::unstable::.. (sid) 64-bit | GNOME

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

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

Beitrag von dufty2 » 14.02.2018 16:27:14

Par@noid hat geschrieben: ↑ zum Beitrag ↑
14.02.2018 13:51:46
* Kernel compiled with retpoline option: YES
* Kernel compiled with a retpoline-aware compiler: YES (kernel reports full retpoline compilation)
* Retpoline enabled: NO
> STATUS: NOT VULNERABLE (Mitigation: Full generic retpoline)
Schaut irgendwie komisch aus: Not enabled aber dennoch sicher ;)

gcc-7.3 ist jetzt in buster (testing): Es geht voran :)

Antworten