Вмёржили.

Zig's New Async I/O

#upstream #блоги

спасибо китайцам за новую аву

вернул старую, чет не зашло никому

Ищу коллегу, пишущего на зиге для реализации одного из проектов. Подробности расскажу в созвоне, как и условия работы

через 15 минут будут рассказывать ещё про async https://www.twitch.tv/kristoff_it

Уже началось

Resizable structs in Zig

VLA на зигушках

#блоги #библиотеки

[RFC] Upstream target support for CHERI-enabled architectures - LLVM Project

Если Zig хочет поддерживать эту архитектуру и быть настолько же кросс-платформенным, как Си, придётся парочку вещей подправить:

CHERI заменяет указатели на capability-объекты, которые не являются целыми числами и не могут быть подделаны. Это нарушает исторически сложившиеся предположения в Clang и LLVM о том, что указатели могут быть без потерь преобразованы в целые числа и обратно. Это также касается обхода системы типов через память.

Если простыми словами, @intFromPtr и @ptrFromInt на этих архитектурах не будет работать, и usize с isize надо переделывать на них

Во общем, что это такое. Для начала, CHERI расшифровывается как Capability Hardware Enhanced RISC Instructions, поэтому чтобы понять суть, нужно начать с Capability:

Capability a.k.a возможности это особые маркеры, которые определяют, к каким ресурсам можно получить доступ и какие действия с ними разрешены.

CHERI использует эти capability, чтобы контролировать доступ к памяти на компьютере. Они реализованы в железе (поэтому hardware enchanced), в виде расширения для архитектур процессоров (ARM, RISC-V, x86 и т.д.), которое заменяет обычные указатели такими capability (поэтому RISC instructions)

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

В CHERI, capabilities содержат в себе не только адрес, но и права, границы и специальная метка, которая проверяет целостность. Это всё занимает память, поэтому на 64-битных архитектурах указатель занимает не 64 бит, а 128 бит (здесь лоомается usize)

Можно заметить, что он похож на супер-слайс/срез как в Zig, который тоже содержит в себе границы (длину в случае Zig). В коде это можно представить так:

const Slice = struct(u128) {
    address: u64,
    len: u64,
}

const Capability = struct(u128) {
    address: u64,
    metadata: struct(u64) {
        permissions: ... // bitfield,
        type: ... // enum или boolean
        bounds: ... // специальной свой мини-float
    }
}

Теперь что делают эти capability: они проверяют на уровне процессора все доступы, сделанные через них, и разрешает только явно прописанные действия.

К примеру, доступ по индексу к слайсу имеет проверку в рантайме, которая проверяет на out of bounds:

const a: []const u8 = ...;
const b = a[1000]; // panic если вышел за диапазон

Я думаю, многим из вас эта проверка помогла найти какой-то баг в коде и т. д. Однако, у нашего варианта есть минусы:
* Она работает только в ReleaseSafe, Debug и функциях с setRuntimeSafety(true)
* Она проверяется программно, с дополнительной нагрузкой на производительность
* Её очень легко обойти

В CHERI:
* Её невозможно обойти.

Я не показал в struct, но на картине видно, что дополнительно к каждому указателю хранится тег в отдельной памяти, который проверяет целостность. Если указатель изменили неправильно или "подделали" (к примеру рандомное число превратили в адрес), он заблокирует любой доступ по этому указателю и вернет аппаратную ошибку.

* Она проверяется на уровне железа, с очень маленькой нагрузкой на производительность

* Она работает везде, для всех языков и с большой точностью, будь то Си, Zig, unsafe Rust, Python, и т.д.

К примеру точности, в Zig можно сделать слайс и указать, к примеруадрес 100 и длину 10, т.е. можно использовать память с 100 по 110 байт.

В CHERI можно сделать указатель с таким же длмной, плюс добавить, к примеру, права только на чтение. Любое изменение черезу казатель блокируется процессором

К тому же, так как эти capability работают на уровне системы, они защищают всю память: не только ОЗУ, но и к примеру порты или регистры или стек.