http://www.tomshardware.com/news/intel- ... 36405.html
Da bin ich mal mächtig gespannt, ob das wahr wird?Krzanich later said the company would begin to ship products with "in-silicon" fixes for the vulnerabilities this year.
Da bin ich mal mächtig gespannt, ob das wahr wird?Krzanich later said the company would begin to ship products with "in-silicon" fixes for the vulnerabilities this year.
Oha, da hast du mich erwischt.
Falls ich es richtig ge-grep-t habe:ingo2 hat geschrieben:28.01.2018 18:56:23Womit wurde denn der Kernel kompiliert?
Momentan hat nur gcc8 die retpoline-patches, wird aber auf gcc7 zurückportiert und ist in 7.3 enthalten.
Ob Stretch je in den Genuß kommt? Für gcc6 hat noch niemand mit Backports begonnen.
Code: Alles auswählen
# strings /boot/vmlinuz-4.15.0-rc8-amd64 | grep gcc
4.15.0-rc8-amd64 (debian-kernel@lists.debian.org) (gcc version 7.2.0 (Debian 7.2.0-19)) #1 SMP Debian 4.15~rc8-1~exp1 (2018-01-15)
Also, noch etwas Geduld, dann weden bestimmt auch die retpoline-Funktionen in den Kernel Einzug halten.dufty2 hat geschrieben:29.01.2018 15:58:29gcc 7.3 ist seit ein paar Tagen bereits in sid,
weiss aber nicht, ab wann dann auch die Pakete damit kompiliert werden.
GCC 7.3 mit Retpoline-Patches erschieneningo2 hat geschrieben:29.01.2018 16:32:32Also, noch etwas Geduld, dann weden bestimmt auch die retpoline-Funktionen in den Kernel Einzug halten.dufty2 hat geschrieben:29.01.2018 15:58:29gcc 7.3 ist seit ein paar Tagen bereits in sid,
weiss aber nicht, ab wann dann auch die Pakete damit kompiliert werden.
Und mit Glück gibt's dann einen Backport-Kernel damit - ich weiß allerdings nicht, ob das in Stretch dann mit unterschiedlichen Kompilerversionen rund läuft?
root@Defiant:/home/towo/test/security/spectre-meltdown-checker# ./spectre-meltdown-checker.sh
Spectre and Meltdown mitigation detection tool v0.33
Checking for vulnerabilities on current system
Kernel is Linux 4.15.0-towo.1-siduction-amd64 #1 SMP PREEMPT siduction 4.15-1 (2018-01-29) x86_64
CPU is Intel(R) Core(TM) i5-4670K CPU @ 3.40GHz
Hardware check
* Hardware support (CPU microcode) for mitigation techniques
* Indirect Branch Restricted Speculation (IBRS)
* SPEC_CTRL MSR is available: NO
* CPU indicates IBRS capability: NO
* Indirect Branch Prediction Barrier (IBPB)
* PRED_CMD MSR is available: NO
* CPU indicates IBPB capability: NO
* Single Thread Indirect Branch Predictors (STIBP)
* SPEC_CTRL MSR is available: NO
* CPU indicates STIBP capability: NO
* Enhanced IBRS (IBRS_ALL)
* CPU indicates ARCH_CAPABILITIES MSR availability: NO
* ARCH_CAPABILITIES MSR advertises IBRS_ALL capability: NO
* CPU explicitly indicates not being vulnerable to Meltdown (RDCL_NO): NO
* CPU microcode is known to cause stability problems: NO
* CPU vulnerability to the three speculative execution attacks variants
* Vulnerable to Variant 1: YES
* Vulnerable to Variant 2: YES
* Vulnerable to Variant 3: YES
CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Mitigated according to the /sys interface: NO (kernel confirms your system is vulnerable)
> STATUS: VULNERABLE (Vulnerable)
CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigated according to the /sys interface: YES (kernel confirms that the mitigation is active)
* Mitigation 1
* Kernel is compiled with IBRS/IBPB support: NO
* Currently enabled features
* IBRS enabled for Kernel space: NO
* IBRS enabled for User space: NO
* IBPB enabled: NO
* Mitigation 2
* Kernel compiled with retpoline option: YES
* Kernel compiled with a retpoline-aware compiler: YES (kernel reports full retpoline compilation)
* Retpoline enabled: YES
> STATUS: NOT VULNERABLE (Mitigation: Full generic retpoline)
CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Mitigated according to the /sys interface: YES (kernel confirms that the mitigation is active)
* Kernel supports Page Table Isolation (PTI): YES
* PTI enabled and active: YES
* Running as a Xen PV DomU: NO
> STATUS: NOT VULNERABLE (Mitigation: PTI)
A false sense of security is worse than no security at all, see --disclaimer
Ich habe das Spectre-Papier so verstanden, dass der Angreifer das Opfer "irgendwie" dazu bringen muss, vorher ausgewählten Code wiederholt auszuführen, um die Sprungsvorhersage zu trainieren. Mir fehlt gerade die Fantasie, um mir sämtliche dafür geeigneten Möglichkeiten zu überlegen, aber da der Angreifer nicht direkt in den Speicherbereich des Opfers springen darf, müsste da doch immer irgendeine Interprozesskommunikation inklusive Kontextwechsel stattfinden, oder? Eigentlich müsste es sogar immer ein Betriebssystemaufruf sein, also ein Kontextwechsel in den Kernel und zurück, oder?hikaru hat geschrieben:29.01.2018 10:31:15Meinem (und deinem?) Verständnis nach greift IBPB nur bei Kontextwechseln.
Auf einem SMP-System könnte man allerdings auf fremde Cache-Inhalte zugreifen ohne dass dafür überhaupt ein Kontextwechsel nötig ist, weil eben zwei Prozese tatsächlich gleichzeitig auf dem selben Cache arbeiten können.
Es ist eine Blackbox. Ich finde die Stelle leider nicht mehr, aber irgendwo sagen die Jungs von der TU Graz sehr klar, dass auch sie keine Ahnung haben, wie die betroffenen Intel-Prozessoren genau funktionieren. Sie sagen klar, dass sie nur eine Arbeitshypothese haben, die sich als tauglich herausgestellt hat, die tatsächliche Implementierung aber völlig anders aussehen könnte. Und das auch nur für die untersuchten Prozessoren. Und schon die untersuchten Prozessoren unterscheiden sich in Pipelinelänge, Größe der Sprungvorhersagetabelle und Timing-Verhalten. Darum gilt Spectre ja auch als etwas anspruchsvoller.hikaru hat geschrieben:29.01.2018 10:31:15Natürlich ist das letztendlich Intels Problem. Falls wir hier aber halbwegs qualifiziert diskutieren wollen wäre es schon schlau, zumindest zu versuchen zu verstehen, was da im Detail passiert, statt es wie eine Black Box zu behandeln.
Ist er das? Tun sie das (in hier relevanter Art)? Irgendeine Separierung muss es geben, sonst würden die "gemischten" Befehle zweier Prozesse die Sprungvorhersage durcheinanderbringen. Es könnte Spectre sogar erschweren, wenn Angreifer und Opfer sich zwei HT-Kerne teilen ... das dürfte das Timing durcheinanderbringen.hikaru hat geschrieben:29.01.2018 10:31:15Ein wichtiger Punkt ist z.B., dass zwei HT-Siblings sich eine Pipeline teilen.
Umgekehrt wird ein Schuh draus ... jeder Kontextwechsel kann einen Hüpfer bedeuten. Der Kontextwechsel findet also so oder so statt.hikaru hat geschrieben:29.01.2018 10:31:15Im Rahmen eine Angriffs willst du das vielleicht schon, denn jeder Hüpfer bedeutet einen Kontextwechsel, der dir potenziell deinen Angriff kaputt machen könnte.
Cache-Angriffe bleiben natürlich weiterhin möglich, wie die ganzen letzten Jahre auch. Es ist ja nicht so, dass die Prozessoren vorher sicher waren. Der Vorteil von Spectre ist nur, dass du genau bestimmen kannst, wen du da bei was belauscht hast. Das reduziert das Rauschen beträchtlich.hikaru hat geschrieben:29.01.2018 10:31:15Das hilft mMn nicht weiter, so lange diese Prozesse sich weiterhin die selben Cache-Register teilen, denn damit bleiben Zeitmessungen weiterhin möglich.
Spekulieren? Wirfst du gerade Intels Meltdown und Spectre in einen Hut und versuchst, das ganze Nvidia ans Bein zu binden?hikaru hat geschrieben:29.01.2018 10:31:15Ich vermute, das Problem ist wie bei CPUs nicht der Treiber selbst sondern die bediente Hardware. Nvidia-GPUs könnten ebenso verwundbar für Meltdown sein wie Intel-CPUs. Vieleicht spekuliert Nouveau nicht, was Teil einer Erklärung für den Leistungsunterschied zwischen den Treibern sein könnte.
Meinem Verständnis nach muss nur IRGENDWER ausgewählten Code ausführen, der in ein Register schreibt, in das auch das Opfer schreibt.NAB hat geschrieben:29.01.2018 17:45:19Ich habe das Spectre-Papier so verstanden, dass der Angreifer das Opfer "irgendwie" dazu bringen muss, vorher ausgewählten Code wiederholt auszuführen, um die Sprungsvorhersage zu trainieren.
das ist sicher richtig. Aber es hilft uns nicht, dass weit fähigere Leute als wir genauso wie das Schwein in's Uhrwerk schauen.NAB hat geschrieben:29.01.2018 17:45:19Es ist eine Blackbox. Ich finde die Stelle leider nicht mehr, aber irgendwo sagen die Jungs von der TU Graz sehr klar, dass auch sie keine Ahnung haben, wie die betroffenen Intel-Prozessoren genau funktionieren.
Zwei HT-Kerne teilen sich eine Pipeline. Auf dieser Pipelne gibt es "replicated resources" (jeder HT-Sibling hat physisch seine Eigenen), "partitioned resources" (teilen sich beide, sind aber im Betrieb klar aufgeteilt) und "shared resources" (nutzen beide gemeinsam ohne Aufteilung).NAB hat geschrieben:29.01.2018 17:45:19Ist er das? Tun sie das (in hier relevanter Art)? Irgendeine Separierung muss es geben, sonst würden die "gemischten" Befehle zweier Prozesse die Sprungvorhersage durcheinanderbringen.hikaru hat geschrieben:29.01.2018 10:31:15Ein wichtiger Punkt ist z.B., dass zwei HT-Siblings sich eine Pipeline teilen.
Irgendwo habe ich gelesen, dass LPDDR4 hardwareseitig immun gegen Rowhammer sei. Ich kenne allerdings keine Details, wie das erreicht wird oder warum das nur für LPDDR4 gilt.NAB hat geschrieben:29.01.2018 17:45:19(Rawhammer gibt's übrigens auch weiterhin. Inzwischen arbeiten sie an "Erkennungsroutinen". Sich danebenbenehmende Prozesse sollen also abgewürgt werden. Ähnliches wäre auch bei Spectre denkbar.)
Meltdown ist doch nur ein Spezialfall von Spectre, der sich in Angriffsvektor und Behandlung dadurch auszeichnet, dass ein Kontextwechsel nicht (nur) zwischen Prozessen auf gleicher Privilegebene passiert, sondern dass dabei die Privilegebene gewechselt wird. Oder sehe ich das falsch?NAB hat geschrieben:29.01.2018 17:45:19Spekulieren? Wirfst du gerade Intels Meltdown und Spectre in einen Hut und versuchst, das ganze Nvidia ans Bein zu binden?hikaru hat geschrieben:29.01.2018 10:31:15Ich vermute, das Problem ist wie bei CPUs nicht der Treiber selbst sondern die bediente Hardware. Nvidia-GPUs könnten ebenso verwundbar für Meltdown sein wie Intel-CPUs. Vieleicht spekuliert Nouveau nicht, was Teil einer Erklärung für den Leistungsunterschied zwischen den Treibern sein könnte.
Meinem Verständnisnach sollte das nicht so sein. KPTI funktioniert ja so, dass die Kernel Page Tables aus dem Cache entfernt werden, bevor ein Userspace-Prozess den Kern (und dessen Cache) benutzen darf. Dieser Löschvorgang ist unter Kontrolle des Kernels. Als Module geladene Treiber (egal ob proprietär oder nicht) haben auf diesen Vorgang keinen Einfluss, können den Kernel also nicht an der Löschung der KPT vor Übergabe an den Userspace hindern.NAB hat geschrieben:29.01.2018 17:45:19Ich vermute eher, dass im Rahmen der Kerneländerungen gegen Meltdown auch sämtliche Treiber angepasst werden müssen, auch für ältere Kernel. Wenn das stimmt, müssten sich Besitzer von proprietärer Althardware zwischen Meltdown und Hardware entscheiden.
Muss er nur das? Ich weiß es nicht. Das Spectre-Papier hält sich da sehr zurück mit allgemeingültigen Aussagen über die praktische Anwendbarkeit. Auch der Beispielcode zeigt nur, wie ein Programm sich selber aushorchen kann.hikaru hat geschrieben:30.01.2018 13:11:30Meinem Verständnis nach muss nur IRGENDWER ausgewählten Code ausführen, der in ein Register schreibt, in das auch das Opfer schreibt.
Das Opfer muss also selber den Code ausführen, der ihn in die Pfanne haut. Ich schließe daraus, dass irgendeine Prüfung der Speicherzugriffsberechtigungen doch greift.Spectre attacks induce a victim to speculatively perform
operations that would not occur during correct program
execution and which leak the victim’s confidential infor-
mation via a side channel to the adversary.
Der Angriffscode muss also im Kontext des Opfers ausgeführt werden.During the second phase, the processor speculatively
executes instruction(s) that transfer confidential informa-
tion from the victim context into a microarchitectural
side channel.
Das Opfer muss also gut fernsteuerbar sein, also irgendwie an- oder aufrufbar sein.This may be triggered by having the at-
tacker request that the victim to perform an action (e.g.,
via a syscall, socket, file, etc.).
Die gesamte Sprungvorhersage findet also nicht immer statt, sondern nur unter bestimmten Umständen.Speculative execution was only observed when the
branch destination address was executable by the vic-
tim thread, so gadgets need to be present in the mem-
ory regions executable by the victim.
Das musst du nicht "halten", es ist anscheinend so:hikaru hat geschrieben:30.01.2018 13:11:30denn meinem Verständnis nach [...] hängt der gerade geschilderte Angriff davon ab, ob mehrere Threads sich eine gemeinsame Sprungvorhersage teilen, was ich insbesondere bei HT für plausibel hielte.
Wobei "mistrain" noch nicht bedeutet, dass es auch ausnutzbar ist. In ihrer "Example Implementation on Windows" geben sie sich ja etwas mehr Mühe, um zum Erfolg zu kommen. Da sind wieder Kontextwechsel nötig.Tests, primarily on a Haswell-based Surface Pro 3, con-
firmed that code executing in one hyper-thread of Intel
x86 processors can mistrain the branch predictor for code
running on the same CPU in a different hyper-thread.
Wir sind aber nur Schweine, die von außen auf die Uhr schauen und merken, dass sie falsch geht. Genauer gesagt merken wir, dass zig Uhren unterschiedlicher Hersteller falsch gehen. Dass da ein Uhrwerk drin ist, wissen wir nur, weil der Hersteller es uns gesagt hat. Bei der Risikobewertung müssen wir uns auch auf den Hersteller verlassen - unter dem Vorbehalt, dass wir ihn irgendwann der Lüge überführen. Sicherlich wäre es wünschenswerter wenn wir mehr wüssten ... aber aus meiner Sicht bleiben das fromme Wünsche und Spekulationen.hikaru hat geschrieben:30.01.2018 13:11:30Aber es hilft uns nicht, dass weit fähigere Leute als wir genauso wie das Schwein in's Uhrwerk schauen.
Fakt ist, dass sich eine bestimmte CPU auf eine bestimmte Weise verhält. Dieses Verhalten ist ausschlaggebend für die Risikobewertung. Wer über das Verhalten bescheid weiß und wer nicht, ändert an der Sachlage des Risikos nichts.
Also das ging ungefähr so: "Oh. DDR3 ist anfällig gegen Rowhammer? Na, dann machen wir DDR4 besser!".hikaru hat geschrieben:30.01.2018 13:11:30Irgendwo habe ich gelesen, dass LPDDR4 hardwareseitig immun gegen Rowhammer sei. Ich kenne allerdings keine Details, wie das erreicht wird oder warum das nur für LPDDR4 gilt.
Ich werd mich hüten, dass als falsch zu bezeichnen, so abstrakt wie du es ausgedrückt hast, aber aus meiner Sicht ist Meltdown eine völlig eigenständige Sicherheitslücke, die sich aus einem Fehler in Intels out-of-order execution ergibt. Sie hat so gar nichts mit der Sprungvorhersage zu tun, ist wesentlich besser verstanden, leichter ausnutzbar und leichter patchbar.hikaru hat geschrieben:30.01.2018 13:11:30Meltdown ist doch nur ein Spezialfall von Spectre, der sich in Angriffsvektor und Behandlung dadurch auszeichnet, dass ein Kontextwechsel nicht (nur) zwischen Prozessen auf gleicher Privilegebene passiert, sondern dass dabei die Privilegebene gewechselt wird. Oder sehe ich das falsch?
Unabhängig davon, ob deine Überlegungen stimmen, hast du Recht:hikaru hat geschrieben:30.01.2018 13:11:30Falls meine Überlegungen zu IBPB und SMP zutreffen, dann wäre allerdings innerhalb des Kernelspace' ein Spectre-Angriff von einem Tätermodul auf andere Teile des Kernels möglich.
Wobei das noch nicht meine Frage beantwortet, ob das nur Nvidias Treiber betrifft oder ob sämtliche Treiber für proprietäre Althardware angepasst werden müssen.The Linux driver contains updates to maintain compatibility with recent Linux updates for this security issue.
Wir schauen hier aus verschiedenen Blickwinkeln auf das Thema. Du gehst vom vorhandenen Informationsstand aus, ich vom zur Beurteilung notwendigen Informationsstand. Die sind leider nicht deckungsgleich.NAB hat geschrieben:30.01.2018 23:23:57Wir sind aber nur Schweine, die von außen auf die Uhr schauen und merken, dass sie falsch geht. Genauer gesagt merken wir, dass zig Uhren unterschiedlicher Hersteller falsch gehen. Dass da ein Uhrwerk drin ist, wissen wir nur, weil der Hersteller es uns gesagt hat. Bei der Risikobewertung müssen wir uns auch auf den Hersteller verlassen - unter dem Vorbehalt, dass wir ihn irgendwann der Lüge überführen. Sicherlich wäre es wünschenswerter wenn wir mehr wüssten ... aber aus meiner Sicht bleiben das fromme Wünsche und Spekulationen.
Danke!NAB hat geschrieben:30.01.2018 23:23:57Also das ging ungefähr so: "Oh. DDR3 ist anfällig gegen Rowhammer? Na, dann machen wir DDR4 besser!".
Und dann passierte das hier:
https://arstechnica.com/information-tec ... rowhammer/
Und dann hieß es "Oh, Mist, na wer konnte das schon ahnen. Aber dafür machen wir jetzt LPDDR4 besser!"
Und dann passierte das hier:
https://arxiv.org/pdf/1710.00551.pdf
Unter "Rowhammer Elimination Countermeasures." und "B. Rowhammer mitigations in hardware".
Es sind beides Sicherheitslücken, die sich aus einem Side-Channel-Angriff ergeben, der durch "Out Of Order Execution" möglich wird.NAB hat geschrieben:30.01.2018 23:23:57Ich werd mich hüten, dass als falsch zu bezeichnen, so abstrakt wie du es ausgedrückt hast, aber aus meiner Sicht ist Meltdown eine völlig eigenständige Sicherheitslücke, die sich aus einem Fehler in Intels out-of-order execution ergibt. Sie hat so gar nichts mit der Sprungvorhersage zu tun, ist wesentlich besser verstanden, leichter ausnutzbar und leichter patchbar.hikaru hat geschrieben:30.01.2018 13:11:30Meltdown ist doch nur ein Spezialfall von Spectre, der sich in Angriffsvektor und Behandlung dadurch auszeichnet, dass ein Kontextwechsel nicht (nur) zwischen Prozessen auf gleicher Privilegebene passiert, sondern dass dabei die Privilegebene gewechselt wird. Oder sehe ich das falsch?
Nein, du bist da schon auf einer heißen Spur. Hat nur nichts mit den Registern zu tun (genau wie Spectre eigentlich nichts mit den Registern zu tun hat). Man weiß nur nichts genaues, nur die Andeutungen aus dem Spectre-Papier. Und der wirkliche Vorteil von HT ist, dass du Dank Superskalarität wirklich den Cache permanent ohne Unterbrechungen belauschen kannst. Das ist aber nichts Neues, diese Sicherheitslücke ist seit Jahren bekannt.hikaru hat geschrieben:31.01.2018 18:24:10Mein ganzes Hyperthreading-Geschwurbel zu Spectre kann ich abhaken.
Mit Verlaub, das schrieb ich schon hier:hikaru hat geschrieben:31.01.2018 18:24:10Manchmal reicht schon ein Blick in den Wikipedia-Artikel. [1] Da steht drin, dass der komplette Registersatz zu den "replicated resources" gehört.
Nunja ... ich beobachte seit vielen Jahren einen Mangel an "zur Beurteilung notwendigen Informationsständen". Auch bei Spectre mangelt es seit 20 Jahren an den notwendigen Informationsständen. Da habe ich wenig Hoffnung auf kurzfristige Besserung.hikaru hat geschrieben:31.01.2018 18:24:10Wir schauen hier aus verschiedenen Blickwinkeln auf das Thema. Du gehst vom vorhandenen Informationsstand aus, ich vom zur Beurteilung notwendigen Informationsstand. Die sind leider nicht deckungsgleich.
Fein. Wollen wir es noch weiter abstrahieren? Es gibt Spectre und Meltdown gar nicht. Die Out-of-order-execution und die branch prediction funktionieren genau so wie sie es sollen. Man hat nur neue Methoden gefunden, wie man mit Cache-Timing-Angriffen noch schneller an noch mehr Informationen kommen kann.hikaru hat geschrieben:31.01.2018 18:24:10Es sind beides Sicherheitslücken, die sich aus einem Side-Channel-Angriff ergeben, der durch "Out Of Order Execution" möglich wird.
Falls es Dich interessiert, für stable gibt es ein "proposed-update" (4.9.80), welcher auch erfolgreich kompiliert wurde. Weiss aber nicht, ob das Kompilat (.deb) für die Allgemeinheit zugänglich ist oder nur für die debian-kernel-maintainer.Nice hat geschrieben:09.02.2018 17:25:34Was imho einzig zählt ist die Frage, wann der neue gestählte Kernel in Stable eingespeist wird.
Klar doch. Thx!Falls es Dich interessiert
Doch, der ist über "proposed-updates" allgemein zugänglich, spiele ihn gerade ein:dufty2 hat geschrieben:09.02.2018 19:07:20Falls es Dich interessiert, für stable gibt es ein "proposed-update" (4.9.80), welcher auch erfolgreich kompiliert wurde. Weiss aber nicht, ob das Kompilat (.deb) für die Allgemeinheit zugänglich ist oder nur für die debian-kernel-maintainer.
Code: Alles auswählen
- bpf: prevent out-of-bounds speculation (mitigates Spectre#1 / CVE-2017-5753)
- [x86] x86/spectre: Add boot time option to select Spectre v2 mitigation
- [x86] x86/retpoline/crypto: Convert crypto assembler indirect jumps
- [x86] x86/retpoline/entry: Convert entry assembler indirect jumps
- [x86] x86/retpoline/ftrace: Convert ftrace assembler indirect jumps
- [x86] x86/retpoline/hyperv: Convert assembler indirect jumps
- [x86] x86/retpoline/xen: Convert Xen hypercall indirect jumps
- [x86] x86/retpoline/checksum32: Convert assembler indirect jumps
- [x86] x86/retpoline/irq32: Convert assembler indirect jumps
- [x86] x86/retpoline: Fill return stack buffer on vmexit
Tja, das war wohl nix. Der spectre-meltdown-checker sagt, ich sei weiterhin gegen Variant 1 und Variant 2 verwundbar. Bei Variant 2 liegt's wohl daran, dass der Kernel auch mit einem Compiler kompiliert werden müsste, der Retpoline unterstützt, und das ist hier nicht der Fall (sagt das Script).NAB hat geschrieben:09.02.2018 20:36:15Doch, der ist über "proposed-updates" allgemein zugänglich, spiele ihn gerade ein:
Get:18 http://ftp.de.debian.org/debian stretch-proposed-updates/main amd64 linux-image-4.9.0-5-amd64 amd64 4.9.80-1
Also doch ... irgendwann ... vielleicht, falls ich das richtig einordne.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.
https://www.heise.de/ct/artikel/Kernel- ... 63549.htmlDie 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.
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
#