Гайд: Как прострелить ноги unsafe кодом в C# / forpes.ru

Главная
Гайд: Как прострелить ноги unsafe кодом в C#

Гайд: Как прострелить ноги unsafe кодом в C# +6

15.12.2025 11:19

Nagg 0 5100 Источник

ДИСКЛЕЙМЕР: Это статья является ручным переводом оригинальной статьи с небольшими пояснениями. Поводом для перевода стало слишком частое использование unsafe кода в других статьях о C# на русском языке в том числе тут на хабре. Заранее извиняюсь за англицимзы.

Глоссарий

AVE - Access Violation Exception
Byref/Managed pointer - Управляемый указатель (ref T t), похожий на неуправляемый указатель, но GC его отслеживает, что налагает определенные ограничения на него. Обычно указывает на произвольные части объектов или стека.
Reference - ссылка на объект в куче. Фактически, это Managed Pointer со смещением +0.
Unmanaged pointer (или raw pointer) - Неуправляемый указатель (T* p), который указывает на произвольное место в памяти (куча, стэк, "нативная" память, и т.п.) и не управляется и не отслеживается GC.

Другие термины см. в .NET Runtime Glossary.

Распространенные проблемы с unsafe кодом в C#

C# предоставляет безопасную среду, где разработчикам не нужно беспокоиться о внутренней работе среды выполнения и GC. Unsafe код позволяет обойти эти проверки безопасности, с соответсвующими рисками. Хотя unsafe может быть полезен в определенных сценариях, его следует использовать с осторожностью и только в случае крайней необходимости. C# и .NET не только не предоставляют инструментов для проверки корректности unsafe кода (как это могут делать различные санитайзеры C/C++), но еще и добавляется специфическое поведение GC (precise scanning, compacting) которое может создавать дополнительные риски в unsafe C#, помимо тех, с которыми могут быть знакомы традиционные разработчики C/C++. По фатку, небезопасный код в C# на порядки более опасный чем изначально небезопасные ЯП как С/С++.

Unsafe код должен писаться с учетом следующих консервативных предположений:

GC может прервать выполнение любого метода в любой момент времени по своему усмотрению на любой (машинной) инструкции, что намного более гранулярно, чем строчки исходного кода C#.
GC может перемещать объекты в памяти и обновлять все отслеживаемые ссылки в регистрах и стеке.
GC точно знает, когда ссылки больше не нужны.

Классический пример повреждения кучи (heap corruption) возникает, когда GC теряет ссылку на объект (under-reporting) или рассматривает невалидные указатели как ссылки на кучу (over-reporting). Такое, как правило, просходит из-за неаккуратного использования unsafe кода. Ошибки повреждения кучи особенно сложны для диагностики и воспроизведения, потому что:

Эти проблемы могут оставаться скрытыми долгое время и проявляться только после абсолютно несвязанного изменения кода или обновления среды выполнения (и вот уже виноват Microsoft, а не изначально некорректный код).
Они часто требуют точного тайминга для воспроизведения, например, прерывания выполнения GC в определенном месте и начала компактирования кучи, что является редким и недетерминированным событием.

ВАЖНО: если вы не используете unsafe код, вы защищены от всех проблем, описанных в этой статье. Однако, понятие "unsafe C#" код планируется сильно расширить в .NET 11 и .NET 12 аннотированием многих публичных API как требующих unsafe контекста.

В следующих разделах описываются распространенные unsafe паттерны с рекомендациями ✔️ DO (ДЕЛАТЬ) и ❌ DON'T (НЕ ДЕЛАТЬ).

1. Неотслеживаемые управляемые указатели (Unsafe.AsPointer и его друзья)

В безопасном C# невозможно преобразовать управляемый (отслеживаемый) указатель в неуправляемый (неотслеживаемый). Когда возникает такая необходимость, часто используют самое опасное из всех API System.Runtime.CompilerServices.Unsafe.AsPointer<T>(ref T), дабы избежать оверхеда от оператора fixed (или необходимости ограничивать скоуп). Хотя для этого есть валидные сценарии использования, это создает риск создания неотслеживаемых указателей на перемещаемые объекты.

Пример:

unsafe void UnreliableCode(ref int x)
{
    int* nativePointer = (int*)Unsafe.AsPointer(ref x);
    nativePointer[0] = 42;
}

