Zur üblichen Arbeit eines Systemadministrators gehört der Umgang mit persistentem Speicher (a.k.a. Festplatte), der heutzutage in Form von HDDs, SSDs oder auch NVMes daherkommt. Üblicherweise werden in Produktivsystemen die Platten in einem RAID angeordnet, um bei einem Festplattenausfall die Verfügbarkeit des Systems zu erhöhen. Soll in diesem Zusammenhang allerdings eine Festplatte vor einem drohenden Ausfall manuell aus dem RAID entfernt werden, ist es ratsam, sie vorher sicher zu löschen. In diesem Artikel möchte ich allerdings kurz umschreiben, warum der Hinweis, Backups vor jeglicher Formatierung zu erstellen, so wichtig ist - besonders bei NVMe-Speichern.

Um die gleich folgende Syntax zu verstehen, sei noch gesagt, dass unter Linux ein bestimmtes Schema existiert, wie Festplatten oder eben NVMes angesprochen werden. Bei SCSI- bzw. SATA-Platten kennt man z. B. /dev/sda für die erste erkannte SATA-Festplatte (= sd für den Treiber und a für die Platte) und /dev/sda3 für die dritte Partition (= 3) auf der ersten erkannten SATA-Festplatte. Wichtig ist, dass "erste erkannte Festplatte" genau so relativ verstanden werden muss, wie es klingt. Wird, aus welchem Grund auch immer, eine andere Festplatte zu erst erkannt und ist die Buchstabenzuweisung nicht persistiert, ändert sich über mitunter auch die Zuweisung. Nicht ohne Grunde werden Linux-Nutzer angehalten, mit UUIDs eindeutig identifizierbare Bezeichner für ihre /etc/fstab zu nutzen.

Bei NVMe ist das scheinbar ähnlich, auch wenn es hier einen Zusatz gibt. Eine Partition auf einem NVMe-Gerät, das alleine in einem Rechner steckt (d. h. nur eine NVMe ist eingebaut) könnte /dev/nvme0n1p3 heißen. Hier bedeutet die Syntax, dass es sich um die dritte Partition (p3) auf dem ersten Namespace (n1) hinter dem Controller mit der Nummer 0, handelt, das über den NVMe-Treiber angesprochen wird. NVMes verfügen mit Namespaces über eine weitere Abstraktionsschicht, sodass der NVMe-Controller seinen Storage in Namespaces unterteilen kann, die jeweils über eine eigene Partitionstabelle verfügen.

Im administrativen Umgang arbeitet man oft mit mehreren Block-Devices, einerseits der "Platte selber", klassischerweise einer /dev/sda, und den Partitionen, also /dev/sda3. Bei NVMe ist die "Platte selber" in den allermeisten Fällen ein Namespace, also /dev/nvme0n1 und NICHT /dev/nvme0.

Es gibt allerdings ein Szenario, wo man mal den Controller direkt ansprechen muss: beim Kommando nvme format. Hier gibt es eine Syntax, wo als Argument das NVMe-Device, also der Controller, angesprochen und der Namespace per Option übergeben wird. Ich durfte nun erleben, wie das sehr, sehr schiefgehen kann.

Wer nämlich glaubt, dass man von /dev/nvme1n1 auf den Controller /dev/nvme1 schließen kann, irrt sich gewaltig. Diese beiden Bezeichner haben streng genommen nichts miteinander zu tun. Und so kann es dazu führen, dass wenn

• man zwei NVMe-Devices hat
• /dev/nvme1n1 behalten und
• /dev/nvme0n1 mittels nvme format /dev/nvme0 -n 1 löschen möchte,

man sich potenziell den Boden unter den Füßen wegzieht und die eigentlich zu behaltende NVMe löscht - was nach der Formatierung mit der netten Fehlermeldung bash: <executable>: cannot execute binary file: Exec format error quitiiert wird, wenn man das nächste Kommando in der Bash aufrufen will.

Der Zusammenhang wird zwischen /dev/nvmeX und /dev/nvmeYn1 nämlich - NVMe Multpathing sei dank - dynamisch gewählt. Und ich bin nicht der einzige, dem das aufgefallen ist. Normalerweise hängen die Bezeichner zusammen, aber wenn man beim Tausch der NVMes zwischendurch Reboots durchführen muss, kann sich die Reihenfolge schon mal verdrehen - aber eben nur halb.

Und so muss man manuell nachprüfen, welches Device wirklich hinter dem Block-Device eines Namespaces steckt:

me@server:~$ ls -l /sys/block/nvme1n1/device
lrwxrwxrwx 1 root root 0 Aug 31 19:43 /sys/block/nvme1n1/device -> ../../nvme0

In diesem Fall steckt hinter /dev/nvme1n1 das Device /dev/nvme0. Muss man beachten.

Dies hat übrigens nicht nur auf das Formatieren Auswirkungen: auch die SMART-Überwachung zeigt für /dev/nvme0n1 und /dev/nvme0 völlig unterschiedliche Resultate an. An dieser Stelle ist mir übrigens erst aufgefallen, dass der Zusammenhang zwischen den Devices mitunter nicht-systematisch gewählt werden könnte.

Was lernen wir daraus? Neue Treiber, wie in unserem Fall nvme, bringen neue Herausforderungen mit. Es ist gut, sich jedes Mal, wenn man seine Produktivsysteme mit neuen Fähigkeiten ausstattet, mit der Dokumentation und dem Standard hinter dem Treiber zu beschäftigen. Darüber hinaus - und das ist noch viel wichtiger - sollte man jederzeit auf seine Backups als zusätzliches Sicherheitsnetz achten, weil es immer etwas geben wird, was man übersieht. In meinem Fall hatte ich Glück, weil der betroffene Server aus der Testumgebung stammte und das Formatieren der falschen Platte nur vernachlässigbare Auswirkungen hätte - ich bin aber froh, auf diesem Umstand aufmerksam geworden zu sein und wollte euch an dieser Stelle einfach "vorwarnen".

Heute eine Nachricht in eigener Sache. Während immer mehr Nachrichtenportale sukzessive ihre RSS-Angebote einstellen, erlebt momentan ein Medium, das fundamental darauf aufbaut, einen kometenhaften Aufstieg in der Breite: der Podcast. Technisch handelt es sich dabei um eine Erweiterung des RSS-2.0-Standards und ermöglicht, dass der ein und selbe Inhalt an verschiedene Podcatcher, also Podcast-Clients, ausgespielt wird. Zunehmend übernehmen Streaming-Plattformen wie Spotify das Konzept und führen eigene Verzeichnisse hierfür ein.

Der Podcast ist in der Medienlandschaft längst angekommen und entwickelt sich zu einem beliebten Gesprächsformat. Es gibt bereits Stimmen, die ihn schon als Nachfolger des Blogs sehen. Besonders trenden Themen zu Politik, Wirtschaft, aber auch Technologie. Eine nicht zu unterschätzende Nische ist dabei die IT-Sicherheit – und diese Nische möchte ich in meinem neusten Projekt füllen.

Mein neuer Podcast „Risikozone“ geht ab morgen, dem 01. September 2022 an den Start und beschäftigt sich u. a. mit den Themen IT-Sicherheit, Open-Source-Software und Künstliche Intelligenz bzw. Maschinelles Lernen. Im Podcast kann ich endlich die Themen behandeln, die zu lang für einen Blogartikel, aber zu kurz für ein Video/-kurs sind, oder gar nicht in die beiden Kategorien passen. Es geht auch um Grundlagenthemen der Kryptographie, Computerkommunikation und des Datenschutzes sowie um aktuelle Nachrichten aus diesen Bereichen. Die Zielgruppe liegt in der Breite: es geht darum, IT zu vermitteln. Aus diesem Grund werden die technisch tiefgreifenden Themen weiterhin im Blog behandelt, während im Podcast weitere Themen Einzug finden können.

Pro Monat sollen mindestens zwei ca. 20 bis 45 Minuten lange Episoden enstehen, die dann über unterschiedlichste Wege abrufbar sind. In den Folgen werden entweder Gäste dabei sein oder ich werde alleine Schwerpunktthemen vorstellen.

Um den Podcast zu abonnieren, gibt es verschiedene Möglichkeiten: da heutzutage die Plattformökonomie auch bei Podcasts angekommen ist, möchte ich hier Spotify und Apple Podcasts erwähnen, bei weiteren Plattformen folgt die Listung in Kürze. Der Feed des Podcasts ist unter https://risikozone.de/feed/mp3/ erreichbar. Weitere Informationen und Aktualisierungen sind auch auf der entsprechenden Seite verfügbar.

Morgen Vormittag werden die beiden ersten Episoden veröffentlicht, in denen es um das Thema E-Mail-Sicherheit geht. Eine Trailerepisode 0 ist bereits jetzt schon verfügbar. Wie es dann weitergeht, könnt ihr mit eurem Feedback auch mitentscheiden. Gefällt es euch, habt ihr Themenvorschläge oder Anmerkungen? Das alles könnt ihr an info@risikozone.de schicken.

Darüber hinaus könnt ihr gerne, wenn euch der Podcast gefällt, euren Freunden und eurer Familie davon erzählen oder ihn auf Spotify und/oder Apple Podcasts bewerten und uns dort folgen.

Was sich als Projekt vor zwei Jahren langsam abzeichnete, geht nun in die finale Umsetzung: der Linux-Kernel soll zukünftig nicht nur in der Programmiersprache C, sondern auch in Rust geschrieben sein. Während die Rust-Unterstützung noch die Aufnahme in Linux 6.0 knapp verpasst hat, soll es mit Linux 6.1 nun so weit sein. ZDNET berichtet von einer geplanten Aufnahme in die kommende Linux-Version:

The implementation has begun. In an email conversation, Linux's creator Linus Torvalds, told me, "Unless something odd happens, it [Rust] will make it into 6.1." (Steven Vaughan-Nichols, ZDNET.com, 19. September 2022)

Für die Implementierung ist das Projekt "Rust for Linux" zuständig (siehe Git-Repo auf GitHub). Federführend bei der Implementierung ist Miguel Ojeda, die Entwicklung wird von Unternehmen wie Google unterstützt und gesponsert.

Während C oft als "portable Assemblersprache" wahrgenommen wird, die viel Eigenverantwortung voraussetzt, abstrahiert Rust insbesondere das Speichermanagement zu gewissen Teilen über die Ownership-, Reference- und Borrowing-Konzepte weg. Die Sicherheit und Zuverlässigkeit des Linux-Kernels soll erhöht werden, indem bestimmte Programmierfehler konzeptionell verhindert werden.

Rust soll dabei den Kernel nur ergänzen und mittelfristig nicht ersetzen. Die Anstregungen, die das Rust-for-Linux-Projekt auf sich genommen hat, umfassen eine Infrastruktur und Umgebung, um Treiber in Rust für den Kernel entwickeln zu können.

Der Standard der Standards: Gestern wurde der Smart-Home-Standard Matter in Version 1.0 von der Connectivity Standards Alliance (CSA) veröffentlicht. Er soll Licht ins Dunkle bringen und das Standard-Chaos unter den Smart-Home-Geräten auflösen. Reflexartig werden viele meiner Leser jetzt die Zahl 927 in die Tastatur tippen, aber ich werde mich erstmal überraschen lassen, was sich ergibt. Vielleicht ist es nicht "yet another standard", sondern tatsächlich eine Verbesserung. Zudem haben sich viele große Smart-Home-Anbieter in der Allianz zusammengeschlossen, um diese Harmonisierung durchzuführen – bevor es die Regulatoren tun, wie wir gerade erst mit USB-C gesehen haben.

