News AMD gibt Programmierleitfaden gegen Spectre heraus

[Nero24]

Wer einen Blick in den Leitfaden wirft, findet eine ganze Palette an Vorschlägen. So sollen z.B. Register geleert werden sobald sie nicht mehr benötigt werden, der Befehl LFENCE soll genutzt werden, um Ladeoperationen seriell durchzuführen und es wird anhand eines Beispiels gezeigt, wie Retpoline, Googles Vorschlag zur Milderung von Spectre 2, in der Programmierpraxis umgesetzt werden kann; im Whitepaper V2‑1 genannt.
(…)

» Artikel lesen

 

[TAL9000]

Hoffe ich wirklich auf den V2-1 Lösungsansatz, da ich viel alte HW unter Windows nutze und die wahrscheinlich nie ein BIOS Update bekommen wird...

 

[Complicated]

In diesem Satz funktioniert der Link zu dem weiteren Vorschlag nicht.

Von Kernelentwickler Ingo Molnár existiert mittlerweile noch ein weiterer Vorschlag,

 

[Nero24]

Link gefixt.

 

[Complicated]

Danke für das fixen. Allerdings scheint das keine weitere Option zum patchen des Exploits zu sein. Es ist vielmehr eine Möglichkeit die Verwundbarkeit von Skylake bei Nutzung von Retpoline zu eliminieren, sprich es ist nur in Kombination mit Retpoline wirksam. Es ist eine Methode "Deep stacks" zu verhindern, die dazu führen, dass Retpoline umgangen werden kann.

Im Artikel wird der falsche Eindruck erweckt als ob dies eine dritte Alternative zu Microcode Updates und Retpoline sei. Tatsächlich ist es lediglich eine Methode um spezifisch bei Skylake CPUs die Lücken zu schließen, die trotz Retpoline noch bestehen bleiben. Daher bleibt es bei lediglich 2 Methoden und es kommt keine Compilerfreie dazu.

 

[Nero24]

Hm, Du könntest Recht haben. In seiner Zusammenfassung kommt es so rüber, als wäre es eine Alternative zu Retpoline und V2-4. Aber wenn man den Fließtext selbst liest, erfährt man, dass es eine Erweiterung zu sein scheint, um Retpoline auch auf Skylake-CPUs wirksam einsetzen zu können. Für AMD-Prozessoren also (vermutlich) irrelevant?

 

[skelletor]

Danke fürs erwähnen, Nero - und die detailiert recherchierte News dazu. (Auch wenn ich da selbst als ITler nicht mehr komplett folgen kann)

Gruß,
skell.

 

[Complicated]

Für AMD-Prozessoren also (vermutlich) irrelevant?

Das würde ich auch so sehen. Sogar irrelevant für alle Intels vor Skylake.

 

[cologne46]

Kann mir von euch mal einer den grundlegenden Unterschied zwischen Windows und Linux erklären? Warum braucht Windows BIOS Updates und unter Linux werden die Microcode Updates als Repositorys in den Kernel geschrieben? Die BIOS Updates müssten doch auch Auswirkung auf Linux haben, oder etwa nicht?

 

[Peet007]

Microsoft nutzt anscheinend nur den microcode vom Bios/UEFI, beim Linux Kernel kann man sich das Paket Firmware nachinstallieren wo dann aktuelle oder angepasste microcodes beim Start geladen und genutzt werden. Linux ist halt ein Projekt was auch von den Universitäten genutzt und betreut wird. Alles sehr flexible gestaltet das man es auf dem kleinsten bis hin zu einem Großrechner nutzen kann.

 

[cyrusNGC_224]

Warum braucht Windows BIOS Updates und unter Linux werden die Microcode Updates als Repositorys in den Kernel geschrieben? Die BIOS Updates müssten doch auch Auswirkung auf Linux haben, oder etwa nicht?

Das könnte MS genauso handhaben. Tun sie aber nicht.
In Debian-basierenden Systemen sind die in den Paketen amd64-microcode und intel-microcode enthalten, welche bei deren Installation umgehend in die Initrd gebaut werden und die beim Start direkt nach dem BIOS geladen wird.

 

