Tag Archives: Linux

Kernel 4.14.14 OOPSt rum

Posted on by

Heute soll es einen kleinen Bericht aus der Praxis mit den neuen Kernelpatchen geben. Seit 2 Wochen bauen die Kernelentwickler an den Patches für Spectre & Meltdown rum. Vermutlich schon länger, aber seit 2 Wochen sind die Ergebnisse im Umlauf 😉 Nach anfänglichen Erfolgen gegen den Angriff, wurden schnell die Probleme zu Tage gefördert, die durch den Patch verursacht werden.

Massenbetatests

Da ich auf unserer Serverfarm die neuen Kernel ausprobiert habe, habe ich die gefundenen Fehler an Redhat gemeldet. Das war vor 14 Tagen, als die Patche rauskamen. Seitdem sind „wir“ (an dem Bugreport sind viele Leute beteiligt) im ständigen Dialog und testen die neuen Kernel unter „real“(tm) Bedingungen aus.

Stand ist, die Kernel funktionieren soweit stabil. Aber einzelne Prozesse in der Virtualisierung und bei JAVA führen immer wieder zu Fehlern. Zwei von den vielen Fehlern, habe ich Euch mal mitgebracht:

Jan 21 06:04:21 xxx kernel: BUG: unable to handle kernel NULL pointer dereference at 0000000000000003
Jan 21 06:04:21 xxx kernel: IP: 0x99cf048
Jan 21 06:04:21 xxx kernel: PGD 461b067 P4D 461b067 PUD 57fd067 PMD 0
Jan 21 06:04:21 xxx kernel: Oops: 0002 [#3] SMP NOPTI
Jan 21 06:04:21 xxx kernel: Modules linked in: nfsv3 nfs fscache fuse nfsd auth_rpcgss nfs_acl lockd grace xt_owner xt_multiport ip6table_filter ip6_tables cfg80211 rfkill xenfs xen_privcmd sunrpc edac_mce_amd crct10dif_pclmul crc32_pclmul ghash_clmulni_intel xen_netfront xen_blkfront crc32c_intel
Jan 21 06:04:21 xxx kernel: CPU: 0 PID: 6020 Comm: xenstore-read Tainted: G D W 4.14.14-201.fc26.x86_64 #1
Jan 21 06:04:21 xxx kernel: task: ffff880005708000 task.stack: ffffc90000d18000
Jan 21 06:04:21 xxx kernel: RIP: e030:0x99cf048
Jan 21 06:04:21 xxx kernel: RSP: e02b:ffffc90000d1bfd0 EFLAGS: 00010206
Jan 21 06:04:21 xxx kernel: RAX: 0000000000000003 RBX: 0000000000000003 RCX: 00000000099cf048
Jan 21 06:04:21 xxx kernel: RDX: 0000000000000002 RSI: 00000000099cf048 RDI: 0000000000000000
Jan 21 06:04:21 xxx kernel: RBP: 00000000ffddc0a8 R08: 0000000000000000 R09: 0000000000000000
Jan 21 06:04:21 xxx kernel: R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
Jan 21 06:04:21 xxx kernel: R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
Jan 21 06:04:21 xxx kernel: FS: 00007f8761262b40(0000) GS:ffff88007f400000(0000) knlGS:0000000000000000
Jan 21 06:04:21 xxx kernel: CS: e033 DS: 002b ES: 002b CR0: 0000000080050033
Jan 21 06:04:21 xxx kernel: CR2: 0000000000000003 CR3: 0000000003556000 CR4: 0000000000000660
Jan 21 06:04:21 xxx kernel: Call Trace:
Jan 21 06:04:21 xxx kernel: ? switch_to_thread_stack+0x21/0x40
Jan 21 06:04:21 xxx kernel: Code: Bad RIP value.
Jan 21 06:04:21 xxx kernel: RIP: 0x99cf048 RSP: ffffc90000d1bfd0
Jan 21 06:04:21 xxx kernel: CR2: 0000000000000003
Jan 21 06:04:21 xxx kernel: ---[ end trace 50c257ff957ddb5b ]---

Jan 21 08:17:31 xxx kernel: invalid opcode: 0000 [#4] SMP NOPTI
Jan 21 08:17:31 xxx kernel: Modules linked in: nfsv3 nfs fscache fuse nfsd auth_rpcgss nfs_acl lockd grace xt_owner xt_multiport ip6table_filter ip6_tables cfg80211 rfkill xenfs xen_privcmd sunrpc edac_mce_amd crct10dif_pclmul crc32_pclmul ghash_clmulni_intel xen_netfront xen_blkfront crc32c_intel
Jan 21 08:17:31 xxx kernel: CPU: 0 PID: 7087 Comm: xenstore-read Tainted: G D W 4.14.14-201.fc26.x86_64 #1
Jan 21 08:17:31 xxx kernel: task: ffff88007a873c00 task.stack: ffffc900008c8000
Jan 21 08:17:31 xxx kernel: RIP: e030:0xffd9af11
Jan 21 08:17:31 xxx kernel: RSP: e02b:ffffc900008cbfd0 EFLAGS: 00010206
Jan 21 08:17:31 xxx kernel: RAX: 0000000000000004 RBX: 0000000000000003 RCX: 00000000ffd9af11
Jan 21 08:17:31 xxx kernel: RDX: 0000000000000022 RSI: 00000000ffd9af11 RDI: 0000000000000000
Jan 21 08:17:31 xxx kernel: RBP: 00000000ffd99b58 R08: 0000000000000000 R09: 0000000000000000
Jan 21 08:17:31 xxx kernel: R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
Jan 21 08:17:31 xxx kernel: R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
Jan 21 08:17:31 xxx kernel: FS: 00007f2cc2baeb40(0000) GS:ffff88007f400000(0000) knlGS:0000000000000000
Jan 21 08:17:31 xxx kernel: CS: e033 DS: 002b ES: 002b CR0: 0000000080050033
Jan 21 08:17:31 xxx kernel: CR2: 00000000088bb004 CR3: 0000000079d66000 CR4: 0000000000000660
Jan 21 08:17:31 xxx kernel: Call Trace:
Jan 21 08:17:31 xxx kernel: ? switch_to_thread_stack+0x21/0x40
Jan 21 08:17:31 xxx kernel: Code: Bad RIP value.
Jan 21 08:17:31 xxx kernel: RIP: 0xffd9af11 RSP: ffffc900008cbfd0
Jan 21 08:17:31 xxx kernel: ---[ end trace 50c257ff957ddb5c ]---

Die sind vom Kernel 4.14.14, also von gestern 🙂 und wie man an dem Datum sehen kann, sind die Kernel OOPS von heute morgen. Die Beschreibungen die gleich kommen, sind extra simple gehalten, da wohl die wenigsten wissen, was ein IP oder eine NULL POINTER Dereferenz ist. Wer schonmal in Assembler programmiert hat, dem wird das sofort was sagen, dem Rest eher nicht 🙂

Ein Opcode ist eine definierte Bitfolge, welche die CPU als Assemblerbefehl interpretiert und dann macht, was der Befehl meint.

„invalid opcode: 0000 [#4] SMP NOPTI“

Meint, daß die CPU über eine Anweisung gestolpert ist, die nicht definiert ist, in dem Fall eine 0x0000 = 0W . 0W meint den Wert Null (0) auf einer Bitbreite von 16 Bit (= 1 WORD daher das W von 0W => 00000000 00000000. 0L wäre Null(0) auf 32bit auch bekannt als LONGWORD = 00000000 00000000 00000000 00000000).

Das kann nur passieren, wenn ein IP ( Instruction Pointer ) im Speicher wohin gezeigt hat, wo „NICHTS“ war. Das da NICHTS war, war gut so, weil sonst hätte die CPU womöglich die dortigen Bits&Bytes als Befehle interpretiert und wäre Amok gelaufen.

Trivia: Wenn man eine CPU dazu bekommt, so einen Fehler zumachen während sie einen fremden Prozess(z.b. für root) ausführt UND bestimmen kann, WO im Speicher weitergemacht wird, hat man einen EXPLOIT geschafft, also einen ANGRIFF durchgezogen. Das ist dann immer das, was in den Medien landet 🙂

NULL pointer dereference

kernel: BUG: unable to handle kernel NULL pointer dereference at 0000000000000003
kernel: IP: 0x99cf048
kernel: Oops: 0002 [#3] SMP NOPTI

Das ist eine NULL POINTER Exception. Da ist die CPU über einen falschen IP(siehe oben) zu einer Adresse im Speicher gesprungen, wo ein weiterer Zeiger(Pointer) hätte sein sollen, es stand aber nur „0L“  dort.

Das ist eigentlich ein Programmierfehler, denn man müßte Zeiger genau auf „0L“ prüfen, bevor man sie benutzt. Da stellt sich jetzt die Frage, reagiert der Kernel seit den Patchen empfindlicher auf den Fehler ( der womöglich schon seit Jahren da war) oder ist der Fehler durch den Patch entstanden?

IMHO:

Es zeigen sich jetzt lustige Programmierfehler in allen möglichen Sachen/Kernel, weil der schlampige Stil jetzt nicht mehr hinhaut 😀 In C und C++, worin die Masse des Kernelcodes und der Anwendungen geschrieben ist, gibt es das Konstrukt des Doppelzeigers, also einem Zeiger auf einen Zeiger. Natürlich gibt es dafür eine Abkürzung im C Code die auch gern genommen wird, nur daß dabei der Code nicht prüft, ob da 0 als Zeiger steht. Das würde nämlich Performance kosten und genau die will man ja damit erreichen. Der Code geht also davon aus, daß die Zeiger immer stimmen, also optimistische Grundeinstellung des Entwicklers. Seit dem Patch kann man sich da wohl nicht mehr drauf verlassen.

Fazit

Aber zurück zur Situation, wenn man unbedingt muß, kann man die 64Bit Kernel benutzen. Für daheim ist das eh kein Problem, so weit ich das von meiner Serverfarm ableiten kann, betrifft es nur VM und JAVA Prozesse (z.b. Jitsi / Tomcat usw.). Die 32Bit Kernel sind besonders anfällig und derzeit noch nicht zu empfehlen, aber wer braucht auch noch 32bit ?

Die meisten werden die neuen Kernel also ohne Probleme fahren können.

Wer den 4.14.14 Kernel für Fedora 26 haben will :  https://koji.fedoraproject.org/koji/taskinfo?taskID=24303894

Eure Distros werden ähnliche Buildumgebungen haben, wo die aktuellen Testkernel gebaut werden.

 

Linux – Fedora reagiert auf Meltdown und Spectre

Posted on by

Fedora stellt für die beiden Angriffsvectoren der neuesten Sicherheitslücken Meltdown & Spectre Kernelpatche für Fedora 26 & 27 zur Verfügung. Die Updates werden bereits über die Stablerepos verteilt. Ein Reboot des Computers ist zwingend nötig um auf den neuen Kernel umzustellen.

Leistungseinbußen inklusive

Intel rechnet damit, daß die Gegenmaßnahmen ca. 2 % CPU Leistung schlucken werden. Gestern wurde in den Veröffentlichungen noch mit Zahlen von 5 – 30% kolportiert.  Mal sehen wie sich die AMD CPUs damit schlagen, oder ob das nur im Intel-Codesegment angesiedelt wird.

Früher gab es ja mal Kernel für Intel und AMD getrennt, man könnte eine Neuauflage fordern 🙂

 

Linux – Wenn das Bios die NVMe-SSD nicht bootet

Posted on by

Von dem Problem habe ich nur durch Dritte erfahren, konnte es aber leicht lösen.  Stellt Euch mal vor Ihr kauft Euch eine NVMe SSD  und Euer Bios kann die nicht booten, was macht Ihr dann  ?

Das Problem

Es soll Motherboards geben, die zwar einen passenden Port für die NVMe SSD haben, aber leider vergessen haben, daß man ja auch davon booten können müßte. Wenn man jetzt nur so eine NVMe SSD hat, ist man sprichwörtlich gearscht. Falls man nicht vor hat, seinen Rechner per USB Stick zu booten und von der LiveDisk mit der SSD zu spielen, wird das eine sehr frustrierende Neuanschaffung.

Die Idee

Aber halt! Wenn man das System von einem USB Stick booten kann, könnte man dann nicht auch NUR davon booten ohne die Livedisk zu starten ?

Die Lösung

Na ja, vom Prinzip her schon, aber USB-Stick, das muß doch besser gehen. Ja geht es, aber ihr braucht dafür eine normale SSD oder HD, die kann aber ganz winzig sein, Hauptsache 512 MB passen drauf!

Bei der Installation Eures OSes wählt man für /, Swap und /home die neue NVMe SSD aus. Normal partitionieren und formatieren, soweit nichts besonderes.

Die /boot Partition kicken wir jetzt aber nicht auf die NVMe sondern die alte/kleine SSD. Dort wird auch der Bootloader installiert. Linux ist es nämlich völlig egal, wo die Partionen liegen, Hauptsache der Bootloader kann es finden und das kann er ja dann. Problem gelöst.

Sein System auf die neue NVMe umstellen, ohne neu zu installieren

Wie man eine defekte Bootpartition fixen kann, hatte ich schon mal thematisiert, daher setzte ich das Wissen jetzt bei Euch voraus. Wie man unschwer erkennen kann, habe ich hier den Booteintrag in Grub vor mir :

menuentry 'Fedora (4.14.4-200.fc26.x86_64) 26 (Twenty Six)' --class fedora --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-4.13.8-100.fc25.x86_64-advanced-e62edbbe-a1ae-4242-bca5-1249d6f2df67' {
 load_video
 set gfxpayload=keep
 insmod gzio
 insmod part_msdos
 insmod ext2
 set root='hd2,msdos1'
 if [ x$feature_platform_search_hint = xy ]; then
 search --no-floppy --fs-uuid --set=root --hint-bios=hd2,msdos1 --hint-efi=hd2,msdos1 --hint-baremetal=ahci2,msdos1 221608f2-5914-4619-9ef7-6dfddf233fd4
 else
 search --no-floppy --fs-uuid --set=root 221608f2-5914-4619-9ef7-6dfddf233fd4
 fi
 linux /vmlinuz-4.14.4-200.fc26.x86_64 root=/dev/mapper/luks-ffbd61f2-4c1e-4dc8-b12b-c89e9f69c9fa ro rd.driver.blacklist=nouveau modprobe.blacklist=nouveau vconsole.font=latarcyrheb-sun16 rd.luks.uuid=luks-ca1f019d-39ce-4cf8-b522-f6d3e63ebe2a rd.luks.uuid=luks-ffbd61f2-4c1e-4dc8-b12b-c89e9f69c9fa rhgb quiet splash audit=0 rd.driver.blacklist=nouveau nouveau.modeset=0 modprobe.blacklist=nouveau LANG=de_DE.UTF-8
 initrd /initramfs-4.14.4-200.fc26.x86_64.img
}

Ok, meine Systempartition ist vollverschlüsselt, daher habe ich da die LUKS-ID stehen. Auf einem „normalen“ System könnte das so aussehen :

menuentry 'Fedora (4.14.6-200.fc26.x86_64) 26 (Twenty Six)' --class fedora --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-4.7.10-100.fc23.x86_64-advanced-dca7eea1-687e-476a-a9a0-c41ef0329113' {
 load_video
 set gfxpayload=keep
 insmod gzio
 insmod part_msdos
 insmod ext2
 set root='hd0,msdos1'
 if [ x$feature_platform_search_hint = xy ]; then
 search --no-floppy --fs-uuid --set=root --hint='hd0,msdos1' dca7eea1-687e-476a-a9a0-c41ef0329113
 else
 search --no-floppy --fs-uuid --set=root dca7eea1-687e-476a-a9a0-c41ef0329113
 fi
 linux /boot/vmlinuz-4.14.6-200.fc26.x86_64 root=UUID=dca7eea1-687e-476a-a9a0-c41ef0329113 ro rhgb quiet audit=0 LANG=de_DE.UTF-8
 initrd /boot/initramfs-4.14.6-200.fc26.x86_64.img
}

Alles was man machen muß, ist die UUID der Partition zu ändern und schon bootet das System als System von der anderen SSD. Wie bekommt man die jetzt, nachdem man die NVMe SSD partitioniert und formatiert hat ?

UUID ermitteln

# blkid
/dev/xvda1: UUID=“dca7eea1-687e-476a-a9a0-c41ef0329113″ TYPE=“ext4″ PARTUUID=“000af34a-01″
/dev/xvda2: UUID=“262b5659-4c18-4d8b-89e9-d9ba932e77c0″ TYPE=“swap“ PARTUUID=“000af34a-02″
/dev/xvdb: UUID=“65d31ff9-53c9-4e0b-8a52-0a16622c82d9″ TYPE=“ext4″

Mit dem gleichen Befehl bekommt man auch die LUKS ID mitgeteilt, so man denn eine verschlüsselte Luks-Partition hat:

/dev/mapper/luks-ca1f019d-39ce-4cf8-b522-f6d3e63ebe2a: UUID=“46da0d80-21fb-45b7-8567-ba047de66cb6″ TYPE=“swap“
/dev/mapper/luks-ffbd61f2-4c1e-4dc8-b12b-c89e9f69c9fa: UUID=“e62edbbe-a1ae-4242-bca5-1249d6f2df67″ TYPE=“ext4″

(Zwischenfrage aus dem Publikum: Wieso verschlüsselst Du auch SWAP ?  Antwort: Weil in dem ausgelagerten Speicher Klartext steht und man sich andernfalls eine Sicherheitslücke ins Haus holt. )

Natürlich muß man sein System noch ein bisschen pimpen, damit es später nicht wieder von der alten Systempartition auf der „alten SSD“ booten, nur weil der Kernel neu erstellt wurde 😀 Folgende Punkte sind zu manipulieren:

/etc/fstab
/etc/mtab
/etc/default/grup

Also alle alten UUID/LUKS-IDs durch die neuen ersetzen. Das ist ein ganz schöner Schock, wenn man seine neue SSD im Betrieb hat und dann ein paar Tage später der Rechner wieder auf einem alten Stand ist 😀