Ich werde mich in den nächsten Wochen genauer mit Matter beschäftigen und schauen, was sich dazu erforschen lässt. Auch die Security-Aspekte werden dabei relevant werden. Was ich aber ausgesprochen schade finde, ist, dass die Spezifikation (also der Kern des Standards), gar nicht öffentlich ist, wie sich in der Wikipedia lesen lässt:

Version 1.0 of the specification was published 30 September 2022. The Matter specification is provided at no charge upon request after providing full name, company name, email address and consenting to their privacy policy, but cannot be redistributed without permission from CSA.

Das steht natürlich im Kontrast zu anderen Standards wie QUIC, die einfach online und ohne Registrierung vom RFC Editor abgefragt werden können. Ich werde mir wohl für meine Arbeit einen Zugang diesbezüglich holen, kann dann aber im Blog höchstwahrscheinlich nicht mehr auf die Details aus der Spezifikation eingehen. Im Grunde ist es dann ähnlich wie mit Standards von z. B. der IEEE, aber die Chance der besseren Zugänglichkeit des Standards wurde offenbar nicht genutzt. Deswegen ein Blogartikel im Voraus mit meinen Hypothesen und Erwartungen.

Was ich bereits gut finde

Es gibt viele Standards, die sich in den vergangenen Jahren im IoT-Umfeld entwickelt haben. Das hat für eigene Anwendungen natürlich einen Einfluss auf den Layer 7 (Application), also die konkrete Implementierung von Anwendungen: wenn sich der Lichtschalter anders als der Heizkörperthermostat verhält (z. B. das eine System bietet nur HTTP REST auf einer Cloud an, das andere erwartet lokales MQTT), dann bedeutet das einen Mehraufwand, der verhindert werden könnte, wenn man sich auf ein Interface einigt. Aber bevor wir über Layer 7 überhaupt nachdenken können, muss Layer 3 (Network) geklärt sein. In beiden Fällen gibt Matter Vorgaben, wie in Abbildung 1 dargestellt: Layer 7 wird durch den Standard selber beschrieben und als Layer 3 wird IPv6 erwartet. Das ist spannend, da sich hier – sofern technisch dem Zugriff keine Schranken gesetzt werden – damit eine Integration in Heim- und Unternehmensnetze auf klassischen Standards möglich ist. Als Layer 1 bzw. 2 können Ethernet, Wi-Fi, Thread (IEEE 802.15.4), IPv6 for Bluetooth Low Energy, u. v. m. dienen.

Der Einsatz von IPv6 muss allerdings auch technisch implementiert werden: so müssen nicht nur Router und Firewall IPv6 generell unterstützen, sondern die (hoffentlich dedizierten) IPv6-Netze müssen auch bereitgestellt werden. Ob und in welchem Umfang die lokalen Unique Local Addresses (ULAs) nach RFC 1884 eingesetzt werden können, weiß ich zum aktuellen Zeitpunkt noch nicht. Begrüßenswert ist es in jedem Fall.

Warum rede ich überhaupt von ULA? Da IPv6 nativ kein NAT kennt, dürfte man doch damit gar nicht ins Internet kommen? Ja genau, das muss man bei Matter auch nicht, da der Standard auch lokal und ohne Cloud laufen kann. Somit müssen Schaltbefehle nicht umständlich über das Internet geroutet werden, sondern können den Weg direkt im Heim- oder Unternehmensnetz laufen. Auch das ist eine gute Sache, da so eine Zugriffskontrolle auf Vermittlungsebene in der Organisation durchgesetzt werden kann und man nicht vor verschlüsselten REST-Nachrichten steht.

Apropos Verschlüsselung, an die wurde auch gedacht. So sollen die ausgetauschten Nachrichten signiert und verschlüsselt werden können, ein Aspekt, der vielen Smart-Home-Geräten bisher fehlt.

Matter stellt weiterhin nicht nur eine Spezifikation, sondern auch ein SDK bereit. Dieses ist tatsächlich Open Source und unter der Apache-2.0-Lizenz auf GitHub verfügbar.

Wo ich noch genauer nachhaken werde

Grundsätzlich stellt sich die Frage der Zugänglichkeit zum System: es bleibt zu hoffen, dass die Geräte nicht nur mit fremden Smart-Home-Anwendungen, sondern auch mit den eigenen Smart-Home-Anwendungen kommunizieren können. Wenn ich mir ein Script schreiben will, das Steckdosen schaltet oder Heizthermostate einstellt, brauche ich einen standardisierten, nicht-diskriminierenden Zugriff. Konkret meine ich damit, dass das System – solange ich mich standardkonform verhalte – nicht danach unterscheiden (= diskriminieren) soll, ob ich ein anderes zertifiziertes Smart-Home-Device bzw. eine solche Anwendung bin, oder nicht. Wenn sich ein Ökosystem entwickelt, das zwar Institutionen freien Zugriff gewährt, aber interessierte Einzelpersonen kategorisch ausschließt, ist in der Frage dem fortgeschrittenen Smart-Home-Entwickler bzw. -Anwender wenig geholfen.

Auch der Punkt mit dem Distributed Compliance Ledger (vgl. diesen Artikel von Espressif, den ESP32-Machern, dazu) muss kritisch hinterfragt werden: die Funktionsweise liest sich wie die einer klassischen PKI, vor allem, da die CSA offenbar sowieso Top-Down organisiert ist. Vielen wird sowieso beim Begriff permissioned blockchain der Kamm hochgehen, da eine Blockchain-Datenbank mit Zugriffsverwaltung dem Urgedanken des P2P-Netzwerkes mit der gemeinsamen Konsensfindung zuwiderläuft. Bisher konnte ich diesbezüglich nur ein GitHub-Projekt der ZigBee-Alliance finden, bei dem als Grundlage die Cosmos-Blockchain läuft.

Von der Kritik deutlich zu trennen ist aber der lobenswerte Umstand, dass Firmware-Downloads überhaupt integritätsgeschützt und authentifiziert werden. Sollte es aber tatsächlich so sein, dass es sich beim DCL um eine PKI handelt, über die eine Blockchain gestülpt wurde, kann man sich die Blockchain mitunter gleich sparen.

Abschließend ist auch Kompatibilität ein Punkt: so sollen einige bereits existierende Smart-Home-Geräte zukünftig Matter-Fähigkeiten über ein Firmware-Update erhalten können. Mit Matter 2.0 stellt sich aber auch früher oder später die Frage, ob Matter sich als auf- und abwärtskompatibel erweisen wird: Können bestehende Matter-1.0-Geräte geupdated werden und wie gehen 2.0er-Geräte mit 1.0-Geräten um? Müssen diese mitunter neu gekauft werden?

Wofür ich einen Smart-Home-Standard brauche

Hier habe ich aktuell ein Projekt, das ich bei Gelegenheit implementieren möchte: so soll sich mein Heizthermostat an meinem Kalender orientieren. Wenn ich mir in meinem CalDAV-unterstützenden Kalender einen Außer-Haus-Termin setze, soll die Temperatur abgesenkt werden. Hierzu brauche ich ein Script auf einem Server und ein Heizthermostat. Dieses Heizthermostat selber soll nun aber nicht in meinen Kalender schauen können (Warum auch? Ich habe mehrere Kalender, die in Kombination betrachtet werden müssen.), sondern durch mein Script lokal angesteuert werden. Dieses Script arbeitet dann auf einer Workstation oder einem Raspberry Pi.

Somit managed das Script dynamisch die Heiztemperatur (Input: CalDAV-Kalender) und soll das den Aktoren, also den Thermostaten, über einen Standard mitteilen können.

Ich bin gespannt, ob Matter auch für so einen Fall gebaut ist oder ob der Schwerpunkt in Smart-Home-Zentralen größerer und kleinerer Hersteller liegt.

Am Samstag, dem 15.10.2022 wurden neue Versionen des Linux-Kernels veröffentlicht, darunter 6.0.2, 5.19.16 und 5.15.74. Mit diesen Versionen werden verschiedene Sicherheitslücken geschlossen, die der Sicherheitsforscher Sönke Huster aufgedeckt hat.

Konkret geht es hierbei um den WLAN-Stack. Er ist im Kernel notwendig, um drahtlose Netzwerkzugriffe zu ermöglichen. Verschiedene Treiber unterstützen die verschiedenen WLAN-Chips, welche die Kommunikation zur Außenwelt bereitstellen. Trotzdem teilen sich die Treiber eine gemeinsame Infrastruktur – und in dieser Infrastruktur wurden einige Fehler gefunden.

Den Fehlern wurden verschiedene CVEs zugewiesen. Konkret geht es um:

• CVE-2022-41674: fix u8 overflow in cfg80211_update_notlisted_nontrans
  • (max 256 byte overwrite) (RCE)
• CVE-2022-42719: wifi: mac80211: fix MBSSID parsing use-after-free
  • use after free condition (RCE)
• CVE-2022-42720: wifi: cfg80211: fix BSS refcounting bugs ref counting
  • use-after-free possibilities (RCE)
• CVE-2022-42721: wifi: cfg80211: avoid nontransmitted BSS list corruption
  • list corruption, according to Johannes will however just make it endless loop (DOS)
• CVE-2022-42722: wifi: mac80211: fix crash in beacon protection for P2P-device
  • NULL ptr dereference crash (DOS)

Besonders ins Auge fällt eine Lücke, die einen Buffer Overflow beim Scannen verschiedener WLAN-Netze zur Anzeige verfügbarer Netze ermöglicht. Die Brisanz entsteht dadurch, dass die Lücke interaktionslos (Zero Click) ausgenutzt werden kann: dadurch, dass der Scan automatisch abläuft und ein Angreifer bösartige WLAN-Frames ausstrahlen kann, die dann automatisch verarbeitet werden, ist kein aktives Klicken auf eine ausführbare Datei nötig. Glücklicherweise existiert zum aktuellen Zeitpunkt noch kein bekannter Exploit, der diese Lücke bösartig ausnutzt. Die Updates sollten trotzdem eingespielt werden, um hier nicht unnötig einem Risiko ausgesetzt zu sein.

Weitere Details und die Geschichte hinter der Lücke gibt es in der Sonderepisode 6 meines Risikozone-Podcasts. In dieser Episode führen Prof. Dr. Andreas Noack und ich ein Interview mit Sönke Huster, dem Entdecker der Lücke. Sönke erklärt in der Episode die Lücken und erläutert, wie er sie entdeckt und gemeldet hat. Insbesondere der Disclosureprozess wird Thema der Episode sein, da hier die Arbeitsweise in einem Open-Source-Projekt wie dem Linux-Kernel bei so einem Vorfall deutlich wird. Die Podcastepisode ist ab sofort auf risikozone.de/rz006 als Audio und – extra für diese Episode – auf YouTube als Video verfügbar. Sie ist aufgrund des besonderen Themas mit etwa 90 Minuten etwas länger als die üblichen 40 Minuten, aber dennoch für den Ausklang des Wochenendes sehr empfehlenswert.

