Lese-Ansicht

Kritischer ext4-Bug (besonders betroffen: Linux 6.1.64)

Aktuell sollte beim Updaten des Linux-Kernels Vorsicht walten gelassen werden. Bestimmte Kernel-Releases weisen ein Problem mit ext4 auf, das theoretisch im schlimmsten Fall zu einer Datenbeschädigung führen kann.

Es gibt eine Konstellation, in der in einem Release nur der erste ohne den zweiten Commit enthalten ist und somit der Code nicht wie gewünscht arbeitet. Konkret geht es um

  • 91562895f803: "ext4: properly sync file size update after O_SYNC direct IO" (ab v6.7-rc1)
  • 936e114a245b6: "iomap: update ki_pos a little later in iomap_dio_complete" (ab v6.5-rc1)

Jan Karas E-Mail auf der LKML zufolge geht es darum, dass der erste Commit nur dann im Code vorhanden sein darf, wenn der zweite Commit bereits enthalten ist. Eigentlich ist das logisch, weil das ja mit der Reihenfolge dann auch so passt.

Jetzt kommen allerdings noch die Backports und Distributionen ins Spiel. Für den Kontext: da nicht jeder immer auf die neuste Linux-Version aktualisieren kann, gibt es ein Team, was alte Versionen nachpflegt und kleine, unkritische Fixes neuerer Versionen auf die älteren Versionen "rückportiert", also backported. Allerdings kann es nun passieren, dass etwas ganz neues rückportiert wird, ohne, dass eine ältere Voraussetzung rückportiert wurde. Die Fehler, die dann auftreten, nennt man klassicherweise eine Regression. Die einzelnen Codeänderungen sind da nicht an sich das Problem, sondern eher die Konstellation, in der sie zusammengesetzt wurden.

Linux 6.1.64 und 6.1.65 sind betroffen, 6.1.66 enthält den Fix. Debian 12, das auf die Kernels setzt, ist dabei besonders in Aufruhe, da eine problematische Kernel-Version verteilt wird. Aus diesem Grund wurde auch die Veröffentlichung von Debian 12.3 verzögert.

Weitere Informationen

  •  

Schwere Sicherheitslücken in Exim4

Wer Exim4 als Mailserver einsetzt, wie es zum Beispiel in Debian-basierten Linux-Distributionen der Standard ist, sollte sich zeitnah um Updates bemühen oder - wenn der Dienst nicht zwangsläufig benötigt ist (bei manchen läuft Exim unbewusst) - spätestens jetzt gänzlich abschalten. Es gibt zumindest eine schwere Remote-Code-Execution-Sicherheitslücke.

Bleeping Computer berichtete über die Lücke(n), denn es geht um bis zu 6 Schwachstellen unterschiedlicher Stärke. Die genauen Details sind zum aktuellen Zeitpunkt noch nicht verfügbar, um Exploits nicht zu befördern. Es reicht allerdings unauthentifizierter Zugriff auf Port 25.

Der Fund geht auf die Zero Day Initiative von Trend Micro zurück. Sie hatte bereits im Juni letzten Jahres, also 2022, auf die Lücken aufmerksam gemacht. Besonders pikant: bis vor kurzem waren noch keine Patches verfügbar, zumal die schwerwiegende Lücke ZDI-23-1469 bereits Mitte der Woche veröffentlicht wurde.

Laut einer E-Mail der Entwickler ist ein bedeutenden Teil der Lücken bereits geschlossen und die Updates an die Distributoren verteilt. Dass die Lücke nicht schneller gefixt wurde, lag an Schwierigkeiten bei der Kommunikation. Bei Ubuntu wird die Lücke als CVE-2023-42115 geführt, hier sind noch keine Updates verfügbar.

Exim4-Admins sollten dies im Auge behalten und sofort reagieren. Mit ersten Exploits ist demnächst zu rechnen, wenn mehr über die Lücke bekannt wird. Der Mailserver ist weit verbreitet, es gibt laut Bleeping Computer mehrere Millionen Instanzen im Internet.

  •  

Mistral 7B: Fortschrittliches Open-Source-LLM aus Europa

