Wie werde ich aus Intels' Microcodes "für Linux" schlau (CPU Identifikation usw.)?

Diese Frage wollte ich früher schon stellen, aber dank Meltdown/Spectre ist mir wieder eingefallen, daß ich sowas machen wollte; Nämlich µCodes aus dem [Paket von Intel für Linux] zu nehmen, und in alte BIOSes zu patchen, die ansonsten keinerlei Updates mehr bekommen würden (und auf deren Maschinen tlw. auch kein Linux läuft).

Aber ich habe KEINE Ahnung wie ich meine exakten Ziel-CPUs in diesen Updatefiles finde?!

Speziell bei älteren Releases (die keine beiliegenden Binaries hatten) ist das irgendwie nicht so einfach? Und Releasenotes haben auch die wenigsten Pakete.

Ich entpacke die µCodes halt Mal, und wandle die beiliegende Textdatei microcode.dat mit dem [iucode_tool] in die Binärversionen um, also irgendwie so, hier Mal mit den neuesten µCodes von Intel:

Code:

$ tar -xzvf ./microcode-20180108.tgz
$ mkdir ./out/
$ iucode_tool -t d -L --write-named-to=./out/ ./microcode.dat

Da fängt's schon an. Im dieser neuen Version beiliegenden Ordner intel-ucode/ liegen 95 vorgebaute Binärdateien, deren Namen so ähnlich lauten:

Code:

06-1d-01
06-1e-05
06-25-02
06-25-05

Das ist wohl <step>-<model>-<family> oder so was ähnliches. Im ./out/ Ordner wohin ich microcode.dat extrahiert habe (und bei älteren Releases GEHT es eben nur so) liegen jetzt aber 165 Binärdateien?! Und mit der Namensgebung kann ich gar nichts anfangen, hier ein paar Beispiele:

Code:

s000306C3_m00000032_r00000023.fw
s000306D4_m000000C0_r00000028.fw
s000306E4_m000000ED_r0000042A.fw
s000306E6_m000000ED_r00000600.fw
s000306E7_m000000ED_r0000070D.fw
s000306F2_m0000006F_r0000003B.fw

Der String schaut nach einem Triplet aus "s[tepping]", "m[odel]" und "r[revision]" aus, aber ich kann diese Strings nicht richtig interpretieren, im Falle der hier Mal beiliegenden Binärfiles sind die einzelnen Teile immer nur 2 Bytes groß.

Wenn ich jetzt also alle Updates der letzten Jahre suche und entpacke, wie finde ich dann für eine ganz bestimmte CPU den jeweils neuesten µCode?! Gibt es da irgendwelche Zusatztools, die mir diese Arbeit erleichtern?

Und: Kann ich diese Binärdaten wirklich ohne weiteres z.B. mit AMI MMTool direkt in ein BIOS stopfen?

Danke!

Edit: Hmm, scheinbar findet sich die "Processor Signature" in dem "s" String? Liege ich da richtig, oder ist das nur ein Zufall und eine Falschannahme? Hier für Signatur 0x206C2 (Xeon X5690):

Code:

$ find . -iname "*0206c2*"
./20100914/out/s000206C2_m00000003_r00000013.fw
./20100826/out/s000206C2_m00000003_r0000000F.fw

"r00000013" würde zur Revision 13 passen, nur: Wenn ich meine Rev. 13 Firmware (extrahiert aus einem AMI BIOS) hernehme, und mit dieser "s000206C2_m00000003_r00000013.fw" vergleiche...

Code:

$ diff ./06C2-Rev13.bin ./20100914/out/s000206C2_m00000003_r00000013.fw
Binary files 06C2-Rev13.bin and 20100914/out/s000206C2_m00000003_r00000013.fw differ

Sind auch nicht gleich groß. Die aus dem BIOS extrahierten µCodes messen 8192 Bytes, die aus dem Linux Paket von Intel ist nur 7168 Bytes groß..

Klar gibt's das, aber um das geht's mir ja nicht. Ich will die Microcodes aus dem Linux Paket RAUS extrahieren und in ein echtes BIOS patchen können, damit die aktualisierten µCodes auch für andere Betriebssysteme zur Verfügung stehen, für die evtl. kein solches Update mehr zur Verfügung gestellt wird. Oder auch, um Mainboards mit CPUs betreiben zu können, die sonst nicht drauf laufen.

Und ich habe es jetzt auch zuwege gebracht, dank ein wenig Hex Editing! Die AMI BIOSes für mein Board haben einfach hinten noch ein 1kiB großes Zero Padding dran, und AMI MMTool verweigert das Einpflegen der µCodes in das BIOS Image, wenn dieses Zero Padding fehlt.

So kann ich jetzt also die den Linux µCodes aufbereiten um mir ein damit ausgestattetes, flashbares BIOS Image zu bauen:

Code:

$ dd bs=1 count=1024 if=/dev/zero of=./1kiB-zero-padding.bin
$ cat ./20100914/out/s000206C2_m00000003_r00000013.fw ./1kiB-zero-padding.bin > ./0x206C2-rev.13.bin

diff bestätigt, daß die Files nun identisch sind, und MMTool akzeptiert die Binärdaten als µCodes zum Einpflegen in BIOS Images.

Sowas ist auch nützlich, wenn man schnell irgendeinem Mainboard Xeon µCodes reinstopfen will, aber grad kein Spender-BIOS hat, bei dem man davon ausgehen kann, die neueste Version zu bekommen..