Konkrete Informationen zur Lücke in der E-Mail von Sönke verfügbar, LWN.net hatte bereits am Donnerstag darüber berichtet. Mittlerweile hat auch das BSI eine Warnung aufgrund der CVEs herausgegeben.

Man pages formen auf heutigen unixoiden Systeme eine entscheidende Säule. Sie sind das integrierte Handbuch, das einerseits die Kommandos erklärt und andererseits auch eine Referenz für die jeweiligen C-Bibliotheken und Syscalls darstellt. Wer also Anwendungsentwicklung auf Linux o. ä. betreibt und dabei insbesondere auf C zurückgreift, kommt an man pages schwer vorbei. Dabei bieten sie einige Vorteile: sie sind lokal verfügbar, nach einem konsistenten Schema aufgebaut und erklären die verschiedenen Befehle und Schnittstellen. Man pages sind tatsächlich so unverzichtbar, dass jeder C-Entwickler sie regelmäßig konsultieren sollte. Immerhin werden hier nicht nur die Kommandos und ihre Wirkungsweise erklärt, sondern auch auf Seiteneffekte und Fehlermeldungen eingegangen. Dies ist essentiell, da viele Bestätigungen oder Fehler nur über Rückgabewerte kommuniziert und im letzteren Fall über spezielle (globale) Variablen wie errno erläutert werden.

In diesem Zusammenhang ist es wichtig, diese man pages aufzusuchen und durchsuchen zu können. Den ersteren Teil könnt ihr im Artikel von Ralf Hersel auf gnulinux.ch nachlesen, das konkrete durchsuchen aller man pages möchte ich heute in diesem Artikel kurz betrachten.

Wir können mit dem man-Kommando alle Beschreibungen der man pages (-k, apropos) und auch den gesamten Inhalt der man pages (-K) durchsuchen.

Beschreibungen durchsuchen

Für den heutigen Fall möchten wir uns damit beschäftigen, wie wir ein Programm beenden können. Grundsätzlich kann ein exit vielfältig aussehen: wir können ihn auf der Shell durchführen, exit könnte aber auch einen Syscall oder eine C-Funktion aus der Standardbibliothek bezeichnen. Wenn wir schon dabei sind: exits gibts natürlich auch auf der pthread-Ebene, wir können aber auch eine Funktion registrieren, die bei einem normalen exit aufgerufen werden soll. Kurzum: wir müssen uns vorher erst einmal informieren, was wir überhaupt finden können, um dann die richtige man page aufzurufen. Diese Suche geht mit folgenden Kommandos, die auf das gleiche Ergebnis kommen:

man -k exit
apropos exit

Uns wird eine Liste aller man pages zusammengestellt, die exit im Namen oder der Kurzbeschreibung enthalten. Hier haben wir die Möglichkeit, die richtige Handbuchseite aufzufinden, um dann z. B. exit(0) im C-Programm aufzurufen.

Komplette man pages durchsuchen

Manchmal kann es allerdings passieren, dass wir zu einem gegebenen Suchbegriff über apropos nicht fündig werden. Dann müssen wir den kompletten Inhalt der man pages einbeziehen, weil der gesuchte Begriff mitunter in den detaillierten Beschreibungen erst zu finden ist.

Um bei unserem Beispiel zu bleiben, möchten wir weitere Informationen über die Konstante EXIT_SUCCESS finden, die oft anstelle von 0 als exit-Code benutzt wird. Hier müssen wir alle man pages nun durchsuchen, weil es keine man page dazu gibt, die diese Konstante in der Kurzbeschreibung erwähnt.

Wir nutzen:

man -K EXIT_SUCCESS

Nun werden alle man pages durchsucht, was zu vielen Ergebnissen führen kann. Das erste Ergebnis wird automatisch geöffnet (bei mir ist es das certtool), das mag uns aber nicht zufriedenstellen.

Wir können den Pager über q verlassen und nun durch die anderen Ergebnisse uns durcharbeiten. <Enter> führt zur Anzeige der man page, <Strg + D> zum Überspringen des Suchergebnisses und <Strl + C > zum Abbruch der Suche.

Bei dieser konkreten Konstante müssen wir uns Beispiele und Hinweise anschauen, um die Verwendung zu verstehen, deswegen kann es sein, dass man sich mehrere man pages anschauen muss, die thematisch dazu passen.

Zusammenfassung

Man pages sind das klassische Offline-Handbuch von unixoiden Systemen. Wenn man nicht sofort weiß, wo man etwas suchen soll, kann man die beiden Suchfunktionen (Beschreibung, Volltext) nutzen, die das man-Kommando bereitstellt. Weitere Informationen hierzu sind unter man man (man(1)) verfügbar.

Viele der Technologien, die wir heutzutage einsetzen, haben eine lange Geschichte hinter sich. Moderne Ansätze, sie nachzurüsten, können in bestimmten Szenarien jedoch unangenehme Auswirkungen haben. Ein kleines Beispiel möchte ich euch heute vorstellen.

Craig Younkins hat in seinem Blog auf Medium ein kurzes Szenario beschrieben, das verschlüsseltes DNS (DoH/DoT) und NTP involviert. Normalerweise gibt es bei so einem Setup wenig Probleme: der Client synchronisiert seine Zeit über NTP, kann Abweichungen ausgleichen und seine DNS-Anfragen über TLS-verschlüsselte Verbindungen abwickeln. Dabei hat der Client jederzeit seine vertrauenswürdigen Zertifikate lokal gespeichert, ebenso die Standardserver für NTP, die üblicherweise durch einen Hostname nach dem Muster *.pool.ntp.org adressiert werden.

Das Problem

Der Fallstrick: vergisst der Client die Zeit komplett, kann er in einem Deadlock landen und gegebenenfalls die Zeit nicht mehr synchronisieren. So ein Szenario kann auftreten, wenn ein System ausgeschaltet wurde und keine Real-Time-Clock in der Hardware verbaut wurde, die über eine eigene Batterieversorgung (i. d. R. Knopfzelle) verfügt. Bei einigen günstigen Routern bzw. IoT-Geräten wie dem Raspberry Pi ist das der Fall.

Findet das System keinen Anhaltspunkt über die aktuelle Zeit, so startet es, je nach Implementierung, meist beim Unix-Timestamp 1 bzw. am 01.01.1970. Dies kann jedoch in Verbindung mit TLS eine gefährliche Wirkung entfalten, da für die Zertifikatsvalidierung auf das aktuelle Datum zurückgegriffen wird – schließlich verfügen die meisten Zertifikate über einen festen Gültigkeitszeitraum, der nur wenige Monate umfasst.

Das Ergebnis: alle mit TLS abgewickelten DNS-Anfragen über die NTP-Server schlagen fehl. Dabei ist hervorzuheben, dass NTP selber unverschlüsselt weiterhin abläuft, es können lediglich die IP-Adressen der Server nicht ermittelt werden.

Lösungen

Damit soetwas nicht passiert, können Administratoren auf verschiedene Art und Weise vorbeugen. Eine erste Möglichkeit wäre, wie im Artikel beschrieben, das Hinterlegen von IP-Adressen im NTP-Client. Damit umgeht man DoH/DoT und kann direkt mit der NTP-Synchronisation fortfahren. Nachteil dieser Variante ist jedoch, dass es einerseits nur wenige NTP-Server mit wirklich statischen Adressen gibt (einer der wenigen Anbieter ist z. B. die NIST) und andererseits NTP generell eher auf Hostnames arbeitet, um z. B. einen Lastausgleich sicherzustellen.

Die zweite Variante wäre der Einsatz spezieller DHCP-Optionen wie Option 42, mit der beim Bezug der Netzwerkkonfiguration auch durch den DHCP-Server bestimmte IPv4-Adressen empfohlen werden können. In der Regel handelt es sich um lokale IPv4-Adressen, wenn lokal ein eigener NTP-Server betrieben wird, der seine Zeit mit höherrangigen Servern wiederum synchronisiert. DHCPv6 verfügt mit Option 56 über ein Äquivalent. (Q, RFC 2132 sec. 8.3., RFC 5908)

Es gibt allerdings auch spannendere Methoden: so ist der Ansatz von tlsdate, die Zeit über den TLS-Handshake von Internetdiensten wie Google oder Wikipedia zu extrahieren. Darüber hinaus wird momentan bei der IETF die Entwicklung von roughtime vorangetrieben, das hierfür ein eigenes kryptographisches Protokoll einsetzt. (Q, draft-ietf-ntp-roughtime-07, Artikel von Cloudflare)

Wer ein Dateisystem wie ext4 nutzt, findet darüber hinaus im Superblock aus dem vergangenen Mount hilfreiche Zeitangaben. Diese mount time und write time werden nämlich in der Regel bei jedem Mount und Schreibvorgang gesetzt und können als Anhaltspunkt für die Systemzeit des vergangenen Starts dienen - genug, um bei regelmäßig verwendeten Systemen immerhin die DoH-Anfrage für die initiale NTP-Namensauflösung abzuwickeln. (Q)

Fazit

Verschiedene komplexe Komponenten wie DoH/DoT und NTP können bei bestimmten Randbedingungen zu Situationen führen, die man bei der Erstkonfiguration vermutlich nicht vor Augen hatte. Wer jedoch mit dafür anfälligen Systemen ohne Real-Time-Clock arbeitet, kann auf verschiedene Strategien zur Abhilfe setzen: einerseits können Anhaltspunkte für die Zeit aus dem vergangenen Start gesucht werden oder zunehmend Protokolle genutzt werden, die genau dieses Problem adressieren.

Der Jahreswechsel steht bevor und ich möchte mich an dieser Stelle bei allen Lesern bedanken, die mich auch dieses Jahr auf meinem Blog begleitet haben. 16 Artikel habe ich dieses Jahr auf diesem Blog veröffentlicht, womit ich weiterhin die übliche Frequenz an Artikel auf diesem Blog halten konnte.

Das Highlight in diesem Jahr war der Start des Risikozone-Podcasts, der seit September regelmäßig läuft und Themen der IT-Sicherheit in ca. 45-minütigen Episoden behandelt. Eine besondere Ausgabe war dabei gleich die Sonderepisode 6, in der Sönke Huster seine entdeckten Lücken im Linux-WLAN-Stack uns erläutert hat.

Ich wünsche euch allen einen guten Rutsch ins neue Jahr und hoffe, dass ihr noch eine schöne Silvesternacht verbringen werdet. Lassen wir gemeinsam das Jahr 2022 hinter uns und starten mit voller Vorfreude und Zielen ins Jahr 2023.

Viel Glück, Gesundheit und Erfolg!

Wie GitHub bereits im Juni 2022 verlauten ließ, wurde der Editor Atom eingestellt. Dabei wurde am 15. Dezember 2022 das Repository archiviert und die Entwicklung somit vollständig beendet. Atom erschien im Jahr 2014 und wurde direkt durch GitHub entwickelt und stellte eine Alternative zu Editoren wie Sublime Text oder Notepad++ dar. Der Editor hat dabei nachhaltig die Welt der Desktop-Anwendungen verändert.

Der Grund hierfür liegt in der Basis, die anfangs noch Atom Shell hieß, aber später in Electron umbenannt wurde – ein Begriff, den viele sicherlich kennen werden. Electron wiederum nutzt Chromium als Basis, sodass die Entwicklung plattformunabhängiger Anwendungen ermöglicht wird, bei denen die eigentliche Anwendung lediglich innerhalb der Chromium-Browserinstanz ausgeführt wird.

