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

Thomas Bork tom at eisfair.org
Do Jul 26 23:21:16 CEST 2018 

Hi @all,

es ist eine Version 3.18.0 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 3.16.56.
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].

Denkt daran, eventuell bei Euch installierte kernel-abhängige Treiber 
(z.B. die AVM- und Dahdi-Module) für diesen Kernel vorher zu 
installieren, da der Name sich geändert hat!


Änderungen zum stabilen eiskernel 3.16.0:
=========================================
- Name auf 3.16.57-eisfair-1 geändert (war 3.16.56-eisfair-1).
- Alle Patches bis zu 3.16.57 integriert (war 3.16.56).
   usbip basiert auf einer älteren angepassten Version.
- e1000e 3.4.0.2 -> 3.4.1.1
- Konfiguration geändert, um das frühe Laden von Microcode-
   Updates zu ermöglichen:
   +CONFIG_MICROCODE=y
   +CONFIG_MICROCODE_INTEL=y
   +CONFIG_MICROCODE_AMD=y
   +CONFIG_MICROCODE_OLD_INTERFACE=y
   +CONFIG_MICROCODE_INTEL_EARLY=y
   +CONFIG_MICROCODE_AMD_EARLY=y
   +CONFIG_MICROCODE_EARLY=y
- Konfiguration geändert, um hamradio zu unterstützen:
   +CONFIG_HAMRADIO=y
   +
   +#
   +# Packet Radio protocols
   +#
   +CONFIG_AX25=m
   +# CONFIG_AX25_DAMA_SLAVE is not set
   +CONFIG_NETROM=m
   +# CONFIG_ROSE is not set
   +
   +#
   +# AX.25 network device drivers
   +#
   +CONFIG_MKISS=m
   +CONFIG_6PACK=m
   +CONFIG_BPQETHER=m
   +# CONFIG_SCC is not set
   +# CONFIG_BAYCOM_SER_FDX is not set
   +CONFIG_BAYCOM_SER_HDX=m
   +# CONFIG_BAYCOM_PAR is not set
   +# CONFIG_BAYCOM_EPP is not set
   +# CONFIG_YAM is not set
- Es wurde eine Datei /var/install/initrd/intel-ucode.img in das System
   integriert, die ein mit iucode_tool erstelltes cpio-Archiv der Intel-
   Microcode-Updates aus microcode-20180703.tgz enthält.


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 alle Intel-Microcode-Updates aus 
microcode-20180703.tgz in einem Image unter 
/var/install/initrd/intel-ucode.img mit. Die Veränderungen in diesem 
Kernel erlauben das frühe Laden dieser Microcodes.
Bei einem Update wird die erzeugte normale initrd.gz unter 
/var/install/initrd/initrd.gz.without.iucode abgelegt und es wird eine 
initrd.gz aus /var/install/initrd/intel-ucode.img und 
/var/install/initrd/initrd.gz.without.iucode erzeugt und unter 
/var/install/initrd/initrd.gz.with.iucode abgelegt. Die alte 
unveränderte initramfs ohne intel-ucode wird wie bisher als 
/boot/initrd.gz nach einem Neustart verwendet.

Dieses Verfahren erlaubt es...

1.
...die Datei /var/install/initrd/initrd.gz.with.iucode nach 
/boot/initrd.gz zu kopieren, lilo aufzurufen und nach einem Reboot zu 
überprüfen, ob ein neuer Microcode geladen wurde. Ich rufe hiermit alle 
User mit Intel-Prozessoren und nicht-virtualisierten Systemen zu diesem 
Test auf. Bitte postet nach dem Booten die Ausgabe von

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.iucode nach /boot/initrd.gz, 
Aufruf von 'lilo' und Reboot.

2.
...die alte unveränderte initramfs ohne intel-ucode zu behalten und auch 
später noch zu manipulieren. Die alte unveränderte initramfs ohne 
intel-ucode ist /var/install/initrd/initrd.gz.without.iucode. 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.iucode erzeugen:

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

Nun kann man wahlweise

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

oder

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

nach /boot/initrd.gz kopieren.


Dieses Paket bei https://pack-eis.de:
=====================================
PAE : https://www.pack-eis.de/index.php?p=25172
SMP : https://www.pack-eis.de/index.php?p=25173
VIRT: https://www.pack-eis.de/index.php?p=25174


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


Änderungen zum vorherigen stabilen eiskernel-dev 3.16.0:
========================================================
- Basiert auf 3.16.57 (war 3.16.56).
- Setzt installierten eiskernel 3.18.0 voraus.
- Lädt 3.16.57 herunter (war 3.16.56).
- e1000e 3.4.0.2 -> 3.4.1.1.
- require developer 2.8.0 (was 2.6.1)
- require gcc5 2.8.2
- check for activated gcc 5.5.0


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


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