Hardware-Sicherheitslücken: Meltdown und Spectre: ehem. Intel-Bug

[novalix]

In dem weiter oben verlinkten Blog-Post von Greg Kroah-Hartmann war ja auch schon zu erkennen, dass die Kernelentwickler alles andere als zufrieden waren, mit dem "Krisenmanagement".
Ein Entdecker dieser Bugs war ja ein Team von der TU Graz. Mit einem Mitglied hatte der Spiegel wohl ein Interview geführt.

Daniel Gruss sagte, er finde es "beunruhigend", dass sein Forscherteam aus Graz nur eines von mehreren sei, die die Angriffe unabhängig voneinander und ungefähr zeitgleich entdeckt haben sowie ihr Wissen öffentlich gemacht haben. "Da stellt sich natürlich die Frage, wie viele andere das Problem noch entdeckt und nicht gemeldet haben", sagt Gruss. "Inwiefern Geheimdienste davon gewusst haben, können wir überhaupt nicht einschätzen." Im Nachhinein lasse sich auch nicht eindeutig klären, "ob das ein Bug oder eine Backdoor war".

[whiizy]

Jetzt ist auch Debian Jessie nicht mehr auf einen Backports-Kernel angewiesen:

https://security-tracker.debian.org/tra ... -2017-5754

Gerade, bei einem dist-upgrade, ist linux-image-3.16.0-5-amd64 bei mir eingelaufen.

Changelog:

Code: Alles auswählen

linux (3.16.51-3+deb8u1) jessie-security; urgency=high

  * dccp: CVE-2017-8824: use-after-free in DCCP code
  * Bluetooth: cmtp: cmtp_add_connection() should verify that it's dealing with
    l2cap socket
  * Bluetooth: bnep: bnep_add_connection() should verify that it's dealing with
    l2cap socket (CVE-2017-15868)
  * media: dvb-usb-v2: lmedm04: Improve logic checking of warm start
    (CVE-2017-16538)
  * media: dvb-usb-v2: lmedm04: move ts2020 attach to dm04_lme2510_tuner
    (CVE-2017-16538)
  * ipsec: Fix aborted xfrm policy dump crash (CVE-2017-16939)
  * netfilter: nfnetlink_cthelper: Add missing permission checks
    (CVE-2017-17448)
  * netlink: Add netns check on taps (CVE-2017-17449)
  * netfilter: xt_osf: Add missing permission checks (CVE-2017-17450)
  * USB: core: prevent malicious bNumInterfaces overflow (CVE-2017-17558)
  * [armhf,arm64,x86] KVM: Fix stack-out-of-bounds read in write_mmio
    (CVE-2017-17741)
  * crypto: salsa20 - fix blkcipher_walk API usage (CVE-2017-17805)
  * crypto: hmac - require that the underlying hash algorithm is unkeyed
    (CVE-2017-17806)
  * KEYS: add missing permission check for request_key() destination
    (CVE-2017-17807)
  * [x86]  KVM: VMX: remove I/O port 0x80 bypass on Intel hosts
    (CVE-2017-1000407)
  * bluetooth: Prevent stack info leak from the EFS element.
    (CVE-2017-1000410)
  * Bump ABI to 5 and apply deferred stable changes:
    - Input: i8042 - break load dependency between atkbd/psmouse and i8042
    - Input: i8042 - set up shared ps2_cmd_mutex for AUX ports
    - ACPICA: Utilities: split IO address types from data type models.
    - [arm64] Define AT_VECTOR_SIZE_ARCH for ARCH_DLINFO
    - block: fix bdi vs gendisk lifetime mismatch
    - cgroup: make sure a parent css isn't offlined before its children
    - libata: Align ata_device's id on a cacheline
    - libata: Ignore spurious PHY event on LPM policy change
    - net/ipv6: add sysctl option accept_ra_min_hop_limit
    - quota: Store maximum space limit in bytes
    - quota: Switch ->get_dqblk() and ->set_dqblk() to use bytes as space units
    - [s390*] Define AT_VECTOR_SIZE_ARCH for ARCH_DLINFO
    - scsi: scsi_error: count medium access timeout only once per EH run
    - [x86] panic: replace smp_send_stop() with kdump friendly version in panic
      path
  * [amd64] Implement Kernel Page Table Isolation (KPTI, aka KAISER)
    (CVE-2017-5754)

 -- Ben Hutchings <ben@decadent.org.uk>  Mon, 08 Jan 2018 22:13:59 +0000
 

