[Sammelthread] Intel Microcodes patchen - mod BIOS - uCodes Bootloader - OS Patch - Spectre II

Marcellus5000 · 21.01.2018

floogy schrieb:
Das soll scheinbar optimiert werden:
Re: Geht nicht | Forum - heise online

Hab ich auch gelesen (nehme an, der Poster ist da involviert)
Windows: How to get latest CPU microcode without modding the BIOS | Page 4 | guru3D Forums

Aber bis es so weit ist, würde ich es nicht kommentarlos verlinken. Sonst stolpern die Leute immer wieder über die gleichen Probleme und der Thread wächst ins Nirvana.

Marcellus5000 · 22.01.2018

kroxx schrieb:
Nicht die Sache, sondern die Meldungen auf hardwareLUXX

Ich hoffe Du bleibst uns hier dennoch erhalten. Wäre schade, aus dem Thread könnte was werden.

kroxx · 22.01.2018

Ja, klar.
Ich habe mich konkret auf diese zwei Meldungen bezogen:

Intel kämpft mit schwerer Sicherheitslücke (21. Update: Intel versieht hunderte Prozessoren mit Microcode-Update)
Präsens wird im Deutschen ja manchmal wie Futur verwendet. Aber man könnte auch sagen: Das ist so, wie es da steht, schlichtweg falsch.

... und dann natürlich noch die hier:
Weitere Sicherheitslücken: Auf Spectre und Meltdown könnten Skyfall und Solace folgen

Haben wir denn schon April? :haha:

AliManali · 22.01.2018

Hi

Ich habe den Guide nun etwas allgemeiner gestaltet. Neben mod BIOS habe ich nun auch die Aspekte:

Überprüfung der Mitigation gegen Spectre und Meltdown
Gefixte CPU's bzw. Plattformen
per Bootloader uCodes nachladen
im OS Microcode nachladen
benötigte OS Patches
Anwendungen patchen

mit dazu genommen.

Weitere Vorschläge und Infos werden gerne gesehen. Insbesondere zu den Gefixte CPU's und Plattformen, Bedrohungen, Bootloader, OS Patches und Anwendungen patchen brauch ich noch mehr Input.

MAG66 · 22.01.2018

Hallo,

@AliManali

Der Abschnitt Im OS Microcode nachladen ist keine Lösung, m.E. führt das bei dem Leser nur zur Verwirrung. Der Microcode muss vor dem OS-Kernel geladen werden.
Den VMWare-Treiber kann man verwenden, um festzustellen, ob die Microcode-Datei die eigene CPU bereits unterstützen würde oder eben nicht. Aber wenn man bereits einen Bootloader vorbereitet hat, den man ohne BIOS-Fix des Boardherstellers sowieso benötigt, dann ist der VMWare-Treiber dbzgl. ebenfalls überflüssig.

Gefixte CPU's
4770K Haswell, Family 6, Model C, Stepping 3, Rev C0

floogy · 22.01.2018

Es kann gut sein, dass das der tiefere Grund ist, weshalb microsoft (noch) keinen microcode mit den Sicherheits-Rollups ausliefert (neben Reboots, Performanceeinbußen und anderen Problemen).

hawk7000 schrieb:
mbk1969 said: ↑ schrieb:

Looks like Windows store microcodes right inside two DLLs - "mcupdate_AuthenticAMD.dll" and "mcupdate_GenuineIntel.dll" located in "C:\Windows\System32". I was hoping for raw binary files. Will see if I can spot known microcodes there...

Zum Vergrößern anklicken....

It's also unclear if that would do any better than the Vmware tool, it's entirely possible it would also apply the microcode update too late to work with the spectre mitigation.

guru-3d | Windows: How to get latest CPU microcode without modding the BIOS, #75 (Dank an Marcellus 5000)

Es ist wohl schwierig das in den schon laufenden Kernel zu heben und die zusätzlichen Funktionen so effektiv zur Umschiffung der CPU-Probleme zu nutzen.

Seit Windows 7 ist Microsoft in der Lage ein Microcode-Update auch per OS-Update zu realisieren.

Intel kämpft mit schwerer Sicherheitslücke (Update: Intel veröffentlicht Server-Benchmarks) - Hardwareluxx

