Games – 1 Mio. $ Schlacht, oder doch nicht ?

Letzte Nacht fand in dem mit Linux spielbaren MMORPG EVE Online der als „1 Mio. $ Schlacht“ angekündigte Kampf um eine Pandamic Horde Keepstar statt. Dummerweise  blieb der Schaden weit runter den ankündigten 1 Mio. Dollar .

Was war passiert ?

Wie in keinem anderen MMO, kann man in EVE Online tatsächlich Werte aufbauen, etwas besitzen und es von anderen Spielern verloren bekommen, wenn die diese Werte vernichten. Da man dazu die Hilfe von anderen braucht, gründen Spieler  Firmen und bilden Allianzen im Spiel, damit sie mehr erreichen und besser geschützt sind.

Die Allianzen wiederum bilden mit unter Machtblöcke. Zwei dieser Machtblöcke sind letzte Nacht im System 9-4RP2 in der Region Cloud Ring aufeinander getroffen. Die Koalition des Nordes mit NC., Pandamic Horde und Pandamic Legion verteidigte die größte aufstellbare Struktur , einen Keepstar, gegen die Kräfte des Südens: Test & Goons. Natürlich hat jede dieser Allianzen noch Anhängsel mitgebracht, so daß am Ende mehr als 6000 Kämpfer in 9-4RP2 gleichzeitig am kämpfen waren.

Das keine Seite viel Spaß haben würde, war EVE Spielern bewußt, denn was bei soviel Aktion passiert ist, daß der Server das nicht mehr in Echtzeit bearbeiten kann. Der sogenannte TIDI setzt ein und das Spiel wird für alle Spieler in dem System langsamer. So dauerten Flüge von wenigen Kilometern in Echtzeit Stunden. Wer einen Disconnect hatte, brauchte schon 45 Minuten um wieder einzuloggen.

Der Grund des Kampfes

Normalerweise reiben sich so große Machtblöcke nicht an einander, wie sich im Laufe des Abends aber herausstellte, hatte Pandamic Legion (PL) ein Abkommen mit der TEST Allianz gebrochen und eine kleinere Version des Keepstars, namens Fortizar, in der Region Catch plaziert. TEST hat das als Beginn einer Invasion gewertet und zum Gegenschlag ausgeholt.

Durch einen kleinen Fehler der Pandamic Horde, welcher der Keepstar gehört, ergab sich für den Süden ein Angriffsfenster das entsprechend genutzt wurde. Nun kann man so einen Keepstar nicht einfach von Feld ballern. Es gibt gewisse Regeln die das weltweite Zeitzonenproblem ausgleichen sollen, um zu verhindern das jemand von Australien ausnutzt, daß man selbst im Bett ist. Diese Regeln verlangen insgesamt drei Kämpfe: einen zum erstmaligen Reinforce, da ist der Verteidiger meistens nicht so präsent, es folgt der Armortimer einen Tag später und eine Woche später der finale Kampf. Um so einen finalen Kampf ging es gestern. Den Armortimer hatte PL durch eine ungeschickte Taktik verloren.

Der Kampf

Nach 22 Uhr unserer Zeit konnte man endlich den Keepstar angreifen, was die „Imperiumsflotte“ von Goons und TEST dann auch gemacht hat, indem sie Fighter (kampfkräftige Dronen) von Ihren Strukturen zum Keepstar geschickt hat. Die Verteidiger haben eine Welle Anti-Fighter losgeschickt, um die Fighter des Imperiums abzuwehren. Durch eine Reihe eher fragwürdiger Entscheidungen, kam das Kommando über eine Verteidigerflotte in die Hand eines unerfahrenen Fleetcommanders, der in einer Panikreaktion eine Verteidigerflotte von 250 Schlachtschiffen vom Keepstar weggewarpt hatte.  Diese Schlachtschiffe waren auf ECM / Elektronische Gegenmaßnahmen ausgerüstet und sollten die Fighter daran hindern den Keepstar unter Feuer zu nehmen. Zu allem Überfluß drücke der Spieler, der die Verteidigungswaffen des Keepstar bediente gleich mehrfach auf den falschen Kopf. Statt den Fleetcommander der Angreifer mit seinen Waffen aus dem Verkehr zu ziehen, traf er damit unglücklich ein paar kleinere Schiffe, die zwar zerstört wurden, aber keinen Wert darstellten. Damit waren seine mächtigsten Waffen für 1,5 Stunden verstummt. Als wenn das nicht gereicht hätte, drücke der Gleiche nochmal einen Knopf und vaporisierte eine seiner eigenen ECM Frigflotten (Griffin ECM Frigatten), die grade am Keepstar aktiv im Kampf gegen die Fighter und damit der Pointdefence ausgeliefert waren.