Das Wettrennen um die Technologieführerschaft der Large Language Models lief größtenteils bisher auf dem amerikanischen Kontinent ab. OpenAI hat das Produkt populär gemacht und Meta AI veröffentlicht den Konkurrenten mit den freien Gewichten. Mit Falcon 40B und 180B gab es allerdings schon Konkurrenz aus Abu Dhabi, zumal mit der gewählten Apache-2.0-Lizenz ein deutlich offenerer Ansatz gewählt wurde.

Als kurz vor dem Sommer das Start-up Mistral aus Paris 105 Millionen Euro eingesammelt hat, waren die Medienberichte zumindest leicht kritisch, da nicht nur das Start-up mit einer gigantischen Finanzierungssumme aus der Taufe gehoben wurde, sondern das Produkt auch noch gar nicht fertig war. Aus der LLM-Sicht ist dies allerdings verständlich, da solche großen Summen schlicht die Voraussetzung sind, um an den Start zu gehen. Schließlich benötigt Training leistungsfähige GPUs und die sind teuer.

Mit dem veröffentlichten Modell Mistral 7B zeigt das Start-up, was es kann. Dabei handelt es sich um ein LLM, das über 7 Mrd. Parameter verfügt und Llama 2 13B in allen und LLaMa 34B in vielen üblichen Benchmarks überbietet: Commonsense Reasoning, World Knowledge, Reading Comprehension, Math, Code, Popular aggregated results. In Codingaufgaben kann die Leistung von CodeLlama 7B erreicht werden.

Das Beste am LLM ist, dass es unter der Apache-2.0-Lizenz steht. Als klassische Open-Source-Lizenz gibt es nicht nur den Forschern und Entwicklern viele Freiheiten, sondern auch eine gewisse Lizenzsicherheit, dass das Modell in freier Software verwendet werden kann.

Ich hatte bereits vor Wochen geschrieben, dass freie Modelle eine gute Möglichkeit sind, um sich als neuer Player auf dem Markt zu profilieren. Diesen Plan verfolgt nicht nur Falcon, sondern nun auch offenbar Mistral. Es ist trotzdem davon auszugehen, dass die 105 Millionen Euro keine "Forschungsspende" waren und kommerzielle Produkte zeitnah folgen werden.

Für die Forscher und Entwickler von LLMs hat die aktuelle Veröffentlichung nichtsdestotrotz Vorteile. Meta AI hat mit der Lizenzgebung von Llama 2 auf die Open-Source-Bewegung in der LLM-Welt reagiert und sein aktuelles Modell unter eine permissive, aber trotzdem proprietäre Lizenz gestellt. Mistral geht allerdings noch einen Schritt weiter und setzt eine "klassische" Open-Source-Lizenz ein. Das hat nicht nur Signalwirkung, sondern ermöglicht, dass Unternehmen ihre LLM-Lösungen zunehmend privat hosten können, da die Parameteranzahl mit 7 Mrd. so dimensioniert ist, dass auch kleinere Datacenter-GPUs für die Ausführung bzw. Inferenz ausreichen. Es bleibt also weiterhin spannend im Umfeld der LLMs.

Die Mistral-7B-Modelle sind in Version 0.1 auf HuggingFace als normales Modell und als auf Chats spezialisiertes Modell (Instruct) verfügbar.

  •  

KI-Wochenrückblick KW 32/2023

Auch in der Sommerpause gibt es vereinzelte Neuigkeiten aus der Welt der künstlichen Intelligenz. Heute möchte ich mich dabei wieder einmal den Agenten widmen.

MetaGPT

Beim Einsatz von ChatGPT und ähnlichen LLMs stellt sich schnell die Frage, ob da nicht auch mehr geht. Ob das System nicht zur Abbildung alltäglicher Arbeit herangezogen werden kann. Insbesondere mit Anfang des Jahres aus dem Winterschlaf erwachten Konzept der Agenten wurde die Zusammenarbeit unterschiedlicher KI-Instanzen wieder relevant und spannend. Umso interessanter ist es, diese Konzepte zusammenzuführen.

AutoGPT und Co. sind diesem Ziel gefolgt und konnten schon lustige Ergebnisse demonstrieren, wenn man die LLMs sinnbildlich an den eigenen Computer anschließt und z. B. die Ausgaben des LLMs als Eingabe für die eigene Shell verwendet (nicht nachmachen, ist eine dumme Idee). Doch auch hier gab es einige Schwächen, ganz rund lief alles bei weitem noch nicht.