Electron

Electron wird dabei kontrovers diskutiert. Es fällt auf der einen Seite der Ressourcenverbrauch auf, der entsteht, wenn mehrere Electron-Anwendungen mehrere Chromium-Browserinstanzen ausführen, die dann den RAM belagern. Auch sind Anwendungen nicht gerade klein – so ist eine Größe von über 100 MB selbst für kleinere Anwendungen nicht unüblich. Nicht allzuletzt wird der Kern der Anwendung auch in JavaScript und mit Paketen aus dem npm-Ökosystem ausgeführt. All das sind Faktoren, die zu einer hohen Komplexität und regelmäßigen Sicherheitsaktualisierungen führen, welche nicht außer Acht gelassen werden dürfen. Auf der anderen Seite stellt Electron aber eine Alternative zu verschiedensten Desktop-Frameworks wie Qt oder wxWidgets dar, steht unter der MIT-Lizenz und ermöglicht dank HTML, CSS und JavaScript eine mitunter einfachere Entwicklung von grafisch hochwertigen Anwendungen. Ob die Vorteile die Nachteile aufwiegen, bleibt dem Einzelfall überlassen.

Electron wird von Anwendungen wie Discord, Microsoft Teams oder auch Microsoft Visual Studio Code eingesetzt. Letztere Anwendung wird auch Atom beerben, da es nach dem Aufkauf von GitHub durch Microsoft nur eine Frage der Zeit war, bis einer der beiden Editoren weichen muss. GitHub selber möchte sich mit der Entscheidung vor allem auf die GitHub Codespaces konzentrieren, die Visual Studio Code in den Webbrowser bringen.

Mittlerweile gibt es im übrigen auch Alternativen zu Electron. Eine davon ist Tauri. Das Rust-Framework bietet dabei ähnliche Funktionen, baut intern aber nicht auf Chromium, sondern auf den jeweiligen WebView der OS-Plattform auf. Hier ist ein kurzer Einführungsartikel zu Tauri zu finden.

Aktueller Sicherheitshinweise zu Atom

Obgleich ich diesen Artikel deutlich früher schreiben wollte, gibt es heute einen wichtigen Anlass dazu: wer Atom noch einsetzt, sollte diesen Artikel beachten, da GitHub einige Zertifikate für Atom und GitHub Desktop zurückziehen musste und ggfs. ein Downgrade der Versionen erforderlich ist.

Das Team hinter dem bekannten Multimedia-Programm FFmpeg hat am 27.02.2023 die Version 6.0 freigegeben. Bei diesem Majorrelease gibt es Änderungen an der API, die trotzdem teils inkompatibel zu älteren Versionen sind und somit diesen Majorrelease nötig machen.

Da oftmals Informationen über die einzelnen Releases nicht direkt aufbereitet bereitgestellt werden, kann ich den Talk zu FFmpeg und VLS.js von Jean-Baptiste Kempf auf der FOSDEM 2023 am 4. Februar 2023 in Brüssel empfehlen. Die wichtigsten Änderungen gliedern sich laut ihm in CLI-Verbesserungen für Multithreading, RISC-V-Optimierungen, die Einbindung der AV1-Hardwareunterstützung bei Intel, Nvidia und AMD, optimiertem FFT-Code für SIMD bei x86 und ARM sowie einigen Änderungen an der API.

Das Projekt hat sich vorgenommen, eine Majorversion und bis zu zwei Minorversionen pro Jahr zu veröffentlichen. Dabei soll alle zwei Jahre die x.1-Version Long Term Support (LTS) von zwei Jahren erhalten, für alle anderen Versionen ist ein Support von einem Jahr angesetzt.

FFmpeg erschien 2000 und wurde von Fabrice Bellard initiiert, der auch für sein QEMU-Projekt bekannt ist, welches eine wichtige Rolle in der Virtualisierung auf Linux einnimmt. Das offizielle und stichwortorientierte Changelog ist im Git-Repository von FFmpeg verfügbar.

Kurz notiert: soeben hat OpenAI GPT-4 angekündigt. Das Modell ist in ChatGPT+ verfügbar, API-Nutzer können sich bereits auf einer Warteliste eintragen. Neuerungen sind u. a. die größere Anzahl an Tokens und die Fähigkeiten, auch Grafiken zu verarbeiten – das Modell wird somit multimodal.

Die Fähigkeiten werden heute in einem Livestream um 1 PM PT bzw. 21 Uhr deutscher Zeit vorgestellt. Der Livestream ist auf YouTube verfügbar.

Das Paper zu GPT-4 wurde ebenso veröffentlicht.

Das Team hinter PyTorch hat am 15. März 2023 Version 2.0 des Machine-Learning-Frameworks veröffentlicht. PyTorch 2.0 bringt zahlreiche Verbesserungen und Neuerungen mit sich. Zu den Highlights zählen die Beta-Version der torch.compile()-API und die verbesserte Integration von torch.nn.functional.

Neben der bewährten Entwicklung über den „eager mode“ gibt es nun die Möglichkeit, Modelle über den Befehl torch.compile zu kompilieren. Diese Änderung ermöglicht Leistungssteigerungen und ist vollständig abwärtskompatibel zur vorherigen Version. Der Versionssprung auf 2.x dient eher symbolischer Natur – ansonsten würde es eher einer Version 1.14 entsprechen.

Die Integration ist einfach und erfordert lediglich die Installation einer Nightly-Version und die Optimierung des Modells mit einer einzigen Codezeile:

model = torch.compile(model)

Version 2.0 bietet Leistungssteigerungen sowohl beim Training als auch bei der Inferenz und ist insbesondere für neuere GPU-Generationen optimiert. Neben der Hauptversion werden auch Beta-Updates für PyTorch-Domain-Bibliotheken wie TorchAudio, TorchVision und TorchText veröffentlicht. Weitere Informationen zu den Änderungen bei den Domain-Bibliotheken sind in einer gesonderten Pressemitteilung verfügbar. Für PyTorch 2.0 selber ist eine eigene Get-Started-Seite bereitgestellt worden.

PyTorch ist ein Machine-Learning-Framework unter der BSD-3-Lizenz, welches ursprünglich von Facebook AI (heute: Meta AI) 2016 veröffentlicht wurde und nun unter der Schirmherrschaft der Linux Foundation steht. Es baut auf das zwischenzeitlich eingestellte Torch auf, welches 2002 am EPFL in Lausanne in der Schweiz entstand. Heute steht PyTorch in Konkurrenz zu TensorFlow von Google und wird von verschiedenen Anwendungen eingesetzt, darunter Hugging Face Transformers, OpenAI Whisper oder der Tesla Autopilot.

Der KI-Wochenrückblick fasst die Nachrichten der Kalenderwoche 11 des Jahres 2023 zusammen. In dieser Woche gab es viele Neuigkeiten, darunter die Veröffentlichung von GPT-4, Midjourney 5, PyTorch 2.0 oder Alpaca.

Treue Leser des Blogs können sich noch an das Jahr 2018 und den Wochenrückblick erinnern. Über ein halbes Jahr habe ich im Wochentakt das Geschehen der Woche zusammengefasst. Der Wochenrückblick wurde nach kurzer Zeit wieder eingestellt und sollte auch nur als Experiment dienen.

Im Jahr 2023 wird allerdings der Wochenrückblick aus einem anderen Blickwinkel wieder relevant. Wir erleben momentan etwas, was mich an die Erfindung des iPhones erinnert: eine neue Technologie ist da und man möchte den ganzen Tag die Funktionalität ausprobieren. Dies fing bereits 2022 mit GPT-3 und DALL-E an setzt sich nun mit Stable Diffusion, ChatGPT und den ganzen neuen Modellen fort.

Um die Flut an Informationen zu sortieren, möchte ich die Gelegenheit nutzen und im KI-Wochenrückblick das Geschehen der Woche aufarbeiten und kurz zusammenfassen.

GPT-4 erschienen

Den Anfang macht ganz klar OpenAI mit GPT-4. Um die neue Version des bekannten Large Language Models (LLM) gab es schon seit einiger Zeit einen gewissen Hype. Am Dienstag war es dann soweit: OpenAI hat GPT-4 veröffentlicht. In einem Demo-Livestream wurden die Möglichkeiten vorgestellt. GPT-4 soll multimodal sein und neben Text auch Bilder verarbeiten können. Die Anzahl der Tokens steigt von 2048 auf 32k Tokens, was in etwa 25.000 Wörtern entspricht. Eine Eingabe kann also deutlich länger sein als bisher.

Das mit Spannung erwartete Paper, welches jetzt auf arxiv.org liegt, bietet allerdings recht wenig Einblicke in die Funktionsweise. Hier wurde der Fokus besonders auf Vergleiche bei standardisierten Tests gelegt, Details zur Architektur wurden nicht verraten. Diese Politik enttäuscht teilweise die Forschungswelt und wird bisher mit dem Konkurrenzdruck begründet. (Blogartikel von Dienstag)

Midjourney V5 Alpha veröffentlicht

Bei den Text-zu-Bild-Wandlern gibt es auch Neuigkeiten. Midjourney ist als Alpha in Version 5 verfügbar, wie das Team auf Twitter berichtet. Mit dem neuen Release werden die Bilder deutlich realistischer und die Qualitätssteigerungen werden sichtbar.

Midjorney ist allerdings, im Gegensatz zu OpenAI-Produkten, aktuell nicht als API verfügbar und kann nur teils kostenpflichtig über den Discord-Server erreicht werden.

ViperGPT: Visuelle Inferenz mittels Python-Ausführung

Eines meiner persönlichen Highlights der Woche ist die Vorstellung von ViperGPT und dem dazugehörigen Paper. Es geht ein Problem an, welches insbesondere bei Bild-Tasks präsent ist: während jeweils die Erkennung von Objekten oder die Codegenerierung für ein Problem relativ zuverlässig sind, ist die Kombination aus beidem fehleranfällig.

Beispiel: wir haben ein Bild mit verschiedenen Pizzastücken und Personen vorliegen. Die Frage "Wie viele Stücke könnte jede Person erhalten, wenn die Pizza fair aufgeteilt wird?" ist schwierig zu beantworten, wenn wir einen End-to-End-Ansatz fahren. ViperGPT wählt allerdings einen anderen Ansatz: hier wird ein Python-Programm generiert, welches Platzhalter für die eigentlichen Image-Recognition-Tasks im Rahmen von speziellen find()-Funktionsaufrufen lässt. Die eigentliche Aufteilungberechnung pizzastueckzahl // personenanzahl wird vom Codegenerator-Modell zwar formuliert, dann aber ganz normal deterministisch in Python auf einer CPU ausgeführt. Somit wird einerseits das Modell erklärbarer und andererseits auch deterministischer.

Ich freue mich schon auf den Code, um das Verfahren auszuprobieren. Wenn das funktioniert, lassen sich in meinen Augen die Vorteile unscharfer Large Language Models und präsizer Computerberechnungen besser kombinieren.

PyTorch 2.0 erschienen

PyTorch ist ein wichtiger Baustein in der ML-Forschung, da es als wichtiges Framework und TensorFlow-Konkurrent die Modelle erst implementierbar und trainierbar macht. Umso spannender ist es, dass hier eine neue Version erschienen ist.

