News April-Patch nutzt Microcode-Updates für AMD-CPUs mit Spectre-Schutz

Ich finde das Security Advisory 180002 von Microsoft hier noch aufschlussreich:
https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV180002

Unter Punkt 15. heisst es dann:
"15. What are the mitigations for AMD processors for CVE 2017-5715, Branch Target Injection?

Customers running Windows 10 Version 1709 need to install security update 4093112 for additional mitigations for AMD processors for CVE 2017-5715, Branch Target Injection. See the Affected Products table for links to download and install the updates. This update is also available via Windows Update.

The following table summarizes the attack scenarios that are protected against when the Windows Branch Target Injection mitigation is enabled and required hardware support is present on AMD CPUs:
Scenario Mitigation
Process-to-process scenarios where a malicious user-mode application could use CVE-2017-5715 to disclose the contents of memory used by other applications. Enabled by default

User-to-kernel scenarios where a malicious user-mode application could use CVE-2017-5715 to disclose the contents of kernel memory. Disabled by default

Virtualization scenarios where a compromised virtual machine could use CVE-2017-5715 to read the contents of privileged memory allocated to the host, hypervisor, or other guest virtual machine. Enabled by default

By default, user-to-kernel protection for CVE-2017-5715 is disabled for AMD CPUs. Customers must enable the mitigation to receive additional protections for CVE-2017-5715. Enabling this mitigation may affect performance. The actual performance impact will depend on multiple factors, such as the specific chipset in your physical host and the workloads that are running. For details on how to enable this protection, see Microsoft Knowledge Base Article 4073119 for Windows Client operating systems.

For AMD CPUs that support SMT, further protection against attacks from sibling hardware threads is provided by STIBP enablement or turning off SMT. For additional details and AMD recommended mitigations please see AMD Security Updates and AMD Architecture Guidelines around Indirect Branch Control."

Wenn ich das also richtig verstehe sind 2 von 3 Einfallstoren automatisch via IBPB + OS-Patch geschlossen und nur 1 User=> Kernel Space ist per default "offen" ?

User => Kernel-Space Zugriffe sind aber afaik nur dann problematisch wenn auf dem System Virtualisierung läuft. Denn dann könnte eben aus dem User der VM heraus der Kernel der VM hosts attackiert werden. ? Für Otto-Normalo aber eben nicht kritisch deswegen per default OFF ?

Vielleicht kann Complicated oder jemand anders mit mehr Ahnung die Patchvarianten etwas einordnen.
 
Bemerkenswert:
Windows Update and WSUS will offer this update to applicable Windows client and server operating systems regardless of the existence or value of the "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\QualityCompat\cadca5fe-87d3-4b96-b7fb-a231484277cc" registry setting. This change has been made to protect user data.
https://support.microsoft.com/de-de/help/4093118/windows-7-update-kb4093118
Es bekommen also auch diejenigen automatisch dieses Update, die kein oder kein "kompatibles" Antivirenprogramm installiert haben.

Leider wie erwartet keine Änderung auf einem Beema mit Windows 7.
 
Wenn ich das also richtig verstehe sind 2 von 3 Einfallstoren automatisch via IBPB + OS-Patch geschlossen und nur 1 User=> Kernel Space ist per default "offen" ?

User => Kernel-Space Zugriffe sind aber afaik nur dann problematisch wenn auf dem System Virtualisierung läuft. Denn dann könnte eben aus dem User der VM heraus der Kernel der VM hosts attackiert werden. ? Für Otto-Normalo aber eben nicht kritisch deswegen per default OFF ?

Vielleicht kann Complicated oder jemand anders mit mehr Ahnung die Patchvarianten etwas einordnen.

Das hast du missverstanden. Das beschriebene Szenario ist auf jedem Einzelplatzsystem vorhanden und nicht nur bei Virtualisierung. Nur ist es eben jener PoC, der das besitzen einer Teiladresse im Usermode (Benutzer) mit dem kombinieren von Adrerssen aus der branch prediction Daten aus dem geschützen Kernelmode (System) lesen kann. Genau das ist aber wegen der Nutzung von vollständigen Adressen in der branch prediction bei AMD ja nicht durchführbar gewesen als PoC.

