[Eisfair] [e1] eiskernel 3.18.1 (Status 'stable') verfügbar - 3.16er Kernel für eisfair-1

Thomas Bork tom at eisfair.org
Mi Aug 8 22:41:54 CEST 2018 

Hi @all,

es ist eine Version 3.18.1 von eiskernel mit dem Status 'stable' für 
eisfair-1 verfügbar.

Intern wird hierfür der Kernel 3.16.57 aus der Kernel-Serie 3.16 
verwendet, die zur Zeit als longterm-Variante die längst mögliche 
Unterstützung bietet.

Siehe dazu:

https://www.kernel.org/category/releases.html

Obwohl der Kernel die KPTI-Patches enthält, werden diese bei uns nicht 
aktiv, da die bisherige Implementation nicht bei 32-Bit-Kerneln greift.

https://de.wikipedia.org/wiki/Kernel_page-table_isolation

Aber es wird die Verwundbarkeit durch Spectre (v1/v2) in dieser 
Kernel-Version vermindert.

https://de.wikipedia.org/wiki/Spectre_(Sicherheitsl%C3%BCcke)

Das sieht dann mit meiner CPU unter 32 Bit so aus:

kernel316 # dmesg | grep -i spectre
[    0.003702] Spectre V2 : Vulnerable: Minimal generic ASM retpoline
[    0.003704] Spectre V2 : Filling RSB on context switch

kernel316 # ls -l /sys/devices/system/cpu/vulnerabilities/
total 0
-r--r--r-- 1 root root 4096 Mar 23 12:58 meltdown
-r--r--r-- 1 root root 4096 Mar 23 12:58 spectre_v1
-r--r--r-- 1 root root 4096 Mar 23 12:58 spectre_v2

kernel316 # cat /sys/devices/system/cpu/vulnerabilities/meltdown
Vulnerable

Es gibt noch keine KPTI für 32 Bit in unserem Kernel.
Wir sind verwundbar.

kernel316 # cat /sys/devices/system/cpu/vulnerabilities/spectre_v1
Mitigation: __user pointer sanitization

Unterstützung ist im Kernel. Die Gefahr wird abgemildert.

kernel316 # cat /sys/devices/system/cpu/vulnerabilities/spectre_v2
Vulnerable: Minimal generic ASM retpoline

Wir haben noch keinen gcc mit retpoline-Support. Wir sind verwundbar und 
nur minimal geschützt durch eine generische Unterstützung im Kernel.


Dieser Kernel wird in 3 Varianten angeboten (alle 32-Bit):

1. SMP
2. PAE
3. VIRT

Der SMP-Kernel unterstützt Systeme mit einem oder mehreren Prozessoren 
und Prozessoren mit einem oder mehreren physikalischen oder virtuellen 
Kernen.

Der PAE-Kernel ist der SMP-Kernel plus PAE und Sparse-Memory-Model. Die 
CPU muss die Features cmov und pae unterstützen - das wird bei der 
Installation überprüft.

Ein emulierter mathematischer Co-Prozessor (CONFIG_MATH_EMULATION) ist 
nur noch bei SMP gesetzt (um auch alte 486 ohne Co-Prozessor zu 
unterstützen). Ab PAE ist sowieso immer ein solcher Co-Prozessor 
vorhanden, PAE und VIRT bringen die Emulation deswegen bei uns nicht mit 
- das spart Platz.
Ab PAE ist das NX-Bit gesetzt, PAE und VIRT sind somit sicherer als SMP. 
Ab PAE ist ausserdem CONFIG_TRANSPARENT_HUGEPAGE gesetzt.

Wenn man einen Prozessor verwendet, der cmov und pae unterstützt und 
wenn man noch dazu mehr als 4GB RAM ansprechen möchte, sollte man also 
die PAE-Variante installieren.

Der VIRT-Kernel sollte alle notwendigen Features mitbringen (die die 
verwendete Kernel-Version anbietet), um als Gast-Kernel auf 
Virtualisierungs-Systemen zu laufen. Er ist der PAE-Kernel, erweitert um 
Funktionen für Xen, KVM und Hyper-V.

Diese Kernel-Pakete lassen sich auf allen Systemen mit laufendem Kernel 
3.2.xx-eisfair-1 und 3.16.xx-eisfair-1 installieren.

Beim Update von einem älteren Kernel als 3.16.57-eisfair-1 aus wird *bei 
genügend Platz in /boot* ein lilo-Start-Eintrag für diesen Kernel 
erzeugt, wenn noch kein Backup unter /boot existiert, um problemlos 
diesen alten stabilen Kernel booten zu können. Beim Update von 
3.16.57-eisfair-1 aus werden alle alten Kernel samt der Fallbacks gelöscht.

