Kernel 5.7.8+ Problem entdeckt

Posted on by

Es ist mal wieder soweit, ein fieses Kernelproblem wurde entdeckt. Ja ok, passiert dauernd, aber meisten sind nicht alle davon betroffen, hier schon, da es ein Speicherzugriffsfehler ist.

Kernel 5.7.8+ Problem entdeckt

In den letzten zwei Tagen sind zwei verschiedene Computer mit dem gleichen Fehlerbild stehen geblieben:

Aug 2 18:01:17 shortname kernel: BUG: unable to handle page fault for address: ffff8881e2e48630
Aug 2 18:01:17 shortname kernel: #PF: supervisor write access in kernel mode
Aug 2 18:01:18 shortname kernel: #PF: error_code(0x0003) – permissions violation

Der PC bleibt dabei nicht gleich stehen, sondern der Zugriff auf Strukturen im /proc Filesystem ( procfs ) friert einfach ein. Als Resultat bleiben Programme wie „top“ oder „pidof“ stecken. Das ist besonders blöd, weil „pidof“ beim Startprozess eines Terminals für die Bash mitmischt und man so keins mehr starten kann.

Ich hatte erst gedacht, daß wäre ein VM Problem, weil es zunächst im Servercluster aufgetreten ist, aber da es jetzt auch bare-metal auf einem Desktop-PC passiert ist, was es Zeit Alarm zu schlagen.

Wer Kernel 5.7.8 einsetzt kann sich derzeit nicht sicher sein, daß der PC durchläuft. Bei mit lag der Ausfallzeitpunkt bei knappen 15 Stunden Betriebszeit für bare-metal und ~2 Wochen für eine VM in der heute das gleiche passiert ist. Da das Problem frisch entdeckt wurde, gibt es noch keine Reaktion vom Kernel Team. Ich kann aber nur dazu raten einen anderen Kernel lauf zu lassen.

Wenn Ihr das Problem rechtzeitig bemerkt, könnt Ihr noch über die Desktop-Systemüberwachung in die Prozessliste und die „pidof“ Prozesse abbrechen, die das Starten eines Terminals verhindern. Danach kommt die Bash i.d.r. sauber hoch und Ihr könnt Reboot eingeben. Ein „systemctl reboot -i“ wird nötig sein, da der normale Reboot, zumindest bei mir, verweigert wurde.

Hier für Euch die ganze Kernelmeldung für Vergleichszwecke:

Aug 2 18:01:17 shortname kernel: BUG: unable to handle page fault for address: ffff8881e2e48630
Aug 2 18:01:17 shortname kernel: #PF: supervisor write access in kernel mode
Aug 2 18:01:18 shortname kernel: #PF: error_code(0x0003) – permissions violation
Aug 2 18:01:18 shortname kernel: PGD 2a0c067 P4D 2a0c067 PUD 3800067 PMD 1ffff2067 PTE 100001e2e48065
Aug 2 18:01:19 shortname kernel: Oops: 0003 [#3] SMP NOPTI
Aug 2 18:01:19 shortname kernel: CPU: 0 PID: 96 Comm: kswapd0 Tainted: G D W 5.7.8-100.fc31.x86_64 #1
Aug 2 18:01:19 shortname kernel: RIP: e030:ptep_clear_flush_young+0x1d/0x30
Aug 2 18:01:19 shortname kernel: Code: 48 0f ba 32 05 0f 92 c0 0f b6 c0 c3 90 0f 1f 44 00 00 48 8b 05 ec 74 40 01 48 25 00 f0 ff ff 48 f7 d0 48 23 02 83 e0 20 74 0c <f0> 48 0f ba 32 05 0f 92 c0 0f b6 c0 c3 66 0f 1f 44 00 00 0f 1f 44
Aug 2 18:01:19 shortname kernel: RSP: e02b:ffffc90001127a48 EFLAGS: 00010202
Aug 2 18:01:19 shortname kernel: RAX: 0000000000000020 RBX: ffff888101c64ed8 RCX: 0000000000000000
Aug 2 18:01:19 shortname kernel: RDX: ffff8881e2e48630 RSI: 00007fe123ac6000 RDI: ffff888101c64ed8
Aug 2 18:01:19 shortname kernel: RBP: ffffea00049c2e80 R08: 0000000000000101 R09: 0000000000000125
Aug 2 18:01:19 shortname kernel: R10: ffff8881f483e8d0 R11: ffffea0005ddc2a0 R12: ffffc90001127b08
Aug 2 18:01:19 shortname kernel: R13: 0000000000000000 R14: 00007fe123ac6000 R15: 0000000000000186
Aug 2 18:01:19 shortname kernel: FS: 00007f37db3a7700(0000) GS:ffff8881f5c00000(0000) knlGS:0000000000000000
Aug 2 18:01:19 shortname kernel: CS: e030 DS: 0000 ES: 0000 CR0: 0000000080050033
Aug 2 18:01:19 shortname kernel: CR2: ffff8881e2e48630 CR3: 0000000002a0a000 CR4: 0000000000040660
Aug 2 18:01:19 shortname kernel: Call Trace:
Aug 2 18:01:19 shortname kernel: page_referenced_one+0x59/0x150
Aug 2 18:01:19 shortname kernel: rmap_walk_file+0x157/0x2f0
Aug 2 18:01:19 shortname kernel: page_referenced+0xdb/0x150
Aug 2 18:01:19 shortname kernel: ? rmap_walk_file+0x2f0/0x2f0
Aug 2 18:01:19 shortname kernel: ? page_get_anon_vma+0x80/0x80
Aug 2 18:01:19 shortname kernel: shrink_active_list+0x2e5/0x560
Aug 2 18:01:19 shortname kernel: shrink_lruvec+0x3b9/0x6b0
Aug 2 18:01:19 shortname kernel: ? do_shrink_slab+0x52/0x2c0
Aug 2 18:01:19 shortname kernel: shrink_node+0x169/0x680
Aug 2 18:01:19 shortname kernel: balance_pgdat+0x2d9/0x5c0
Aug 2 18:01:19 shortname kernel: kswapd+0x1ed/0x3a0
Aug 2 18:01:19 shortname kernel: ? __schedule+0x2c2/0x730
Aug 2 18:01:19 shortname kernel: ? finish_wait+0x80/0x80
Aug 2 18:01:19 shortname kernel: kthread+0xf9/0x130
Aug 2 18:01:19 shortname kernel: ? balance_pgdat+0x5c0/0x5c0
Aug 2 18:01:19 shortname kernel: ? kthread_park+0x90/0x90
Aug 2 18:01:19 shortname kernel: ret_from_fork+0x35/0x40
Aug 2 18:01:19 shortname kernel: Modules linked in: fuse btrfs blake2b_generic xor raid6_pq hfsplus hfs minix vfat msdos fat jfs xfs nfsv3 nfs_acl nfs lockd grace fscache xt_owner ipt_REJECT nf_reject_ipv4 xt_connlimit nf_conncount nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c xt_multiport ip6table_filter ip6_tables cls_u32 sch_htb iptable_filter intel_rapl_msr intel_rapl_common cfg80211 sb_edac x86_pkg_temp_thermal coretemp crct10dif_pclmul rfkill crc32_pclmul ghash_clmulni_intel intel_rapl_perf sunrpc ip_tables xen_netfront xen_blkfront crc32c_intel
Aug 2 18:01:19 shortname kernel: CR2: ffff8881e2e48630
Aug 2 18:01:19 shortname kernel: —[ end trace 7fb962ee698fa150 ]—
Aug 2 18:01:19 shortname kernel: RIP: e030:unmap_page_range+0x631/0xec0
Aug 2 18:01:19 shortname kernel: Code: fe e8 03 f8 ff ff 48 83 7c 24 18 00 48 89 c3 74 09 48 85 c0 0f 85 c0 05 00 00 41 f6 44 24 20 01 0f 84 25 03 00 00 4c 8b 6d 00 <48> c7 45 00 00 00 00 00 4d 39 7c 24 10 4c 89 f8 49 0f 46 44 24 10
Aug 2 18:01:19 shortname kernel: RSP: e02b:ffffc90002a2bb38 EFLAGS: 00010202
Aug 2 18:01:19 shortname kernel: RAX: ffffea0001b72500 RBX: ffffea0001b72500 RCX: 0000000000000125
Aug 2 18:01:19 shortname kernel: RDX: 0000000000000000 RSI: 00005589f49e7000 RDI: 000000083aa94125
Aug 2 18:01:19 shortname kernel: RBP: ffff8881e3d90f38 R08: ffff88810011e320 R09: 0000000000000000
Aug 2 18:01:19 shortname kernel: R10: 0000000000007ff0 R11: 0000000000000000 R12: ffffc90002a2bc80
Aug 2 18:01:19 shortname kernel: R13: 000000083aa94125 R14: 00005589f49e8000 R15: 00005589f49e7000
Aug 2 18:01:19 shortname kernel: FS: 00007f37db3a7700(0000) GS:ffff8881f5c00000(0000) knlGS:0000000000000000
Aug 2 18:01:19 shortname kernel: CS: e030 DS: 0000 ES: 0000 CR0: 0000000080050033
Aug 2 18:01:19 shortname kernel: CR2: ffff8881e2e48630 CR3: 0000000002a0a000 CR4: 0000000000040660

 

CoronaChroniken: Infizierte sind nicht zwangsweise Kranke oder Tote

Posted on by

Liebe Maskierte,

ich hab da mal eine kleine Umfrage für Euch gestartet, weil meine Frage nicht in der Lancet-Studie über Corona in Deutschland beantwortet wurde.

CoronaChroniken: Infizierte sind nicht zwangsweise Kranke oder Tote

Meine Frage war ursprünglich, sterben jetzt eigentlich immer gleich viele Menschen an/mit Covid-19 oder hat die Sterberate abgenommen?

Dazu braucht man erstmal die Sterbezahlen und rein praktisch, auch die Verweildauer der Patienten im Krankenhaus. Die AOK, welche die im Lancet veröffentlichte Studie unterstützt hat, war so freundlich mir die Zahlen zu übermitteln:

Die gestorbenen Patienten liegen im Durchschnitt 12,8 Tage im Krankenhaus. Bei den beatmeten verstorbenen sind es 16,4 Tage, bei den nicht beatmeten Patienten sind es 10,3 Tage.
Wie lange die Patienten nach der Diagnosestellung bis zu Ihrem Krankenhausaufenthalt noch zu Hause waren, ist nicht bekannt.

Viele Grüße

Carina Mostert
Forschungsbereichsleiterin

Forschungsbereich Krankenhaus
Wissenschaftliches Institut der AOK (WIdO)

Es gibt also einen Unsicherheitsfaktor, aber wir können mit 14 Tagen rechnen. Nicht geantwortet hatte übrigens: das RKI. Nun brauchen wir die Zahlen der Leute die als Covid-19 Verstorbene gelten, die gibts beim Bundesamt für Statistik:

https://www.destatis.de/DE/Themen/Querschnitt/Corona/Gesellschaft/kontextinformationen-gesellschaft.html

Leider gibt es die Zahlen nur Wochenweise, was in Verbindung mit den täglichen Infiziertenzahlen zu einem, sagen wir es mal vorsichtig, gewöhnungsbedürftigen Graphen geführt hat:

Ein vergleich zwischen den Gestorbenen und den InfiziertenTrotzdem ist der Graph sehr aufschlussreich, da er anzeigt, daß zu Beginn der Pandemie die Leute im gleichen Maße wie die Neuinfiziertenzahlen gestiegen bzw. gefallen sind. Der Ausbruch bei Tönnies Mitte Juni hatte keine Zunahme der Sterbezahlen zur Folge … die Zahlen sind sogar weiter gesunken! Aus dem Graphen und den Zahlen der AOK kann man ablesen, daß auch drei Wochen nach dem Anstieg die Zahlen der mit Verbindung zu Corona verstorbenen weiter abnimmt. Drei Wochen sind als Zeitraum deswegen wichtig, weil die durchschnittliche Sterbedauer der Patienten 12,8 Tage (+7 Tage Inkubationszeit) beträgt und innerhalb der drei Wochen defakto Menschen hätten sterben müssen. Was nicht klar ist, ist die Frage, ob die ausländischen Hilfsarbeiter in ihren Ländern an der Infektion verstorben sind, so sie sich überhaupt absetzen konnten. Ein kleiner Unsicherheitsfaktor bleibt hier also im Spiel.

Schlußfolgerung

Das Virus ist entweder so mutiert, daß es weniger tödlich ist, oder die Behandlung wurde erfolgreich verbessert (unwahrscheinlich). Sollte der Virus nicht mutiert sein, dann hatten einige einfach Glück, daß sie in dieser Statistik nicht auftauchen ( Quarantäneerfolg z.B. ) oder die, die für einen tödlichen Ausgang empfänglich waren, sind jetzt bereits tod und können nicht nochmal sterben. Würde letzteres zutreffen, wären alle allgemeinen Maßnahmen zur Ausbreitungskontrolle überflüssig geworden. Auf die Maßnahmen zum Schutz von Risikopatienten hätte das keinen Einfluß.

In ca. drei Wochen wissen wir mehr, was genau der Fall ist, denn dann kommen die Sterbezahlen für den aktuellen Anstieg in die Destatis Auswertung und sollte es auch dort keine zusätzlichen Covid-19 Opfer geben, wäre der Fall klar: Virus Richtung harmlos mutiert oder empfängliche Personen bereits verstorben, denn diesmal ist es kein örtlich begrenzter Herd wie bei Tönnies, sondern aufs gesamte Bundesgebiet verteilt (mit örtlichen Schwerpunkten ). Dann könnten wir eine zügige Normalisierung einleiten und einfordern.

Ich bin optimistisch, daß es auch beim aktuellen Anstieg nicht zu viel-mehr neuen Toten kommen wird. Mit einigen wenigen werden wir aber leider rechnen müssen, da der aktuelle Anstieg andere Gruppen von Menschen getroffen hat, als Menschen im arbeitsfähigen Alter oder kurz „Nicht-Risikogruppe“ wie bei Tönnies. Das es derzeitig überhaupt noch Tote gibt, die Corona zugerechnet werden, liegt auch in dem Umstand begründet, daß das RKI nicht von seiner Politik „Einmal Corona nachgewiesen, immer an Corona gestorben“ abweichen will. Ich halte diese Regel für komplett falsch. Andere Länder sind da weiter: CoronaChroniken: Auch England hat die Statistiken überhöht

Das RKI

Ich finde auch eine Aussage in der letzten RKI-Pressekonferenz von Herrn Wiehler für höchst bedenklich: „Wir dürfen die Maßnahmen ( gemeint sind Maske, Hygiene, Abstand ) nicht hinterfragen!“

Doch Herr Wiehler, das dürfen, nein, das müssen wir sogar! Jeden Tag müssen wir die Zahlen auf die Probe stellen und die Maßnahmen und Entscheidungen überdenken, denn so wie es jetzt ist, ist es für alle nicht gut. Wenn die Implosion von insolventen Unternehmen wie erwartet jetzt im August (durch Auslaufen der Schutzmaßnahmen) stattfindet, dann wird es sogar richtig schlimm für alle!

PS: Ihr glaubt gar nicht, wie mir dieser Artikel unter den Nägeln gebrannt hat 🙂 Ich habe die Analyse rund 8 Tage zurückhalten müssen, weil das Bundesamt mit seinen Zahlen nicht nachgekommen ist 😀 die nächsten drei Wochen werden also seeeeeehr spannend 🙂

Kleine Fun Fakt am Rande: Das RKI zeigt in seiner Dashboard Darstellung der Neuinfizierten immer an, wenn frühere Tage nach oben korrigiert wurden. Was der Graph nicht darstellt ist der Fakt, daß die Zahlen auch nachträglich nach UNTEN geändert werden. Da ich die Zahlen aus dem Graphen übernehme und abgleiche, bevor ich die neuen Grafiken erstelle, bemerke ich das natürlich. Guter Transparenz ist das Verhalten des RKI leider nicht zuträglich, ein Trend zum „nach oben“ könnte natürlich auch gewollt sein 😉

Boothole – Ja, und?

Posted on by

Ähm.. ich fühle mich geradezu .. ähm.. genötigt.. auch was zum Grubproblem zu schreiben:

Ja, und?

Als ich bei Heise das erstmal davon gelesen hatte, ging mir nur das Satzfragment „ja,und?“ durch den Kopf? Was bitte ist an einer Lücke mit der einen PC „übernehmen“ kann, für die man aber schon Root sein muß, besonders? Naja, nichts. Wenn ich schon durch einen Hack Root wurde, dann brauche ich diese Lücke nicht mehr, weil ich schon drin bin. Wenn man diese Lücke von außen per physischem Zugriff ausnutzen kann, dann brauche ich das auch nicht mehr, denn dann hatte ich schon den Zugriff auf den PC mit allem was drauf ist, denn die meisten haben keine Festplattenvollverschlüsselung. Ich kann als Angreifer also nicht nur den Bootbereich, sondern alles ändern, wenn ich das wollte.

Es bleibt also nur die eine Kombination übrig, für die das ein Problem ist: Systeme mit Verschlüsselung + physikalischem Zugriff  und hier auch nur die, wo /Boot unverschlüsselt ist.

Jetzt ist das mit dem physischem Zugriff so eine Sache, denn was bitte hindert mich daran, einen Bootloader auf die Platte zu bannen und dem Bios des Pcs zusagen, es soll Legacy booten, ergo der Secureboot ist nicht mehr im Spiel? Ein BIOS-Passwort vielleicht? Nicht wirklich, weil physischer Zugriff meint halt auf alles, ich könnte als Angreifer also auch mit genug Zeit, das Mainboard austauschen und so das Biospasswort umgehen, oder ich resette das einfach.

Antwort von Euch: „Dann schließ das Gehäuse halt ab.“ .. ja, das ist so.. ich war mal bei den deutschen Meisterschaften im Schlösserknacken dabei ( Zuseher ) und naja, so sicher wie man glaubt,  sind Schlösser gar nicht. Türschlösser z.b. sind in unter 3 Sekunden geöffnet. Es gibt sogar einen Sportverein der sich ganz der Schlossknackkunst verschrieben hat. Wenn uns das eins lehrt: Schlösser sind kein Hindernis für Profis und die (baulich)einfachen Schlösser von PC Gehäusen oder ausm Baumark schon gar nicht.

Merke.. wer physischen Zugriff auf Euren PC hatte, stellt IMMER ein unkalkulierbares Risiko da. Daher kann einen diese Lücke nicht wirklich schrecken. Spannender wird die Frage, wie M$ das nötige Secure-Bootupdate für die Sperre alter Grub Shims verteilen möchte, weil ohne das, ist der Fix oder nicht Fix komplett unwichtig 😀