Bullseye Standard: blacklist microcode

[willy4711]

Warum ist das eigentlich Standard ?
die /etc/modprobe.d/intel-microcode-blacklist. sagt:

Code: Alles auswählen

# The microcode module attempts to apply a microcode update when
# it autoloads.  This is not always safe, so we block it by default.
blacklist microcode

Heute kam gerade ein neuer Microcode.
Normalerweise ist das ja auch im BIOS implementiert, jedoch hab ich keine Lust, jedes mal nachzusehen, ob da wieder ein Update
vorhanden ist.

Sollte man der Empfehlung aus der /etc/modprobe.d/intel-microcode-blacklist.conf folgen ?
Was ist das Sicherheitsproblem ?

Artikel:
https://www.pro-linux.de/sicherheit/2/5 ... ocode.html

[OrangeJuice]

Ich spiele die ein(auch Bios Updates, laufen bei Intel eigenlich immer sehr gut) und halte mich an die Voreinstellungen der Spectre...Maßnahmen. Du kannst mit "lscpu" nun auch nachschauen, welche Lücken für deine CPU bestehen, ansonsten ist "spectre-meltdown-checker" genauer.

Aktuell haben die Intel CPU ein paar Lücken hinzubekommen, die die SGX-Enklave betreffen und über Kerne hinweg den L3 Cache auslesen lassen(außerdem Bug in RDRAND und RDSEED(siehe heise: 1 und 2)).

Code: Alles auswählen

dmesg|grep -i microcode

[willy4711]

Tja und nu ? BIOS ist aktuell (4.30 v. 2020/1/2)

Code: Alles auswählen

Modellname:                      Intel(R) Core(TM) i9-9900 CPU @ 3.10GHz
Stepping:                        13
CPU MHz:                         800.124
Maximale Taktfrequenz der CPU:   5000,0000
Minimale Taktfrequenz der CPU:   800,0000
BogoMIPS:                        6199.99
Virtualisierung:                 VT-x
L1d Cache:                       256 KiB
L1i Cache:                       256 KiB
L2 Cache:                        2 MiB
L3 Cache:                        16 MiB
NUMA-Knoten0 CPU(s):             0-15
Vulnerability Itlb multihit:     KVM: Mitigation: Split huge pages
Vulnerability L1tf:              Not affected
Vulnerability Mds:               Not affected
Vulnerability Meltdown:          Not affected
Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl and seccomp
Vulnerability Spectre v1:        Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2:        Mitigation; Enhanced IBRS, IBPB conditional, RSB filling
Vulnerability Tsx async abort:   Mitigation; TSX disabled

Also Blacklist entfernen oder wie oder was ?????

[OrangeJuice]

Schau mal hier gab es die Frage schon einmal und eine Antwort darauf.

Bei mir sieht es so aus(Debian Sid):

Code: Alles auswählen

grep -i microcode /boot/config-5.6.0-2-amd64
CONFIG_MICROCODE=y
CONFIG_MICROCODE_INTEL=y
CONFIG_MICROCODE_AMD=y
# CONFIG_MICROCODE_OLD_INTERFACE is not set

[willy4711]

Danke für den Link
Aber schlauer macht mich das trotzdem nicht

Hierzu auch die Config des Kernels:

Code: Alles auswählen

$ grep -i microcode /boot/config-4.9.0-5-amd64 
CONFIG_MICROCODE=y
CONFIG_MICROCODE_INTEL=y
CONFIG_MICROCODE_AMD=y
CONFIG_MICROCODE_OLD_INTERFACE=y

Anscheinend wird das jetzt fest eingebaut (sonst wäre anstelle von 'y' ein 'm'). Vielleicht aus Sicherheitsgründen?
Wie auch immer, der aktuelle Microcode wird jedenfalls in die initrd mit eingebaut und beim Start in den Prozessor geschrieben.

Sieht bei mir wie bei dir aus:

Code: Alles auswählen

$ grep -i microcode /boot/config-5.6.0-2-amd64
CONFIG_MICROCODE=y
CONFIG_MICROCODE_INTEL=y
CONFIG_MICROCODE_AMD=y
# CONFIG_MICROCODE_OLD_INTERFACE is not set

Was heisst das denn nun ?
CONFIG_MICROCODE_INTEL=y ; aber Blacklisted

Verstehe ich nicht
Ich verstehe das so: Der geblacklistete Microcode wird als Kernelmodul genutzt ------> also nicht

aber dennoch:

Code: Alles auswählen