Die Frage ist, ob Microsoft und Vmware es schaffen werden den µcode früh genug auf die CPU zu bringen, so dass der Kernel diesen rechtzeitig berücksichtigen kann.

Zu den neu unterstützten CPUs (Intel upstream microcode datafile 20180108)

Code:

intel-microcode (3.20180108.0~ubuntu16.04.2) xenial-security; urgency=medium

  * New upstream microcode datafile 20180108
    + New Microcodes:
      sig 0x000506c9, pf_mask 0x03, 2017-03-25, rev 0x002c, size 16384
      sig 0x000706a1, pf_mask 0x01, 2017-12-26, rev 0x0022, size 73728
      sig 0x000906ea, pf_mask 0x22, 2018-01-04, rev 0x0080, size 97280
      sig 0x000906eb, pf_mask 0x02, 2018-01-04, rev 0x0080, size 98304
    + Updated Microcodes:
      sig 0x000306c3, pf_mask 0x32, 2017-11-20, rev 0x0023, size 23552
      sig 0x000306d4, pf_mask 0xc0, 2017-11-17, rev 0x0028, size 18432
      sig 0x000306e4, pf_mask 0xed, 2017-12-01, rev 0x042a, size 15360
      sig 0x000306f2, pf_mask 0x6f, 2017-11-17, rev 0x003b, size 33792
      sig 0x000306f4, pf_mask 0x80, 2017-11-17, rev 0x0010, size 17408
      sig 0x00040651, pf_mask 0x72, 2017-11-20, rev 0x0021, size 22528
      sig 0x00040661, pf_mask 0x32, 2017-11-20, rev 0x0018, size 25600
      sig 0x00040671, pf_mask 0x22, 2017-11-17, rev 0x001b, size 13312
      sig 0x000406e3, pf_mask 0xc0, 2017-11-16, rev 0x00c2, size 99328
      sig 0x00050654, pf_mask 0xb7, 2017-12-08, rev 0x200003c, size 27648
      sig 0x00050662, pf_mask 0x10, 2017-12-16, rev 0x0014, size 31744
      sig 0x00050663, pf_mask 0x10, 2017-12-16, rev 0x7000011, size 22528
      sig 0x000506e3, pf_mask 0x36, 2017-11-16, rev 0x00c2, size 99328
      sig 0x000806e9, pf_mask 0xc0, 2018-01-04, rev 0x0080, size 98304
      sig 0x000806ea, pf_mask 0xc0, 2018-01-04, rev 0x0080, size 98304
      sig 0x000906e9, pf_mask 0x2a, 2018-01-04, rev 0x0080, size 98304
   * source: remove unneeded intel-ucode/ directory
   * source: remove superseded upstream data file: 20170707

Bzw.:

Code:

-- Updates [B][color=red]upon[/color][/B] 20171117 release --
IVT C0        (06-3e-04:ed) 428->42a
SKL-U/Y D0    (06-4e-03:c0) ba->c2
BDW-U/Y E/F    (06-3d-04:c0) 25->28
HSW-ULT Cx/Dx    (06-45-01:72) 20->21
Crystalwell Cx    (06-46-01:32) 17->18
BDW-H E/G    (06-47-01:22) 17->1b
HSX-EX E0    (06-3f-04:80) 0f->10
SKL-H/S R0    (06-5e-03:36) ba->c2
HSW Cx/Dx    (06-3c-03:32) 22->23
HSX C0        (06-3f-02:6f) 3a->3b
BDX-DE V0/V1    (06-56-02:10) 0f->14
BDX-DE V2    (06-56-03:10) 700000d->7000011
KBL-U/Y H0    (06-8e-09:c0) 62->80
KBL Y0 / CFL D0    (06-8e-0a:c0) 70->80
KBL-H/S B0    (06-9e-09:2a) 5e->80
CFL U0        (06-9e-0a:22) 70->80
CFL B0        (06-9e-0b:02) 72->80
SKX H0        (06-55-04:b7) 2000035->200003c
GLK B0        (06-7a-01:01) 1e->22

sig 0x000406e3, pf_mask 0xc0, 2017-11-16, rev 0x00c2, size 99328
entspricht wohl
SKL-U/Y D0 (06-4e-03:c0) ba->c2 ?

Ja, die Stellen in der Signatur sind vertauscht. Ich habe das mal umgestellt und zugeordnet: show at bpaste

Code:

