Nachdem die Gematik das Bundesgesundheitsministerium und ihre Gesellschafter aufgrund des schleppenden Austauschs von elektronischen Heilberufsausweisen (eHBA) und Praxis- sowie Institutionsausweisen (SMC-Bs) gewarnt hatte, läuft die Produktion bei einem der Vertrauensdiensteanbieter Medisign nun auf Hochtouren. Andernfalls könnten tausende Ärzte und Apotheker zum Jahreswechsel nur noch eingeschränkt die Telematikinfrastruktur (TI) nutzen und beispielsweise keine E-Rezepte mehr signieren oder die elektronische Patientenakte befüllen.

Bis zum 31. Dezember 2025 müssen alle eHBA und SMC-Bs Generation 2.0 durch Karten der Generation 2.1 ersetzt werden. Grund dafür ist die Umstellung der bisherigen Verschlüsselung mit RSA 2048 auf das ECC 256 (Elliptic Curve Cryptography). Damit kommen die Beteiligten den Vorgaben des Bundesamts für Sicherheit in der Informationstechnik nach. ECC 256 bietet bei gleicher Sicherheitsstufe deutlich kürzere Schlüssellängen und damit schnellere Verarbeitungszeiten.

Für Apotheken ist die Lage ebenfalls brenzlig, wie die Pharmazeutische Zeitung in ihrem Beitrag verdeutlicht hatte. Versicherte können in betroffenen Apotheken dann keine E-Rezepte mehr einlösen. Speziell für Apotheken führen Ausfälle und TI-Störungen zu Verlusten, weshalb Apotheker kürzlich erneut mehr Zuverlässigkeit beim E-Rezept gefordert hatten.

Laut Angaben der Gematik müssen auch noch 13.000 Konnektoren getauscht werden, die nur RSA-fähig sind. Im Mai hatte die Kassenärztliche Bundesvereinigung (KBV) bereits vor Engpässen gewarnt und gefordert, die Frist zu verlängern, wie es auch in anderen Ländern beschlossen wurde.

Produktion läuft auf Hochdruck

Eine Sprecherin von Medisign räumt gegenüber heise online ein: „Durch die Umstellung auf ein komplett neues Antrags- und Produktionssystem ist es leider zu einem Zeitverzug in der Kartenproduktion von etwa vier Wochen gekommen. Die Daten vom Altsystem mussten ins neue System migriert werden, was sich als sehr komplex und aufwändig erwiesen hat. Mit Hochdruck arbeiten wir aktuell daran, verschiedene Prozesse und Funktionalitäten bei der Kartenbeantragung zu optimieren.“

Mit einer neuen Produktionsstraße wolle man pro 6-Tage-Woche bis zu 15.600 Karten ausstellen. So will der Vertrauensdienstanbieter den Sondertausch planmäßig bis Jahresende abschließen. Bereits in den ersten drei Tagen nach der Umstellung, am 27. September, seien 2.511 SMC-B und eHBA produziert worden. Medisign habe den Produktionsrückstand wieder aufgeholt.

Zudem sollen alle betroffenen Praxen und Apotheken rechtzeitig per E-Mail informiert werden. Kunden will Medisign außerdem ein „vereinfachtes, mit der Gematik abgestimmtes Verfahren anbieten: Dabei wird ausschließlich die Karte selbst getauscht – eine erneute Identifizierung ist nicht erforderlich, wenn sich die Ausweisdaten nicht geändert haben“, so die Sprecherin.

Sicherheitsforscherin Bianca Kastl sagt zum Tausch der Karten: „Traditionell ist das Problem kryptographischen Materials in der Telematikinfrastruktur, dass die Identifizierung oder die korrekte Zustellung von Karten schwach überprüft wird. Sofern neue Karten nicht wieder einfach so an die Käsetheke geliefert werden können und stattdessen sicher mit Identifikation zugestellt werden, mag das für einen Tausch der Karten reichen. Andernfalls ergeben sich hier neue Angriffsszenarien“.

Die Probleme bei Medisign reihen sich ein in eine Serie von Schwierigkeiten bei der Digitalisierung des Gesundheitswesens. Erst im August gab es Kompatibilitätsprobleme zwischen CGM-Praxissoftware und Rise-Konnektoren, die wochenlang den Zugriff auf die elektronische Patientenakte verhinderten. Für die Weiterentwicklung der TI setzt die Gematik künftig auf ein Zero-Trust-Sicherheitskonzept, das ab Mitte 2026 schrittweise eingeführt werden soll. Erst kürzlich hatte Bundesgesundheitsministerin Nina Warken ein Update der Digitalisierungsstrategie angekündigt – dies soll auch der Betriebsstabilität der TI zugute kommen.

(mack)