Hier hätte man bereits den Schlußstrich ziehen können, denn solche Fehler bestraft der Gegner normalerweise sofort. Im Tidi dann halt Stunden später 😉  Zunächst sah es auch so aus, als wenn der Keepstar fallen würde. Gegen 1.20 Uhr unserer Zeit waren bereits 25% der Struktur zerstört und alle 3 Minuten kam 1% dazu. Das gegen 3.40 Uhr dann, der Keepstar doch noch gerettet wurde, konnte noch keiner erklären. Der Kampf dauerte noch bis 8 Uhr morgens an.

Die Bilanz

Zunächst mal das Berechnungsmodell für die realen Schäden. Spieler können sich Spielzeit für Realgeld kaufen. Diese Spielzeit können sie im Spiel gegen Spielwährung tauschen. Hier sind 12 -15  € pro 1,5 Milliarden ISK anzusetzen, kommt immer drauf an, ob man das direkt bei CCP oder einen Zwischenhändler kauft. Das macht im günstigsten Fall 0,8 Cent pro Million ISK. Genauer ist das nicht nötig.

Laut Zkillboard, dem derzeit einzigem  Weg zu ermitteln, wieviele Schiffe und damit Werte zerstört wurden, liegt die Summe für den kompletten Januar für das System 9-4RP2 bei 619 Milliarden ISK.  Das entspricht einem Kurs von 4952 € realem Geld und liegt damit weit unter den Schäden die für diese Schlacht angesetzt waren.

Allein CCP, der Gamehersteller, wird am Ende sagen können, wieviel ISK wirklich zerstört wurde. Die Zahl wird sicherlich noch etwas steigen, weil nicht alle zerstörten Objekte auf dem Killboard gelandet sind, oder in benachbarten Systemen vernichtet wurden. Alleine der Keepstar wäre 300 + X Milliarden ISK wert gewesen.

DPD, die zweite.

Vor ein paar Tagen, habe ich ja berichtet, daß DPD seine Pakete für Kunden nicht immer an die Haustür liefert. Grund ist natürlich, daß die Zusteller nicht pauschal bezahlt werden, sondern nach Paketen, die sie zugestellt haben. Eine Quelle bei der Konkurrenz hat das bestätigt 😉 Als Zustellung gilt auch, wenn es im DropShop abgeworfen wird.  Dem Zusteller ist es also egal, ob er es persönlich abgibt oder es im DropShop landet.

Ursachen

Wichtig für den Zusteller ist, daß er möglichst viele Pakete  am Tag schafft, weil die Marge so gering ist. D.h. nicht zum Kunden zu fahren und alles im Shop abzuwerfen, ist im Interesse des Zustellers um auf seinen Verdienst zu kommen. Kundenservice kann ihm egal sein, er trifft den Kunden ja nicht, auch wird es ihm egal sein, daß der Transportvertrag die Lieferung an die Tür vorsieht. Da wird es sicherlich Ausnahmen geben, so von wegen Berufsehre usw.. aber wer kann sich die schon leisten ?

Jetzt zum Paket

Das ist natürlich nie gekommen, es wurde nicht im DropShop abgegeben, es wurde nicht an die Haustür geliefert, es wurde nicht nochmal zugestellt und es wurde mit dem Kunden, also mir, auch keine Vereinbarung getroffen. Trotzdem hatte das Paket 3 Tage nach der Arbeitsverweigerung des Zustellers und somit 3 Tage Lagerung im Zentrallager, davon 2 Arbeitstage, plötzlich den Vermerk, daß der Kunde die Annahme verweigert hat. Ich wünschte, ich hätte die Gelegenheit dazu gehabt.

Natürlich ist genau das Gegenteil zutreffend, denn ich habe mehrfach in der Zeit bei DPD angefragt, ob mir jemand sagen kann, wie es weiter geht, wann es erneut geliefert wird und ausdrücklich auf Zustellung an die Haustür bestanden. Um es nochmal deutlich zu machen, es ging um 15g Wachs für 6 € ! und nicht um ein 40kg Paket 😀

„Zurück zum Lück“

Das Paket ging dann an den Absender, dem es technisch nicht mehr gehört hat, zurück. Zum Glück habe ich mit dem über Ebay die ganze Zeit Infos ausgetauscht, da absehbar war, das DPD keinen Bock hat, wurde es zwischenzeitlich erneut per DHL verschickt.

In der Zeit, in der das Paket nicht von DPD geliefert wurde, schlug DHL 2x bei mir auf 🙂 und nach 2 weiteren Tagen war dann auch der Briefumschlag aus Pappe mit dem 15g Döschen Wachs da. Ok, der Herr von DHL war wegen dem Brief dann nicht extra an der Tür, dafür gibt es ja schließlich diese ominösen Briefkästen, aber er war da, was ihn extrem positiv gegenüber DPD erscheinen läßt 😀

Merke: DHL Boten werden pauschal bezahlt, DPD Zusteller werden ausgebeutet mit Akkordarbeit.

Also seid nett zu Eurem Zusteller, egal von welchem Dienst er kommt, die haben es beide nicht leicht. Mein DHLer bekommt demnächst einen kleinen Anerkennungsbonus.

Kernel 4.14.14 OOPSt rum

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.