debianforum.de

Verfasst: **12.02.2018 10:43:28**

NAB hat geschrieben:
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:
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.

Verfasst: **12.02.2018 11:52:05**

NAB hat geschrieben:
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:
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

Verfasst: **12.02.2018 18:42:23**

clue hat geschrieben:
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:
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:
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:
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:
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

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

Verfasst: **13.02.2018 10:58:54**

NAB hat geschrieben:
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:
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.

Verfasst: **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 ....

Verfasst: **13.02.2018 19:32:16**

hikaru hat geschrieben:
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:
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:
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:
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".

Verfasst: **13.02.2018 23:39:12**

NAB hat geschrieben:
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:
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.

Verfasst: **14.02.2018 04:02:28**

hikaru hat geschrieben:
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:
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:
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?)

Verfasst: **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

Verfasst: **14.02.2018 16:27:14**

Par@noid hat geschrieben:
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

Verfasst: **14.02.2018 23:34:47**

dufty2 hat geschrieben:
14.02.2018 16:27:14

Par@noid hat geschrieben:
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

Abwarten und Kaffee trinken

Verfasst: **16.02.2018 03:39:54**

Aha ... hab ich doch richtig vermutet:
https://www.paulkocher.com/doc/Microsof ... ation.html
Microsoft versucht, seinem Compiler LFENCE beizubringen ... und hat dann testweise das gesamte Windows neu durchkompiliert, also nicht nur den Kernel.

Solange nicht ganz Debian neu durchkompiliert ist, ist man also auch nicht gegen Spectre geschützt.

Der Herr Kocher orakelt da was von 60% Geschwindigkeitseinbuße bei konsequentem Einsatz von LFENCE ... ich bin ja mal gespannt ...

Heise fasst das hier zusammen:
https://www.heise.de/security/meldung/M ... 70815.html

Und hier:
https://www.theregister.co.uk/2018/02/1 ... _variants/
experimentieren sie mit neuen Angriffsszenarien. Das Interessante findet sich ganz unten im "Updated". Intel hat anscheinend schon eine Hardwarelösung entwickelt. Allerdings nennen die die auch nur "mitigation" und nicht "fix".

Verfasst: **16.02.2018 04:28:46**

In sid ist derzeit gerade die 4.14.17-1 am köcheln.
Warum die .17 und nicht .18 (oder .19)? Muss man nicht verstehen

Bzgl. bisherige Performance-einbußen hier ein Artikeln von Brendan Gregg (of Netflix-fame):
http://www.brendangregg.com/blog/2018-0 ... mance.html
Zusammenfassung: Es hält sich - bisher - in Grenzen

Ich glaube nicht, dass es - rein sicherheitstechnisch - nötig sein wird, _alle_ Pakete neu zu kompilieren.
Könnte mir aber gut vorstellen, dass es zukünftig - rein packetverwaltungstechnisch - eine Standardeinstellung beim Paketbauen wird.

Verfasst: **16.02.2018 05:15:10**

Brendan Gregg beschäftigt sich einzig mit Meltdown. Das habe ich gedanklich schon abgehakt.

Genau das fehlt mir ... eine profunde Analyse, wie sich Spectre denn nun in freier Wildbahn ausnutzen lässt. Der Paul Kocher schreibt da auch nur wieder "operating systems, device drivers, web APIs, database systems, and almost anything else that receives untrusted input and may run on the same computer as untrusted code." seien angreifbar (falls sie geeignete conditional branches verwenden). An der Pauschalität dieser Aussage habe ich mal wieder meine Zweifel. Andererseits ... er ist der Fachmann.

Entweder übersehe ich da was ... oder Debian wird große Schwierigkeiten haben, Pakete in "ist angreifbar" und "ist nicht angreifbar" zu sortieren.

Davon abgesehen bräuchten wir aber erst mal einen Compiler, der die Programme mehr oder weniger intelligent mit LFENCE pflastert. Ich glaub, den von Microsoft können wir nicht nehmen