In Version 2.0 sind allerdings glücklicherweise keine substantiellen Breaking Changes zu erwarten, es ist eine umgebrandete Version 1.14. Hinzu gekommen ist insbesondere torch.compile(), sodass Modelle vorkompiliert werden können und nicht mehr zwangsläufig im "eager mode" arbeiten müssen. (Blogartikel von Samstag)

Alpaca: Do-it-yourself GPT?

Ein großer Nachteil der aktuellen KI-Forschung liegt in der Verfügbarkeit der Modelle. Dabei müssen wir zwischen Modellen und Modellen unterscheiden – leider wird beides oft mit dem gleichen Namen bezeichnen. Modelle können einerseits die Architektur beschreiben (GPT-3, LLaMA, AlexNet, ...), andererseits aber auch die Architektur plus die dazugehörigen Gewichte (= das Herzstück für den Einsatz eines Modells) bedeuten. Die Gewichte sind das Ergebnis des Trainings.

Die Architektur wird meist offengelegt (in GPT-4 jetzt nicht mehr, wie wir gesehen haben), die Gewichte sind oft unter Verschluss, sind aber die Voraussetzung für den Betrieb eines vortrainierten Modells. LLMs wie GPT-4 oder PaLM sind prioprietär, Meta beschreitet mit LLaMA einen Mittelweg mit einer restriktiven Lizenz und andere Modelle wie die Spracherkennung Whisper sind komplett offen.

Um nun aber zügig ein lauffähiges, lokales LLM aufzubauen, haben die Stanford-Forscher mit Alpaca einen Trick angewandt. Sie nehmen das LLaMA-Modell und führen mittels Instructions, die mit ChatGPT synthetisiert werden, über das Self-Instruct-Verfahren ein Fine-Tuning durch. Herauskommen soll ein Modell, welches mit GPT-3 konkurrieren kann, aber unter 600 USD im Training gekostet hat. Das ist für bisherige Verhältnisse sehr billig.

Das Modell gibt es noch nicht zum Download, hier möchte das Alpaca-Team in Verhandlung mit Meta treten. Die Auswirkungen wären tatsächlich enorm, da einerseits die Entwicklungen lokal nachvollziehbar werden (für die Wissenschaft unerlässlich), andererseits aber der Alleinstellungswert von LLM-Providern sinkt, wenn ein anderes Modell einfach ihr Modell imitieren kann.

Weitere Neuigkeiten

• Microsoft 365 Copilot hält Einzug in Office
  Dieser Schritt war aus meiner Sicht seit dem 10 Mrd.-Investment erwartbar und wird nun umgesetzt. Effektiv wird dadurch ChatGPT direkt in Office nutzbar.
• Google führt KI-Systeme in Google Workspace ein
  Google zieht nach und bietet ähnliche Funktionen in den eigenen Produkten mit den eigenen Modellen an. Auch hier geht es darum, das Prompting innerhalb der Dokumente zu ermöglichen. Durch die enge Einbindung von Gmail in die Business-Suite können aber auch über die Schnittstellen z. B. E-Mail-Vorlagen schnell modifiziert werden.

Kurz notiert für alle, die GitHub nutzen, um ihre Git-Repositories zu speichern. Laut einem Artikel auf dem GitHub-Blog sah sich das Team durch einen Leak eines RSA-SSH-Private-Keys diese Woche gezwungen, heute am 24. März 2023 um 05:00 UTC (06:00 Uhr deutscher Zeit) die Keys zu tauschen.

Da nach TOFU-Prinzip vom SSH-Client der Key gespeichert wird, der bei der ersten Nutzung verwendet wurde, werden nachträgliche Änderungen auf Host-Seite als Man-in-the-Middle-Angriff (MitM-Angriff) vermutet. Deswegen sollte der alte, nun komprimittierte Key aus der known_hosts entfernt werden. Wie das geht, habe ich auf dem Blog hier schon einmal beschrieben.

Bei der erneuten, jetzt wieder "erstmaligen" Verbindung mit github.com sollte in jeden Fall der neue Key unbedingt mit der verlinkten GitHub-Dokumentationsseite abgeglichen werden, da man sonst erst recht MitM-Angriffen ausgesetzt ist. In der Regel wird spätestens jetzt ein auf einem neuen Verfahren wie ed25519 basierender Host-Key angeboten, was man auch nutzen sollte.

Während vergangene Woche die Nachrichten sich täglich überschlagen haben, ging es diese Woche etwas ruhiger zu – was aber nicht bedeutet, dass die Neuerungen weniger bahnbrechend sind. Die Woche im KI-Wochenrückblick.

ChatGPT Plugins

Wer die 17. Episode des Risikozone-Podcasts gehört hat, weiß, dass ich schon länger eine Erweiterung der "Text-KIs" skizziert habe, die das Sprachmodell auf die Textgenerierung beschränkt, aber die Informationsbeschaffung auf klassischem, deterministischem Weg umsetzt. Das habe aber nicht nur ich so gedacht, sondern auch die Forscher hinter Toolforge oder Entwickler hinter Werkzeugen wie LangChain oder ICortex. OpenAI hat ChatGPT mit den ChatGPT Plugins diese Woche seiner Text-KI genau diese Möglichkeit ebenfalls verpasst. Was als kleiner Schritt erscheint, dreht kurzfristig die KI-Nahrungskette um: während bisher die GPT-Modelle das Werkzeug waren, das in fertige Dienste integriert wurde, stellt ChatGPT nun das Tor in die Welt dar, das durch externe Informationen angereichert wird. So kann OpenAI nun z. B. einen Sachverhalt an WolframAlpha weiterleiten, ein Dienst, der (wissenschaftliche) Zusammenhänge präsizer verarbeiten kann und bereits seit langer Zeit die Grundlagen von Sprachassistenten darstellt. Weitere Informationen hierzu beschreibt Stephen Wolfram in seinem Blog. Aber auch Document Retreival, also das Durchsuchen der eigenen Datenberge, wird nun als Plugin unterstützt. Das dazugehörige GitHub-Repository chatgpt-retrieval-plugin trendet seit dem unentwegt.

Die Auswirkungen hinter dieser Neuerung werden maßgeblich durch die Bekanntheit von OpenAI verstärkt. Die Plugins setzen OpenAI jetzt in die Lage, Projekte und Startups, die lediglich ein Mashup, also eine Verschmelzung von GPT mit eigenen Informationen, angeboten haben, existentiell zu bedrohen. In diesem Aspekt ist OpenAI heute wie Google in den ersten Jahren: sie machen ein neues Feld besonders zugänglich, veröffentlichen in einer hohen Frequenz interessante Produkte – sind aber auch gefürchtet, weil sie die low-hanging fruits – die leichten Probleme – schnell lösen. Es bleibt weiterhin spannend.

Hello Dolly! Demokratisierung der Sprachmodelle

OpenAI wird zunehmend dafür kritisiert, die Entwicklung der neuen Sprachmodelle proprietär zu gestalten. Während GPT-2 noch einfach zugänglich war, ist GPT-3 nicht mehr einfach als Download verfügbar. Das ist natürlich für Forschung und Weiterentwicklung hinderlich, sichert für OpenAI aber nebenbei einen Wettbewerbsvorteil.

Die Antwort auf diesen "Missstand" kommt in diesen Tagen prompt: Databricks hat mit Hello Dolly an Alpaca aus letzter Woche angeknüpft und gezeigt, dass ein ChatGPT-ähnliches Modell auch auf Basis von GPT-J statt LLaMA (wie bei Alpaca) trainiert werden kann. GPT-J ist deshalb interessant, weil es noch aus der Zeit von vor zwei Jahren stammt, als Sprachmodelle offen bereitgestellt wurden.

Auch wenn GPT-J insgesamt über z. B. weniger Parameter verfügt, kann es trotzdem die hochwertigen Ergebnisse ermöglichen. Dabei zeichnet sich ab, dass die Methodik hinter Self-Instruct mächtig ist, was wiederum den Wettbewerbsvorteil der geheimen GPT-3-Gewichte relativiert.

Aber auch die Grundmodelle entwickeln sich weiter: so ist flan-ul2 von Google ein spannender Kandidat für ein solches Basismodell. flan-ul2 wurde erst Anfang des Monats veröffentlicht.

OpenAI stellt Codex-API ein

Realtiv geräuschlos stellte OpenAI offenbar die Zugänge zu den Codex-Modellen ein, hierzu gibt es nur Nutzerberichte. Im OpenAI Playground sind die Codex-Modelle auch nicht mehr anwählbar. Bemerkenswert ist hierbei die Vorwarnzeit, die lediglich wenige Tage betrug.

OpenAI Codex wurde 2021 veröffentlicht und war die spezielle Anpassung der GPT-3-Modelle für Code. Es bildete die Grundlage für den GitHub Copilot. GitHub hat in dieser Woche GitHub Copilot X vorgestellt, welcher nun auf GPT-4-Basis arbeitet. Die Einstellung von Codex ist hier schon fast folgerichtig, da OpenAI scheinbar ihr neues Modell GPT-4 als so allgemeingültig sieht, dass Textaufgaben und Codingprobleme über das gleiche System abgewickelt werden können.

Aber auch Codex bekommt Konkurrenz: Code Alpaca ist auch diese Woche erschienen und funktioniert ähnlich wie Alpaca, konzentriert sich aber speziell auf Codingprobleme. Die Web-Demo ist noch aktiv.

In dieser Woche gab es ebenfalls spannende Entwicklungen im Bereich der Künstlichen Intelligenz, die ich mit euch im KI-Wochenrückblick vorstellen möchte.

GPT4All

Die Welt der offenen GPT-artigen Modelle wurde in dieser Woche um ein weiteres Mitglied reicher: GPT4All. Das Projekt veröffentlicht neben einem Bericht eine Demo, Daten und Code, um ein Assistenten-ähnliches Sprachmodell auf LLaMa-7B-Basis zu trainieren. GPT4All nutzt rund eine Million Dialogpaare, die mit GPT-3.5-Turbo von OpenAI zwischen dem 20. März und 26. März 2023 generiert wurden. Die Daten stammen aus verschiedenen Quellen, darunter LAION OIG, Stack Overflow und Bigscience/P3. Nach Bereinigung der Datensätze verbleiben 437.605 Dialogpaare, die für das Training verwendet werden. Das Projekt veröffentlicht nicht nur die trainierten Modellgewichte, sondern auch 4-Bit-quantisierte Versionen, die eine Ausführung des Modells auf herkömmlichen CPUs ermöglichen.

Forderung nach einem Moratorium für KI

Ein offener Brief des Future of Life Institute, unterzeichnet von Persönlichkeiten wie Elon Musk oder Steve Wozniak, fordert ein mindestens sechmonatiges Moratorium für die Entwicklung von KI-Modellen, die leistungsstärker sind als GPT-4. Die Unterzeichner argumentieren, dass eine solche Pause notwendig sei, um sicherzustellen, dass die KI der Menschheit dient und nicht schadet. In den Reaktionen (z. B. 1 oder 2) gibt es für den Vorstoß auch viel Gegenwind.

Italien sperrt ChatGPT

