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

Alles rund um sicherheitsrelevante Fragen und Probleme.
dufty2
Beiträge: 1502
Registriert: 22.12.2013 16:41:16

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

Beitrag von dufty2 » 23.02.2018 18:58:00

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.

Benutzeravatar
Par@noid
Beiträge: 215
Registriert: 09.11.2005 13:33:35
Lizenz eigener Beiträge: GNU Free Documentation License
Wohnort: Schwarzwald

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

Beitrag von Par@noid » 12.03.2018 13:40:57

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)
Man hilft den Menschen nicht, wenn man für sie tut, was sie selbst tun können .....



Debian GNU/Linux ..::unstable::.. (sid) 64-bit | GNOME

seanxenos
Beiträge: 90
Registriert: 31.01.2015 14:11:36

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

Beitrag von seanxenos » 14.03.2018 13:58:27

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
Beiträge: 112
Registriert: 01.12.2017 20:51:31
Lizenz eigener Beiträge: neue BSD Lizenz
Wohnort: der wilde Süden

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

Beitrag von fireburner » 14.03.2018 14:20:06

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

seanxenos
Beiträge: 90
Registriert: 31.01.2015 14:11:36

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

Beitrag von seanxenos » 14.03.2018 14:32:36

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
Beiträge: 90
Registriert: 31.01.2015 14:11:36

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

Beitrag von seanxenos » 14.03.2018 15:24:17

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
Beiträge: 90
Registriert: 31.01.2015 14:11:36

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

Beitrag von seanxenos » 14.03.2018 15:34:43

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
Beiträge: 90
Registriert: 31.01.2015 14:11:36

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

Beitrag von seanxenos » 20.03.2018 13:14:11

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. :cry:

Benutzeravatar
ingo2
Beiträge: 621
Registriert: 06.12.2007 18:25:36
Lizenz eigener Beiträge: GNU Free Documentation License
Wohnort: Wo der gute Riesling wächst

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

Beitrag von ingo2 » 21.03.2018 12:04:49

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
Beiträge: 5502
Registriert: 06.03.2011 16:02:23
Lizenz eigener Beiträge: MIT Lizenz

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

Beitrag von NAB » 21.03.2018 15:37:29

ingo2 hat geschrieben: ↑ zum Beitrag ↑
21.03.2018 12:04:49
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.
Never change a broken system. It could be worse afterwards.

"No computer system can be absolutely secure." Intel Document Number: 336983-001

Benutzeravatar
ingo2
Beiträge: 621
Registriert: 06.12.2007 18:25:36
Lizenz eigener Beiträge: GNU Free Documentation License
Wohnort: Wo der gute Riesling wächst

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

Beitrag von ingo2 » 21.03.2018 18:00:41

@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
Beiträge: 112
Registriert: 01.12.2017 20:51:31
Lizenz eigener Beiträge: neue BSD Lizenz
Wohnort: der wilde Süden

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

Beitrag von fireburner » 21.03.2018 18:11:59

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

Benutzeravatar
ingo2
Beiträge: 621
Registriert: 06.12.2007 18:25:36
Lizenz eigener Beiträge: GNU Free Documentation License
Wohnort: Wo der gute Riesling wächst

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

Beitrag von ingo2 » 21.03.2018 18:45:30

@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
Beiträge: 112
Registriert: 01.12.2017 20:51:31
Lizenz eigener Beiträge: neue BSD Lizenz
Wohnort: der wilde Süden

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

Beitrag von fireburner » 21.03.2018 18:57:12

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

Benutzeravatar
ingo2
Beiträge: 621
Registriert: 06.12.2007 18:25:36
Lizenz eigener Beiträge: GNU Free Documentation License
Wohnort: Wo der gute Riesling wächst

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

Beitrag von ingo2 » 22.03.2018 12:31:46

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.

Antworten