sig 0x000506c9, pf_mask 0x03, 2017-03-25, rev 0x002c, size 16384        06-5c-09
sig 0x000706a1, pf_mask 0x01, 2017-12-26, rev 0x0022, size 73728        06-7a-01        GLK B0        (06-7a-01:01) 1e->22
sig 0x000906ea, pf_mask 0x22, 2018-01-04, rev 0x0080, size 97280        06-9e-0a        CFL U0        (06-9e-0a:22) 70->80
sig 0x000906eb, pf_mask 0x02, 2018-01-04, rev 0x0080, size 98304        06-9e-0b        CFL B0        (06-9e-0b:02) 72->80
sig 0x000306c3, pf_mask 0x32, 2017-11-20, rev 0x0023, size 23552        06-3c-03        HSW Cx/Dx    (06-3c-03:32) 22->23
sig 0x000306d4, pf_mask 0xc0, 2017-11-17, rev 0x0028, size 18432        06-3d-04        BDW-U/Y E/F    (06-3d-04:c0) 25->28
sig 0x000306e4, pf_mask 0xed, 2017-12-01, rev 0x042a, size 15360        06-3e-04        IVT C0        (06-3e-04:ed) 428->42a
sig 0x000306f2, pf_mask 0x6f, 2017-11-17, rev 0x003b, size 33792        06-3f-02        HSX C0        (06-3f-02:6f) 3a->3b
sig 0x000306f4, pf_mask 0x80, 2017-11-17, rev 0x0010, size 17408        06-3f-04        HSX-EX E0    (06-3f-04:80) 0f->10
sig 0x00040651, pf_mask 0x72, 2017-11-20, rev 0x0021, size 22528        06-45-01        HSW-ULT Cx/Dx    (06-45-01:72) 20->21
sig 0x00040661, pf_mask 0x32, 2017-11-20, rev 0x0018, size 25600        06-46-01        Crystalwell Cx    (06-46-01:32) 17->18
sig 0x00040671, pf_mask 0x22, 2017-11-17, rev 0x001b, size 13312        06-47-01        BDW-H E/G    (06-47-01:22) 17->1b
sig 0x000406e3, pf_mask 0xc0, 2017-11-16, rev 0x00c2, size 99328        06-4e-03        SKL-U/Y D0    (06-4e-03:c0) ba->c2
sig 0x00050654, pf_mask 0xb7, 2017-12-08, rev 0x200003c, size 27648     06-55-04        SKX H0        (06-55-04:b7) 2000035->200003c
sig 0x00050662, pf_mask 0x10, 2017-12-16, rev 0x0014, size 31744        06-56-02        BDX-DE V0/V1    (06-56-02:10) 0f->14
sig 0x00050663, pf_mask 0x10, 2017-12-16, rev 0x7000011, size 22528     06-56-03        BDX-DE V2    (06-56-03:10) 700000d->7000011
sig 0x000506e3, pf_mask 0x36, 2017-11-16, rev 0x00c2, size 99328        06-5e-03        SKL-H/S R0    (06-5e-03:36) ba->c2
sig 0x000806e9, pf_mask 0xc0, 2018-01-04, rev 0x0080, size 98304        06-8e-09        KBL-U/Y H0    (06-8e-09:c0) 62->80
sig 0x000806ea, pf_mask 0xc0, 2018-01-04, rev 0x0080, size 98304        06-8e-0a        KBL Y0 / CFL D0    (06-8e-0a:c0) 70->80
sig 0x000906e9, pf_mask 0x2a, 2018-01-04, rev 0x0080, size 98304        06-9e-09        KBL-H/S B0    (06-9e-09:2a) 5e->80

Mich würde nun interessieren, wie man am sinnvollsten den microcode per GRUB vor dem Starten Windows laden kann, oder ob das, und aus welchen Gründen, nur per BITS funktioniert. Ein zusätzlichen USB-Stick finde ich jetzt nicht so toll, aber besser als nichts.

Eine weitere Frage wäre, wegen der Performanceeinbuße bei Spectre v2, ob Microsoft (oder Intel und AMD) googles retpoline gegen Spectre v2 implementieren kann. Diese Methode soll nahezu ohne Performanceeinbuße funktionieren.

h00bi · 22.01.2018

AliManali schrieb:
Ja, ich war da auch einige Stunden dran seit Mittwoch Abend