Если GC прервет выполнение метода UnreliableCode сразу после чтения указателя (адреса, на который ссылается x) и переместит объект, на который ссылается x, GC корректно обновит местоположение, хранящееся в x, но ничего не будет знать о nativePointer и не обновит значение, которое он содержит. В этот момент запись в nativePointer — это запись в произвольную память.

unsafe void UnreliableCode(ref int x)
{
    int* nativePointer = (int*)Unsafe.AsPointer(ref x);
    // <-- GC срабатывает здесь между двумя строками кода 
    // и обновляет `x`, чтобы он указывал на новое место.
    // Однако `nativePointer` все еще указывает на старое 
    // место, так как о нем не сообщено GC.
    
    nativePointer[0] = 42; // Потенциально повреждающая
    // запись, access violation или другая проблема.
}

Как только GC возобновит выполнение метода, он запишет 42 в старое местоположение x, что может привести к неожиданному исключению, общему повреждению глобального состояния или завершению процесса из-за access violation.

Рекомендуемое решение — использовать ключевое слово fixed и оператор взятия адреса &, чтобы гарантировать, что GC не сможет переместить ссылку в течение операции.

unsafe void ReliableCode(ref int x)
{
    fixed (int* nativePointer = &x) // `x` больше не может быть перемещен
    {
        nativePointer[0] = 42;
    }
}

2. Раскрытие указателей за пределы области fixed

Хотя ключевое слово fixed определяет область видимости для указателя, полученного из запиненного объекта, все еще возможно, что этот указатель выйдет за пределы области fixed что приведет к багам, так как C# не предоставляет никакой защиты владения/жизненного цикла для него (никаких гарантий для любетелей unsafe кода).
Типичный пример — следующий фрагмент:

unsafe int* GetPointerToArray(int[] array)
{
    fixed (int* pArray = array)
    {
        _ptrField = pArray; // Баг!

        Method(pArray);     // Баг, если `Method` позволяет `pArray` "убежать",
                            // возможно, присвоив его полю.

        return pArray;      // Баг!

        // И другие способы выхода за пределы области видимости.
    }
}

В этом примере массив правильно запинен с использованием ключевого слова fixed (гарантируя, что GC не сможет переместить его внутри блока fixed), но затем указатель раскрывается за пределы блока fixed. Это создает висячий указатель (dangling pointer), разыменование которого приведет к неопределенному поведению.

3. Внутренние детали реализации среды выполнения и библиотек

Хотя доступ к внутренним деталям реализации является плохой практикой в целом, стоит упомянуть конкретные часто встречающиеся случаи. Это не исчерпывающий список всего, что может пойти не так, когда код ненадлежащим образом полагается на внутреннюю деталь реализации.

4. Невалидные управляемые указатели (даже если они никогда не разыменовываются)

Определенные категории кода опираются на манипуляции с указателями и арифметику, и такой код часто имеет выбор между использованием неуправляемых указателей (T* p) и управляемых указателей (ref T p).
Этими указателями можно манипулировать произвольно, например, с помощью операторов над неуправляемыми указателями (p++) и с помощью методов Unsafe над управляемыми указателями (p = ref Unsafe.Add(ref p, 1)). Оба варианта считаются "unsafe кодом", и с обоими можно сильно накосячить. Однако для определенных алгоритмов может быть проще случайно создать GC-unsafe паттерны при манипулировании управляемыми указателями. Поскольку неуправляемые указатели не отслеживаются GC, совершенно не важно куда они указывают, пока они не разыменовываются. Это не является проблемой и иногда используется намеренно. Это совершенно не допустимо для управляемых указателей, т.к. даже если вы нигде явно не разыменовываете невалидный управляемый указатель, Runtime/GC могут в любой момент сделать это за вас с неопределенными последствиями.

unsafe void UnmanagedPointers(int[] array)
{
    fixed (int* p = array)
    {
        int* invalidPtr = p - 1000;
        // invalidPtr указывает на неопределенное место в памяти
        // это нормально, пока он не разыменован.

        int* validPtr = invalidPtr + 1000; // Возвращаемся к исходному месту
        *validPtr = 42; // OK
    }
}

Однако аналогичный код с использованием byrefs (управляемых указателей) является невалидным.

void ManagedPointers_Incorrect(int[] array)
{
    ref int invalidPtr = ref Unsafe.Add(ref array[0], -1000); // Уже баг!
    ref int validPtr = ref Unsafe.Add(ref invalidPtr, 1000);
    validPtr = 42; // возможно повреждающая запись
}