Danke!

[hikaru]

Mir kam über Nacht im Halbschlaf eine Idee zur Spectre-Abmilderung auf Kernel-Ebene:

Mozilla hat ja zumindest in FF 57 die Genauigkeit seines Timers von 5 auf 20 Microsekunden reduziert, um die für Spectre nötige Zeitmessung von Speicherzugriffen zu erschweren. [1]
Was wäre, wenn man die Genauigkeit der Software-Uhr des Linux-Kernels entsprechend reduziert? Müsste das nicht den selben Effekt haben, und zwar für alle Programme?

Aktuelle Kernel nutzen wohl eine Auflösung von einer Nanosekunde:

Code: Alles auswählen

$ grep -m 1 resolution /proc/timer_list
  .resolution: 1 nsecs

Aber wenn ich es richtig verstehe, dann waren in Kernel 2.4 noch 10 Millisekunden üblich. [2]
Es war also offenbar zumindest in grauer Vorzeit kein Problem, ein Linux-System mit einer noch viel geringeren Software-Uhr-Auflösung zu betreiben. Geht das (von Spezialfällen abgesehen) auch heute noch und wenn ja, was müsste man dafür ändern?

Hat vielleicht noch jemand ein potenziell für Spectre anfälliges System, das mit Kernel 2.4 (bis Sarge) lauffähig ist, auf dem er die Spectre-Attack-Demo mal testen könnte? Ich könnte das auf meinem Merom-Notebook versuchen. Das könnte für Sarge allerdings schon zu neu sein.

Oder bringe ich hier etwas durcheinander und schon mein theoretischer Ansatz ist fehlerhaft?


[1] https://www.mozilla.org/en-US/security/ ... sa2018-01/
[2] https://elinux.org/High_Resolution_Time ... _kernel.29

[RobertDebiannutzer]

Was ist eigentlich mit hidepid? Nützt das was?
Aus "man proc":

hidepid=n (since Linux 3.3)
This option controls who can access the information in /proc/[pid] directories. The argument, n, is one of the following values:

0 Everybody may access all /proc/[pid] directories. This is the traditional behavior, and the default if this mount option is not specified.