[cologne46]

Danke euch Beiden für die Erklärung.

D.h. dann aber ja unter Umständen, dass bei Linux das doppelt gemoppelt ist, wenn ein BIOS-Update mit Code erscheint der auch schon im Linux Repository Einzug gehalten hat. Dann wären wir ja quasi auf dem Weg zu BIOS-Versionen für MS und Linux. Kein Wunder, dass die Linux-Kernel Entwickler kotzen. Bei jedem BIOS-Update/Microcode-Update (für Windows-Geräte) müssten die ja dann gucken ob das mit ihrer Lösung harmoniert und falls nein selber wieder etwas anpassen.

 

[Complicated]

Für AMD Systeme braucht es unter Linux kein BIOS Update und auch kein Microcode Update, wenn Retpoline genutz wird. Das Microcode Update für AMD ist optional für diejenigen, die Retpoline nicht nutzen wollen aus irgendeinem Grund.

 

[cyrusNGC_224]

Danke euch Beiden für die Erklärung.

D.h. dann aber ja unter Umständen, dass bei Linux das doppelt gemoppelt ist, wenn ein BIOS-Update mit Code erscheint der auch schon im Linux Repository Einzug gehalten hat.

Ich weiß es nicht sicher, aber meines Wissens wird der zuletzt geladene Mikrocode alle vorigen überschreiben. Also das sollte kein Problem sein. (Die neuen UEFIs sind im Grunde auch nur angepasste Linux Kernel mit etwas rudimentärem Rootsystem, welche Mikrocode auf dieselbe Weise laden sollten (wie dann später eventuell das OS))
Übrigens hat der Mikrocode mit dem Kernelcode nichts zu tun. Ersterer wird vom CPU Hersteller oder OEM geliefert. Letzterer von den Kernelentwicklern erschaffen oder durchgewunken.

 

[cologne46]

Für AMD Systeme braucht es unter Linux kein BIOS Update und auch kein Microcode Update, wenn Retpoline genutz wird. Das Microcode Update für AMD ist optional für diejenigen, die Retpoline nicht nutzen wollen aus irgendeinem Grund.

Das ist ja meine Aussage, vll ungenau formuliert. Die Mainboardhersteller wissen aber ja nun nicht ob Windows oder Linux installiert ist. Sie bringen also ein BIOS-Update heraus, welches bei Windows einen Nutzen und bei Linux keinen hat. So kam ich zu BIOS-Versionen für Windows und Linux (z.B. 2.9W und 2.8L)

Ich weiß es nicht sicher, aber meines Wissens wird der zuletzt geladene Mikrocode alle vorigen überschreiben. Also das sollte kein Problem sein.

Na das würde die Sache aber auch nicht unbedingt einfacher machen. Wenn nur das letzte angewendet wird. Da sie aber ja alle aus der selben Quelle stammen (Chip-Hersteller), sollten die das aber ja eigentlich auf die Reihe kriegen. (Wenn sie durch das selbstverursachte Patchchaos wieder durchblicken)

Übrigens hat der Mikrocode mit dem Kernelcode nichts zu tun. Ersterer wird vom CPU Hersteller oder OEM geliefert. Letzterer von den Kernelentwicklern erschaffen oder durchgewunken.

Das ist mir schon klar. Meiner Spekulation die du zum Teil zitierst lag ja meine Annahme zu Grunde, dass das Linux Repository an das neu erschienene BIOS mit Mikrocode-Update angepasst werden müßte, wenn das Mikrocode-Update im BIOS eine Umsetzung/Ansatz im Repository konterkariert/zuwiderläuft. Wenn nun aber immer nur der letzte geladene Mikrocode zur Anwendung kommt, kann ja kein BIOS-Update der Lösung im Repository reinpfuschen.

Ich hoffe, ich konnte meinen Gedankengang ein bisschen verständlicher rüberbringen.