Das sieht man. Tolle Zusammenstellung, vielen Dank :bigok:

friendlyfire · 22.01.2018

MAG66 schrieb:
Hallo,

@AliManali

Der Abschnitt Im OS Microcode nachladen ist keine Lösung, m.E. führt das bei dem Leser nur zur Verwirrung. Der Microcode muss vor dem OS-Kernel geladen werden.
Den VMWare-Treiber kann man verwenden, um festzustellen, ob die Microcode-Datei die eigene CPU bereits unterstützen würde oder eben nicht. Aber wenn man bereits einen Bootloader vorbereitet hat, den man ohne BIOS-Fix des Boardherstellers sowieso benötigt, dann ist der VMWare-Treiber dbzgl. ebenfalls überflüssig.

Gefixte CPU's
4770K Haswell, Family 6, Model C, Stepping 3, Rev C0

Das ist korrekt!

Bitte meinen Beitrag aus dem Tutorial dementsprechend anpassen!

Auch ist meine Aussage, dass für Broadwell-E kein neues Bios kommt mit Vorsicht zu genießen. Asrock hat offiziell bestätigt, dass für x99 was kommt.

Ich rate jedem hier ausdrücklich auf den neuen Microcode von Intel zu warten. Der vom 08.01.2018 ist fehlerhaft!

MAG66 · 22.01.2018

@floggy

