Linux – Fedora – Spectre & Meltdown Kernels nicht fehlerlos

Posted on by

Seit einigen Tagen sind ja die „gepatchten“ Fedora Kernel zu den Specture & Meltdown Schwachstellen verfügbar. Leider kommt es bei 32 und 64 Bit zu diversen Bugs, die ganze Serverfarmen inoperabel machen.

Der Kernel OOPS

so sieht so ein Kernel Fehler aus :

Jan 8 15:15:43 xx kernel: BUG: unable to handle kernel NULL pointer dereference at 00000008
Jan 8 15:15:43 xx kernel: IP: __radix_tree_lookup+0xe/0xa0
Jan 8 15:15:43 xx kernel: *pdpt = 0000000019977027 *pde = 0000000000000000 
Jan 8 15:15:43 xx kernel: Oops: 0000 [#1] SMP
Jan 8 15:15:43 xx kernel: Modules linked in: nfsv3 nfs_acl nfs lockd grace sunrpc fscache rmd160 ip_vti ip_tunnel af_key ah6 ah4 esp6 esp4 xfrm4_mode_beet xfrm4_tunnel tunnel4 xfrm4_mode_tunnel xfrm4_mode_transport xfrm6_mode_transport xfrm6_mode_ro xfrm6_mode_beet xfrm6
_mode_tunnel ipcomp ipcomp6 xfrm6_tunnel tunnel6 xfrm_ipcomp chacha20poly1305 cmac camellia_generic cast6_generic cast5_generic cast_common deflate ccm serpent_sse2_i586 serpent_generic glue_helper ablk_helper blowfish_generic cls_u32 blowfish_common twofish_generic sch_h
tb twofish_i586 twofish_common xcbc sha512_generic des_generic geode_aes xt_owner xt_multiport ip6table_filter ip6_tables xenfs xen_privcmd coretemp xen_netfront nf_conntrack_pptp nf_conntrack_proto_gre nf_conntrack libcrc32c crc32c_intel xen_blkfront
Jan 8 15:15:43 xx kernel: CPU: 0 PID: 1740 Comm: java Not tainted 4.14.11-200.fc26.i686+PAE #1
Jan 8 15:15:43 xx kernel: task: d750c500 task.stack: d7f96000
Jan 8 15:15:43 xx kernel: EIP: __radix_tree_lookup+0xe/0xa0
Jan 8 15:15:43 xx kernel: EFLAGS: 00010282 CPU: 0
Jan 8 15:15:43 xx kernel: EAX: 00000004 EBX: 0de6d000 ECX: 00000000 EDX: 00000000
Jan 8 15:15:43 xx kernel: ESI: 00000000 EDI: 00000004 EBP: d7f97da8 ESP: d7f97d98
Jan 8 15:15:43 xx kernel: DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0069
Jan 8 15:15:43 xx kernel: CR0: 80050033 CR2: 00000008 CR3: 01ee4000 CR4: 00002660
Jan 8 15:15:43 xx kernel: Call Trace:
Jan 8 15:15:43 xx kernel: radix_tree_lookup_slot+0x1d/0x40
Jan 8 15:15:43 xx kernel: find_get_entry+0x20/0x160
Jan 8 15:15:43 xx kernel: pagecache_get_page+0x24/0x290
Jan 8 15:15:43 xx kernel: lookup_swap_cache+0x3a/0x100
Jan 8 15:15:43 xx kernel: swap_readahead_detect+0x55/0x280
Jan 8 15:15:43 xx kernel: ? xen_set_pte_at+0x81/0x140
Jan 8 15:15:43 xx kernel: do_swap_page+0x22a/0x990
Jan 8 15:15:43 xx kernel: ? wp_page_copy+0x361/0x6f0
Jan 8 15:15:43 xx kernel: ? kmap_atomic_prot+0x3e/0x130
Jan 8 15:15:43 xx kernel: handle_mm_fault+0x498/0xc90
Jan 8 15:15:43 xx kernel: ? xen_timer_interrupt+0x17/0x30
Jan 8 15:15:43 xx kernel: __do_page_fault+0x202/0x4d0
Jan 8 15:15:43 xx kernel: ? __do_page_fault+0x4d0/0x4d0
Jan 8 15:15:43 xx kernel: do_page_fault+0x27/0xd0
Jan 8 15:15:43 xx kernel: ? __do_page_fault+0x4d0/0x4d0
Jan 8 15:15:43 xx kernel: common_exception+0x6f/0x76
Jan 8 15:15:43 xx kernel: EIP: 0x1f51b404
Jan 8 15:15:43 xx kernel: EFLAGS: 00010202 CPU: 0
Jan 8 15:15:43 xx kernel: EAX: 00000000 EBX: 0de6df60 ECX: 00000000 EDX: 40000000
Jan 8 15:15:43 xx kernel: ESI: 00000001 EDI: 40000000 EBP: 0f1f40b8 ESP: 0f1f409c
Jan 8 15:15:43 xx kernel: DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b
Jan 8 15:15:43 xx kernel: Code: b6 00 00 00 00 0f 0b 8d b6 00 00 00 00 b8 ef ff ff ff eb a4 e8 34 73 8b ff 8d 74 26 00 55 89 e5 57 56 53 89 c7 83 ec 04 89 4d f0 <8b> 5f 04 89 d8 83 e0 03 83 f8 01 75 6d 89 d8 83 e0 fe 0f b6 08
Jan 8 15:15:43 xx kernel: EIP: __radix_tree_lookup+0xe/0xa0 SS:ESP: 0069:d7f97d98
Jan 8 15:15:43 xx kernel: CR2: 0000000000000008
Jan 8 15:15:43 xx kernel: ---[ end trace 91253bf32b64ee98 ]---

Wie man sieht ist hier ein Java Prozess der gestorben ist. Das Problem dabei ist allerdings, daß die Prozesse gar nicht sterben, sondern einfach nicht mehr reagieren. Das ist besonders blöd, weil so Prozessüberwachungstools, die Prozesse nicht einfach neu starten können.

Im Fall oben war es ein Tomcat Webserver der hängen blieb und damit keine Webseiten mehr auslieferte.

Verschärfung

Problematisch an der Sache ist, daß auch kerneleigene Prozesse betroffen sind z..b der „swapper/0“ crasht mal einfach beim Hochfahren des Rechners weg. Ob sich das negativ auswirkt oder die Server einfach nicht mehr swappen, weiß man noch nicht.

Abhilfe ?

Da habt Ihr leider Pech. Redhat ist dran, aber das kann dauern. Bis zu einer Lösung könnte Ihr hängende Prozesse nur neustarten.