Проект TrapC развивает Си-подобный язык, безопасно работающий с памятью

На ассемблере должно обходиться, но специально я это не проверял.

Именно испортить указатель или через него получить доступ за пределами нельзя. Там аппаратная проверка. По ссылке подробно описано.

Вы не сможете добиться RCE в коде, что уязвим на других архитектурах. Так что свой код можно выполнить только имея доступ к shell.

Вот есть уязвимость в shell или в сервисе — это особой разницы не имеет. Сервисов много. Но то, что 90% векторов атак закрываются автоматически, заметно повышает общую безопасность.

Именно испортить указатель или через него получить доступ за пределами нельзя.

Если есть возможность сделать

uintptr_t i = p;
i += offset;
char *p2 = i;

то пофиг, какая там проверка.

Может, мы обсуждаем разные вещи. Для меня лично нет разницы на каком уровне реализована хэш-таблица. Язык, рантайм, либа – какая разница? Хэш-таблица и в Африке хэш-таблица.

Собственно, я не вижу каким образом отсутствие управления памятью вредит программам. Уже продолжительное время пишу на C и Go. Когда приходится заботиться о памяти, хотя мне не посчастливилось встретиться с этой проблемой, нужно оперировать понятиями GC. Можно считать это абстракцией, с присущими ей достоинствами и недостатками, как у любой абстракции.

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

Эти указатели не совместимы со стандартом Си. Можно сконвертировать указатель в intptr, но нельзя обратно.

Поэтому, например, нельзя сделать выравнивание указателя вот так:

p = (char*)(((intptr_t)p + 15) & ~15);

Нужно так:

p += -(intptr_t)p & 15;

Эти указатели не совместимы со стандартом Си.

Ясно.

Вот пример:

printf("%zu, %zu\n", sizeof(void*), sizeof(intptr_t));

В режиме с защищёнными указателями теневая часть указателя не переводится в intptr.

16, 8

это(большая безопасность за счёт аппаратных «издержек») преимущество «неуловимого Джо»

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

само по себе тегированное железо не новость но в первом мире оно маргинально :)

былы времена когда не только функции в библиотеках но и сама машинерия «вызова» функции это кодовые вставки из «библиотек» (например железки где нет стека а организация кода полностью прерогатива софта)

зачем быть таким прибитым к «одной единственно верной» реализации?