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

[dufty2]

Das Script hat ja inzwischen die Version 0.35 (ob das jetzt einen großen Unterschied macht, sei mal dahingestellt).

Jedenfalls laut security-tracker ist CVE-2017-5754 (Meltdown) gelöst bei stretch mit dem 4.9.82-1+deb9u2:
https://security-tracker.debian.org/tra ... -2017-5754

Gestern gab's auch Updates: 4.4.117, 4.9.83, 4.14.21, 4.15.5.
Da sind auch noch ein paar Optimierungen dabei.

CVE-2017-5753 (Spectre Variant 1) ist jedenfalls gemäss Debian noch unvollständig/nicht gelöst:
https://security-tracker.debian.org/tra ... -2017-5753

Ihr könntet ja mal Eure 'cat /proc/cpuinfo | grep -m 1 "model name" ' posten, ob auch andere mit gleichen CPU die Probleme - laut Skript - haben.

[Par@noid]

stable: 4.15.9 2018-03-11

Hardware check
* Hardware support (CPU microcode) for mitigation techniques
* Indirect Branch Restricted Speculation (IBRS)
* SPEC_CTRL MSR is available: YES
* CPU indicates IBRS capability: YES (SPEC_CTRL feature bit)
* Indirect Branch Prediction Barrier (IBPB)
* PRED_CMD MSR is available: YES
* CPU indicates IBPB capability: YES (SPEC_CTRL feature bit)
* Single Thread Indirect Branch Predictors (STIBP)
* SPEC_CTRL MSR is available: YES
* CPU indicates STIBP capability: YES
* Enhanced IBRS (IBRS_ALL)
* CPU indicates ARCH_CAPABILITIES MSR availability: NO
* ARCH_CAPABILITIES MSR advertises IBRS_ALL capability: NO
* CPU explicitly indicates not being vulnerable to Meltdown (RDCL_NO): NO
* CPU microcode is known to cause stability problems: NO (model 158 stepping 9 ucode 0x84)
* CPU vulnerability to the three speculative execution attacks variants
* Vulnerable to Variant 1: YES
* Vulnerable to Variant 2: YES
* Vulnerable to Variant 3: YES

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Mitigated according to the /sys interface: YES (kernel confirms that the mitigation is active)
* Kernel has array_index_mask_nospec: YES (1 occurence(s) found of 64 bits array_index_mask_nospec())
* Kernel has the Red Hat/Ubuntu patch: NO
> STATUS: NOT VULNERABLE (Mitigation: __user pointer sanitization)

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigated according to the /sys interface: YES (kernel confirms that the mitigation is active)
* Mitigation 1
* Kernel is compiled with IBRS/IBPB support: YES
* Currently enabled features
* IBRS enabled for Kernel space: UNKNOWN
* IBRS enabled for User space: UNKNOWN
* IBPB enabled: UNKNOWN
* Mitigation 2
* Kernel compiled with retpoline option: YES
* Kernel compiled with a retpoline-aware compiler: YES (kernel reports full retpoline compilation)
> STATUS: NOT VULNERABLE (Mitigation: Full generic retpoline, IBPB)

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Mitigated according to the /sys interface: YES (kernel confirms that the mitigation is active)
* Kernel supports Page Table Isolation (PTI): YES
* PTI enabled and active: YES
* Running as a Xen PV DomU: NO
> STATUS: NOT VULNERABLE (Mitigation: PTI)

[seanxenos]

Ich habe mal eine Frage zu den upgedateten Microcodes von Intel, es gibt da ein neues Update vom 12.03.2018

https://downloadcenter.intel.com/downlo ... -Data-File

Intel beschreibt auf der Downloadseite ein relativ einfaches Verfahren den Microcode selbst unter /lib/firmware/intel-ucode/
mit der neuen Version zu überschreiben und anschließend mit echo 1 > /sys/devices/system/cpu/microcode/reload auf den neuen Microcode upzudaten

