Speichersicherheit in C# 16 Microsoft plant neues unsafe-Modell für C#

Microsoft will das unsafe-Modell in C# neu fassen. Unsichere Operationen sollen sichtbarer, prüfbarer und stärker vom Compiler kontrolliert werden. Hinsichtlich Speichersicherheit orientiert sich Microsoft dabei an einem Prinzip der vergleichsweise jungen Programmiersprache Rust.

Microsoft arbeitet an einer Überarbeitung des unsafe-Modells von C#. Ziel ist es, Speicherzugriffe außerhalb der normalen verwalteten Laufzeit deutlicher zu kennzeichnen und besser überprüfbar zu machen. Die Änderung ist für C# 16 vorgesehen, das voraussichtlich zusammen mit .NET 12 erscheint.

Das heutige unsafe-Modell stammt im Kern aus C# 1.0. Es erlaubt unter anderem Pointer, Pointer-Arithmetik und direkten Zugriff auf nicht verwalteten Speicher. Solche Funktionen werden typischerweise für Interop-Szenarien, hardwarenahe Zugriffe oder besonders performancekritischen Code genutzt.

Microsoft begründet die geplante Änderung mit der Bedeutung von Speichersicherheit für Cloud-, Plattform- und KI-Szenarien. Ein zusätzlicher Faktor ist KI-gestützte Codegenerierung: Wenn Code schneller entsteht, steigt auch der Bedarf an Regeln, die unsichere Stellen eindeutig markieren und für Reviews zugänglich machen.

Markierte Unsicherheiten sollen sich durch Signaturen fortpflanzen

Künftig soll unsafe stärker als Vertrag verstanden werden. Wird eine Methode als unsafe markiert, signalisiert sie nicht nur intern unsichere Operationen, sondern stellt auch Anforderungen an ihre Aufrufer. Diese müssen sich ebenfalls in einem unsicheren Kontext befinden oder die unsichere Stelle bewusst in einer abgegrenzten Methode kapseln.

Damit übernimmt Microsoft ein Prinzip, das an Rust erinnert: Unsichere Operationen sollen nicht verdeckt in sicher wirkenden APIs verschwinden. Stattdessen sollen Annahmen, Vorbedingungen und Verantwortlichkeiten entlang der Aufrufkette sichtbar werden.

Eine wichtige Änderung betrifft den Gültigkeitsbereich von unsafe. Nach dem geplanten Modell soll ein Typ nicht mehr pauschal als unsicher markiert werden können. Stattdessen wandert die Kennzeichnung auf Member-Ebene, also zu Methoden, Properties oder Feldern, an denen der unsichere Zugriff tatsächlich relevant ist.

Auch Pointer-Typen sollen differenzierter behandelt werden. Allein die Verwendung eines Pointer-Typs gilt künftig nicht automatisch als unsichere Operation. Erst der Zugriff auf den Speicherinhalt, etwa durch Dereferenzierung, erfordert einen unsafe-Kontext. Damit soll der Code genauer ausdrücken, an welcher Stelle tatsächlich nicht verwalteter Speicher gelesen oder geschrieben wird.

Auswirkungen vor allem auf Low-Level- und Library-Code

Für viele Entwickler von Geschäftsanwendungen dürfte sich wenig ändern, weil sie unsafe Code in der Regel nicht direkt verwenden. Relevanter ist die Änderung für Bibliotheken, Runtime-nahe Komponenten, Native Interop, Serialisierung, Performance-Code und APIs wie System.Runtime.CompilerServices.Unsafe oder Teile von System.Runtime.InteropServices.Marshal.

Microsoft plant außerdem, Sicherheitsdokumentation stärker in das Modell einzubeziehen. Für unsafe Member soll ein dokumentierter Vertrag beschreiben, unter welchen Bedingungen die Verwendung korrekt ist. Statische Analysewerkzeuge könnten solche Angaben künftig einfordern oder prüfen.

Die neue Regelung soll zunächst als Opt-in kommen. Eine Vorschau ist für C# 15 und .NET 11 geplant, die produktive Einführung für C# 16 und .NET 12. Microsoft erwägt zudem Kennzeichnungen für NuGet-Pakete, die das neue Modell aktivieren, um die Umstellung in Bibliotheken sichtbarer zu machen.

Das neue Modell macht unsafe Code nicht automatisch sicher. Es soll aber die Stellen reduzieren, an denen unsichere Speicherzugriffe implizit bleiben. Für Entwickler bedeutet das mehr explizite Grenzen, mehr Compilerunterstützung und voraussichtlich auch etwas mehr Aufwand bei APIs, die bewusst außerhalb der verwalteten Sicherheitsgarantien arbeiten.(sg)

Speichersicherheit in Embedded-Systemen

Warum Embedded-Entwickler auf Rust vertrauen sollten

(ID:50858574)