User-to-kernel scenarios where a malicious user-mode application could use CVE-2017-5715 to disclose the contents of kernel memory. Disabled by default
Man kann wegen der vollständigen Adressen nicht Teile des kernel-memorys auslesen. Daher kann man es auch abgeschaltet lassen und muss keine Performance reduzieren.

Die beiden anderen Szenarien sind ja zum einen im eigenen User-Mode, benötigt also überhaupt keine anderen Rechte, da es um eine Anwendung im selben Modus geht die parallel ausgeführt wird und somit der User sowieso schon Leserechte darauf hat. Hier wird lediglich der umständliche Weg über die branch prediction geschlossen. (Und eventuelle App-Eigene Sicherheitsgrenzen gefestigt)

Und beim virtualisieren wird es ebenfalls geschlossen, da es keinen Grund gibt das offen zu lassen und das Zugreifen auf Hypervisor, Host und andere Gastsysteme aus Prinzip verhindert werden muss.

Der User-Space ist alles was der aktuell eingeloggte Benutzer macht. Der Kernel-Space ist alles was mit System-Root Rechten statt findet und zumeist für alle Benutzer funktionieren muss. Detailierter: https://de.wikipedia.org/wiki/Kernel_(Betriebssystem)
 
Zuletzt bearbeitet:
Heißt das, wenn man die Lücke ganz genau nimmt (was bei der AMD-Variante vermutlich nicht nötig ist), sollte man mit einem Phenom nicht mehr surfen?
Oder anders gefragt: bei alten CPUs wird keine Firmware nachgeladen und Windows hat keine eigenen Schutzmechanismen? Habe ich das so richtig verstanden?

EDIT: Scheint, als ob man mit Linux dank retpoline eh kein Problem hat. Was anderes würde ich auf ältere Kisten sowieso nicht installieren.
 
Zuletzt bearbeitet:
Ich blicke da langsam gar nicht mehr durch dank AMD, Intel und MS.
Habe einen PC mit älterer AMD APU und das Board bekommt wohl gar kein Updates mehr. Wie genau sehe ich 100 %tig was wie wo verwundbar ist? Nutze dort Win 10 wie auch beim Ryzen System.
Wie sehe ich das beim Ryzen 7 1700x Gigabyte GA-AB350M-Gaming 3 und hat wer das Board und weiß ob das letzte BIOS F22 OK ist und gut mit dem Ryzen zusammen läuft und mehr Sicherheit mitbringt? Ich frage, weil ein älteres BIOS ärger machte. War wohl Beta aber stand da leider auf der HP so direkt nicht. Hatte mir das dann zusammengereimt oder besser der Buchstabe a bei dem Namen ließ mich dann denken das es so ist.

Entschuldigt sollte das hier OT sein aber ich dachte hier passt es noch am ehesten rein.

Edit:
Habe im US Gigabyt Foren etwas gelesen und da ist auch nicht alles einfach zu verstehen. Damit meine ich nicht das US Englisch sondern, dass viele Infos da herum schwirren von wegen ältere BIOSE sind besser für RYZEN 1 und RAM oder das bestimmte neuere BIOSE auch nicht besser machen und Augenscheinlich Gigabyte es nicht hinbekommt ein ordentliches BIOS zu bauen wozu ich nicht viel sagen kann sondern nur das schreibe was die dort posten. Von den Updates für Spectre-Schutz und Co steht da leider gar nichts oder ich habe es überlesen.
 
Zuletzt bearbeitet:
Hallo!

Also auch die APUs (bis 2011 zurück) sollen doch neue Microcode-Updates von AMD erhalten.
Diese sind nur noch nicht erschienen. AMD MC hier!
Um welche APU handelt es sich denn (genaues Modell oder CPUID)?

Das neue F22 beinhaltet schon das neue AGESA v1.0.0.1a -> das ist gut.
Allerdings ist der MC für den R7 1700X -> CPUID 00800F11 immer noch auf Revision 1136 vom 18.01.2018.
Der neueste MC 800F11 Rev. 1137 ist aber vom 14.02.2018.