Linus Torvalds hat den Support für Bcachefs aus dem Hauptentwicklungszweig seines Kernels entfernt; das in neun oder zehn Wochen erwartete Linux 6.18 wird mit dem Dateisystem formatierte Datenträger daher von Haus aus nicht mehr einbinden können. Der für Linux-Verhältnisse ungewöhnliche Rauswurf erfolgte rund 24 Stunden nach der Freigabe von Linux 6.17 zum Wochenstart. Diese Version hatte bereits keine Bcachefs-Neuerungen mehr gebracht, denn der Linux-Erfinder hatte den Stand dort vor zwei Monaten als „extern gewartet“ gekennzeichnet und damit eingefroren – nach mehrfachem Zank mit Kent Overstreet, dem Erfinder und Hauptentwickler von Bcachefs.

Bcachefs lässt sich jetzt via DKMS einrichten

Der Rauswurf sollte nur wenige Linux-Anwender betreffen, denn der Bcachefs-Code in Linux ist nie dem experimentellen Stadium entwachsen. Da einzelne Distributionen das Dateisystem aber als Option für Tester anboten, hat es durchaus Nutzer. Darunter sind auch einige sehr laute Fürsprecher. Kein Wunder, lockt doch Bcachefs mit einer attraktiven Kombination einiger von anderen Dateisystemen bekannten Features.

Für diese und zukünftige Anwender hat Overstreet einige Umbaumaßnahmen am Code vorgenommen, die er fortan extern entwickelt, wie er es vor der Aufnahme bei Linux 6.7 vor rund eindreiviertel Jahren getan hat. Durch die Umbauten lässt sich Bcachefs jetzt per DKMS (Dynamic Kernel Module Support) bei verschiedensten Kerneln ab Linux 6.16 nachrüsten – und wird bei Kernel-Updates idealerweise auch automatisch passend zum neuen Kernel übersetzt. Das Ganze kennen viele Anwender etwa von Distributionen wie Debian oder Ubuntu, die das ältere, proprietäre Kernel-Modul der Nvidia-Grafiktreiber via DKMS handhaben.

Auch zur Virtualisierung mit VMware oder VirtualBox oder zum Support des Dateisystem OpenZFS setzen viele Distributionen auf das unabhängig vom Kernel gewartete DKMS. Das funktioniert in vielen Fällen recht zuverlässig, fällt gelegentlich aber beim Kompilieren auf die Nase. Das liegt zumeist nicht an DKMS, sondern am eher monolithischen Design von Linux.

Bei dem sind Treiber, Dateisystemcode und nichts Separates, sondern formen zusammen den „Kernel“ – auch dann, wenn man beim Bau des Kernels festlegt, einige Teile als nur bei Bedarf nachgeladenes Modul auszulagern. Bei gängigen Linux-Distributionen passen Kernel-Module daher nur zu dem Kernel-Image, für das sie kompiliert wurden. Diese sind somit eben nicht ab- oder aufwärtskompatibel, wie man es von stabilen Plug-in- oder Add-on-Schnittstellen bei Browsern oder Treibern von Windows kennt.

Gefahr des „sich selbst Aussperrens“ durch instabile Schnittstellen

Das liegt auch an einem anderen Aspekt: Um den Kernel schnell und schlank zu halten, verändern Torvalds und seine Helfer bei Bedarf die Kommunikationswege zwischen den verschiedenen Bestandteilen von Linux; dabei nehmen sie keine Rücksicht auf externe gewarteten Kernel-Code, der sich über diese Wege einklinkt. Entwickler von extern entwickeltem Kernel-Code wie fortan Bcachefs müssen diesen daher hin und wieder an die Belange neuer Linux-Versionen anpassen; das kann alle paar Wochen oder nur alle paar Jahre nötig sein, je nachdem, welche Kernel-Funktionen der externe Code verwendet und wie häufig sich diese Kernel-seitig ändern.

Diese Änderungen am externen Code müssen es dann aber auch zu den Nutzern schaffen, bevor diese auf Kernel-Version mit veränderten Schnittstellen wechseln. Hakt es daran, schlägt beim Anwender das automatische Kompilieren des Moduls via DKMS fehl.

Bei extern gewarteten Modulen für Grafikchips führt das zu Problemen, die zumindest Kenner oft mit einigen Handgriffen lösen können. Bei Modulen für Dateisysteme kann es schwieriger sein, denn wenn dem startenden Kernel ein Modul für das Root-Dateisystem fehlt, kann man das System darüber nicht mehr starten und daher kein passendes neues Modul einrichten. Um sich aus so einer Situation ohne Live-Linux heraus zu manövrieren, belassen einige Distributionen den jeweils letzten als funktionierend bekannten Kernel bei Updates als Boot-Option zurück. Derlei braucht man im dümmsten Fall auch, wenn neuer Modulcode nicht funktioniert und man das alte Modul schon gelöscht hat.