1 Users may not access files and subdirectories inside any /proc/[pid] directories but their own (the /proc/[pid] directories themselves remain visible). Sensitive files such as /proc/[pid]/cmdline and /proc/[pid]/status are now protected against other users. This makes it impossible to learn whether any user is running a specific program (so long as the program doesn't otherwise reveal itself by its behavior).

2 As for mode 1, but in addition the /proc/[pid] directories belonging to other users become invisible. This means that /proc/[pid] entries can no longer be used to discover the PIDs on the system. This doesn't hide the fact that a process with a specific PID value exists (it can be learned by other means, for example, by "kill -0 $PID"), but it hides a process's UID and GID, which could otherwise be learned by employing stat(2) on a /proc/[pid] directory. This greatly complicates an attacker's task of gathering information about running processes (e.g., discovering whether some daemon is running with elevated privileges, whether another user is running some sensitive program, whether other users are running any program at all, and so on).

[Ellison]

Hat vielleicht noch jemand ein potenziell für Spectre anfälliges System, das mit Kernel 2.4 (bis Sarge) lauffähig ist, auf dem er die Spectre-Attack-Demo mal testen könnte? Ich könnte das auf meinem Merom-Notebook versuchen. Das könnte für Sarge allerdings schon zu neu sein.

Wenn das bis zum Wochenende warten könnte, würde ich das mal probieren. Habe noch einen Amilo A 1640 mit Intel Sempron auf dem Dachboden. Der lief 2005/2006. Sarge habe ich noch auf DVD rumfliegen.

[inne]

Hallo

@Inne

aus dem @hikaru verlinkten Artikel von de Raadt:

"Intel engineers attended the same conferences as other company engineers, and read the same papers about performance enhancing strategies – so it is hard to believe they ignored the risky aspects. I bet they were instructed to ignore the risk," he said.

Danke! Also ist das broken by design und alle sind sehenden Auges ins Dilemma gelaufen, was wir nun haben...

[hikaru]

Wenn das bis zum Wochenende warten könnte, würde ich das mal probieren.

Spectre wird bis dahin nicht verschwunden sein.

Habe noch einen Amilo A 1640 mit Intel Sempron auf dem Dachboden. Der lief 2005/2006. Sarge habe ich noch auf DVD rumfliegen.

Sehr gut!
Falls da etwas anderes als eine 100%ige Erkennung des Opferstrings rauskommt, dann wäre ein Vergleich mit einem aktuellen Debian auf dem Gerät interessant, denn unter Stretch hatte ich ja auf dem Merom (übrigens ein Amilo Si 1520) nur eine ca. 50%ige Erkennung. Man müsste also ausschließen, dass ein möglicher Effekt von der CPU selbst herrührt, insbesondere, da sich ein AMD vielleicht ohnehin anders verhält als ein Intel.

Also ist das broken by design und alle sind sehenden Auges ins Dilemma gelaufen, was wir nun haben...

Könnte man so sehen. Das ist auch die einzige Grundlage, auf der ich mir Hoffnungen für einen Microcode-Fix für Sandy/Ivy Bridge mache.
Falls das Absicht war, dann wird vielleicht eine der Sammelklagen in den USA Erfolg haben, in deren Folge Intel dann in VW-Manier auch für ältere CPUs einen Fix für billiger hält als die Sache auszusitzen.

[Ellison]

Das ist auch die einzige Grundlage, auf der ich mir Hoffnungen für einen Microcode-Fix für Sandy/Ivy Bridge mache.

Dito. Mein X220 fällt, wenn das mit den 5 Jahren stimmt, was man aktuell so liest, dann auch hinten über. Bin ebenfalls Sandy geschädigt.

[inne]

Kann mir bitte jemand was zu diesen CPUs sagen. U.a. ob die gefixed werden? Betroffen ist der erste auf jedenfall, soweit ich gesehen habe wird die CPU im PDF genannt. Die microcode Pakete und aktuelle Kernel habe ich installiert.

Code: Alles auswählen

$ lscpu | grep "^Model name:"
Model name:          Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz

Code: Alles auswählen

$ ssh acme 'lscpu | grep "^Model name:"'
Model name:            Intel(R) Core(TM) i3-4030U CPU @ 1.90GHz

// Ganz allgemein wäre am Ende, wenn das Thema durch ist ein Zusammenfassung für den Enduser interessant. Welche Hardware wurde gefixed, welche nicht und was kauft man in der Zukunft für Hardware.

[ingo2]

Check doch einfach mit dem neuesten "intel-microcode" und schau mit "dmesg" nach, welches Datum die Updates haben - sollt nach Juni 2016 liegen
Die 1. CPU ist ein Ivy-Bridge, die 2. ein Haswell

[hikaru]

@inne:
Beide CPUs sind von Meltdown (ohne KPTI) und Spectre betroffen. Der erste ist ein Ivy Bridge, für den es nach aktuellem Stand keine neuen Microcodes gegen Spectre geben wird. Der zweite ist ein Haswell, für den es neue Microcodes gibt, die zumindest zum Teil Abhilfe schaffen sollen (intel-microcode ab Version 3.20171215.1).

// Ganz allgemein wäre am Ende, wenn das Thema durch ist ein Zusammenfassung für den Enduser interessant. Welche Hardware wurde gefixed, welche nicht und was kauft man in der Zukunft für Hardware.

Möchtest du dafür ab 2021 einen Termin vormerken, oder machen wir das dann spontan?
Früher wird es wohl entwicklungsbedingt keine Hardware-Fixes geben. Ich las dazu etwas auf Twitter von einem ehemaligen Intel-Entwickler, der erklärte, wie etwa der Entwicklungszyklus läuft und warum das so lange dauert. Leider habe ich die Quelle nicht im Kopf.

[hikaru]

Check doch einfach mit dem neuesten "intel-microcode" und schau mit "dmesg" nach, welches Datum die Updates haben - sollt nach Juni 2016 liegen

Du meinst Juni 2017 (da wurden die Hersteller informiert).
Was die neuen Microcodes machen wissen wir leider trotzdem nicht. Wenn ich böse wäre würde ich jetzt behaupten, Intel hat einfach nur den Datumsstring aktualisiert.

[Aiki09]

Hallo Leute,

Irgendwie blicke ich nicht so richtig durch.

Ich habe bei mir ein Notebook mit Ivy-bridge (IntelCore I3-3110M) und eins mit Sandy- bridge (IntelCore I5-2450M).
Soweit ich weiß sind beide (durch die Updates von Stretch und dessen Kernel) gegen Meltdown abgesichert.

Laut diesem Thread habe ich auch verstanden das es mit Absicherung gegen Spectre schwierig wird bzw. gar nichts wird.

Jetzt meine Frage:
Wie kann man sich das "Spectre" einfangen, bzw. verhindern (neuen Firefox (57.0.4.) unter Stretch installieren?). Würde das dann schon ausreichen?

Edit. Gerade gelesen:"Praktisch muss man es bei den Angriffen, die wir präsentiert haben, nur schaffen, dass die dafür nötige Software auf dem angegriffenen System läuft", sagt Daniel Gruss. Auf dem Rechner könne sie zum Beispiel in Form eines E-Mail-Anhangs oder eines Downloads landen."

(http://www.spiegel.de/netzwelt/gadgets/ ... 86193.html)

Danke

[heisenberg]

Nicht für jeden ist das irgend etwas besonders beunruhigendes....

https://www.unix.com/what-is-on-your-mi ... -bugs.html

[towo]

Hm, sehr eigenartig

Neue intel-microcode 3.20180108.1 und es ändert sich genau nichts.

boot mit microcode 3.20171215.1

Code: Alles auswählen

Jan 10 16:18:02 Defiant kernel: microcode: microcode updated early to revision 0x23, date = 2017-11-20
Jan 10 16:18:02 Defiant kernel: microcode: sig=0x306c3, pf=0x2, revision=0x23
Jan 10 16:18:02 Defiant kernel: microcode: Microcode Update Driver: v2.2.

nach update auf 3.20180108.1

Code: Alles auswählen

Jan 10 16:27:52 Defiant kernel: microcode: microcode updated early to revision 0x23, date = 2017-11-20
Jan 10 16:27:52 Defiant kernel: microcode: sig=0x306c3, pf=0x2, revision=0x23
Jan 10 16:27:52 Defiant kernel: microcode: Microcode Update Driver: v2.2.

Meine CPU Intel(R) Core(TM) i5-4670K CPU @ 3.40GHz ist auf der Intel Seite für dieses Nicrocode Update gelistet.

[hikaru]

Ich habe bei mir ein Notebook mit Ivy-bridge (IntelCore I3-3110M) und eins mit Sandy- bridge (IntelCore I5-2450M).
Soweit ich weiß sind beide (durch die Updates von Stretch und dessen Kernel) gegen Meltdown abgesichert.

Richtig.

Laut diesem Thread habe ich auch verstanden das es mit Absicherung gegen Spectre schwierig wird bzw. gar nichts wird.

Jetzt meine Frage:
Wie kann man sich das "Spectre" einfangen, bzw. verhindern (neuen Firefox (57.0.4.) unter Stretch installieren?). Würde das dann schon ausreichen?

Soweit öffentlich bekannt, gibt es abgesehen von den Demo-Exploits noch nichts das Spectre ausnutzt. Demnach kann das momentan auch nicht ausgenutzt werden.
Was diverse Schlapphüte und andere Ganoven hinter verschlossenen Türen wissen und tun, kann natürlich keiner sagen. Einen endgültigen Schutz vor Spectre wird es ohne neue Hardwaredesigns nicht geben, man kann sich mit ständigen Updates dem nur annähern.

Insofern halte ich auch diese Aussage für optimistisch:

Nicht für jeden ist das irgend etwas besonders beunruhigendes....

https://www.unix.com/what-is-on-your-mi ... -bugs.html

Die Aussage an sich mag stimmen oder auch nicht. Der verlinkte Thread enthält aber nichts Gehaltvolles, das eine Entscheidung in die eine oder andere Richtung beeinflussen könnte.

Meine CPU Intel(R) Core(TM) i5-4670K CPU @ 3.40GHz ist auf der Intel Seite für dieses Nicrocode Update gelistet.

Es sind wohl noch nicht alle Fixes eingepflegt, für die Intel einen Fix angekündigt hat. Mit Haswell als ältester überhaupt berücksichtigten Generation stehst du wahrscheinlich ganz hinten in der Schlange. Wenigstens stehst du drin.

Wo du als Kernel-Experte schon mal da bist:
Von Performanceaspekten abgesehen, wenn ich in der Debian-Kernel-Config CONFIG_HIGH_RES_TIMERS=y und CONFIG_HZ_250=y deaktiviere, sowie CONFIG_HZ=250 auf 50 ändere, kriege ich dann einen Kernel der nur Zeitmessungen auf 20ms genau erlaubt und demnach als globale Spectre-Gegenmaßnahme taugt, falls an Mozillas Timer-Verschlechterung in Firefox auf 20ms was dran ist?
Oder übersehe ich hier weitere Optionen bzw. habe gar einen grundsätzlichen Denkfehler?

[towo]

Von Performanceaspekten abgesehen, wenn ich in der Debian-Kernel-Config CONFIG_HIGH_RES_TIMERS=y und CONFIG_HZ_250=y deaktiviere, sowie CONFIG_HZ=250 auf 50 ändere, kriege ich dann einen Kernel der nur Zeitmessungen auf 20ms genau erlaubt und demnach als globale Spectre-Gegenmaßnahme taugt, falls an Mozillas Timer-Verschlechterung in Firefox auf 20ms was dran ist?

Ich glaube nicht, daß das irgendeine Auswirkung als Gegenmaßnahme hätte. Wäre dem so, wären die Kernel-Devs die Ersten gewesen, die das kommuniziert hätten und es wäre vermutlich sogar als default-config upstream gelandet.

[dufty2]

Meine CPU Intel(R) Core(TM) i5-4670K CPU @ 3.40GHz ist auf der Intel Seite für dieses Nicrocode Update gelistet.

Es sind wohl noch nicht alle Fixes eingepflegt, für die Intel einen Fix angekündigt hat. Mit Haswell als ältester überhaupt berücksichtigten Generation stehst du wahrscheinlich ganz hinten in der Schlange. Wenigstens stehst du drin.

$ grep HSW releasenote
HSW-ULT Cx/Dx (06-45-01:72) 20->21
HSW Cx/Dx (06-3c-03:32) 22->23

Naja, irgendwas haben sie bei Haswell reingepanscht, was genau kann ich aber nicht sagen.

[dufty2]

So, noch ein paar Links zum "rumspielen":

Ein Testskript: https://github.com/speed47/spectre-meltdown-checker

Proof of Concept für meltdown: https://github.com/iaik/meltdown

Angriff im Browser: http://xlab.tencent.com/special/spectre ... check.html

Entnommen aus https://github.com/hannob/meltdownspectre-patches

[ingo2]

Hm, sehr eigenartig

Neue intel-microcode 3.20180108.1 und es ändert sich genau nichts.

Ich an deiner Stelle wäre froh.
Vergiß nicht, daß Intel seit Mitte letzten Jahres über den /di Bugs bescheid weiß - und für den 9.1.18 sollte es öffentlich werden. Da hatten sie ja ½ Jahr Zeit.

[hikaru]

Von Performanceaspekten abgesehen, wenn ich in der Debian-Kernel-Config CONFIG_HIGH_RES_TIMERS=y und CONFIG_HZ_250=y deaktiviere, sowie CONFIG_HZ=250 auf 50 ändere, kriege ich dann einen Kernel der nur Zeitmessungen auf 20ms genau erlaubt und demnach als globale Spectre-Gegenmaßnahme taugt, falls an Mozillas Timer-Verschlechterung in Firefox auf 20ms was dran ist?

Ich glaube nicht, daß das irgendeine Auswirkung als Gegenmaßnahme hätte. Wäre dem so, wären die Kernel-Devs die Ersten gewesen, die das kommuniziert hätten und es wäre vermutlich sogar als default-config upstream gelandet.

CONFIG_HZ_250=y kann man nicht einfach weglassen. Man kann es gegen sowas wie CONFIG_HZ_100=y oder CONFIG_HZ_1000=y ersetzen, aber darunter kommt man nicht. Man kriegt dann bestenfalls einen 100Hz-Kernel.
Damit und mit dem Standardkernel habe ich je 1000x die Spectre-Attack-Demo auf meinem Ivy Bridge laufen lassen und habe die fehlgeschlagenen Charactererkennungen aus dem Opferstring gezählt. Beide haben einen Median von 2, beim Standardkernel mit einer Standardabweichung von 2,37, beim 100Hz-Kernel mit einer von 2,17.
Meine Statistikvorlesungen sind zu lange her um das zu bewerten, aber aus der Hüfte würde ich schießen, dass der Unterschied nicht ausreicht um eine Tendenz abzulesen.

@Ellison:
Da die 100Hz den 10ms in Kernel 2.4 entsprechen, kannst du dir den Sarge-Test eigentlich sparen. Was der Sempron mit aktuellem Kernel zum Thema Spectre sagt, wäre vielleicht trotzdem interessant.

[ChronoBoost]

Beide haben einen Median von 2, beim Standardkernel mit einer Standardabweichung von 2,37, beim 100Hz-Kernel mit einer von 2,17.
Meine Statistikvorlesungen sind zu lange her um das zu bewerten, aber aus der Hüfte würde ich schießen, dass der Unterschied nicht ausreicht um eine Tendenz abzulesen.

Richtig geschossen.

Das Verhältnis der Standardabweichungen ist F-verteilt:
F=2.37/2.17=1.0921 < Fcrit(999,999,5%)=1.1097

[NAB]

Liebe Leute ... ich wollte hier auch noch kurz ein paar Infos loswerden:
1) Welche Prozessoren kriegen Microcode-Updates?
Die Thomas Krenn AG erwartet BIOS-Updates für ihre Supermicro-Boards bis runter zu Nehalem:
https://www.thomas-krenn.com/de/wiki/Si ... nd_Spectre
und beruft sich dabei auf Supermicro:
https://www.supermicro.com/support/secu ... pg=X10#tab
Nun sind das nur Ankündigungen ... und nur Server-Prozessoren ... aber warten wir mal ab.

2) Spectre-Tests
Der Link von duffy2
Angriff im Browser:
http://xlab.tencent.com/special/spectre ... check.html
sagt für meinen alten Firefox ESR 52, er sei nicht angreifbar - sollte er aber momentan sein, sagt die (Fach)Presse.
Warum geht's trotzdem nicht?
Die Seite nutzt "SharedArrayBuffer" für den Angriff, und das ist im ESR 52 eh abgeschaltet:
https://www.mozilla.org/en-US/security/ ... sa2018-01/
(Das verschweigt die Fachpresse)
Wirklich "gefixed" wurde bei mir noch nichts, keine neuen Microcodes, keine recompiled binaries und der Firefox ESR ist vom 8. Dezember. Also vorsicht bei solchen angeblichen Browser-Tests.
(Der "spectre-meltdown-checker" ebenfalls von duffy2 sieht da wesentlich solider aus)