Хотя управляемая реализация здесь избегает небольшого оверхеда на пиннинг, она некорректна, потому что invalidPtr может стать внешним указателем (exterior pointer), в то время как фактический адрес array[0] обновляется GC.
Такие баги сложно диагностировать, и даже .NET сталкивался с ними во время разработки.

5. Приведения типов в стиле reinterpret_cast

Хотя все виды приведений struct-to-class или class-to-struct являются неопределенным поведением по определению, также возможно столкнуться с проблемами при преобразованиях struct-to-struct или class-to-class.
Типичный пример:

struct S1
{
    string a;
    nint b;
}

struct S2
{
    string a;
    string b;
}

S1 s1 = ...
S2 s2 = Unsafe.As<S1, S2>(ref s1); // Баг! Случайное значение
                                   // nint становится ссылкой, сообщаемой GC.

И даже если лейаут похож, вам все равно следует быть осторожными, когда задействованы ссылки GC (поля), т.к. фактически лейаут становится Auto даже если указан Sequential.

6. Обход Write Barrier и неатомарные операции над ссылками GC

Обычно все виды записи или чтения ссылок GC всегда атомарны. Кроме того, все попытки присвоить ссылку GC (или byref на структуру с полями GC) в потенциальное место в куче проходят через GC Write Barrier (барьер записи GC), который гарантирует, что GC знает о новых связях между объектами.
Однако unsafe код позволяет нам обойти эти гарантии и ввести ненадежные паттерны. Пример:

unsafe void InvalidCode1(object[] arr1, object[] arr2)
{
    fixed (object* p1 = arr1)
    fixed (object* p2 = arr2)
    {
        nint* ptr1 = (nint*)p1;
        nint* ptr2 = (nint*)p2;

        // Баг! Мы присваиваем указатель GC в место в куче
        // не проходя через Write Barrier.
        // Более того, мы также обходим проверки ковариантности массивов.
        *ptr1 = *ptr2;
    }
}

Аналогично, следующий код с управляемыми указателями также ненадежен:

struct StructWithGcFields
{
    object a;
    int b;
}

void InvalidCode2(ref StructWithGcFields dst, ref StructWithGcFields src)
{
    // Это уже плохая идея приводить структуру с полями GC к `ref byte` и т.д.
    ref byte dstBytes = ref Unsafe.As<StructWithGcFields, byte>(ref dst);
    ref byte srcBytes = ref Unsafe.As<StructWithGcFields, byte>(ref src);

    // Баг! Обходит Write Barrier. Также неатомарные записи/чтения для ссылок GC.
    Unsafe.CopyBlockUnaligned(
        ref dstBytes, ref srcBytes, (uint)Unsafe.SizeOf<StructWithGcFields>());

    // Баг! То же самое, что и выше.
    Vector128.LoadUnsafe(ref srcBytes).StoreUnsafe(ref dstBytes);
}

7. Предположения о времени жизни объектов (финализаторы, GC.KeepAlive)

Избегайте предположений о времени жизни объектов с точки зрения GC.
В частности, не предполагайте, что объект все еще жив, когда это может быть не так. Время жизни объектов может варьироваться в разных средах выполнения или даже между разными уровнями (Tiers) одного и того же метода (Tier0 и Tier1 в RyuJIT).
Финализаторы — распространенный сценарий, где такие предположения могут быть неверными.

public class MyClassWithBadCode
{
    public IntPtr _handle;

    public void DoWork() => DoSomeWork(_handle); // Баг use-after-free!

    ~MyClassWithBadCode() => DestroyHandle(_handle);
}

// Пример использования:
var obj = new MyClassWithBadCode()
obj.DoWork();

В этом примере DestroyHandle может быть вызван до завершения DoWork или даже до его начала.
Поэтому крайне важно не предполагать, что объекты, такие как this, останутся живыми до конца метода.

void DoWork()
{
    // Псевдокод того, что может произойти "под капотом":

    IntPtr reg = this._handle;
    // Объект 'this' больше не жив в этот момент.

    // <-- GC прерывает здесь, собирает объект 'this' и запускает его финализатор.
    // Вызывается DestroyHandle(_handle).

    // Баг! 'reg' теперь висячий указатель.
    DoSomeWork(reg);

    // Вы можете решить проблему и принудительно сохранить 'this' живым (тем самым гарантируя, что
    // финализатор не запустится), раскомментировав строку ниже:
    // GC.KeepAlive(this);
}