Die Autoren hinter MetaGPT (hier im Bezug auf griechisch meta = über) haben systematisch verschiedene Rollen inkl. ihrer Interaktionen ausgearbeitet und stellen ihre Ergebnisse als Preprint und ihr Framework auf GitHub bereit. Dabei wird eine einzeilige Aufgabe, z. B. die Entwicklung eines Spiels, vom System eingelesen und dann auf ein hierarchisches Team aus Agenten verteilt. Diese Agenten haben verschiedene Rollen, die sich auf die System-Prompts abbilden, d. h. beispielhaft "Du bist ein Entwickler für Python..." oder "Du bist ein Requirements-Engineer...". Am Ende des Tages fällt ein Ergebnis raus, das dann ausprobiert werden kann.

Das Konzept sieht in meinen Augen sehr spannend aus und entwickelt sich stets weiter. Dabei wird deutlich, dass eine simple Prompt für hochwertiges Prompt-Engineering nicht reicht, vielmehr können Effekte ähnlich wie beim Ensemble-Learning genutzt werden, durch die mehrere Instanzen von LLMs, die gemeinsam ein Problem bearbeiten, deutlich effektiver arbeiten.

Was LLMs von Cyc lernen können

Irgendwie habe ich die ganzen letzten Monate schon darauf gewartet, dass sich die Autoren klassischer Expertensysteme beim LLM-Thema zu Wort melden. Immerhin prallen hier zwei komplett unterschiedliche Welten aufeinander, die beide versuchen, die Welt zu erklären.

Klassische Expertensysteme versuchen mit Logik die Welt in Regeln zu fassen. Das typische Beispiel ist "Wenn es regnet, dann wird die Straße nass". Eine klare Implikation, die in eine Richtung geht: ist das Kriterium auf der "wenn"-Seite erfüllt, gilt die Aussage auf der "dann"-Seite. Wird das System gefragt, was mit der Straße passiert, wenn es regnet, antwortet es immer, dass sie nass wird. Immer. Dass es nicht zwangsläufig der Regen sein muss, wenn die Straße nass ist, wird ebenfalls durch Logik ermöglicht, da die obige Regel eine Implikation ist und keine Äquivalenz, denn da würde es heißen "Immer wenn es regnet, dann wird die Straße nass".

Problematischer wird es zu modellieren, dass die Straße selbst bei Regen da nicht nass wird, wo gerade ein Auto parkt. Hieran erkennt man, dass es sich um ein schwieriges Unterfangen handelt, wenn Expertensysteme die echte Welt modellieren sollen. Das Cyc-Projekt hat die Mühe aber auf sich genommen und über die letzten knapp 40 Jahre über eine Million solcher Regeln zusammengetragen. Viele einfache Expertensysteme gelten grundsätzlich aber als veraltet und konnten die Erwartungen für "generelle Intelligenz" schon vor 30 Jahren nicht erfüllen.

Anders funktionieren LLMs, die nicht mit klassischer Logik, sondern Wahrscheinlichkeiten arbeiten, um das "am ehesten passende" nächste Wort für die Antwort zu finden. Zusammengefasst sind Expertensysteme für ihre Präzision zulasten der Vielseitigkeit bekannt und LLMs einfach anders herum.

Doug Lenat von Cyc und Gary Marcus von der NYU haben in ihrem Preprint nun 16 Anforderungen zusammengetragen, die eine "vertrauenswürdige KI" haben sollte, darunter Erklärung, Herleitung oder Kontext. Anschließend gehen die Autoren noch ein, wie ihr (kommerzielles) Cyc das umsetzen kann.

Ich bin tatsächlich überzeugt, dass man untersuchen sollte, wie sich diese beiden Ansätze verheiraten lassen. Dabei sprechen auch die Ergebnisse von AutoGPT, MetaGPT & Co. dafür, dass das Vorhaben auf neuronaler Ebene angegangen werden muss, da einfache Varianten wie System-Prompts á la "Du bist LogikGPT. Gib mir die Entscheidungsregeln in Prädikatenlogik aus." immer noch auf Token-/Wortvorhersagen basieren und zu viel Halluzination zulassen.

Dennoch bin ich sicher, dass es auch hier Fortschritte geben wird, die wir dann früher oder später in einem Wochenrückblick diskutieren können. Bis dahin!

  •  
❌