# dmesg|grep -i microcode
[    0.000000] microcode: microcode updated early to revision 0xd6, date = 2020-04-23
[    1.229038] microcode: sig=0x906ed, pf=0x2, revision=0xd6
[    1.229340] microcode: Microcode Update Driver: v2.2.

[MSfree]

Ich verstehe das so: Der geblacklistete Microcode wird als Kernelmodul genutzt ------> also nicht

Das ist etwas unglücklich formuliert.

Es gibt im Kernel ein Modul, das sich um das Hochladen des Microcodes in die CPU kümmert. Das funktioniert wie die Firmwareloader für z.B. WLAN-Karten. Und diesen "Firmwareloader" kann man blacklisten.

Dieses "his is not always safe, so we block it by default. kann wohl in Einzelfällen zu Problemen führen, und wird daher erstmal abgeschaltet, damit die Kiste überhaupt mal bootet. Ich würde den Blacklisteintrag entfernen, denn ohne den Microcode ist die CPU nicht gegen die bekannten CPU-Angriffe geschützt.

[OrangeJuice]

Scheint so, als ob damit sichergestellt wird, dass der installierte Microcode auch geladen wird(es gibt ja noch den Microcode vom UEFI).

+ modprobe.d: blacklist microcode module from autoloading outside
of the initramfs. Still load it inside the initramfs for logging

* add a microcode best-effort blacklist. This is a reactive blacklist
which renames problematic microcode data files in such a way they
will only be used for the [early] initramfs. Use it to blacklist
all Haswell microcode updates

Quelle

Microcode updates are now applied only through the initramfs
+ postinst: don't apply microcode update
+ kernel preinst: stop loading microcode module
+ modprobe.d: blacklist microcode module from autoloading outside
of the initramfs
Quelle

Change log for intel-microcode package in Debian

[willy4711]

So jetzt hab ich das erstmal auskommentiert.

Aber verstehen tue ich das immer noch nicht richtig:

Code: Alles auswählen

dpkg -l intel-microcode
ii  intel-microcode 3.20200609.2 amd64        Processor microcode firmware for Intel CPUs

Soweit so gut
Es müsste doch irgendwo stehen, welche Version genutzt wird
die Zeile sagt darüber ja wohl nichts aus:

Code: Alles auswählen