Поэтому рекомендуется явно продлевать время жизни объектов с помощью GC.KeepAlive(object) или System.Runtime.InteropServices.SafeHandle.

Другой классический пример этой проблемы — API System.Runtime.InteropServices.Marshal.GetFunctionPointerForDelegate<TDelegate>(TDelegate):

var callback = new NativeCallback(OnCallback);

// Преобразование делегата в указатель на функцию
IntPtr fnPtr = Marshal.GetFunctionPointerForDelegate(callback);

// Баг! Делегат может быть собран GC здесь.
// Он должен поддерживаться живым, пока нативный код не закончит с ним работу.

RegisterCallback(fnPtr);

8. Доступ к локальным переменным из разных потоков

Доступ к локальным переменным из другого потока обычно считается плохой практикой. Однако это становится явным UB, когда задействованы управляемые ссылки, как описано в .NET Memory Model.

Пример: Структура, содержащая ссылки GC, может быть обнулена или перезаписана небезопасным для потоков образом внутри региона без GC (no-GC region), в то время как другой поток читает ее, что приводит к неопределенному поведению.

9. Удаление проверок границ (bounds check)

В C# все идиоматические обращения к памяти включают проверки границ по умолчанию.
JIT-компилятор может удалить эти проверки, если сможет доказать, что они не нужны, как в примере ниже.

int SumAllElements(int[] array)
{
    int sum = 0;
    for (int i = 0; i < array.Length; i++)
    {
        // JIT знает, что внутри этого тела цикла i >= 0 и i < array.Length.
        // JIT может предположить, что его собственная проверка границ
        // будет дублирующей и ненужной, поэтому он решает не 
        // генерировать проверку границ в финальном сгенерированном коде.
        sum += array[i];
    }
}

Хотя JIT постоянно улучшается в распознавании таких паттернов, все еще существуют сценарии, где он оставляет проверки на месте, потенциально влияя на производительность в горячем коде. В таких случаях у вас может возникнуть соблазн использовать unsafe код для ручного удаления этих проверок, не до конца понимая риски или точно не оценивая преимущества производительности.

Рассмотрим, например, следующий метод.

int FetchAnElement(int[] array, int index)
{
    return array[index];
}

Если JIT не может доказать, что index всегда легально находится в границах array, он перепишет метод примерно так:

int FetchAnElement_AsJitted(int[] array, int index)
{
    if (index < 0 || index >= array.Length)
        throw new IndexOutOfBoundsException();
    return array.GetElementAt(index);
}

Чтобы уменьшить накладные расходы от этой проверки в горячем коде, может возникнуть соблазн использовать unsafe-эквивалентные API (Unsafe и MemoryMarshal):

int FetchAnElement_Unsafe1(int[] array, int index)
{
    // Доступ ниже не проверяется на границы и может вызвать access violation.
    return Unsafe.Add(ref MemoryMarshal.GetArrayDataReference(array), index);
}

Или использовать пиннинг и unmanaged указатели:

unsafe int FetchAnElement_Unsafe2(int[] array, int index)
{
    fixed (int* pArray = array)
    {
        // Доступ ниже не проверяется на границы и может вызвать access violation.
        return pArray[index];
    }
}

Это может привести к случайным сбоям или повреждению состояния, если index находится за пределами границ array.
Такие unsafe преобразования могут иметь преимущества в производительности на очень горячих путях, но эти преимущества часто временны, так как каждый релиз .NET улучшает способность JIT устранять ненужные проверки границ, когда это безопасно.

10. Объединение доступа к памяти (Memory access coalescing)

Иногда используют unsafe код для объединения обращений к памяти с целью повышения производительности. Классический пример — этот код для записи "False" в массив char:

// Наивная реализация
static void WriteToDestination_Safe(char[] dst)
{
    if (dst.Length < 5) { throw new ArgumentException(); }
    dst[0] = 'F';
    dst[1] = 'a';
    dst[2] = 'l';
    dst[3] = 's';
    dst[4] = 'e';
}