InSpectre #8 gibt Dir Auskunft darüber, inwieweit Dein System (BIOS, WIN, MC) aktuell/sicher ist.

Gruß, TM


--- Update ---

Hier das Gigabyte AB350M Gaming 3 rev1.x BIOS F22 mit aktuellem Microcode 800F11 rev.1137.
CRC32: 0DFF434E

!!! Ich gebe keine Garantie oder Gewährleistung auf dieses BIOS. !!!
Ich habe es aber nach besten Wissen und Gewissen erstellt.
 
Zuletzt bearbeitet:
@Tanzmusikus
Erst Mal danke.
Das Tool schaue ich mir sicher mal die Tage an.
Ob ich das BIOS Test was du gebaut hast weiß ich noch nicht. Habe im Moment keine Lust vielleicht doch ein kaputtes Mainboard zu haben. Ich warte mal ab. Vielleicht in ein paar Wochen wenn ich auch wieder genug Zeit fürs Basteln habe und weiß was ich mache wenn alles schief geht.
Würde dann auf was neues Updaten aber im Moment sind mir die GPUs von AMD einen Tick zu teuer (brauche aber so oder so in naher Zukunft eine schnellere) und ich warte auf erste Test und Infos zu den Ryzen 2 oder + oder was die gerade erscheinenden Rayzen genau sind. Vielleicht dann ein neues Board und RAM für den und meinen alten Ryzen mache ich auf ein neues kleines Board und nutze dort die GPU die ich da habe. Alles im Falle eines Problems.

Sag mal woher stammt die MC genau? Sind die offiziell von AMD und du hast die mit einem Tool die alten Teile gegen die Neuen ersetzt oder verstehe ich das alles etwas falsch?

Ansonsten noch Mal danke.

Edit: Ja, dass mit MC Updates stimmt so weit aber leider bauen nur wenige MB-Hersteller dies dann in ihre UEFIS und BIOSE ein. Welche APUs das genau sind auf den beiden gleichen Boarads schaue ich noch mal nach. Es müssten 2 x die gleichen APUs sein. Habe das System zweimal hinter einander gleich aufgebaut.
 
Zuletzt bearbeitet:
Ein BIOS-Flash ist heutzutage meist kein großes Risiko mehr, denn:
- die allermeisten Mainboards besitzen mittlerweile ein Dual-BIOS oder
- einige neue sogar ein BIOS, welches man ohne CPU, RAM usw. flashen kann.

Außerdem prüft z.B. ein BIOS-internes Flashtool immer die Checksumme, sodass kaum etwas schief gehen kann.
Damit auf dem Wege des Internets keine Bytes verändert werden oder verloren gehen, hier die CRC32: 0DFF434E.

InSpectre verrät Dir zumindest den jetztigen Sicherheitsstand. Bei AMD braucht man eh im Moment nicht zu bangen.

***

Die Microcodes auf Github sind extra dafür da, dass sich die (freien) Programmierer diese zu Nutze machen können.
Platomav hält die MC-Datenbank sehr aktuell. Viele haben schon von dort ihren MC geladen und genutzt.
Wie er an diese MCs kommt, weiß ich nicht. Bisher gibt es noch keine Beschwerden.

Eine andere Möglichkeit ist es, die Linux-Datenbanken zu durchforsten & dort die jeweiligen MCs zu extrahieren.
Kann sein, dass Platomav genau diesen Weg geht. Er hat das halt sehr übersichtlich gestaltet (für AMD, Intel, Via).

Geändert habe ich den Microcode einfach per HxD (Hex-Editor) und dann nochmals mit UBU (UEFI BIOS Updater) überprüft.
Da das PXE LAN Option ROM auch nicht ganz aktuell war, dass dann gleich mit aktualisiert.
Dadurch sollte auch die Checksumme aktualisiert sein.