Zu den angegebenen eiskernel-Namen (z.B. 3.16.57-eisfair-1) und den 
darin enthaltenen Versionen siehe [1].


Änderungen zum stabilen eiskernel 3.18.0:
=========================================
- Es wurden die Intel-Microcode-Updates aus microcode-20180807.tgz
   sowie die AMD-Microcode-Updates aus linux-firmware-
   8d69bab7a3da1913113ea98cefb73d5fa6988286.tar.gz in /lib/firmware
   integriert.


Die Umgehung bestimmter Prozessorlücken erfordert das Zusammenspiel 
eines neuen Microcodes für den Prozessor und des Betriebssystems. Wenn 
man nicht das Glück hat, für sein altes Board neue BIOS-Varianten mit 
aktuellem Microcode zu bekommen, ist man auf einen alternativen 
Mechanismus angewiesen, diesen Microcode in den Prozessor zu laden.
Wie oben zu sehen ist, liefere ich Intel- und AMD-Microcode-Updates mit. 
Die Veränderungen in diesem Kernel erlauben das frühe Laden dieser 
Microcodes.
Um Unterschied zur Version 3.18.0 wird nun immer die initrd mit 
integriertem Microcode verwendet.

Dabei arbeitet das Kernel-Update wie folgt:

Auf nicht virtualisierten prüft das zur Laufzeit existierende 
intel-ucode, ob eine Intel-CPU im System existiert und ob unter 
/lib/firmware/intel-ucode Microcode-Dateien vorhanden sind, die zu 
dieser CPU passen.
Ist das der Fall, wird aus diesen Updates die Datei
${microcode_mount}/kernel/x86/microcode/GenuineIntel.bin erzeugt.

Handelt es sich um eine AMD-CPU, wird aus allen AMD-Microcode-Dateien 
aus /lib/firmware/amd-ucode/microcode_amd*.bin die Datei
${microcode_mount}/kernel/x86/microcode/AuthenticAMD.bin erzeugt.

Wenn ${microcode_mount}/kernel/x86/microcode existiert, wird daraus das 
cpio-Archiv /var/install/initrd/ucode.img erzeugt.

Wenn das cpio-Archiv /var/install/initrd/ucode.img existiert:
- wird die normale neue initrd.gz nach
   /var/install/initrd/initrd.gz.without.ucode umbenannt
- wird /var/install/initrd/initrd.gz.with.ucode aus
   /var/install/initrd/ucode.img und
   /var/install/initrd/initrd.gz.without.ucode erzeugt
- wird /var/install/initrd/initrd.gz.with.ucode nach
   /var/install/initrd/initrd.gz umbenannt und diese zum booten verwendet

Ohne weitere Aktion seitens des Anwenders sollten also, wenn vorhanden, 
neuere Microcode-Updates als im BIOS hinterlegt nach dem Booten auf 
nicht-virtualisierten Systemen aktiv sein.

Prüft das mittels

dmesg | grep micro

Dort sollten Meldungen wie

[    0.000000] CPU0 microcode updated early to revision 0x1b, date = 
2014-05-29
[    0.221951] CPU1 microcode updated early to revision 0x1b, date = 
2014-05-29
[    0.242064] CPU2 microcode updated early to revision 0x1b, date = 
2014-05-29
[    0.262349] CPU3 microcode updated early to revision 0x1b, date = 
2014-05-29
[    0.507267] microcode: CPU0 sig=0x306a9, pf=0x2, revision=0x1b
[    0.507272] microcode: CPU1 sig=0x306a9, pf=0x2, revision=0x1b
[    0.507276] microcode: CPU2 sig=0x306a9, pf=0x2, revision=0x1b
[    0.507281] microcode: CPU3 sig=0x306a9, pf=0x2, revision=0x1b
[    0.507286] microcode: CPU4 sig=0x306a9, pf=0x2, revision=0x1b
[    0.507292] microcode: CPU5 sig=0x306a9, pf=0x2, revision=0x1b
[    0.507296] microcode: CPU6 sig=0x306a9, pf=0x2, revision=0x1b
[    0.507300] microcode: CPU7 sig=0x306a9, pf=0x2, revision=0x1b
[    0.507335] microcode: Microcode Update Driver: v2.00 
<tigran at aivazian.fsnet.co.uk>, Peter Oruba

