Tag Archives: kernel

Surface Pro4 … und nichts ist wie es sein sollte

Posted on by

Das Surface Pro4 kam prompt. Der Verkäufer war seriöse, das Gerät in Ordnung, genau wie in der Beschreibung. Eigentlich ein idealer Zeitpunkt vor Freude in die Luft zu springen. Ok, es kam aus der Kälte, also durfte es erst einmal warm werden.

Die Generation macht den Unterschied

Dann der Boot. Der Erzfeind erscheint: Windows 10. Der alte Besitzer hatte es frisch reinstalliert. Ok. Also dann USB-Stick dran und davon booten. Das ging noch. Der Livestick lies sich booten, wenn man im Bios den Bootmanager benutzt und per „Wischen“ sagt: „boote von dem wo ich gewischt habe“. Ja, man hat schon einfachere Bootmanager gesehen 🙂

Fedora bootet. So weit, so gut. Erstmal ein Backup von der alten Platte machen, besonders von der Windows Recovery. Gnome-Disks führte das anstandslos durch. Ein paar Gigabytes später, lagen zwei Partitionen der SSD auf meiner Backupplatte, vielleicht will man das Gerät ja mal weiter verkaufen, da könnte unschönerweise Windows helfen.

Die Installation

Ok, jetzt Fedora installieren. Jooooo.. wie man das von einem i7 und SSD erwarten würde, war das in wenigen Minuten erledigt. Neustart ausgewählt und ….  ging natürlich nicht so einfach. Der wollte doch jetzt glatt primär den Stick booten. Ernsthaft?! Da half nur das Tutorialvideo der M$ Hilfeseite ansehen, etwas textlich zu beschreiben reicht heute offensichtlich nicht mehr 🙁  Na gut. Bootmanager umgestellt, permanent gemacht, und nun bootet auch die SSD durch. Hat ja nur eine halbe Stunde Zeit gekostet. Wer braucht schon benutzerfreundliche und einsichtige Biosware ?

Also auch das Hindernis genommen, aber jetzt kann es … was zum Geier … wer soll das denn lesen können? Das Grubmenü war nur schwer mit Ü40 Augen zu lesen um nicht zu sagen, der klassische Sherlock hätte seine helle Freude gehabt. 3k Display halt, das war zu erwarten gewesen, aber eigentlich hoffte ich auf eine automatische Anpassung, weil die Riesenauflösung ja bekannt zu seien schien. Jetzt wisst Ihr auch, wieso es diesen Beitrag zu Die Schriftgröße des Bootprozesses anpassen gab 😉

Es bootet ja, da kann ja nicht all zu viel schief gehen, denkt man so. Naiv, ich weiß. Die nächste Hürde, und gut, daß ich ein gebrauchtes Gerät mit TypeCover ( so heißt das anflanschbare Keyboard von M$ ) bestellt habe, weil sonst wäre ich an der Festplattenverschlüsselung gescheitert. Ja, ich Wahnsinniger wagte eine Festplattenverschlüsselung bei einem Tablet einzusetzen und hoffte doch tatsächlich auf ein OSK ( On Screen Keyboard ) mit dem man das Passwort eingeben kann. Die Hoffnung war vergebens. Wo GRUB, wir reden vom Bootloader, also dem primitivsten Teil des Systems, der eigentlich kaum Userinteraktivität nötig hat, schon ein virtuelles Keyboard einblendete!!! da wagt es der Luksunlocker wirklich, ohne ein OSK daher zu kommen 🙁

Und Gnome startet

Fairerweise muß ich sagen, hatten wir das bei dem Pro3 im Januar nicht mit Krypto gemacht, daher war es ein Wagnis. Ok, verloren. Naja, nicht so schlimm, Bugreport an Red Hat, mal sehen was passiert. Krypto muß halt sein, schon falls das geklaut wird, da habe ich keinen Bock drauf, daß einer auf meine SSD glotzt. Hey, ein Loginscreen… 🙂  Ein Klick und Gnome ist da.

Hinweis: die meisten Screenshots sind auf FullHD reduziert worden.

Gnome Terminal mit OSKDas OSK von Gnome ist staaaaarkkkkkk verbesserungswürdig, weil:

– keine Umlaute
– keine Cursorsteuertasten
– kein deutsches Layout (mit Umlauten)

Auch dazu ist bereits ein Bugreport abgesetzt, denn schliesslich gibt es da eine Regions&Sprach Taste, die auch das Keyboardlayout umstellt, nur halt nicht im OSK 😀

Jetzt haben wir uns soweit vorgekämpft, dann laß uns mal das Touchgerät austesten…

What the Fuck !?!?!

„Herzlichen Glückwunsch zu Ihrem neuen Angeberlaptop! … und jetzt nerven Sie uns nicht weiter.“

Im nächsten Teil geht es um : INTEL i915 IPTS

Games: Astrolords mit Touchsupport?

Linux – Kernel 4.15.x starten unter 32Bit nicht mehr

Schlechte Nachrichten aus der 32bit Welt.. okok, Insel, soviele sind es ja nicht mehr 😉 Die Fedora Kernel der 4.15er Serie starten bislang nicht in einer paravirtualisierten Xen VM.

Es gibt keinerlei Hinweise auf die Gründe, da die VM nicht mal Dracut starten kann. Bugreport an RedHat ist raus, warten wir es ab. Ich kann derzeit nur abraten 32Bit Kernel mit 4.15 starten zu wollen. 4.14er funktionieren. Ich tippe ja auf die im Kernel verbauten Specture und Meltdown Patche.

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.