Wie geht man beim Flashen am Besten vor?
CRC überprüfen, evtl. neu runterladen. Wenn Dein BIOS-internes Flashtool eine Fehlermeldung ausgibt, dann bitte nicht flashen!
Du kannst natürlich auch @BIOS über Windows nutzen. Ich rate davon ab, außer es geht über das BIOS-Flashtool nicht.
Man muss nämlich unter Windows den Antiviren- und sonstigen Schutz deaktivieren, dass kein Malheur passiert.

Bitte nur Flashen, wenn System stabil ist (Non-OC). Bitte niemals Stromzufuhr unterbrechen!

Wenn doch mal etwas nicht so läuft wie erwartet, dann bitte VORHER das bisherige BIOS auf USB-Stick sichern.
Oder die gleiche BIOS-Version von der Original-Webseite von Gigabyte parat haben.

Sollte man gar nicht mehr ins BIOS reinkommen danach (was ich nicht glaube, dazu habe ich zu wenig daran verändert), ...
... dann 3-5 mal das Netzteil während des Bootens (nicht Windows!!!, sondern noch beim Erkennen der Hardware durch das BIOS) ausschalten.
Man kann auch die Datenkabel der System SSDs/HDDs abziehen, damit nicht in Windows gebootet wird.

Irgendwann sollte dann ein Nachfrage-Option erscheinen, dass man das DualBIOS auf das bisherige wieder zurückflashen kann.
Eventuell gibt es auch einen DIP-Schalter zum Umschalten auf BIOS#2 -> den dann einfach benutzen (dann spart man sich das mehrmalige Ausschalten per Netzteil).
Wird das dann bestätigt, dann löscht das BIOS#2 das aktuelle BIOS#1 und ersetzt durch die alte funktioniernde Version.

***

Ich glaube nicht, dass Du das Board so leicht schrottest. Da musst Du schon Einiges sehr falsch angehen.
Die neuen Boards bringen Dir mit der 1xxxer Ryzen nicht viel, stellen aber auch kein Problem dar.
Es ist ja alles AM4-kompatibel, nur weinge Optionen bleiben dann einfach unbenutzt mit einer alten RyZEN.

:)
 
Zuletzt bearbeitet:
@Tanzmusikus
Danke.
Das Board ist einfach Mist. Es hat zwar dual UEFI aber das läuft nicht so gut. Habe dann beim ersten Board was ich hatte es geschafft das am Ende nichts mehr richtig ging und da ich einen PC brauchte nicht mehr mit beschäftigt und weil auf die Schnell nichts Anderes da war habe ich es noch mal genommen. Ich weiß, dass man eigentlich nicht viel kaputt machen kann aber bei meinem Glück in letzter Zeit bin ich halt vorsichtig.

Was RYZEN und neues Board angeht hat das noch anderer Gründe wieso ich den im Falle das alles kaputt ist oder nicht mehr geht ein Neues nehmen würde aber das führt zu weit. Also noch mal Danke für deine Infos und Hilfeversuche.
 
Hallo The_crow!

Hast Du nach dem BIOS-Flash die "Load Setup Defaults" oder "Load Optimal Defaults" geladen?

Wenn Du ganz sicher gehen willst, dann nimmst Du die BIOS-Batterie für 20 min raus und ziehst den NT-Stecker ab.
Dann noch Kippschalter des NTs auf "1" und ein-/zweimal auf die Powertaste drücken. Nun sollte die Restladung raus sein.

Es kann nämlich bei Veränderungen im BIOS dazu kommen, dass diese nicht wirksam werden, weil sich das BIOS bestimmte Einstellungen gemerkt hat.
Solch ein Reset hilft auch schon mal bei RAM-Erkennungsproblemen usw. ...

Grüße, TM

P.S.
Hast Du das BIOS mal ausprobiert?
Wenn Du das alte speicherst, kann Du jederzeit wieder zurückkehren.
Kann mir kaum vorstellen, dass das Board da so extrem zickig ist.
Vielleicht hast Du auch nicht alles beachtet bei Deinem Vorgehen. *noahnung*

--- Update ---

Es gibt übrigens seit vorgestern ein neues BIOS F23d mit AGESA 1.0.0.2a und SMU FW.

Ich kann mir das nachher mal anschauen & auf neuen Microcode usw. untersuchen sowie ggf. updaten, was geht.