auftauchen, wenn man einen Prozessor besitzt, für den eine neuere 
Microcode-Version als im BIOS hinterlegt geladen wurde. Das funktioniert 
nur auf nicht-virtualisierten Systemen!

Auf den alten Stand zurück kommt man durch das Kopieren von 
/var/install/initrd/initrd.gz.without.ucode nach /boot/initrd.gz, Aufruf 
von 'lilo' und Reboot.

Muss man aus welchen Gründen auch immer die initramfs bearbeiten und 
möchte danach die Microcodes integrieren, so ist nach folgendem Muster 
zu verfahren:

Die initramfs ohne Microcodes findet sich unter 
/var/install/initrd/initrd.gz.without.ucode.
Die kann man wie bisher manipulieren, nach Bearbeitung nach 
/var/install/initrd/initrd.gz.self kopieren und nach folgendem Muster eine
/var/install/initrd/initrd.gz.with.ucode erzeugen:

cat /var/install/initrd/ucode.img \
     /var/install/initrd/initrd.gz.self \
     >/var/install/initrd/initrd.gz.with.ucode

Nun kann man wahlweise

/var/install/initrd/initrd.gz.self
(das ist das bearbeitete Original ohne Microcode)

oder

/var/install/initrd/initrd.gz.with.ucode
(das ist das bearbeitete Original plus Microcode)

nach /boot/initrd.gz kopieren.
Bitte postet bei Problemen die Ausgabe von

cat /var/log/log.kernel-update

nach dem Kernel-Update.


Dieses Paket bei https://pack-eis.de:
=====================================
PAE : https://www.pack-eis.de/index.php?p=25226
SMP : https://www.pack-eis.de/index.php?p=25227
VIRT: https://www.pack-eis.de/index.php?p=25228


Gleichzeitig wird wie gewohnt auch das Paket eiskernel-dev (Version 
3.18.1) mit den Quellen passend zu diesem Kernel freigegeben.


Änderungen zum vorherigen stabilen eiskernel-dev 3.18.0:
========================================================
- Setzt installierten eiskernel 3.18.1 voraus.


Dieses Paket bei https://pack-eis.de:
=====================================
https://www.pack-eis.de/index.php?p=25229


Der Kernel 3.16.57:
===================
http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/log/?id=refs/tags/v3.16.57


[1]
Übersicht der 3.16er eiskernel-1-Pakete:
========================================

eiskernel-Vers.|  eiskernel-Name   | Patchlevel Vanilla
_______________________________________________________
3.18.1         | 3.16.57-eisfair-1 | 3.16.57
3.18.0         | 3.16.57-eisfair-1 | 3.16.57
3.17.0         | 3.16.57-eisfair-1 | 3.16.57
3.16.0         | 3.16.56-eisfair-1 | 3.16.56
3.15.0         | 3.16.56-eisfair-1 | 3.16.56
3.14.1         | 3.16.54-eisfair-1 | 3.16.54
3.14.0         | 3.16.54-eisfair-1 | 3.16.54
3.13.0         | 3.16.54-eisfair-1 | 3.16.54
3.12.0         | 3.16.52-eisfair-1 | 3.16.52
3.11.0         | 3.16.52-eisfair-1 | 3.16.52
3.10.0         | 3.16.50-eisfair-1 | 3.16.50
3.9.0          | 3.16.50-eisfair-1 | 3.16.50
3.8.0          | 3.16.47-eisfair-1 | 3.16.47
3.7.0          | 3.16.47-eisfair-1 | 3.16.47
3.6.0          | 3.16.46-eisfair-1 | 3.16.46
3.5.0          | 3.16.46-eisfair-1 | 3.16.46
3.4.1          | 3.16.44-eisfair-1 | 3.16.45
3.4.0          | 3.16.44-eisfair-1 | 3.16.44
3.3.1          | 3.16.44-eisfair-1 | 3.16.44
3.3.0          | 3.16.44-eisfair-1 | 3.16.44
3.2.0          | 3.16.42-eisfair-1 | 3.16.43
3.1.2          | 3.16.42-eisfair-1 | 3.16.43
3.1.1          | 3.16.42-eisfair-1 | 3.16.43
3.1.0          | 3.16.42-eisfair-1 | 3.16.42


Ich danke allen Mitgliedern des Teams für Tests und Unterstützung und 
wünsche allen Anwendern weiterhin viel Spass mit eisfair!


Das Posting geht parallel an spline.eisfair und spline.eisfair.dev.
Produktive Rückmeldungen bitte an spline.eisfair.

-- 
der tom
[eisfair-team]

Mehr Informationen über die Mailingliste Eisfair