// Unsafe оптимизированная реализация
static void WriteToDestination_Unsafe(char[] destination)
{
    Span<char> dstSpan = destination;
    if (dstSpan.Length < 5) { throw new ArgumentException(); }
    ulong fals_val = BitConverter.IsLittleEndian ? 
        0x0073006C00610046ul : 
        0x00460061006C0073ul;
    MemoryMarshal.Write(MemoryMarshal.AsBytes(
        dstSpan.Slice(0, 4)), in fals_val); // "Fals" (4 chars)
    dstSpan[4] = 'e';                       // "e" (1 char)
}

В предыдущих версиях .NET unsafe версия с использованием MemoryMarshal была заметно быстрее, чем простая безопасная версия. Однако современные версии .NET содержат значительно улучшенный JIT, который производит эквивалентный код для обоих случаев. На момент выхода .NET 10 код для x64 выглядит так:

; WriteToDestination_Safe
cmp      eax, 5
jl       THROW_NEW_ARGUMENTEXCEPTION
mov      rax, 0x73006C00610046
mov      qword ptr [rdi+0x10], rax
mov      word  ptr [rdi+0x18], 101

; WriteToDestination_Unsafe
cmp      edi, 5
jl       THROW_NEW_ARGUMENTEXCEPTION
mov      rdi, 0x73006C00610046
mov      qword ptr [rax], rdi
mov      word  ptr [rax+0x08], 101

Существует еще более простая и читаемая версия кода:

"False".CopyTo(dst);

На момент .NET 10 этот вызов производит идентичный код, как и выше. У него даже есть дополнительное преимущество: он подсказывает JIT, что строгие поэлементные записи не обязаны быть атомарными. JIT может объединить эту подсказку с другими контекстными знаниями, чтобы обеспечить еще больше оптимизаций, выходящих за рамки обсужденного здесь.

11. Невыровненный доступ к памяти

Объединение доступа к памяти, описанное выше, часто приводит к явным или неявным невыровненным чтениям/записям. Хотя это обычно не вызывает серьезных проблем (кроме потенциальных штрафов производительности из-за пересечения границ кэша процессора и страниц), это все же создает некоторые реальные риски.

Например, рассмотрим сценарий, где вы очищаете два элемента массива одновременно:

uint[] arr = _arr;
arr[i + 0] = 0;
arr[i + 1] = 0;

Допустим, предыдущие значения в этих местах были оба uint.MaxValue (0xFFFFFFFF).
.NET Memory Model гарантирует, что обе записи атомарны, поэтому все другие потоки в процессе будут наблюдать только новое значение 0 или старое значение 0xFFFFFFFF, никогда не "разорванные" (torn) значения, такие как 0xFFFF0000.

Однако предположим, что используется следующий unsafe код для обхода проверки границ и обнуления обоих элементов одной 64-битной записью:

ref uint p = ref Unsafe.Add(ref MemoryMarshal.GetArrayDataReference(arr), i);
Unsafe.WriteUnaligned<ulong>(ref Unsafe.As<uint, byte>(ref p), 0UL);

Этот код имеет побочный эффект удаления гарантии атомарности. Разорванные значения могут наблюдаться другими потоками, что приведет к неопределенному поведению.
Чтобы такая объединенная запись была атомарной, память должна быть выровнена по размеру записи (8 байт в данном случае). Если вы попытаетесь вручную выровнять память перед операцией, вы должны учитывать, что GC может переместить (и, фактически, изменить выравнивание) массива в любое время, если он не запинен. См. документацию .NET Memory Model для получения более подробной информации.

Другой риск невыровненного доступа к памяти — потенциальный сбой приложения в определенных сценариях.
Хотя некоторые среды выполнения .NET полагаются на ОС для исправления невыровненных доступов, все еще существуют сценарии на некоторых платформах, где невыровненный доступ может привести к System.DataMisalignedException (или System.Runtime.InteropServices.SEHException).
Примеры:

Операции Interlocked на невыровненной памяти на некоторых платформах (пример).
Невыровненные операции с плавающей точкой на ARM (Linux OS не делает автоматическое исправление для некоторых из этих случаев в ARM32)
Доступ к специальной памяти устройства с определенными требованиями к выравниванию (этот сценарий не особо поддерживается .NET в целом).

12. Бинарная (де)сериализация структур с паддингами или non-blittable членами

Будьте осторожны при использовании различных API, похожих на сериализацию, для копирования или чтения структур в или из байтовых массивов.
Если структура содержит паддинги или non-blittable члены (например, bool или поля GC), то классические unsafe операции с памятью, такие как Fill, CopyTo и SequenceEqual, могут случайно скопировать чувствительные данные из стека в паддинги или рассматривать мусорные данные как значимые при сравнении, создавая редко воспроизводимые баги. Распространенный анти-паттерн может выглядеть так:

T UnreliableDeserialization<TObject>(ReadOnlySpan<byte> data) where TObject : unmanaged
{
    return MemoryMarshal.Read<TObject>(data); // или Unsafe.ReadUnaligned
    // БАГ! TObject : unmanaged не гарантирует, 
    // что TObject является blittable и не содержит паддингов.
}

Единственный правильный подход — использовать загрузку/сохранение поле-за-полем, специализированные для каждого входа TObject (или обобщенные с помощью Reflection, Source Generators или библиотек (де)сериализации).

13. Null управляемые указатели

Как правило, byrefs (управляемые указатели) редко бывают null, и единственный безопасный способ создать null byref на сегодняшний день — это инициализировать ref struct значением default. Тогда все его ref поля будут null управляемыми указателями:

RefStructWithRefField s = default;
ref byte nullRef = ref s.refFld;

Однако существует несколько unsafe способов создать null byrefs. Примеры:

// Null byref путем прямого вызова Unsafe.NullRef:
ref object obj = ref Unsafe.NullRef<object>();

// Null byref путем превращения null неуправляемого указателя в null управляемый указатель:
ref object obj = ref Unsafe.AsRef<object>((void*)0);

Риск возникновения проблем с безопасностью памяти низок, и любая попытка разыменовать null byref приведет к четко определенному NullReferenceException.
Однако компилятор C# предполагает, что разыменование byref всегда успешно и не производит наблюдаемого побочного эффекта. Поэтому законной оптимизацией является удаление любого разыменования, результирующее значение которого не используется явно. См. dotnet/runtime#98681 (и этот связанный комментарий) для примера теперь исправленного бага в .NET, где код библиотеки неправильно полагался на то, что разыменование вызовет побочный эффект, не зная, что компилятор C# фактически удалил предполагаемую логику.

14. stackalloc

stackalloc исторически использовался для создания небольших, не "убегающих" (non-escaping) массивов в стеке, снижая давление на GC. В будущем Escape Analysis в JIT может начать оптимизировать не убегающие GC аллокации массивов в объекты стека (в .NET 10 в каком-то виде это уже происходит), потенциально делая stackalloc избыточным. До тех пор stackalloc остается полезным для выделения небольших буферов в стеке. Для больших или убегающих буферов он часто комбинируется с ArrayPool<T>.

15. Буферы фиксированного размера (Fixed-size buffers)

Буферы фиксированного размера были полезны для сценариев интеропа с источниками данных из других языков или платформ. Затем они были заменены более безопасными и удобными inline arrays.
Пример буфера фиксированного размера (требует контекста unsafe) — следующий фрагмент:

public struct MyStruct
{
    public unsafe fixed byte data[8];
    // Другие поля
}

MyStruct m = new();
ms.data[10] = 0; // Запись за пределы границ, неопределенное поведение.

Современная и более безопасная альтернатива — inline arrays:

[System.Runtime.CompilerServices.InlineArray(8)]
public struct Buffer
{
    private int _element0; // может быть generic
}

public struct MyStruct
{
    public Buffer buffer;
    // Другие поля
}

MyStruct ms = new();
ms.buffer[i] = 0; // Runtime выполняет проверку границ для индекса 'i';
ms.buffer[7] = 0; // Проверка границ опущена; известно, что индекс в диапазоне.
ms.buffer[10] = 0; // Компилятор знает, что это вне диапазона, и выдает ошибку компилятора CS9166.

Еще одна причина избегать буферов фиксированного размера в пользу inline arrays, которые всегда инициализируются нулями по умолчанию, заключается в том, что буферы фиксированного размера могут иметь ненулевое содержимое в определенных сценариях.

16. Передача непрерывных данных как указатели + длины

Избегайте определения API, которые принимают неуправляемые или управляемые указатели на непрерывные данные. Вместо этого используйте Span<T> или ReadOnlySpan<T>:

// Плохой дизайн API:
void Consume(ref byte data, int length);
void Consume(byte* data, int length);
void Consume(byte* data); // zero-terminated
void Consume(ref byte data); // zero-terminated

// Хороший дизайн API:
void Consume(Span<byte> data);
void Consume(Memory<byte> data);
void Consume(byte[] data);
void Consume(byte[] data, int offset, int length);

