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.