Aber hast Du überhaupt Interesse daran, oder willst Du das Board loswerden?

--- Update ---

Was ich sehen kann - sie haben das neue MC 800F11 rev.1137 gleich mit eingebaut & viele andere MCs auch.
Kannst also direkt dieses BIOS flashen. Mein Dir verlinktes BIOS ist damit hinfällig. ;)
 
@Tanzmusikus
Ich habe gar nichts gemacht nach dem nichts mehr richtig ging. Das Problem ist so weit behoben. Es lag definitiv am BIOS oder doch am Board selber das irgendwie gar nicht wollte und am Ende war ich im Backup BIOS und habe dann wohl unbedacht noch mehr kaputt gemacht weil das mit dem Backup UEFI/BIOS echt blöde gelöst ist bei dem Board. Habe da herum gemacht weil win 10 wollte nicht mehr herunterfahren wollte mit dem UEFI mit A am Ende und das war es dann wohl vor einigen Monaten gewesen.
Ist auch das erste Mal das es nicht so ging wie gedacht und dabei habe ich schon sicher in meinem Leben einen ganzen Haufen an Systemen, PC und Andere, mit neuen BIOSen versorgt und hatte nur dieses und ein anderes Mal solchen Ärger. Bei dem Board ist das mit dem Backup BISO/UEFI nicht gut gelöst finde ich. Es war ein UEFI mit a am Ende und es stand nichts dabei was das A bedeutete und ich habe erst später mitbekommen es könnte Beta gewesen sein.
Also irgendwie schafft es anscheinend Gigabyte nicht ordentlich zu testen und dazu zu schreiben ob das BIOS final ist oder nicht. Das schreiben auch einige im US Forum von Gigabyte. Ich probiere keines mehr mit Buchstaben nach den Zahlen von Gigabyte aus für dieses Board wenn ich da überhaupt noch mal was teste. Vielleicht kaufe ich einfach später noch mal was ganz Neues aber vielleicht nicht mehr von Gigabyte mal sehen. Im Moment ist es eben ungepatcht und gut. Kann man halt nichts machen. Was ich mir vielleicht noch mal ansehe sind die anderen Boards wo die APUs drauf sind. Da melde ich mich aber direkt noch mal wenn ich die Tage Zeit habe.


Danke an dich für deine Hilfen und ich hoffe du versteht was ich geschrieben habe. Ist nicht einfach schriftlich zu erklären.
 
Ja, ich verstehe es ein bisschen.

Ich an Deiner Stelle würde allerdings das neue F23d mal ausprobieren.
Zurück kommst Du ja immer noch. Du weißt ja jetzt wie dieses UEFI "tickt".

Ist natürlich Deine Entscheidung.
Keine Ahnung, was Du für wichtige Daten im System hast und will Dich deswegen nicht überreden.

Na dann viel Glück weiterhin!!

***

Ich werde mir Ende des Jahres ein RyZEN 2+ (12nm) + X470-Board holen ... oder später, wenn die RAM-Preise weiter so teuer bleiben.

Danke für Dein Danke!
 
@Tanzmusikus
Vielleicht teste ich es aber nicht im Moment denke ich. Habe da im Moment nicht genug Ruhe dazu.
Ob ich nun weiß wie UEFI auf dem Board tickt keine Ahnung. Ansonsten weiß ich schon was UEFI an sich ist und was das kann oder können sollte aber das hat leider nicht geholfen weil das Board einfach komisch ist oder das UEFI ich weiß einfach nicht und daher auch meine Vorsicht. Gigabyte hat das alles wohl hier etwas anderes Aufgebaut und daher muss ich mir das alles noch mal ansehen damit ich weiß wie das mit dem Backup UEFI genau gedacht ist bei dem Board und ich, wenn was nicht läuft, nicht das falsche Überspiele sondern das erste was vielleicht dann nicht macht was es soll.

Lassen wir das einfach mal so stehen. Sonst drehen wir uns im Kreis. Wenn ich noch was wissen will oder brauche melde ich mich noch mal.
 
Zurück
Oben Unten