Distributions-spezifische Anpassungen erschweren die Auslieferung

Der DKMS-Weg von Bcachefs hat einen weiteren Nachteil, wie Overstreets Mail zur breiten Verfügbarkeit des DKMS-Ansatzes zeigt: Statt Bcachefs mehr oder weniger frei Haus über den Kernel an Distributionen zu verteilen, sind nun Anpassungen für Eigenarten der verschiedensten Distributionen nötig. Zur möglichst einfachen Handhabung durch die Nutzer braucht es ferner idealerweise auch Distributions-spezifische Pakete, die jemand konstant pflegt und testet.

Beim Support für Arch Linux, Debian und Ubuntu scheint die Lage demnach schon recht gut zu sein. Bei Fedora ist es im Werden, während bei openSUSE noch allerlei Fragezeichen im Raum stehen; dessen Entwickler hatten kürzlich den Bcachefs-Support bei Tumbleweed-Kernel beim Wechsel auf 6.17 deaktivierten und Overstreets Verhalten dabei kritisierten.

DKMS ist der Grund für den schnellen Rauswurf

Die Bcachefs-Unterstützung zur Handhabung via DKMS nennt Torvalds jetzt als Grund für die Entfernung des Dateisystems – die Kenner mittelfristig erwartet hatten, aber letztlich jetzt viel flotter kam, als es bei der Stilllegung von Bcachefs vor zwei Monaten schien. Der waren mehrere Streitereien vorangegangen, vor allem zwischen Overstreet und Torvalds. Gleich zweimal hatte es zwischen den beiden lautstark gekracht, weil der Bcachefs-Erfinder Code mit neuen Features zur Aufnahme während der längeren Stabilisierungsphase an den Linux-Erfinder schickte, anstatt während der kurzen Hauptentwicklungsphase (dem „Merge Window“), die dafür vorgesehen ist. Overstreet war aber auch mehrfach mit anderen Entwicklern zusammen gerasselt. Unter anderem, weil er hinterrücks den von ihnen betreuten Code geändert hatte.

Der streitbare Kalifornier hat Bcachefs seit über zehn Jahren weitgehend im Alleingang entwickelt – auch, weil sich mehrere mit der Zeit dazu gestoßene Mitstreiter über kurz oder lang mit ihm überworfen haben. Bis zu einem gewissen Grad ist das nur menschlich, schließlich passiert derlei auch beim Hasenzüchter- und Sportvereinen; bei Häufigkeit und Tonfall der Streitereien hebt sich die Bcachefs-Entwicklung aber negativ von anderen Software-Projekten und auch dem Linux-Kernel ab.

Dateisystem-Entwicklung ist hart

Derlei Drama und der Zank mit zentralen Kernel-Entwicklern dürften Schwergewichte aus dem Linux-Bereich verschrecken, die jährlich schätzungsweise mehrere Millionen von US-Dollar in Hardware und Mitarbeiter investieren, um die direkt in Linux enthaltenen Dateisysteme zu testen und zu verbessern – etwa Google (Ext4), Meta und Suse (Btrfs) oder Oracle und Red Hat (XFS).

Für Overstreet und seine Unterstützer wird es schwer, da mitzuhalten, denn Dateisysteme sind komplex und Linux-Nutzer machen die kuriosesten Dinge mit ihnen – daher sind meist viele Jahre Feldtest und mühsames Feintuning nötig, bis ein universelles Dateisystem wie Bcachefs wirklich stabil und in vielen der gängigen Einsatzgebiete performant arbeitet.

Hier hat Bcachefs noch viel Arbeit vor sich, auch wenn sein Hauptentwickler den extern gewarteten Dateisystemcode kürzlich als „stabil“ deklariert hat. Zumindest, wenn es ähnlich wie bei der Entwicklung von Btrfs, Ext4, Reiserfs oder XFS läuft: Auch dort war ab einem vergleichbaren Punkt noch jahrelange Arbeit und damit letztlich auch viel Geld nötig, um die Erwartungen der breiten Anwenderschar an Robustheit und Performance zu befriedigen.

(ktn)

Zahlen wirken in Programmen so selbstverständlich, dass viele Entwicklerinnen und Entwickler sie intuitiv wie in der Mathematik behandeln: Addition, Subtraktion, Multiplikation – was soll da schon schiefgehen? In der Praxis lauern hier jedoch zahlreiche Fallstricke. Speicherbegrenzungen, Rundungsfehler, Konvertierungen zwischen Datentypen und die unterschiedliche Behandlung von Ganzzahlen und Gleitkommazahlen führen immer wieder zu katastrophalen Fehlern.

Muster 2: Überlauf, Arithmetik und Präzision: Wenn Zahlen kippen