# dmesg|grep -i microcode -A2
[    0.000000] microcode: microcode updated early to revision 0xd6, date = 2020-04-23
[    0.000000] Linux version 5.6.0-2-amd64 (debian-kernel@lists.debian.org) (gcc version 9.3.0 (Debian 9.3.0-13)) #1 SMP Debian 5.6.14-1 (2020-05-23)
[    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-5.6.0-2-amd64 root=UUID=051b95a4-f99d-4808-9237-5a7d0b976423 ro quiet

Ich verstehe da diese Datumsangabe überhaupt nicht.
Der Package-Tracker gibt an:

Code: Alles auswählen

[2020-06-13] intel-microcode 3.20200609.2 MIGRATED to testing (Debian testing watch) 
[2020-05-27] intel-microcode 3.20200520.1 MIGRATED to testing (Debian testing watch) 
[2020-05-15] intel-microcode 3.20200508.1 MIGRATED to testing (Debian testing watch) 

Was bedeutet denn nun updated early to revision 0xd6, date = 2020-04-23
Kann ja wohl nicht mit der Version von heute übereinstimmen.

Mit viel Fantasie kann man das aus der changelog erdenken, da gibt es ja wenigstens das Datum ein paar mal:

Code: Alles auswählen

$ zcat /usr/share/doc/intel-microcode/changelog.gz
2020-06-09:
  * Implements mitigation for CVE-2020-0543 Special Register Buffer Data
    Sampling (SRBDS), aka INTEL-SA-00320
  * Known to fix the regression introduced in release 2019-11-12 (sig
    0x50564, rev. 0x2000065), which would cause several systems with
    Skylake Xeon, Skylake HEDT processors to hang on warm reboots
  * Updated Microcodes:
    sig 0x000306c3, pf_mask 0x32, 2019-11-12, rev 0x0028, size 23552
    sig 0x000306d4, pf_mask 0xc0, 2019-11-12, rev 0x002f, size 19456
    sig 0x00040651, pf_mask 0x72, 2019-11-12, rev 0x0026, size 22528
    sig 0x00040661, pf_mask 0x32, 2019-11-12, rev 0x001c, size 25600
    sig 0x00040671, pf_mask 0x22, 2019-11-12, rev 0x0022, size 14336
    sig 0x00050653, pf_mask 0x97, 2020-04-24, rev 0x1000157, size 32768
    sig 0x00050654, pf_mask 0xb7, 2020-04-24, rev 0x2006906, size 34816
    sig 0x00050656, pf_mask 0xbf, 2020-04-23, rev 0x4002f01, size 52224
    sig 0x00050657, pf_mask 0xbf, 2020-04-23, rev 0x5002f01, size 52224
    sig 0x000506e3, pf_mask 0x36, 2020-04-27, rev 0x00dc, size 104448
    sig 0x000806e9, pf_mask 0x10, 2020-04-27, rev 0x00d6, size 103424
    sig 0x000806e9, pf_mask 0xc0, 2020-04-27, rev 0x00d6, size 103424
    sig 0x000806ea, pf_mask 0xc0, 2020-04-27, rev 0x00d6, size 103424
    sig 0x000806eb, pf_mask 0xd0, 2020-04-27, rev 0x00d6, size 103424
    sig 0x000806ec, pf_mask 0x94, 2020-04-23, rev 0x00d6, size 103424
    sig 0x000906e9, pf_mask 0x2a, 2020-04-23, rev 0x00d6, size 103424
    sig 0x000906ea, pf_mask 0x22, 2020-04-27, rev 0x00d6, size 102400
    sig 0x000906eb, pf_mask 0x02, 2020-04-23, rev 0x00d6, size 103424
    sig 0x000906ec, pf_mask 0x22, 2020-04-27, rev 0x00d6, size 102400
    sig 0x000906ed, pf_mask 0x22, 2020-04-23, rev 0x00d6, size 103424
  * Updated Microcodes (later reported to cause regressions):
    sig 0x000406e3, pf_mask 0xc0, 2020-04-27, rev 0x00dc, size 104448

Der Changelog aud der Webseite sagt was anderes;
https://launchpad.net/debian/+source/in ... 20200609.2

Wie auch immer, der spectre-meltdown-checker sagt:

Code: Alles auswählen

# ./spectre-meltdown-checker.sh
Spectre and Meltdown mitigation detection tool v0.43

Checking for vulnerabilities on current system
Kernel is Linux 5.6.0-2-amd64 #1 SMP Debian 5.6.14-1 (2020-05-23) x86_64
CPU is Intel(R) Core(TM) i9-9900 CPU @ 3.10GHz
[.......]
> SUMMARY: CVE-2017-5753:OK CVE-2017-5715:OK CVE-2017-5754:OK 
CVE-2018-3640:OK CVE-2018-3639:OK CVE-2018-3615:OK CVE-2018-3620:OK 
CVE-2018-3646:OK CVE-2018-12126:OK CVE-2018-12130:OK 
CVE-2018-12127:OK CVE-2019-11091:OK CVE-2019-11135:OK 
CVE-2018-12207:OK CVE-2020-0543:OK

Ich will es dabei erstmal bewenden lassen. Eine Frage habe ich aber noch:
https://launchpad.net/debian/+source/in ... 20200609.2 sagt:

* ucode-blacklist: blacklist models 0x8e and 0x9e from late-loading,
just in case. Note that Debian does not do late loading by itself.
Refer to LP#1883002 for the report, 0x806ec hangs upon late load.

Wie muss man sich das Vorstellen (deshalb ist das ja wohl nur geblacklistetd)?

Note that Debian does not do late loading by itself.

[smutbert]

Code: Alles auswählen

CONFIG_MICROCODE=y

bedeutet, dass die Funktion direkt in den Kernel kompiliert ist. Das Blacklisten des bei diesem Kernel gar nicht vorhandenen gleichnamigen Moduls ändert also gar nichts.

Ich glaube beim Blacklisten des Kernelmoduls ist es darum gegangen, dass das Updaten des Microcodes möglichst früh im Bootprozess passieren soll, weil es später zu Problemen führen kann. Das Umstellen der Kernelkonfiguration und das Blacklisten des Moduls ist halt doppelt gemoppelt.
Wenn ich es recht in Erinnerung habe, war oder ist es unter arch Linux sogar üblich das Microcode-Update bereits im Bootloader einzuspielen.


Was das Datum angeht:
Im Log taucht natürlich das Datum der aktuellsten Version für deinen Prozessor auf. Schwächen, die bei anderen Prozessoren später behoben wurden ändern natürlich nichts am Datum der Version für deinen Prozessor.
Wenn ich deine Versionsangabe und die Informationen in /usr/share/doc/intel-microcode/releasenote.gz richtig interpretiere müsstest du also eine ziemlich aktuelle CPU zwischen Core Generation 7 und 10 haben, also bei den Desktop-CPU irgendetwas zwischen iX 7xxx bis iX 10xxx.