Spricht etwas dagegen das händisch so zu machen?
Bisher hatte ich auf ein Update des Pakets intel-microcode gewartet

Was hat es mit den Einträgen in /lib/firmware/intel-ucode/ mit der Endung initram.fs auf sich?
Diese sind in der alten Version Vorhanden, im neuen Intel Microcode aber nicht

[fireburner]

Ich würde noch die paar Stunden/Tage abwarten, bis der neueste Microde im entsprechenden Debian Paket aktualisiert wurde.

[seanxenos]

ja, das dachte ich auch

bin aber auch gerade neugierig und möchte ein bisschen mehr verstehen, wie mein Linux System an dieser Stelle arbeitet

Was ist die Funktion der .initramfs Dateien, wenn sie im intel-ucode Verzeichnis abgelegt werden? /lib/firmware/intel-ucode/

Werden die .initramfs Dateien von meinem System selbst erzeugt oder sind sie im intel-microcode Paket enthalten?

Sollte ich sie bei einem manuellen Update löschen? Muss ich sie neu erzeugen für die neue Version des microcodes?

[seanxenos]

Im readme zum intel-microcode Paket habe ich den Abschnitt "Downloading new microcode data from Intel" gefunden

Dort steht auch: "After you install the updated intel-microcode.dat file, run as root:

update-initramfs -u
"

Alllerdings bezieht sich die Beschreibung dort noch auf das Updateverfahren über die intel-microcode.dat in /dev/cpu/microcode

und nicht auf /lib/firmware/intel-ucode/

[seanxenos]

Da es sich bei meinem Prozessor um einen Haswell-Tap, also i5-4690 handelt, treffen eventuell die Dateien in der /lib/firmware/intel-ucode/ für die Typen
Haswell HSW-ULT Cx/Dx 06-45-01

oder

Haswell HSW Cx/Dx 06-3c-03
zu

Dort ist jeweils auch eine .initramfs Datei älteren Datums zu diesen Prozessortypen hinterlegt.

[seanxenos]

Nachtrag:

die neuen Intel Microcodes werden jetzt auch als Paket für Stretch als Update bereitgestellt.

Nach der Installation und einem Neustart werden die .initramfs Dateien neu vom System erstellt, der Microcode hat das Datum 12.03.18, die .initramfs Dateien das Datum der Updateinstallation

Ohne weitere Anleitungen oder Hilfe war es mir nicht möglich die Dateien selbst zu erstellen, daher habe ich auf das Update des Pakets gewartet.

Schlauer geworden bin ich nun aber nicht, wie mein Linux-System an dieser Stelle arbeitet, schade.

[ingo2]

Was erstaunlich ist, jetzt sind auch Updates für Sandy- und Ivy-Bridge dabei, obwohl es vorher hieß "nur ab Haswell".
Aus dem changelog:

* New upstream microcode data file 20180312 (closes: #886367)

+ Implements IBRS/IBPB/STIPB support, Spectre-v2 mitigation for:
Sandybridge, Ivy Bridge, Haswell, Broadwell, Skylake, Kaby Lake,
Coffee Lake

Bei meinem i5-3570K funktioniert es:

microcode updated early to revision 0x1f, date = 2018-02-07

vorher war's die revision 0x1c.
Und der Checker sagt:

Hardware check
* Hardware support (CPU microcode) for mitigation techniques
* Indirect Branch Restricted Speculation (IBRS)
* SPEC_CTRL MSR is available: YES
* CPU indicates IBRS capability: YES (SPEC_CTRL feature bit)
* Indirect Branch Prediction Barrier (IBPB)
* PRED_CMD MSR is available: YES
* CPU indicates IBPB capability: YES (SPEC_CTRL feature bit)
* Single Thread Indirect Branch Predictors (STIBP)
* SPEC_CTRL MSR is available: YES
* CPU indicates STIBP capability: YES
* Enhanced IBRS (IBRS_ALL)
* CPU indicates ARCH_CAPABILITIES MSR availability: NO
* ARCH_CAPABILITIES MSR advertises IBRS_ALL capability: NO

Aber brauchen wir das unter Linux wirklich?
Der Kernel ist doch mit "retpoline patch" kompiliert und das ist auch aktiv?

[NAB]

Aber brauchen wir das unter Linux wirklich?
Der Kernel ist doch mit "retpoline patch" kompiliert und das ist auch aktiv?

Ja, aber das gilt nur für den Kernel. Das Userland ist nach wie vor offen wie ein Scheunentor. Und da mag es Sinn machen, dass jeder Prozess sich selber aussuchen kann, ob er lieber Retpoline oder Intels neue Microcodes nutzen möchte ... vielleicht gibt's da Performance-Unterschiede. Ich finde dazu nach wie vor wenig Handfestes.

[ingo2]

@NAB
Danke, soweit hatte ich garnicht gedacht, kann ja auch sein, dass die Redmonter Systeme das benötigen/nutzen

Habe die neuen "intel-microcode" jetzt auch auf meinem T520 mit i5 Sandy-Bridge eingespielt und auch da sind die IBRS-Patches jetzt aktiv. Microcode-Revision wurde auf 0x23 gepatcht.

Ich bin ja mal mächtig gespannt, ob da Lenovo demnächst auch noch entsprechende BIOS-Updates liefert?

[fireburner]

Weiß jemand, ob der Microcode auch unter Stretch noch aktualisiert wird?
Ansonsten würde ich intel-microcode eben über die Stretch Backports installieren.

[ingo2]

@fireburner
Wo ist da das Problem?
1. Freiwillig installieren die sich sowieso nicht, mußt schon apt bemühen.
2. Und die zusätzliche Tipparbeit (-t stretch-backports) hält sich doch in Genzen
3. Ist unwahrscheinlich, da es ein proprietärer Blob ist, der nur in "contrib" liegt.

[fireburner]

Ich hatte das Paket schon aus den normalen Stretch Quellen installiert, daher die Frage.
Ich werds aber jetzt einfach neu aus den Backports installieren.

[ingo2]

Habe jetzt noch eine Frage zu "retpoline":

Kernel und Compiler (gcc) haben ja nun die retpoline-Patches und die sind auch aktiv.
Wie steht es denn da mit Kernelmodulen, die lokal kompiliert werden, z.B. "vboxdrv" - ist da auch retpoline automatisch akiv, oder muß das in den Sources extra konfiguriert werden?

Wenn ich mir den Output von "modinfo" anschaue, dann steht da bei
Debian-Modulen:

Code: Alles auswählen

retpoline:      Y
intree:         Y

und bei den VBox-Modulen:

Code: Alles auswählen

retpoline:      Y

es fehlt also das "intree".
Habe keine Ahnung, ob das in dieser Hinsicht was bedeutet.

[towo]

Da kann auch kein intree stehenm, weil vboxdrv ein Out of Tree Modul ist.

[clue]

@fireburner
Wo ist da das Problem?
1. Freiwillig installieren die sich sowieso nicht, mußt schon apt bemühen.
2. Und die zusätzliche Tipparbeit (-t stretch-backports) hält sich doch in Genzen
3. Ist unwahrscheinlich, da es ein proprietärer Blob ist, der nur in "contrib" liegt.

Wie, der wird nicht über die normalen security updates installiert?

[ingo2]

Hatte mich oben geirrt:
Das Paket liegt in "stretch-backports non-free" (nicht contrib). In stretch findest du nur die alte Version 3.20170707.1~deb9u1.

[fireburner]

Wie, der wird nicht über die normalen security updates installiert?

Bisher zumindest nicht. Siehe: https://packages.debian.org/search?keyw ... lla-search

[NAB]

Wie, der wird nicht über die normalen security updates installiert?

Solange nichts in Debian die neuen Intel Microcodes nutzt (sondern Retpoline und LFENCE), solange wäre es ja kein Security Update, sondern einfach nur zusätzliche (ungenutzte) Funktion.

Die Microcode Updates machen nichts "heil" sondern stellen einfach nur zusätzliche Funktionen bereit, die man gegen Spectre nutzen könnte, wenn man es denn täte.

Meltdown und Spectre sind weiterhin "unreparierbar". Man kann nur versuchen, sie mit Softwareanpassungen zu umgehen bzw. Gelegenheiten dazu zu vermeiden.

[Nice]

@NAB:
Vielen Dank für diese klare Information.

Mir scheint, dass vielen Menschen echte Gefahren auch auf anderen aktuellen Gebieten nicht realisieren wollen, sondern sie immer wieder glauben, sie könnten auf irgend einem Sonderweg ihnen entgehen.

Weniger dramatisch auf des Thread-Thema beschränkt formuliert: Erst neue Hardware kann das Problem Spectre und Meltdown lösen.
Aber dann gibt es wieder andere Probleme...

[ingo2]

Ich bin positiv überrascht:
Lenovo hat heute das BIOS-Update für meinem T520 (Baujahr 2011) verteilt.
Aktuelle Version: 8AET67WW 1.47 vom 14.03.2018.

Ich gehe mal davon aus, daß dort die aktuellen IBRS-Patches für Sandy-Bridge enthalten sind (sowas wie ein ehrliches changelog kennen Firmen offenbar nicht). Das Updaten aus dem Win7-Pro heraus ging völlig problemlos. Ich nutze Win7 praktisch nicht - war eine kostenlose Beigabe - höchstens mal ums Navi upzudaten. Ansonsten läuft Stretch praktisch ohne große Nacharbeit völlig problemlos.

[RobertDebiannutzer]

Gibt es eigentlich einen Grund dafür, dass man den stretch-backports keinen gefixten Kernel zukommen lässt?

Der check, als ich mal den Backport-Kernel gestestet hatte (war am 17.02., deshalb noch mit check-tool v.034, aber wird wohl egal sein):

Code: Alles auswählen

Spectre and Meltdown mitigation detection tool v0.34

Checking for vulnerabilities on current system
Kernel is Linux 4.14.0-0.bpo.3-amd64 #1 SMP Debian 4.14.13-1~bpo9+1 (2018-01-14) x86_64
CPU is Intel(R) Celeron(R) CPU          900  @ 2.20GHz

[...]

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Kernel has array_index_mask_nospec:  NO 
* Checking count of LFENCE instructions following a jump in kernel:  NO  (only 2 jump-then-lfence instructions found, should be >= 30 (heuristic))
> STATUS:  VULNERABLE  (Kernel source needs to be patched to mitigate the vulnerability)

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigation 1
  * Kernel is compiled with IBRS/IBPB support:  NO 
  * Currently enabled features
    * IBRS enabled for Kernel space:  NO 
    * IBRS enabled for User space:  NO 
    * IBPB enabled:  NO 
* Mitigation 2
  * Kernel compiled with retpoline option:  NO 
  * Kernel compiled with a retpoline-aware compiler:  NO 
  * Retpoline enabled:  NO 
> STATUS:  VULNERABLE  (IBRS hardware + kernel support OR kernel with retpoline are needed to mitigate the vulnerability)

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Kernel supports Page Table Isolation (PTI):  YES 
* PTI enabled and active:  YES 
* Running as a Xen PV DomU:  NO 
> STATUS:  NOT VULNERABLE  (PTI mitigates the vulnerability)

A false sense of security is worse than no security at all, see --disclaimer

Die Kernel-Version in den backports ist immer noch die selbe!

Mit dem aktuellen stretch-Kernel (und dem aktuellen check-tool) am 05.03. getestet:

Code: Alles auswählen

Spectre and Meltdown mitigation detection tool v0.35

Checking for vulnerabilities on current system
Kernel is Linux 4.9.0-6-amd64 #1 SMP Debian 4.9.82-1+deb9u3 (2018-03-02) x86_64
CPU is Intel(R) Celeron(R) CPU          900  @ 2.20GHz

[...]

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Mitigated according to the /sys interface:  YES  (kernel confirms that the mitigation is active)
* Kernel has array_index_mask_nospec:  YES  (1 occurence(s) found of 64 bits array_index_mask_nospec())
* Kernel has the Red Hat/Ubuntu patch:  NO 
> STATUS:  NOT VULNERABLE  (Mitigation: __user pointer sanitization)

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigated according to the /sys interface:  YES  (kernel confirms that the mitigation is active)
* Mitigation 1
  * Kernel is compiled with IBRS/IBPB support:  NO 
  * Currently enabled features
    * IBRS enabled for Kernel space:  NO 
    * IBRS enabled for User space:  NO 
    * IBPB enabled:  NO 
* Mitigation 2
  * Kernel compiled with retpoline option:  YES 
  * Kernel compiled with a retpoline-aware compiler:  YES  (kernel reports full retpoline compilation)
> STATUS:  NOT VULNERABLE  (Mitigation: Full generic retpoline)

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Mitigated according to the /sys interface:  YES  (kernel confirms that the mitigation is active)
* Kernel supports Page Table Isolation (PTI):  YES 
* PTI enabled and active:  YES 
* Running as a Xen PV DomU:  NO 
> STATUS:  NOT VULNERABLE  (Mitigation: PTI)

A false sense of security is worse than no security at all, see --disclaimer

[schorsch_76]

backports wird nicht vom security Team gepflegt. [1]

Q: Is there security support for packages from backports.debian.org?

A: Unfortunately not. This is done on a best effort basis by the people who track the package, usually the ones who originally did upload the package into backports. When security related bugs are fixed in Debian unstable the backporter is permitted to upload the package from directly there instead of having to wait until the fix hits testing. You can see the open issues for jessie-backports in the security tracker (though there may be false positives too, the version compare isn't perfect yet)

[1] https://backports.debian.org/FAQ/

[RobertDebiannutzer]

Ja schon, aber bisher schien es mir immer so, wie wenn die Entwicklung der Backports beim Kernel eng an der aktuellen Entwicklung läuft:

Code: Alles auswählen

[2018-01-20] linux 4.14.13-1 MIGRATED to testing (Debian testing watch)
[2018-01-16] Accepted linux 4.14.13-1~bpo9+1 (all source) into stretch-backports, stretch-backports (Ben Hutchings)
[...]
[2018-01-15] Accepted linux 4.14.13-1 (source) into unstable (Ben Hutchings) 
[...]
[2017-12-27] linux 4.14.7-1 MIGRATED to testing (Debian testing watch)
[...]
[2017-12-23] Accepted linux 4.14.7-1~bpo9+1 (all source) into stretch-backports, stretch-backports (Ben Hutchings)
[...]
[2017-12-22] Accepted linux 4.14.7-1 (all source) into unstable, unstable (Ben Hutchings)
[...]
[2017-11-22] Accepted linux 4.13.13-1~bpo9+1 (source) into stretch-backports (Ben Hutchings)
[2017-11-22] linux 4.13.13-1 MIGRATED to testing (Debian testing watch)
[...]
[2017-11-16] Accepted linux 4.13.13-1 (source) into unstable (Ben Hutchings) 
[...]
[2017-10-25] Accepted linux 4.13.4-2~bpo9+1 (all source) into stretch-backports, stretch-backports (Ben Hutchings)
[...]
[2017-10-19] linux 4.13.4-2 MIGRATED to testing (Debian testing watch)
[...]
[2017-10-15] Accepted linux 4.13.4-2 (source) into unstable (Salvatore Bonaccorso) 

Deswegen dachte ich, es gibt vielleicht spezielle Gründe, denn ansonsten würde man bei so wichtigen Veränderungen ja denken, dass es eher schneller als üblich geht.