Zero-termination (завершение нулем) особенно рискованно, потому что не все буферы завершаются нулем, и чтение за пределами любого нулевого терминатора может привести к раскрытию информации, повреждению данных или завершению процесса из-за access violation.

17. Мутации строк

Строки в C# иммутабельны и любая попытка изменить их с помощью unsafe кода может привести к неопределенному поведению. Пример:

string s = "Hello";
fixed (char* p = s)
{
    p[0] = '_';
}

// где-то в другом месте
Console.WriteLine("Hello"); // печатает "_ello" вместо "Hello"

Изменение интернированной строки (все строковые литералы таковыми и являются, но и не литералы могут быть интернированы по разным причинам) изменит значение для всех других использований. Даже без интернирования строк, запись в только что созданную строку должна быть заменена на более безопасный API String.Create:

// Плохо:
string s = new string('\n', 4); // неинтернированная строка
fixed (char* p = s)
{
    // Копирование данных в только что созданную строку
}

// Хорошо:
string s = string.Create(4, state, (chr, state) =>
{
    // Копирование данных в только что созданную строку
});

18. Ручной IL код (например, System.Reflection.Emit и Mono.Cecil)

Вставка ручного IL кода (либо через System.Reflection.Emit, сторонние библиотеки, такие как Mono.Cecil, либо написание IL кода напрямую) по определению обходит все гарантии безопасности, предоставляемые C#.
Избегайте использования таких техник, т.к. по сути это самый опасный вид memory unsafe кода.

19. Неинициализированные локальные переменные [SkipLocalsInit] и Unsafe.SkipInit

[SkipLocalsInit] был введен в .NET 5.0, чтобы позволить JIT пропускать обязательное обнуление локальных переменных (в том числе stackalloc) в методах, либо для всего модуля. Эта фича часто использовалась, чтобы помочь JIT устранить избыточные инициализации нулями, например, для stackalloc. Однако это может привести к неопределенному поведению, если локальные переменные не инициализируются явно перед использованием. С недавними улучшениями в способности JIT устранять инициализации нулями и выполнять векторизацию, необходимость в [SkipLocalsInit] и Unsafe.SkipInit значительно снизилась.

20. ArrayPool.Shared и похожие пулы объектов

ArrayPool<T>.Shared — это общий пул массивов, используемый для снижения давления на GC в горячем коде. Он часто используется для выделения временных буферов для операций ввода-вывода или других короткоживущих сценариев. Хотя API прост и по своей сути не содержит unsafe функций, он может привести к багам use-after-free и double-free в C#. Пример:

var buffer = ArrayPool<byte>.Shared.Rent(1024);
_buffer = buffer; // объект буфера "убегает" из области видимости
Use(buffer);
ArrayPool<byte>.Shared.Return(buffer);

Любое использование _buffer после вызова Return является багом use-after-free. Этот минимальный пример легко заметить, но баг становится труднее обнаружить, когда Rent и Return находятся в разных областях видимости или методах.

21. Преобразования bool <-> int

Хотя стандарт ECMA-335 определяет Boolean как 0-255, где true — это любое ненулевое значение, лучше избегать любых явных преобразований между целыми числами и булевыми значениями, чтобы избежать введения "денормализованных" значений, так как что-либо, отличное от 0 или 1, вероятно, приведет к ненадежному поведению.

// Плохо:
bool b = Unsafe.As<int, bool>(ref someInteger);
int i = Unsafe.As<bool, int>(ref someBool);

// Хорошо:
bool b = (byte)someInteger != 0;
int i = someBool ? 1 : 0;

JIT, присутствующий в ранних средах выполнения .NET, не полностью оптимизировал безопасную версию этой логики (тернарку), что приводило к тому, что разработчики использовали unsafe конструкции для преобразования между bool и int в путях кода, чувствительных к производительности. Это больше не так, и современные JIT-ы .NET способны эффективно оптимизировать безопасную версию.

22. Интероп (Interop)

Хотя большинство предложений в этом документе применимы и к сценариям интеропа, рекомендуется следовать руководству Native interoperability best practices. Кроме того, рассмотрите использование автоматически генерируемых оберток интеропа, таких как CsWin32 и CsWinRT. Это минимизирует необходимость написания ручного кода интеропа и снижает риск внесения проблем с безопасностью памяти.

23. Потокобезопасность (Thread safety)