Verfasst: **16.02.2018 11:03:49**

https://www.heise.de/security/meldung/M ... 70686.html

und

https://www.heise.de/security/meldung/M ... 70815.html

Es sieht wohl tatsächlich danach aus, als ob wir verloren haben.

Daher finde ich diesen Kommentar auch ziemlich passend:

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

Aber ja, ich weiß, unsere US-Amerikanische Abhängigkeit wird sich niemals ändern, weil das genau so gewollt ist. Das einzige worüber die sich ärgern ist doch, dass deren shit jetzt öffentlich geworden ist.
Im folgenden Artikel ist klar ersichtlich, weshalb die Chinesen nicht mehr mitspielen dürfen, dafür aber natürlich auf der ganzen Welt die total vertrauenswürdige US-Amerikanische Hardware verwendet werden soll. Der Gedanke ist doch: Wenn die Chinesen das *könnten*, dann machen das die Amis gemäß Snowden wohl schon die ganze Zeit, nicht wahr?:

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

Nachdem ich das gelesen habe, ist mir nur noch zum k*tzen. Wer also glaubt, es würde sich auch nur irgendetwas ändern, nun ja ...

Verfasst: **17.02.2018 06:56:29**

dufty2 hat geschrieben:
16.02.2018 04:28:46
In sid ist derzeit gerade die 4.14.17-1 am köcheln.

So, haben wir dann einen Unterschied zwischen testing (buster) und unstable (sid)? :

Code: Alles auswählen

# diff t u
1c1
< [    0.000000] Linux version 4.14.0-3-amd64 (debian-kernel@lists.debian.org) (gcc version 7.2.0 (Debian 7.2.0-19)) #1 SMP Debian 4.14.13-1 (2018-01-14)
---
> [    0.000000] Linux version 4.14.0-3-amd64 (debian-kernel@lists.debian.org) (gcc version 7.3.0 (Debian 7.3.0-3)) #1 SMP Debian 4.14.17-1 (2018-02-14)

Jawohl, es geht voran:

Code: Alles auswählen

# diff before after
4c4
< Kernel is Linux 4.14.0-3-amd64 #1 SMP Debian 4.14.13-1 (2018-01-14) x86_64
---
> Kernel is Linux 4.14.0-3-amd64 #1 SMP Debian 4.14.17-1 (2018-02-14) x86_64
28a29
> * Mitigated according to the /sys interface:  NO  (kernel confirms your system is vulnerable)
33a35
> * Mitigated according to the /sys interface:  YES  (kernel confirms that the mitigation is active)
42c44
<   * Kernel compiled with a retpoline-aware compiler:  UNKNOWN 
---
>   * Kernel compiled with a retpoline-aware compiler:  YES  (kernel reports full retpoline compilation)
45a48
> * Mitigated according to the /sys interface:  YES  (kernel confirms that the mitigation is active)

Verfasst: **17.02.2018 13:56:39**

Info linux kernel 4.14.17-1 sid (unstable)

Spectre and Meltdown mitigation detection tool v0.34

Checking for vulnerabilities on current system
Kernel is Linux 4.14.0-3-amd64 #1 SMP Debian 4.14.17-1 (2018-02-14) 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: 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 2 jump-then-lfence instructions found, should be >= 30 (heuristic))
> STATUS: VULNERABLE (Kernel source needs to be patched to mitigate the vulnerability)

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

MfG Par@noid

Verfasst: **19.02.2018 04:50:25**

Info linux kernel 4.15.4-1 sid (unstable)

Code: Alles auswählen

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

Checking for vulnerabilities on current system
Kernel is Linux 4.15.0-1-amd64 #1 SMP Debian 4.15.4-1 (2018-02-18) 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:  YES  (kernel confirms that your CPU is unaffected)
* Kernel has array_index_mask_nospec:  YES  (1 occurence(s) found of 64 bits array_index_mask_nospec())
* Kernel has the Red Hat/Ubuntu patch:  NO 
> 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:  YES  (kernel confirms that your CPU is unaffected)
* 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:  UNKNOWN 
> 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 your CPU is unaffected)
* Kernel supports Page Table Isolation (PTI):  YES 
* PTI enabled and active:  NO 
* 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
#