Wenn ich mir das Repository von BITS ansehe, dann würde ich mal behaupten, dass man BITS (welches GRUB als Grundlage hat) benötigt. Oder anders formuliert, die notwendigen Funktionen zum Laden der Microcodes werden mit hoher Wahrscheinlichkeit in GRUB nicht implementiert sein (siehe https://github.com/biosbits/bits/blob/master/rc/mcu/mcu.c)

Marcellus5000 · 22.01.2018

kroxx schrieb:
Ja, klar.
Ich habe mich konkret auf diese zwei Meldungen bezogen:

Intel kämpft mit schwerer Sicherheitslücke (21. Update: Intel versieht hunderte Prozessoren mit Microcode-Update)
Präsens wird im Deutschen ja manchmal wie Futur verwendet. Aber man könnte auch sagen: Das ist so, wie es da steht, schlichtweg falsch.

... und dann natürlich noch die hier:
Weitere Sicherheitslücken: Auf Spectre und Meltdown könnten Skyfall und Solace folgen

Haben wir denn schon April?

Achso. Dann ist ja gut

Ja da (erste Meldung) bin ich auch schon drüber gestolpert: Intel kämpft mit schwerer Sicherheitslücke (Update: Intel veröffentlicht Server-Benchmarks) - Seite 48

edit: Ja das mit April kommt hin, wenn ich die zweite Meldung lese. :fresse:

floogy · 22.01.2018

MAG66 schrieb:
@floggy

Wenn ich mir das Repository von BITS ansehe, dann würde ich mal behaupten, dass man BITS (welches GRUB als Grundlage hat) benötigt. Oder anders formuliert, die notwendigen Funktionen zum Laden der Microcodes werden mit hoher Wahrscheinlichkeit in GRUB nicht implementiert sein (siehe bits/mcu.c at master Â· biosbits/bits Â· GitHub)

SKL-U/Y D0 (06-4e-03:c0) ba->c2

Ext. Family: 6
Ext. Model: 4e
Stepping: 3
ba ->c2: c2 wird die rev des neuen Microcodes sein

Daher müsste das m.E. so aussehen:
sig 0x000306e4, pf_mask 0xed, 2017-12-01, rev 0x042a, size 15360 --> SKL-U/Y D0 (06-4e-03:c0) ba->c2

Laut dem Arch-Wiki, und auch gemäß meinen Beobachtungen, enthält auch GRUB2 code um microcode auf die CPU zu laden. Microcode - ArchWiki und hier GitHub | grub2 /etc/grub.d/10_linux microcode patch. Es kann natürlich sein, dass das archspezifisch ist und ubuntu das anders in die initrd patcht. Es kann dann sein, dass man unter ubuntu den Grub daher nicht ohne weiteres dazu bewegen kann den microcode auf die CPU zu laden, bevor er Windows oder den Windows Loader startet.

EDIT: Hm, es scheint wohl doch der Kernel zu sein, der den microcode läd? Es gibt einen Mechanismus in Grub2 um den Kernel anzuweisen den microcode NICHT zu laden (Falls der microcode Bootschwierigkeiten verursacht). Microcode - Debian Wiki Diesen Mechanismus hatte ich wohl verwechselt mit code zum Laden des microcodes. Es könnte sich also doch so verhalten, dass grub2 nur in der BITS-Variante dazu in der Lage ist.

Ich glaube, dass mein Skript doch die richtige Zuordnung ermittelt hat, da rev 0x00c2 die rev des neuen Microcodes sein wird.
sig 0x000406e3, pf_mask 0xc0, 2017-11-16, rev 0x00c2, size 99328 06-4e-03 SKL-U/Y D0 (06-4e-03:c0) ba->c2

In der sig sind 4 und 6 vertauscht. Das e wandert zur 4. Weshalb das so ist weiß ich nicht, aber so geht es auf, wenn man sich die rev der µcodes ansieht.

MAG66 · 22.01.2018

In Intel's aktuellem Whitepaper ist bereits die Rede von "Retpoline" (see https://newsroom.intel.com/wp-content/uploads/sites/11/2018/01/Intel-Analysis-of-Speculative-Execution-Side-Channels.pdf)
Allerdings wird auch in diesem Zusammenhang auf das Thema Microcode eingegangen. Damit das o.g. effektiv funktioniert, benötigen Broadwell und die Nachfolger ein Microcode-Update. Im Umkehrschluß könnte man jetzt mutmaßen - entweder funktioniert's bei den anderen ohne ein Update oder gar nicht ...

floogy · 22.01.2018

Das ist doch vielversprechend, dann wird retpoline auch für Windows nutzbar und die Performanceeinbuße z.B. bei SSD i/o werden doch noch korrigiert.

Ich habe im freenode #grub chat mal nachgefragt. GRUB kann zwar mehrere initrds laden, weshalb es den linux-kernel auch mit microcode versorgen kann, den er dann früh auf die CPU laden kann (? bzw. wird der überhaupt "auf die CPU geladen", vielleicht in einen der L1-L3 caches?), aber GRUB läd den microcode und die initrd in den Speicher und weist den kernel an zu starten und diese zu laden und auszuführen. Da Windows kein Konzept für initrd hat müsste also GRUB den microcode auf die CPU laden, was BITS mit mcu.c macht. GRUB unterstützt module. Man könnte ihn wohl leicht um so ein modul erweitern. Vielleicht macht das nun jemand? Mal sehen, wie weit vmware mit seinem tool kommt, oder ob Microsoft, wenn der Code gut genug sein sollte das übernimmt. Bis dahin gibt es wohl nur BIOS updaten, das BIOS patchen oder eben der BITS-USB-Stick.

Marcellus5000 · 22.01.2018

MAG66 schrieb:
Im Umkehrschluß könnte man jetzt mutmaßen - entweder funktioniert's bei den anderen ohne ein Update oder gar nicht ...

Ich tippe ja auf eher garnicht.

floogy schrieb:
oder eben der BITS-USB-Stick.

By the Way. Hat Irgendwer hier ausser MAG66 ein automatisiertes Starten mit dem Stick hinbekommen?
Bei mir klappt es ja nur halbautomatisch und ich habe (durch den Job bedingt) leider aktuell keine Zeit, mich weiter rein zu knien.

Marcellus5000 schrieb:
..mit Deinem Eintrag bootet das System bei mir in Schleife.

Ich habe stattdessen nun folgendes die toplevel.cfg konfiguriert:

if [ -e /boot/cfg/init.cfg ]; then source /boot/cfg/init.cfg; fi
if mcu_load /boot/mcu; then configfile /boot/cfg/boot.cfg; fi

Nun muß ich noch manuell auswählen, von welcher HD ich booten will. Aber der Microcode wird automatisch geladen.
Da es der erste Eintrag im Menü ist, muß ich also nur einmal Enter drücken und er bootet die erste HD...

Marcellus5000 · 22.01.2018

@AliManali das Howto ist schön geworden.

Jetzt muß noch ein Mod die ersten Posts löschen. Frag doch ggf. mal fdsonne via PM, der ist einer.
Ggf. könntest Du bei dem UBU Tool Part noch folgendes aus diesem Screenshot aus meinenen eigenen Notizen einbringen (also ggf. nicht den Screenshot aber das Prinzip. Kannst den aber auch gerne nutzen), bezüglich der Nutzung von HWINFO.
Habe leider aktuell nicht so viel Zeit aber ich denke Du weisst, worauf ich hinaus will:

Der Link ist imo auch ganz gut zu Übersicht:
https://newsroom.intel.com/wp-content/uploads/sites/11/2018/01/microcode-update-guidance.pdf

AliManali · 22.01.2018

floogy schrieb:

Zu den neu unterstützten CPUs (Intel upstream microcode datafile 20180108):

Code:

intel-microcode (3.20180108.0~ubuntu16.04.2) xenial-security; urgency=medium

  * New upstream microcode datafile 20180108
    + New Microcodes:
      sig 0x000506c9, pf_mask 0x03, 2017-03-25, rev 0x002c, size 16384
      sig 0x000706a1, pf_mask 0x01, 2017-12-26, rev 0x0022, size 73728
      sig 0x000906ea, pf_mask 0x22, 2018-01-04, rev 0x0080, size 97280
      sig 0x000906eb, pf_mask 0x02, 2018-01-04, rev 0x0080, size 98304
    + Updated Microcodes:
      sig 0x000306c3, pf_mask 0x32, 2017-11-20, rev 0x0023, size 23552
      sig 0x000306d4, pf_mask 0xc0, 2017-11-17, rev 0x0028, size 18432
      sig 0x000306e4, pf_mask 0xed, 2017-12-01, rev 0x042a, size 15360
      sig 0x000306f2, pf_mask 0x6f, 2017-11-17, rev 0x003b, size 33792
      sig 0x000306f4, pf_mask 0x80, 2017-11-17, rev 0x0010, size 17408
      sig 0x00040651, pf_mask 0x72, 2017-11-20, rev 0x0021, size 22528
      sig 0x00040661, pf_mask 0x32, 2017-11-20, rev 0x0018, size 25600
      sig 0x00040671, pf_mask 0x22, 2017-11-17, rev 0x001b, size 13312
      sig 0x000406e3, pf_mask 0xc0, 2017-11-16, rev 0x00c2, size 99328
      sig 0x00050654, pf_mask 0xb7, 2017-12-08, rev 0x200003c, size 27648
      sig 0x00050662, pf_mask 0x10, 2017-12-16, rev 0x0014, size 31744
      sig 0x00050663, pf_mask 0x10, 2017-12-16, rev 0x7000011, size 22528
      sig 0x000506e3, pf_mask 0x36, 2017-11-16, rev 0x00c2, size 99328
      sig 0x000806e9, pf_mask 0xc0, 2018-01-04, rev 0x0080, size 98304
      sig 0x000806ea, pf_mask 0xc0, 2018-01-04, rev 0x0080, size 98304
      sig 0x000906e9, pf_mask 0x2a, 2018-01-04, rev 0x0080, size 98304
   * source: remove unneeded intel-ucode/ directory
   * source: remove superseded upstream data file: 20170707

Code:

-- Updates [B][color=red]upon[/color][/B] 20171117 release --
IVT C0        (06-3e-04:ed) 428->42a
SKL-U/Y D0    (06-4e-03:c0) ba->c2
BDW-U/Y E/F    (06-3d-04:c0) 25->28
HSW-ULT Cx/Dx    (06-45-01:72) 20->21
Crystalwell Cx    (06-46-01:32) 17->18
BDW-H E/G    (06-47-01:22) 17->1b
HSX-EX E0    (06-3f-04:80) 0f->10
SKL-H/S R0    (06-5e-03:36) ba->c2
HSW Cx/Dx    (06-3c-03:32) 22->23
HSX C0        (06-3f-02:6f) 3a->3b
BDX-DE V0/V1    (06-56-02:10) 0f->14
BDX-DE V2    (06-56-03:10) 700000d->7000011
KBL-U/Y H0    (06-8e-09:c0) 62->80
KBL Y0 / CFL D0    (06-8e-0a:c0) 70->80
KBL-H/S B0    (06-9e-09:2a) 5e->80
CFL U0        (06-9e-0a:22) 70->80
CFL B0        (06-9e-0b:02) 72->80
SKX H0        (06-55-04:b7) 2000035->200003c
GLK B0        (06-7a-01:01) 1e->22

Kann mir einer sagen, wie ich anhand der CPU ID die jeweilige Plattform, bzw. CPU ermitteln kann? Gibts da eine Liste mit den verwendeten Chipsätzen?

Und ein Link mit den aktuellen stable uCodes? Ich kann da nur anhand des Datums raten, ob jetzt da die betreffenden Updates zu den Bedrohungen schon drin sind.

Z.B. sig 0x000306c3, pf_mask 0x32, 2017-11-20, rev 0x0023, size 23552

Das ist ja vom 20.11.2017. Ist das schon gepacht?

Und kann mal ein Mod bitte Post 1-7 löschen, dass #8 der Erste ist?

Gruss und Danke!

Marcellus5000 · 22.01.2018

AliManali schrieb:
Kann mir einer sagen, wie ich anhand der CPU ID die jeweilige Plattform, bzw. CPU ermitteln kann?
Gruss und Danke!

Das zeigt Dir UBU Tool an, wenn Du das mit Deinem Stock Bios "fütterst", schau Dir nochmal meinen Screenshot von 22:33 Uhr an. Das ist eine Kobi aus dem Programm HWINFO (oben) UBU Tool (links unten) und einem (aus dem Microcode.dat extrahierten) bin File.

AliManali · 22.01.2018

Ja, das ist mir schon klar. Nur habe ich nicht all die Systeme

Marcellus5000 · 22.01.2018

Achso Du willst eine Liste machen. OK die musst Du dann aber auch pflegen. Wenn Du postest, wie sich das jeder selbst zieht, kommst Du besser weg

AliManali · 22.01.2018

Ist mir für meine eigenen Plattformen schon zu kompliziert. Ich hatte bislang immer die microcode.dat von Intel extrahiert, und die CPU ID mit den extrahierten uCode Files verglichen. Da steht die CPU ID, uCU Version und das Datum im Datei Namen. Aber wie gesagt, ich kann nur raten, ob die jetzt schon gepacht sind.

Bsp. :

cpu000206d7_plat0000006d_ver00000710_date20130617.bin

Das wär für meine x79 Sandy Bitches.

Ein Link mit einer Tabelle, die aktualisiert wird wär nice!

andre117 · 22.01.2018

Intel hat jetzt gesagt "Übrigens, das ganze war nur ein Witz, bitte nicht mehr updaten..." - Die richtigen Microcode Updates kommen später:

microcode-update-guidance.pdf

AliManali · 22.01.2018

Danke!

Marcellus5000 · 22.01.2018

AliManali schrieb:
Ist mir für meine eigenen Plattformen schon zu kompliziert. Ich hatte bislang immer die microcode.dat von Intel extrahiert, und die CPU ID mit den extrahierten uCode Files verglichen. Da steht die CPU ID, uCU Version und das Datum im Datei Namen. Aber wie gesagt, ich kann nur raten, ob die jetzt schon gepacht sind.

Bsp. :

cpu000206d7_plat0000006d_ver00000710_date20130617.bin

Das wär für meine x79 Sandy Bitches.

Ein Link mit einer Tabelle, die aktualisiert wird wär nice!

OK ich glaube, ich verstehe jetzt Deine Intention. Es geht Dir darum, die Release Notes Datei aus dem Microcode Download Gesammtarchiv "human readable" zu machen? (In welcher ja steht, was gepatched wurde. Wenn man davon ausgeht, dass die 20180108 die erste mit Spectre fixen ist. Man also davon ausgeht, dass alle dort augeführten und alle CPU in späteren Gesammtarchiven aufgeführten, gefixt sind)

- - - Updated - - -

AliManali schrieb:
Danke!

Bitte

Marcellus5000 schrieb:
Der Link ist imo auch ganz gut zu Übersicht:
https://newsroom.intel.com/wp-content/uploads/sites/11/2018/01/microcode-update-guidance.pdf

AliManali · 22.01.2018

andre117 schrieb:
Intel hat jetzt gesagt "Übrigens, das ganze war nur ein Witz, bitte nicht mehr updaten..." - Die richtigen Microcode Updates kommen später:

microcode-update-guidance.pdf

Intel did not post a variant #2 mitigation MCU for this product

Sandy Bridge E, EN, EP, EP4S; 206D7, uCU v 0x710

Aber ich denke, da kommt zeitnah was. Hoffe ich.

- - - Updated - - -

kroxx schrieb:
@ AliManali:

... ach ja: Und wenn Du das MMTool hier verlinkst, kann es Ärger mit AMI geben.

Wieso denn?

Marcellus5000 · 22.01.2018

AliManali schrieb:
Wieso denn?

rtfm...

Forum - [Tool Guide+News] (UBU)
Important: The currently available UBU tool versions require the presence of the AMI Aptio V UEFI MMTool v5.0.0.7 named MMTool.exe within the UBU folder. Since the currently linked UBU packages do not contain the related file (due to restrictions by the Company AMI), the user will only be able to use the UBU tool after having added the file named MMTool into the UBU folder. You may find a link to the missing MMTool.exe, if you do a Google search for "MMTool v5.0.0.7".

floogy · 23.01.2018

AliManali schrieb:
Intel schrieb:

Intel did not post a variant #2 mitigation MCU for this product

Zum Vergrößern anklicken....

Sandy Bridge E, EN, EP, EP4S; 206D7, uCU v 0x710
Aber ich denke, da kommt zeitnah was. Hoffe ich.

Danke Intel!

kroxx · 23.01.2018

kroxx schrieb:
@ AliManali:

... ach ja: Und wenn Du das MMTool hier verlinkst, kann es Ärger mit AMI geben.

AliManali schrieb:
Wieso denn?

Marcellus5000 hat das ja schon wunderbar erklärt.
Vorschlag: Verweise doch bezüglich weiterer zu verwendender Tools - ganz unverfänglich - auf diese Sammlung hier:
https://forums.tweaktown.com/gigabyte/30530-overclocking-programs-system-info-benchmarking-stability-tools.html

Guck mal, was man da alles Schönes findet ... :hust:

The Professor · 23.01.2018

Sehe ich das eigentlich richtig, dass ich mit meiner Z77 Plattform und meiner Ivy Bridge in die Röhre gucken werde? Ich mein bin mit der Plattform super zufrieden, aber wie ein Schweizer Käse wollte ich auch nicht rumfahren

Und zu Z77 gibts eigentlich gar keine Aussage bzw ASUS plant da wohl nichts, µCode für Ivy gibts soweit noch Right?

Marcellus5000 · 23.01.2018

Marcellus5000 schrieb:
Ich habe stattdessen nun folgendes die toplevel.cfg konfiguriert:

if [ -e /boot/cfg/init.cfg ]; then source /boot/cfg/init.cfg; fi
if mcu_load /boot/mcu; then configfile /boot/cfg/boot.cfg; fi

Nun muß ich noch manuell auswählen, von welcher HD ich booten will. Aber der Microcode wird automatisch geladen.
Da es der erste Eintrag im Menü ist, muß ich also nur einmal Enter drücken und er bootet die erste HD. Da kann ich vorerst auch mit leben.

Ich hatte heute Morgen vor der Arbeit eine Eingebung

Das fett markierte oben in die boot\cfg\boot.cfg dazu:

set timeout=02

menuentry "Boot first drive MBR" {
set root=(hd1)
drivemap (hd1) (hd0)
chainloader +1
}

menuentry "Boot second drive MBR" {
set root=(hd2)
drivemap (hd2) (hd0)
chainloader +1
}

Nun bootet das Ding vollautomatisch nach 2 Sekunden. (Geht aber nur, wenn man von der ersten HD bootet, da dies der Default Eintrag ist.)

butcher1de · 23.01.2018

Warum wartet ihr nicht einfach bis alle Fehler bereinigt sind und flasht dann erst den Code ? Meltdown und Spectre: Intel zieht Microcode-Updates für Prozessoren zurück

[Sammelthread] Intel Microcodes patchen - mod BIOS - uCodes Bootloader - OS Patch - Spectre II

Enthusiast

Enthusiast

kroxx

Guest

cpt sunday flyer

Neuling

Neuling

Enthusiast

Enthusiast

Neuling

Enthusiast

Neuling

Neuling

Neuling

Enthusiast

Enthusiast

cpt sunday flyer

Enthusiast

cpt sunday flyer

Enthusiast

cpt sunday flyer

Enthusiast

cpt sunday flyer

Enthusiast

cpt sunday flyer

Enthusiast

Neuling

kroxx

Guest

Legende

Enthusiast

Legende