Безопасность памяти и потокобезопасность — ортогональные понятия. Код может быть безопасным с точки зрения памяти, но все же содержать гонки данных (data races), разорванные чтения (torn reads) или баги видимости; и наоборот, код может быть потокобезопасным, но при этом вызывать неопределенное поведение через unsafe манипуляции с памятью. Для более широкого руководства см. Managed threading best practices и .NET Memory Model.

24. Unsafe код вокруг SIMD/Векторизации

См. Vectorization guidelines для получения более подробной информации.
В контексте unsafe кода важно помнить:

Операции SIMD имеют сложные требования для обеспечения гарантий атомарности (иногда они их вообще не предоставляют).
Большинство API загрузки/сохранения SIMD не предоставляют проверок границ.

25. Предупреждения компилятора

Как правило, компилятор C# не предоставляет обширной поддержки (предупреждения и анализаторы) касающиеся некорректного использования unsafe кода. Однако существуют некоторые существующие предупреждения, которые могут помочь обнаружить потенциальные проблемы, и их не следует игнорировать или подавлять без тщательного рассмотрения. Примеры:

nint ptr = 0;
unsafe
{
    int local = 0;
    ptr = (nint)(&local);
}
await Task.Delay(100);

Этот код кидает ворнинг CS9123 ("The '&' operator should not be used on parameters or local variables in async methods"), что подразумевает, что код, вероятно, некорректен.

Полезные ссылки

What Every CLR Developer Must Know Before Writing Code — продвинутые темы про внутренности CoreCLR и GC.
Native interoperability best practices.
Managed threading best practices.
Best practices for exceptions.
Vectorization guidelines
.NET Memory Model
ECMA-335
ECMA-335 augments

Заключение

Большинство разработчиков никогда не столкнутся с проблемами описанными в этой статье если не используют unsafe код и не пишут интероп. Однако, это не защищает их от потенциальных проблем если одна из подключаемых библиотек использует unsafe код некорректно, т.к. такие баги очень сложно отловить и найти источник проблемы (например, double-free в ArrayPool внутри сторонней библиотеки). Если же вы используете unsafe код (unsafe/Unsafe/MemoryMarshal/Marshal и прочие) и что-то в этой статье показалось вам новым, лучше всего провести аудит всего unsafe кода в вашем проекте. Команда .NET Runtime планирует расширить понятие unsafe кода в будущих версиях .NET (например, многие API станут требовать unsafe контекст для использования).

Гайд: Как прострелить ноги unsafe кодом в C# +6

Глоссарий

Распространенные проблемы с unsafe кодом в C#

1. Неотслеживаемые управляемые указатели (Unsafe.AsPointer и его друзья)

Рекомендации

2. Раскрытие указателей за пределы области fixed

Рекомендации

3. Внутренние детали реализации среды выполнения и библиотек

Рекомендации

4. Невалидные управляемые указатели (даже если они никогда не разыменовываются)

Рекомендации

5. Приведения типов в стиле reinterpret_cast

Рекомендации

6. Обход Write Barrier и неатомарные операции над ссылками GC

Рекомендации

7. Предположения о времени жизни объектов (финализаторы, GC.KeepAlive)

Рекомендации

8. Доступ к локальным переменным из разных потоков

Рекомендации

9. Удаление проверок границ (bounds check)

Рекомендации

10. Объединение доступа к памяти (Memory access coalescing)

Рекомендации

11. Невыровненный доступ к памяти

Рекомендации

12. Бинарная (де)сериализация структур с паддингами или non-blittable членами

Рекомендации

13. Null управляемые указатели

Рекомендации

14. stackalloc

Рекомендации

15. Буферы фиксированного размера (Fixed-size buffers)

Рекомендации

16. Передача непрерывных данных как указатели + длины

Рекомендации

17. Мутации строк

Рекомендации

18. Ручной IL код (например, System.Reflection.Emit и Mono.Cecil)

Рекомендации

19. Неинициализированные локальные переменные [SkipLocalsInit] и Unsafe.SkipInit

Рекомендации

20. ArrayPool.Shared и похожие пулы объектов

Рекомендации

21. Преобразования bool <-> int

Рекомендации

22. Интероп (Interop)

23. Потокобезопасность (Thread safety)

24. Unsafe код вокруг SIMD/Векторизации

25. Предупреждения компилятора

Рекомендации

Полезные ссылки

Заключение

Комментарии (0)