Ein ikonisches Beispiel dafür ist der Fehlschlag des ersten Ariane-5-Starts im Jahr 1996. Nur 37 Sekunden nach dem Start verließ die Rakete ihre Flugbahn, begann sich unkontrolliert zu drehen und zerstörte sich schließlich selbst. Die Ursache war nicht ein Materialproblem oder ein Defekt an der Rakete, sondern ein Softwarefehler in der Trägheitsnavigationssoftware.

Konkret versuchte das System, einen 64-Bit-Gleitkommawert in einen 16-Bit-Integer zu konvertieren. Der Wert war für die Ariane 5 jedoch zu groß und es kam zu einem Überlauf, der dann eine Ausnahme auslöste. Die Folge: Das gesamte Leitsystem schaltete sich ab. Da die Rakete zwei identische Systeme hatte, die synchron liefen, wiederholte sich der Fehler sofort auf dem Backup – die Redundanz konnte also nicht helfen.

Das wirft die Frage auf: Warum passiert so etwas in einem milliardenschweren Raumfahrtprogramm? Die Antwort ist tatsächlich lehrreich: Die Software der Ariane 5 basierte in Teilen auf dem Vorgängermodell Ariane 4. Dort waren die Wertebereiche kleiner, und ein 16-Bit-Integer war völlig ausreichend. Bei der Ariane 5 lagen die Beschleunigungen jedoch in einem anderen Bereich. Die alten Annahmen passten nicht mehr, aber die Entwickler haben die entsprechenden Codepfade nie überprüft – schließlich hatte die Software ja bereits jahrelang zuverlässig funktioniert.

Dieses Muster findet sich auch heute immer wieder in unzähligen Projekten:

• Entwicklerinnen und Entwickler übernehmen alte Codepfade, ohne ihre Gültigkeit für neue Einsatzbedingungen zu prüfen.
• Implizite Typumwandlungen oder fehlende Bereichsprüfungen führen im Grenzfall zu Überläufen.
• Fehlerbehandlung fehlt oder ist zu global – wie im Fall der Ariane, bei der eine einzelne Ausnahme zum Totalausfall führte.

In der Praxis begegnen Developer diesem Risiko immer wieder – auch in völlig alltäglichen Projekten. Typische Symptome sind:

• Plötzliche Sprünge oder negative Werte in Zählern,
• NaN-Ergebnisse oder Inf-Werte bei Gleitkommarechnungen und
• stille Rundungsfehler, die sich erst bei großen Zahlen oder nach langer Laufzeit bemerkbar machen.

Das Schlimmste daran ist, dass Gegenmaßnahmen durchaus bekannt sind, häufig aber aus Zeit- und Kostengründen vernachlässigt werden:

1. Explizite Bereichsanalysen: Vor allem bei Übernahmen prüfen, ob alle Wertebereiche noch passen.
2. Saturating Arithmetic oder Clamping: Wenn ein Wert den zulässigen Bereich überschreitet, diesen auf das Maximum setzen oder den Vorgang abbrechen, statt unbemerkt überlaufen zu lassen.
3. „Fail fast“ bei kritischen Konvertierungen: Lieber ein gezielter Fehler, der sich früh zeigt, als eine stille Datenkorruption.
4. Telemetrie und Monitoring: Wertebereiche im Betrieb überwachen und auffällige Ausreißer melden.

Interessant dabei ist auch die psychologische Komponente: Viele Teams verlassen sich auf ihre Testabdeckung und übersehen, dass Testdaten oft zu nett sind. Grenzwerte, Extrembereiche und ungewöhnliche Kombinationen fehlen häufig. Erst Property-based Testing, Fuzzing oder gezielte Grenzwerttests decken die kritischen Fälle auf.

Der Ariane-5-Vorfall hat gezeigt, dass selbst in hochkritischen Projekten mit gefühlt unendlichem Budget ein scheinbar banales Zahlenproblem zu einer Milliardenkatastrophe führen kann. Für den Alltag in der Unternehmens-IT heißt das: Jede Zahl ist ein Modell, und Modelle haben Grenzen. Wer diese Grenzen kennt und absichert, verhindert nicht nur Abstürze, sondern spart sich auch stundenlange Fehlersuche bei subtilen Rundungsfehlern.

Aus Softwarefehlern lernen – die Serie

Diese Artikelserie stellt neun typische Fehlerklassen vor, die in der Praxis immer wieder auftauchen – unabhängig von Branche oder Technologie. In jeder Kategorie wird die Serie ein konkretes Beispiel vorstellen, dessen Ursachen analysieren und daraus ableiten, was Softwareentwicklerinnen und Softwareentwickler langfristig lernen können.

Im nächsten Teil lesen Sie: Concurrency und Scheduling: Wenn sich Prozesse gegenseitig blockieren.

(who)