Die italienische Datenschutzbehörde hat gegenüber OpenAI eine Sperrung von ChatGPT angeordnet, die zwischenzeitlich bereits offenbar umgesetzt wurde. Der Grund für die Sperrung sind angeführte Verstöße gegen Datenschutz- und Jugendschutzbestimmungen. Die Behörde kritisiert nach FAZ-Angaben insbesondere, dass OpenAI keine ausreichende Rechtsgrundlage für das Sammeln und Speichern von bestimmten personenbezogenen Daten habe. OpenAI muss innerhalb von 20 Tagen über die ergriffenen Maßnahmen informieren, sonst droht eine Straße von bis zu 20 Millionen Euro oder 4 % des Jahresumsatzes. Die erfolgte Sperrung steht auch im Zusammenhang mit der Störung vom 20. März, bei der durch einen Bug in der redis-py-Bibliothek Nutzer Daten Anderer erhalten haben.

Insgesamt zeigt sich, dass die KI-Branche weiterhin rasant voranschreitet, aber auch vor klassischen rechtlichen Herausforderungen steht. Es bleibt spannend, wie sich das Feld auch in der nächsten Woche entwickelt.

Im heutigen Wochenrückblick werde ich einige spannende Einblicke in die KI-Welt der letzten Tage präsentieren. Einige der Nachrichten stammen aus dieser Woche, bei anderen etwas älteren Themen möchte ich diesen Wochenrückblick zur Nachbesprechung nutzen.

LLaMa-Adapter

LLaMA-Adapter (Paper) ist so spannend, dass ich es euch nicht vorenthalten möchte. Über die letzten Wochen haben sich im Rahmen der ChatGPT-DIY-Konkurrenzmodelle einige Modelle und vor allem Methodiken für das Finetuning dieser herausgebildet.

Eine wichtige Rolle hat hierbei Metas LLaMA eingenommen. Das Modell ist zwar für ausgewählte Forscher mit den Gewichten verfügbar, steht aber unter einer restriktiven Lizenz. Trotzdem haben sich verschiedene Methodiken herausgebildet, LLaMa auf die eigenen Bedürfnisse feinzutunen, um insbesondere bessere Resultate zu erhalten.

Eines der ersten verbreiteten Verfahren hierfür war Alpaca. Dabei wurde ein spezielles Dataset herangezogen (52k Instruct), das aus Instruktionen bestand. Anschließend wurde LLaMa(-7B) genommen und die bestehenden Gewichte so angepasst, dass der Loss auf das Dataset als Trainingsdatensatz verringert wird. Problematisch hierbei: alle Gewichte müssen "angefasst" werden – und mit mindestens 7 Mrd. sind es nicht wenige.

LLaMa-Adapter nutzt einen anderen Ansatz und friert erst einmal die bestehenden Gewichte ein. Für das Finetuning wird eine eigene Schicht mit 1,2 Mio. neuen Gewichten hinzugefügt, wobei nur diese trainiert werden. Das Ergebnis ist ein Training, welches lediglich unter einer Stunde mit 8 A100-GPUs dauert. Diese Effizienz schlägt sich in einer kürzeren Trainingszeit und somit auch geringeren Kosten nieder.

Als sei das nicht genug, ermöglicht LLaMa-Adapter auch die Implementierung von Mutlimodalen Modellen, wo zusätzlich zur Texteingabe Bilder als solche verarbeitet werden können.

Semgment Anything Model

Meta bzw. Facebook nimmt in der aktuellen KI-Forschung eine ganz besondere Rolle ein. Denn oft sind es gerade die Entwicklungen und Modelle von Meta, die in der Community weite Anerkennung und Verbreitung finden.

In der aktuellsten Veröffentlichung aus dieser Woche widmen sich die KI-Forscher von Meta der Bildsegmentierung und stellen eines der Modelle frei einsehbar zur Verfügung.

Mit Bildsegmentierung dürften viele iOS-Nutzer letztes Jahr mit der Umstellung auf Version 16 in Kontakt bekommen sein. Eines der zentralen neuen Features war die Möglichkeit, sehr einfach Objekte in Bildern freistellen zu können ("cut out"). Dabei ist es entscheidend, sauber Objekte auf einem Bild trennen zu können.

Das Semgent Anything Model (SAM) stellt solche Möglichkeiten nun für Jedermann zur Verfügung, der damit arbeiten oder forschen möchte. Von Meta werden hierfür das Paper, der Datensatz und eine Demo bereitgestellt.

Auto-GPT

Mit Auto-GPT wurde diese Woche ein experimentelles Werkzeug bekannt, das GPT-4 bzw. GPT-3.5 direkt an den Computer anschließt, um automatisiert Ziele erarbeiten zu können. Man kann sich das wie die ChatGPT Plugins, nur mit viel mehr Freiheiten vorstellen. Um die Ziele zu erreichen, kann z. B. das System im Internet suchen oder auch Dateien lesen.

Für den einzelnen Endnutzer ist natürlich der Einsatz sehr riskant, da das System a) Zugriff auf den eigenen Computer hat und b) nicht vorhersagbar in Bezug auf das nächste ausgeführte Kommando ist. Trotzdem zeigt das Experiment, dass die GPT-Modelle heute beindruckend gut Ziele erreichen können, wenn sie eine Schnittstelle zu einem Computer erhalten.

Das war der KI-Wochenrückblick mit einer Auswahl von spannenden Nachrichten für diese Woche. Ich freue mich schon auf die nächste Woche, wenn wir wieder die Neuerungen der nächsten Woche besprechen können!

Es ist soweit: seit heute erstrahlt der Blog in einem neuen Blogdesign. In diesem Artikel gebe ich einen kleinen Überblick über die Motivation und die Änderungen.

Knapp fünf Jahre ist es her, dass ich das Design meines Blogs überarbeitet habe. Nun ist es wieder soweit: heute ging das neue Design des nun siebenjährigen Blogs live, an dem in den vergangenen Wochen und Monaten viel gearbeitet und geschraubt wurde. In diesem Artikel werde ich kurz die Hintergründe, ausgewählte technische Details sowie einen Ausblick präsentieren.

Im Schnelldurchlauf kurz einmal die Neuerungen und Nicht-Neuerungen:

• Grundsätzlich: Es wurde im Wesentlichen das Template überarbeitet. Die technische Grundlage wird weiterhin durch Django und MySQL gebildet.
• Das bedeutet auch: Cool URIs don't change. So auch bei dieser Änderung. Die Blog-URLs (insb. für die Artikel) bleiben erhalten, nur die Darstellung ändert sich.
• Das Blogdesign setzt nun auf Tailwind CSS und nicht mehr auf Boostrap 4.
• Flexboxen und Grids werden jetzt voll ausgenutzt. Gleiches gilt für den Dark Mode.
• Eine lokale Suche ist nun wieder verfügbar.
• Die Mehrsprachenfähigkeit wird in den nächsten Tagen und Wochen noch implementiert.
• Komplett entfernt wurde die AMP-Unterstützung, diese wurde aber seit 2018 auch nie richtig mehr eingeführt.

Organisatorisch

Bei der Umstrukturierung im Jahr 2018 stand im Vordergrund, mehr Magazinelemente implementieren zu können. Umgesetzt wurde das durch eine Reihe "ausgewählter Artikel", viele Seitenleisten und die strikte Unterteilung in Kategorien. Über die Jahre hat sich jedoch gezeigt, dass der Wert des Blogs insbesondere in der Aktualität der Blogeinträge liegt.

Aus diesem Grund steht beim neuen Design der jeweilige Blogartikel konsequent wieder im Vordergrund. Auf der Hauptseite befindet sich auch nun eine chronologische Auflistung der neusten Artikel. Die Artikelseiten stellen nun das Wichtigste dar: den Inhalt.

Zwar habe ich auch im Jahr 2018 geplant, Podcast-artige Elemente im Blog einzupflegen – für meinen Podcast Risikozone habe ich mich allerdings entschieden, das getrennt zu organisieren.

Ein Format wird allerdings trotzdem bleiben: der Microblog. Dieser entstand als Experiment vor einigen Jahren, um klassische Blogartikel und Kurzmeldungen auseinanderhalten zu können. Technisch sind auch die Feeds weiterhin getrennt: /feed/ ist der RSS-Feed von den normalen Artikeln, /feed/status/ von den Kurz- bzw. Statusmeldungen. Im neuen Blogdesign werden beide Inhalte aber einheitlicher in der Übersicht dargestellt.

Thematisch wird der Blog weiterhin Open-Source-Themen im Fokus behalten, zusätzlich aber auch den Komplex der Künstlichen Intelligenz aufnehmen. Dabei schließt das Eine das Andere nicht aus: ein wichtiger Aspekt der aktuellen Diskussion ist es, Architekturen und Gewichte moderner Machine-Learning-Systeme offen zugänglich zu machen. Auf meinem Blog werde ich Neuerungen und Einschätzungen in diesem Feld zukünftig teilen.

Dabei ist mir auch die Mehrsprachigkeit für die Zugänglichkeit wichtig, weswegen künftig ein größerer Anteil von Artikeln in Deutsch und Englisch veröffentlicht werden soll.

Technisch

Technisch bleibt weiterhin Django das Fundament. Django verrichtet problemlos seit Jahren seine Arbeit und ist einfach anpassbar.

Nicht so einfach anpassbar war das Design bzw. die Struktur dahinter. Deswegen wurden die Templates zu weiten Teilen neu implementiert. Das habe ich als Chance genutzt, den Frontend-Stack einmal zu überarbeiten. Hier setze ich nun auf das Utility-CSS-Framework Tailwind CSS, welches gut mit Template-Engines zusammenarbeitet.

Flexbox und Grids sind Elemente moderner CSS-Entwicklung, um auch die letzten Tabellen und Listen als Stylingelemente zu ersetzen. Diese neuen Elemente habe ich ebenso eingeführt wie den Dark Mode, der sich in den vergangenen Jahren auch als De-facto-Standard entwickelt hat.

Ausblick

Die Umgestaltung ist noch nicht vollständig abgeschlossen. Insbesondere die Internationalisierung (i18n) bedarf noch einiger Anpassungen, da das Blogtheme nun ins Englische, aber noch nicht wieder ins Deutsche rückübersetzt wurde.

Kosmetische Änderungen werden zeitnah und sukzessive eingepflegt. Sollte etwas noch nicht wie gewohnt funktionieren, könnt ihr euch gerne bei mir melden.

Danksagung

Abschließend möchte ich mich bei meinem Bruder Nikolas und meinen Lesern bedanken. Nikolas hat mich wesentlich bei der Konzeption und Implementierung des Designs unterstützt. Meine Leserschaft liest seit vielen Jahren schon meine Artikel und gibt mir regelmäßig per E-Mail oder Kommentar Feedback. Vielen Dank!

Sollte euch etwas besonders gefallen oder, was ich zu vermeiden versuche, stören, könnt ihr mir gerne auch weiterhin eine E-Mail oder einen Kommentar schreiben!

Seit September letzten Jahres produziere ich den Risikozone-Podcast. Über das vergangene halbe Jahr sind auf diese Weise schon 19 Episoden entstanden, die üblicherweise zwischen 40 und 60 Minuten lang sind. Ein besonderes Highlight war die Sonderepisode 6, wo wir Sönke Huster interviewt haben, der über die Erfahrungen beim Auffinden von Sicherheitslücken im WLAN-Stack des Linux-Kernels berichten konnte.