Oh ... hier eine kurze Anleitung, wie man diesen spectre-meltdown-checker anschmeißt:
https://www.cyberciti.biz/faq/check-lin ... erability/
Leider auf Englisch, aber die beiden wichtigen Zeilen sind die, die mit "wget" und mit "sudo" anfangen.

[hikaru]

Liebe Leute ... ich wollte hier auch noch kurz ein paar Infos loswerden:
1) Welche Prozessoren kriegen Microcode-Updates?
Die Thomas Krenn AG erwartet BIOS-Updates für ihre Supermicro-Boards bis runter zu Nehalem:
https://www.thomas-krenn.com/de/wiki/Si ... nd_Spectre
und beruft sich dabei auf Supermicro:
https://www.supermicro.com/support/secu ... pg=X10#tab
Nun sind das nur Ankündigungen ... und nur Server-Prozessoren ... aber warten wir mal ab.

Zwei Anmerkungen zu dem Wiki-Artikel (bzw. deiner Interpretation):

1. Ich finde, dort wird die meiste Zeit nicht sauber genug zwischen Meltdown und Spectre unterschieden. In Anbetracht der Reputation von Thomas-Krenn finde ich das schwach.

2. Für Nehalem bis Ivy Bridge steht dort "Entwicklung in Vorbereitung" und der Satz:

BIOS Updates für Systeme der [Generation] Generation werden entwickelt, sobald Microcode Updates dafür zur Verfügung stehen:

Ich verstehe das so, dass Supermicro bereit wäre, Updates mit neuen Microcodes zu liefern, falls (nicht wenn) diese von Intel geliefert werden.
Dafür DASS Intel Updates liefert sehe ich dort aber keinen Hinweis. Der jeweils dazugehörige englische Satz geht so los:

We are awaiting microcode updates [..]

Das "awaiting" kann man mit "erwarten" übersetzen, hier passt mMn aber besser "abwarten". Ersteres impliziert die Annahme, dass etwas passiert, Letzteres nicht.

Letztendlich ist Supermicro genauso darauf angewiesen, dass Intel in die Hufe kommt, wie jeder andere auch. Bevor also Intel etwas zu Microcodes für Nehalem, Sandy und Ivy Bridge verkündet, ist alles was andere dazu sagen Schall und Rauch.

[MSfree]

Seit meinem gestrigen apt-get dist-upgrade meines Jessie Heimservers liefern:

Code: Alles auswählen

uname -a
Linux cargobay 3.16.0-5-amd64 #1 SMP Debian 3.16.51-3+deb8u1 (2018-01-08) x86_64 GNU/Linux

Code: Alles auswählen

dmesg | grep -i iso
[    0.000000] Kernel/User page tables isolation: enabled

Gegen Meltdown wurde der Kernel also schon abgedichtet.

Code: Alles auswählen

dmesg | grep -i micro
[    0.000000] CPU0 microcode updated early to revision 0x1c, date = 2015-02-26
[    0.080021] CPU1 microcode updated early to revision 0x1c, date = 2015-02-26
[    0.093493] CPU2 microcode updated early to revision 0x1c, date = 2015-02-26
[    0.106995] CPU3 microcode updated early to revision 0x1c, date = 2015-02-26

Gegen Spectre habe ich also noch keine Updates.

Meine CPU ist in diesem Fall ein Core-i5-3450 (Ivy Bridge vom 23. Apr. 2012), für die es (noch) keine Microcode-Updates von Intel gibt. Ob es jemals Updates geben wird, ist unklar, Intel liefert im Moment nur Micorcodes für CPUs, die maximal 5 Jahre alt sind, also Hasswell und neuer.