CVE-2017-5753 ist immer noch offen trotz "Latest Stable Kernel":
https://security-tracker.debian.org/tra ... -2017-5753

4.16-rc2 (heut' nacht veröffentlich) hat weitere Patches (noch nicht in Greg's stable),
vgl. auch https://www.phoronix.com/scan.php?page= ... e-For-4.16

PTI wurde de-aktiviert, da Atom

DIeses spectre-meltdown-checker.sh muss man auch dauernd updaten, jetzt in Version 0.35

Verfasst: **19.02.2018 12:02:29**

Info linux kernel 4.15.4-1 (2018-02-18) x86_64 GNU/Linux sid (unstable)

Spectre and Meltdown mitigation detection tool v0.35

Checking for vulnerabilities on current system
Kernel is Linux 4.15.0-1-amd64 #1 SMP Debian 4.15.4-1 (2018-02-18) 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())
* Kernel has the Red Hat/Ubuntu patch: NO
> 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)
> 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

Verfasst: **19.02.2018 14:22:12**

Info zu heutigen selbstgebackenen kernel 4.16.0-rc2 #1 SMP Mon Feb 19 12:53:15 CET 2018 x86_64

Spectre and Meltdown mitigation detection tool v0.35

Checking for vulnerabilities on current system
Kernel is Linux 4.16.0-rc2 #1 SMP Mon Feb 19 12:53:15 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())
* Kernel has the Red Hat/Ubuntu patch: NO
> 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)
> 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

Verfasst: **19.02.2018 16:52:11**

Par@noid hat geschrieben:
19.02.2018 14:22:12
Info zu heutigen selbstgebackenen kernel 4.16.0-rc2 #1 SMP Mon Feb 19 12:53:15 CET 2018 x86_64

Wenn man einen Diff machen zwischer dieser Ausgabe und Deiner vorherigen, dann sind sie gleich bis auf die eine Zeile mit der Kernelbezeichnung.
Danke, dass das script den Unterschied zwischen 4.15.4 und 4.16.0-rc2 (derzeit) nicht erkennt.

Dein "Thumbs Up" im vorherigen Post in Ehren, denke aber, das Thema wird uns noch länger beschäftigen ...

Verfasst: **19.02.2018 16:59:12**

towo hat geschrieben:
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.

Also, gestern bekam Jessie einen neuen gcc 4.9 und das changelog dazu sagte "mit backport der retpoline-patches". Dann sollte der Backport für Stretch auch bald erscheine.

Verfasst: **23.02.2018 02:58:02**

Jupp ... mit dem neusten Stretch Kernel 4.9.0-6 (4.9.82-1+deb9u2) steht bei mir auch überall "Not Vulnerable".

Interessanter Weise auch bei einem Kaby Lake bei "Spectre Variant 2", genau wie bei Par@noid, wie auch immer die das hinbekommen haben ...

Verfasst: **23.02.2018 11:43:35**

So, jetzt fehlt in Stretch wohl noch etwas - trotz neuem Kernel und Compiler:

* 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)

ist retpoline nicht aktiv.
Weiß da Jemand genaueres, muß man da dem Kernel einen Boot-Parameter übergeben, oder ist das dem fehlenden Microcode-Update (Ivy-Bridge i5-3570K) zu verdanken, oder ist das ein Bug im spectre-meltdown-checker v0.34?

Verfasst: **23.02.2018 12:34:16**

Mit dem neuen Kernel sieht es bei mir auch ganz gut aus.
Lediglich die Meldung

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

verstehe ich nicht recht, beziehungsweise mir ist nicht klar, ob und was ich wie machen soll.
Der Thread https://github.com/speed47/spectre-melt ... /issues/56 brachte mich auch nicht weiter.

debianforum.de

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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