In weiteren Episoden haben wir bereits über Grundlagen der IT-Sicherheit gesprochen, darunter E-Mail-Hosting, VPNs, Mastodon, symmetrische Kryptosysteme oder asymmetrische Kryptosysteme. Ein immer stärkerer Fokus wird allerdings auch auf Machine-Learning-Modelle gerichtet, wie schon im Dezember über ChatGPT angesprochen.

In der heutigen Risikozone-Episode Nr. 19 geht es um eine ganze Reihe von Themen und aktuellen Nachrichten, die wir gestern aufgegriffen haben. Dabei ist ein konkretes Open-Source-Thema dabei, was ich euch nicht vorenthalten möchte.

Open Source wird bei KI-Systemen und hier den oft angesprochenen Large-Language-Models (LLMs) eine besondere Rolle spielen, denn bisher gibt es wenige große Anbieter, die in ihrer Rolle gleichzeitig auch als Gatekeeper fungieren. Gatekeeper, da sie einerseits proprietär die Gewichte bzw. Parameter für sich behalten möchten, aber andererseits auch eine Sicherheitsfunktion einnehmen.

Hier steht Sicherheit dem Open-Source-Gedanken gegenüber. Wer allerdings jetzt nach Verboten von "ungeprüfter" Open-Source-KI ruft, verkennt in meinen Augen allerdings die Bedeutung für die IT-Sicherheit. Es muss immer davon ausgegangen werden, dass "bad actors", also bösartige Akteure, alle technischen Möglichkeiten ausnutzen. Das umfasst auch das eigenständige Beschaffen von Trainingsdaten, Architekturspezifikationen und Rechenressourcen. Sich also nun auf Verbote und Moratorien zu verlassen, bringt im Ergebnis wenig. Ob die Open-Source-Modelle nun verfügbar oder verboten sind, hat auf bösartige Akteure keinen Einfluss und hemmt zudem noch die Weiterentwicklung "gutartiger" Modelle.

Indirekt lässt sich auch hier Kerckhoff's Prinzip anwenden, welches eigentlich eher aus der Welt der Kryptographie kommt:

Es darf nicht der Geheheimhaltung bedürfen und soll ohne Schaden in Feindeshand fallen können.

— Auguste Kerckhoffs: La cryptographie militaire 1883

Heißt also: Software resilient und sicher gestalten, Schutzmaßnahmen ausbauen, sich Gefahren nicht schönreden. Ein Beispiel ist da die Absicherung von BGP durch RPKI, wie sie von der niederländischen Regierung vorangetrieben wird. Auch das wird heute in der Episode kurz besprochen.

Auch wenn viele LLMs momentan frei ausgetauscht werden, sind sie oftmals nicht frei lizenziert, insbesondere, wenn sie von Meta AIs LLaMa abstammen. Das ist so ein bisschen wie das Unix von früher. Ausprobieren: jaein, selber verteilen: nein. Ein Auge richte ich momentan auf das Projekt Open Assistant, hier soll diesen Samstag das erste eigene, größere frei lizenzierte LLM veröffentlicht werden. Es bleibt also spannend.

Die Shownotes und das automatisiert erstellte Transkript befinden sich auf der Episodenseite, Informationen zum RSS-Feed auf der eigens dafür eingerichteten Unterseite. Feedback könnte ihr gerne als E-Mail oder Kommentar hier oder auf risikozone.de geben.

Im heutigen Wochenrückblick werde ich, wie gehabt, einige spannende Einblicke in die KI-Welt der letzten Tage präsentieren. Einige der Nachrichten stammen aus dieser Woche, bei anderen etwas älteren Themen möchte ich diesen Wochenrückblick zur Nachbesprechung nutzen.

Generative Agenten

Diese Woche war insbesondere von einem Paper geprägt: Generative Agents: Interactive Simulacra of Human Behavior. Wer sich noch an Spiele wie "Die Sims" erinnert, wird Teile der Funktionsweise wiedererkennen. 25 Spieler bzw. Avatare wurden auf die virtuelle Welt Smallville losgelassen und können dort textbasiert miteinander interagieren. Jeder Avatar wird durch einen Agenten repräsentiert. Das ist gerade sinnvoll, weil Ausgaben vom einem Avatar als Eingabe für einen anderen Avatar dienen können.

Damit alles funktioniert, haben die Forscher im Paper beschrieben, wie sie das auf GPT-3.5 aufbauende Systeme angepasst haben, um wie richtige "intelligente Agenten" agieren zu können. Das Ergebnis ist eine virtuelle Spielwelt, in der sich die virtuellen Avatare begrüßen, ihren Tag planen oder besondere Termine wie den Valentinstag berücksichtigen – und wir können zuschauen.

Agenten sind ein relativ altes Konzept der künstlichen Intelligenz und betreffen tatsächlich nicht nur Machine Learning direkt. Es geht insbesondere um die Simulation von Ergebnissen, um die Zusamennarbeit bestimmter Akteure praktisch auszutesten. ChatGPT zeichnet sich hierbei durch den Wissensschatz und die Vielfältigkeit aus, was diese Arbeit so interessant macht.

Besonders spannend ist dabei die Wirkungsweise, wie Agenten sich Dinge merken können. Hier war in den letzten Wochen besonders viel Forschungsaktivität zu beobachten, da weiterhin das "Wissen" eines Transformers durch die Eingabe bestimmt wird und Tricks bzw. Datenbanken notwendig sind, um Fakten langfristig zu bewahren.

Dolly 2.0

Databricks hat in dieser Woche Dolly 2.0 veröffentlicht. Die Besonderheit liegt in der Lizenz, denn das Dataset databricks-dolly-15k, auf dem das auf Pythia basierende Modell fingetuned wurde, steht unter der CC-BY-SA-3.0-Lizenz.

Das ist wichtig, weil ein Nachteil bisheriger Modelle wie Alpaca oder GPT4All darin lag, dass die Herkunftskette durch proprietäre, d.h. urherrechtlich geschützte und nicht lizenzierte Daten gekennzeichnet ist. Mit einem solchen freien Dataset wäre das Training allerdings rechtlich eindeutiger möglich.

Open Assisstant

Mit Spannung habe ich diese Woche die Veröffentlichung eines der Teilergebnisse des Open Assistants erwartet. Bei dem Projekt geht es darum, eine Open-Source-Alternative zu ChatGPT zu bauen. Mühsam musste daher durch Community-Unterstüzung ein Dataset aufgebaut werden. Dieses Dataset wurde nun veröffentlicht.

Das LLaMA-basierte Modell konnte noch nicht veröffentlicht werden, eine Delta-Version soll in Kürze freigegeben werden.

Zeitleiste der Transformer-basierten Modelle

Abschließend ein Projekt in eigener Sache: mit der Zeitleiste für die Transformer-Modelle baue ich momentan eine Überblicksseite samt Diagramm der verschiedenen Modelle. Es hat als kleines Projekt angefangen und wird immer größer, da mir immer mehr bewusst wird, wie sehr die heutigen ML-Projekte "auf den Schultern von Riesen stehen".

Die Seite ist für alle interessant, die sehen wollen, welche Modelle, Methoden und Papers aktuell diskutiert werden und wie sie voneinander abstammen. Über Feedback freue ich mich gerne!

In dieser Woche gab es wieder eine Reihe von KI-Entwicklungen, die ich euch heute vorstellen möchte. Auch in dieser Woche zeichnet sich wieder ein Trend ab: die Open-Source-Community schreitet auch bei der Entwicklung von eigenen Modellen voran.

RedPajama

Rechtlich befinden sich LLMs weiterhin oftmals in einer Grauzone. Die gefeierten, erfolgreichen Systeme wurden nicht nur mit viel Rechenkraft, sondern auch anhand eines bestimmten Datensatzes trainiert. Dieser ist in der Regel nicht öffentlich zugänglich. Diese Modelle, die aus dem Nichts trainiert wurden und grundsätzliche Fähigkeiten bereitstellen, werden auch als Foundation Models bezeichnet. Darauf aufbauend wird ein gewisses Fine-tuning unternommen, womit z. B. die Chatfähigkeiten deutlich verbessert werden.

Während Databricks mit Dolly 2.0 schon einen bemerkenswerten Auftakt zur Entwicklung offener LLMs angeboten hat, wurden die Foundation Models bisher wenig angetastet. Das soll sich nun mit RedPajama ändern. Das Projekt hat es sich vorgenommen, den Trainingsdatensatz hinter dem erfolgreichen, aber nicht-offenen LLaMA zu reproduzieren. Anschließend sollen freie Foundation Models trainiert werden.

Die Erstellung des Datensatzes ist nun abgeschlossen, die Ergebnisse können im oben verlinkten Artikel nachvollzogen werden. Nun steht das Training an. Vorteil solcher Modelle ist, dass sie rechtlich einfacher weiterverwendet und -trainiert werden können, was sehr wahrscheinlich einen Innovationsschub verursachen wird. Freie Modelle sind momentan das A und O für eine erfolgreiche Forschung, weil nur kleine Teile am Modell nachtrainiert werden.

VideoLDM

Ich war schon bei der Veröffentlichung von DALL-E und Stable Diffusion davon überzeugt, dass es nur noch eine Frage der Zeit ist, bis nicht nur Bilder, sondern auch Bildersequenz - Videos - generiert werden können. Nun ist es soweit: das Team rund um Andreas Blattmann und Robin Rombach hat mit Align your Latents: High-Resolution Video Synthesis with Latent Diffusion Models die ersten Ergebnisse ihrer Arbeit präsentiert.

Und diese können sich sehen lassen: den auf der Übersichtsseite vorgestellten Videosequenzen sieht man an vielen Stellen noch Unregelmäßigkeiten an, die auf eine Computergenerierung schließen lassen, aber je nach Setting sieht das extrem flüssig und hochwertig aus.

Dazu muss man die Dimension berücksichtigen: immerhin werden die kompletten Szenen aus einer kleinen Textbeschreibung erzeugt. Keine komplexen Beschreibungen oder Modellierung einer Szenerie, keine Animation, keine Videobearbeitung - direkt die Videos. Insbesondere für Filmstudios kann dies einen enormen Umbruch einleiten - entweder als Ergänzung oder aber auch als Ersatz.

NaturalSpeech 2

Modelle, die auf latente Diffusion setzen, haben nicht nur Stable Diffusion und VideoLDM ermöglicht. Ein Team von Microsoft Research hat sich jetzt Sprachsynthese unter Einsatz eines LDM (Latent Diffusion Model) vorgenommen und kommt zu erstaunlichen Ergebnissen.

Auf ihrer Seite können die Beispiele angehört werden.

Bark

Wo wir schon bei schon bei Sprachsynthese sind: könnt ihr euch noch an die Google I/O im Jahre 2018 erinnern? Eines der Highlights war die Demo von Google Duplex. Hier konnte das System selbstständig Personen anrufen, um z. B. Termine zu verabreden und Sprach dabei wie ein Mensch - mit allen Zwischenlauten und Pausen.

Mit Bark kann ein solches System selber ausprobiert werden. Grundsätzlich handelt es sich hierbei um eine normale Text-zu-Sprache-Anwendung, allerdings können Zusatzlaute wie Lachen, Schlucken oder Räuspern eingefügt werden. Darüber hinaus können Wörter besonders betont werden. Die Anwendung bietet beeindruckende Ergebnisse und zeigt, dass in Sachen Sprachsynthese noch einiges an Entwicklung momentan stattfindet.

Aktuelle Entwicklung werden zeitnah im Zeitstrahl der LLMs bzw. Transformer-Modelle vorgestellt.

Diese Woche hat auch wieder spannende Neuigkeiten geboten, die ich euch gerne vorstellen möchte. Legen wir los!

StableLM

Eingangs möchte ich euch heute das Modell StableLM vorstellen. Hierbei handelt es sich um ein Open-Source-LLM aus dem Hause Stability AI – das Team, das auch schon Stable Diffusion populär gemacht hat. Es wurde am 19. April 2023 vorgestellt und steht in verschiedenen Parameterzahlen zur Verfügung, darunter z. B. 7 Milliarden Parameter. Technisch wird die Grundlage durch Pythia und somit auch GPT-NeoX gebildet.

Das Grundtraining von StableLM basiert auf The Pile mit einigen Anpassungen. Diese Anpassungen ermöglichen es, dass ein qualitativ hochwertiges Modell mit deutlich weniger Parametern erstellt werden konnte.

DeepFloyd IF

Stability AI hat in dieser Woche zwei weitere interessante Modelle veröffentlicht, darunter eines in Partnerschaft mit der DeepFloyd-Gruppe. DeepFloyd IF wurde am 28. April 2023 veröffentlicht. Eine der spannendsten Neuigkeiten ist die Fähigkeit, sauberen Text in generierte Bilder einzuarbeiten. Wer Modelle wie DALLE-2 oder Stable Diffusion kennt, weiß, dass dies oft eine Herausforderung ist und oft schlecht aussieht.

Diese Fähigkeiten ermöglichen auch völlig neue Anwendungen in Kunst und Design, weil die Gestaltung von Schrift besser abgedeckt werden kann. Das Modell ist auf HuggingFace verfügbar, im Veröffentlichungsartikel sind schon einige Beispiele dargestellt worden.

StableVicuna

Das zweite Modell in dieser Woche von Stability AI heißt StableVicuna und wurde ebenfalls am 28. April veröffentlicht. Es ist eines der ersten großen Open-Source-Sprachmodelle, das nicht nur klassisch auf Instruktionen gefinetuned, sondern auch mittels RLHF verbessert wurde. Beide Konzepte sind einige der Erfolgsgeheimnisse von ChatGPT.

Um StableVicuna einsetzen zu können, wird allerdings ein Zugang zu LLaMA von Meta AI benötigt, da dies die Grundlage für Vicuna bildet, worauf StableVicuna aufsetzt. Aus diesem Grund sind die Gewichte nur als Deltas verfügbar.

Großes Übersichtsarbeit zu LLMs

Die Arbeit Harnessing the Power of LLMs in Practice: A Survey on ChatGPT and Beyond ist momentan eine der aktuellsten und besten Übersichtsarbeiten zum Thema LLMs. Neben einem Stammbaum, der im Gegensatz zu meiner Timeline eher auf die Grundarchitektur und weniger auf die Details abzielt, werden konkrete Bemerkungen und Einordnungen zu Architektur, Aufgabenstellungen und Abwägungen bei der Entwicklung gegeben.

Für alle, die mit oder an LLMs entwickeln möchten, lohnt sich ein Blick in das dazugehörige GitHub-Repository, das eine Linkliste beinhaltet.

ChatGPT in Italien wieder verfügbar

Das vor einigen Wochen in Italien gesperrte ChatGPT ist nun wieder verfügbar. OpenAI hat an vielen Stellen nachgebessert und konnte den akuten Anliegen entgegenkommen. Nun beginnt die Detailarbeit, die allerdings erwartungsgemäß eher im Hintergrund ablaufen wird.

LLMs als Sprachgeneratoren werden in den praktischen Anwendungen allerdings noch vielen Herausforderungen gegenüber stehen: so sind weiterhin Sprachgenerierung und Wissensbereitstellung in meinen Augen zu eng miteinander verbunden. Speziell wenn wir das "Recht auf Vergessen" diskutieren, müssen wir uns vor Augen führen, dass die verbreiteten LLMs über keinen Wissensspeicher verfügen, in dem falsches Wissen steht und dann korrigiert oder entfernt werden kann. Vielmehr ist dieses Wissen die Fähigkeit selbst, eine Sprache zu sprechen. In der Praxis sollen allerdings logischerweise falsche Aussagen vermieden werden. Damit das zuverlässiger möglich ist, wird vermutlich noch einiges an Forschung benötigt werden. Und vielleicht sind die Transformer in Zukunft nicht das Mittel der Wahl, wenn Projekte wie RWKV-LM voranschreiten.

Eine weitere Woche ist vergangen, in der sich in der KI-Welt wieder viel bewegt hat. Im heutigen Wochenrückblick wird der Fokus auf dem Thema liegen, das seit Wochen heiß diskutiert wird: Open Source.

Open-Source-Trend

Ich habe ja schon in den vergangenen Wochen angemerkt, dass der Trend weiter in Richtung Open-Source-Modelle geht. Die Arbeit mit neuronalen Netzen ist in der Regel kreativ und experimentell und da war es bisher ein Hindernis, dass die Modelle aufgrund der hohen Parameterzahl so groß waren. Genau diesen Umstand konnten kommerzielle Akteure ausnutzen und damit einen "Burggraben" ziehen, auf den ich nachher noch eingehen werde. Große KI-Modelle lassen sich nur mit hohem finanziellen Aufwand ausführen und schon gar nicht auf normaler Hardware trainieren.

Seit Metas LLaMA scheint dieser Damm allerdings gebrochen zu sein. Mit LLaMA wurde ein hochwertiges Modell der Allgemeinheit freigegeben, wenn auch unter einer sehr restriktiven nicht-kommerziellen Lizenz. Da die Gewichte (also das Blut in den Venen des Modells, d. h. Architektur + Gewichte = nutzbares Produkt) allerdings ausgewählten Forschern der Öffentlichkeit zur Verfügung gestellt wurden, dauert es nicht lange, bis sie geleakt wurden. Für quasi alle.

Die Folgen waren ganz interessant: die Community begann, die Modelle auszuprobieren. Als Erstes wurde mit llama.cpp die Quantisierung populär: wenn wir sowieso schon mit Unschärfe arbeiten, wird die Präzision nachrangig und es ist nicht mehr erheblich, ob wir 32-Bit-Floats oder 8-Bit-Floats nutzen. Reduzieren wir die Bits pro Gewicht, reduzieren wir die Modellgröße im (GPU-)RAM und machen das Modell verarbeitbarer. Schlagartig wird ein vortrainiertes Modell wie LLaMA sogar auf CPUs lauffähig und zum sog. Foundation Model, das nun für einen bestimmten Zweck nachtrainiert werden kann. Auch hier hat die Community Techniken wie LoRA angewandt, die den Trainingsaufwand reduzieren.

Dabei stellt sich schnell die Frage, wie weit die großen Firmen noch voraus sind. Glaubt man dem geleakten Memo eines Google-Engineers, schätzt er ein, dass der Burggraben (engl. Moat) nicht mehr so groß ist. Er glaubt zudem auch, dass das gleiche für OpenAI gilt. Der Economic Moat ist im übrigen ein Begriff von Warren Buffet und symbolisiert den Wettbewerbsvorteil von Unternehmen.

Neue Open-Source-Modelle

Metas LLaMA kann man nicht klassisch als "Open Source" bezeichnen, weil die Lizenz restriktiv ist und das Teilen der Gewichte zum Beispiel verbietet. Ich weiß, dass "freie Modelle" (im Sinne von "freie Software") anstatt "Open Source" die korrektere Wortwahl wäre, möchte mich aber an den Begriffen der Community halten.

Während der Zeit enstanden einige Fine-tunings (Nachtrainings), die auf speziellen Datasets beruhten, die tatsächlich frei waren. Besonders ist hier Databricks' Dolly-15k hervorzuheben. Allerdings werden finegetunte Modelle auf LLaMA-Basis nicht freier als LLaMA selber, weswegen es sich nur um eine Zwischenlösung handelte.

Das war Stand Anfang April 2023. Nun gibt es Modelle, die von Grund auf so trainiert und lizenziert wurden, dass es eine einheitliche Lizenz gibt. In dieser Woche kamen viele neue Modelle diesbezüglich heraus, darunter:

• StarCoder von HuggingFace für Programmieraufgaben,
• RedPajama-INCITE von Together AI als freier LLaMA-Nachbau und
• MPT-7B von MosaicML als weiteres freies Foundation Model.

Das Transformer-Framework von HuggingFace ist gut geeignet, um die Modelle zu testen und Anleitungen in den Model Cards helfen beim Einstieg.

OMR23

Nächste Woche werde ich auch auf der OMR23 in Hamburg sein. Auch das Thema künstliche Intelligenz und deren Auswirkungen wird dort präsent sein. Wer auch auf der OMR ist, kann mich gerne via Mail oder LinkedIn anschreiben, sodass man sich eventuell treffen kann!

In dieser Woche fasse ich mich mit dem Wochenrückblick recht kurz, im Wesentlichen war die Woche vom Google-Event geprägt.

Google I/O

Wer die KI-Entwicklung der letzten Wochen und Monate beobachtet hat, wird bemerkt haben, dass Google bisher mit der Veröffentlichung von Modellen und Projekten zurückhaltender war. Mit der Google I/O hat sich Google allerdings wieder vermehrt an die Öffentlichkeit gewagt, wie sich im umfangreichen Blogartikel lesen lassen kann.

Im Vordergrund stand insbesondere PaLM 2, welches laut Vorstellungsbeitrag besonders in drei Punkten nachzieht: Multilingualität, Schlussfolgerung und Coding. Letzter Punkt mag interessant sein, da wir in der letzten Woche sehen konnten, wie viele Open-Source-Coding-LLMs veröffentlicht wurden. PaLM 2 soll bereits schon in 25 (neuen) Google-Produkten arbeiten.

LLaMA-13B auf 6-GB-Grafikkarten

Während Google PaLM 2 vorstellt, aber die Gewichte nicht veröffentlicht, geht die Entwicklung bei den offeneren Modellen ungebremst weiter. Insbesondere die Zugänglichkeit im Bezug auf die Ressourcen wird laufend verbessert.

LLaMA-13B (13 Mrd. Parameter) wurde nun im Rahmen des llama.cpp-Projekts so eingesetzt, dass es auf einer NVIDIA RTX 2060 mit 6 GB VRAM lauffähig wird. Damit werden nicht nur die kleinsten Modelle auf normaleren Grafikkarten betreibbar, sondern auch die etwas größeren Modelle.

OMR23 mit dem Thema KI

Wie letzte Woche schon angekündigt, war ich diese Woche auf der OMR. Der Fokus der Konferenz lag dieses Jahr - wie konnte es anders sein - auch auf dem KI-Themenkomplex und so haben sich viele Vorträge daran ausgerichtet.

Einige der Vorträge können online abgerufen werden, darunter der von Jonas Andrulis von Aleph Alpha oder der von Philipp Justus und Zeina Hatem von Google. Das ist für alle interessant, die sehen wollen, wie die KI-Firmen diese Thematik betrachten.

Schauen wir auch diese Woche wieder, was uns die neue Woche bringt. Es bleibt spannend!