Проект 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

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

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

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

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

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

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

Проверил. В user-mode нельзя скрафтить произвольный указатель. Зато можно получить указатель на все статические данные текущей программы (которая приложение, про библиотеки не знаю). Если в статических данных хранятся какие-то ключи, то к ним можно получить доступ. Но традиционные способы получить RCE закрыты. Поэтому я не вижу способов это эксплуатировать.

Круто.

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

Так статические данные и так всем доступны. А уже на стеке просто так указатель не получить.

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

Это, мягко говоря, спорное утверждение.

А с каким утверждением спорите? В том сообщении их много.

Вы считаете, что сложность языка определяет способ записи его конструкций ?

Смотря что понимать под словом «сложность». Сложность изучения часто зависит от способа записи конструкций. Например, конструкции Haskell и APL сходу сложно выучить. В отличие от конструкций BASIC, например.

А сложность языка в смысле семантики, разумеется, от конструкций не зависит. И даже сложность восприятие конструкций достаточно субъективна. Кому-то хорошо читается COBOL, кому-то APL.

Конструкции хаскеля определённо проще конструкций бейсика.

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

Совместимы.

Вот это выполняется:

The following type designates a signed integer type with the property that any valid pointer to void can be converted to this type, then converted back to pointer to void, and the result will compare equal to the original pointer:

Только после «converted back to pointer» по ним нельзя объект читать.

Стандарт разрешает блокировать указатели из чисел: «An integer may be converted to any pointer type. Except as previously specified, the result is implementation-defined, might not be correctly aligned, might not point to an entity of the referenced type, and might be a trap representation.».

Конструкции хаскеля

Назови хоть один оператор бейсика, сравнимый по сложности объяснения с >>=.

the result is implementation-defined

Интересненько. Спасибо за уточнение.

#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
 
int main() {
  int *p = (int*)malloc(sizeof(int));
  intptr_t c1 = (intptr_t)p; 
  int *k = (int*)realloc(p, sizeof(int));
  intptr_t c2 = (intptr_t)k;
  *k = 2;
  if (c1 == c2) {
    *(int *)c1 = 1;
    printf("%d %d\n", *(int *)c1, *(int *)c2);
  }
}

Выводит 1 2 на clang. Хотя тут формально даже UB нет: к p я после realloc не обращаюсь, по адресу из c1 пишу после того, как убедился, что он указывает на k (равен c2).

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

Хотя тут формально даже UB нет

Есть:

The original pointer ptr is invalidated and any access to it is undefined behavior (even if reallocation was in-place).

https://en.cppreference.com/w/cpp/memory/c/realloc

так себе попытка.

оказывается в Python массив называется list

Это не массив.

Не надо путать список и связный список это не одно и тоже.

похоже на подход в html5

Так к p нет доступа после строки

int *k = (int*)realloc(p, sizeof(int));

Могу даже так переписать, чтобы даже области видимости не было:

#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
 
int main() {
    intptr_t c1;
    int *k;
    {
        int *p = (int*)malloc(sizeof(int));
        c1 = (intptr_t)p; 
        k = (int*)realloc(p, sizeof(int));
    }
    intptr_t c2 = (intptr_t)k;
    *k = 2;
    if (c1 == c2) {
        *(int *)c1 = 1;
        printf("%d %d\n", *(int *)c1, *(int *)c2);
    }
}

А с каким утверждением спорите? В том сообщении их много.

С тем что использование похожего синтаксиса существенно упрощает освоение нового языка.

Смотря что понимать под словом «сложность». Сложность изучения часто зависит от способа записи конструкций.

Если не рассматривать какие-то патологические примеры, то не зависит. Главное это семантическая нагрузка. Если она другая, то похожие конструкции только будут вводить в заблуждение, во всяком случае сначала.

Зато к c1 есть обращение, который оптимизатором определяется как алиас на p.

который оптимизатором определяется как алиас на p.

c1 - это число. Где в стандарте указывается алиасинг для чисел?

Могу так сделать

#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
 
int main() {
    intptr_t c1;
    int *k;
    {
        int *p = (int*)malloc(sizeof(int));
        c1 = (intptr_t)p; 
        k = (int*)realloc(p, sizeof(int));
    }
    intptr_t c2 = (intptr_t)k;
    intptr_t x = c1 + 5;
    intptr_t y = x - 5;
    *k = 2;
    if (y == c2) {
        *(int *)y = 1;
        printf("%d %d\n", *(int *)y, *(int *)c2);
    }
}

y – это число, полученное путём некоторых арифметических операций из числа c1 и равное c2. Но всё равно объект, полученный из указателя, полученного из этого числа не тот, который получается из равного ему числа c2.

c1 - это число. Где в стандарте указывается алиасинг для чисел?

Ну тут оптимизатор сам себя перехитрил, я думаю. Логика его тут понятна. А вот насколько она обоснована, это вопрос…

Но «the result will compare equal to the original pointer» выполняется. (int *)y == k.

Стандарт разрешает из одинаковых чисел получать указатели на разные объекты. Или вообще неработающие указатели. Оптимизатор пользуется.

Не надо смешивать список как АТД и список как структуру данных.

Так и я о том. В Python конструктор list() создаёт другую структуру данных. Не список.

FOR .. TO .. STEP .. NEXT

8 страниц, а про address-sanitizer ни слова

это очень фрактальнная ситуация

и python( в прочем как и любая открытая(по сырцам){конкретнее обозримая и в пределах «5+-2» постигаемая система<антитеза немыслимой/по Биру Стафарду>}система})

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

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

али полный спектр охватывающий(и возможно не ограниченый) вышеприведённые 'крайности'

ps. инструментализация(и экспоненциальный рост о общей вычь моще) позволяет использовать в качестве нотации ваще любую произвольную «достаточно полную» 'систему указаний действий и хранения данных и их обмена'

А уже на стеке просто так указатель не получить.

Эти указатели не защищают от Use-After-Free, достаточно аллоцировать много памяти, записать указатели, освободить память. А указатели останутся корректными, по ним можно получить доступ к уже чужим данным. То же самое со стеком, выделить много стека, запомнить указатель, освободить стек, теперь по указателю у нас есть окно. Впрочем, памяти много и можно выделять всегда в разных местах. И насчёт стека я не уверен, может там еще какие-то защиты понатыканы, тем не менее, указатель будет корректный.

см

https://tinlizzie.org/IA/index.php/Alan_Kay_at_OOPSLA_1997:_The_Computer_Revo...

лаг по времени между Кнутовым литературным программированием и распространением ещё даже не в индустрии Jupyter блокнотов (ipython не подходящее имя :( )

полезно переодически пробегать глазами:

https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.pdf

ради понимания что на одном и том тексте совсем разное вчитывается как функция уровня читающего :)

The Real Computer Revolution Hasn't Happened Yet

;(

https://tinlizzie.org/IA/index.php/The_Computer_Revolution_Hasn't_Happened_Ye...

Учить полгода Rust вместо использования уже знакомого Си мало кто будет, легче взять TrapC.

Абсолютно согласен. Мало того, я лично руками и ногами за такой язык. Как-то у меня давно прошли времена, когда лихо гусарствовал с адресами на Си и PDP-11/VAX макроассемблере. Как-то хочется спокойно и без лишних нервов нужные утилиты покод(ж)ивать.

Как только задача чуть меняется, тебе нужно реализовывать ту же хэш-таблицу немного по другому. Но менять стандартную реализацию ты не можешь. Начинаешь вешать костыли, в ущерб читаемости и производительности.

Как-то хочется спокойно и без лишних нервов

на Си

Ловите наркомана!

Если не страивает стандартная реализация просто пишешь свою. В чем проблема-то?

Из глубин интернетов пишут:

I don’t use C cause it’s «fast». I use it cause it’s Simple (Simple != Easy). If you dismiss the Simplicity Argument with «I’d sAcRiFiCe sPeEd fOr cOnVeNiEnCe» you are a moron who can’t listen and should not be taken seriously (too many such cases). If I needed speed I’d use Rust

Атаку такого вида сложно сделать. Фактически, для этого уже нужна возможность исполнить на атакуемой машине произвольный код.

Там это: https://www.opennet.ru/opennews/art.shtml?num=62241

Fil-C - компилятор для языков C и C++, гарантирующий безопасную работу с памятью

На текущем этапе развития, собираемые в Fil-C программы медленнее примерно в 1.5-5 раз, по сравнению со сборкой обычными компиляторами. В планах заявлена работа по проведению оптимизации. Предполагается, что после завершения этой работы в большинстве случаев код будет выполняться медленнее в 1.2 раза, а в наихудших сценариях замедление не превысит полтора раза.

Хмм. С такими показателями лучше писать на Расте.

Ещё хуже:

Другим ограничением Fil-C является принципиальный отказ от сохранения совместимости на уровне ABI для кода на C/C++, что не позволяет связывать собираемый в Fil-C код с библиотеками и объектными файлами, собранными другими компиляторами. Методы вызова функций и способ динамического связывания в Fil-C отличается от существующих компиляторов и компоновщиков. Подобное решение объясняется тем, что при связывании с незащищённым кодом теряется суть предлагаемой в Fil-C защиты и возникает иллюзия защищённого приложения - при наличии совместимости ABI, у разработчиков возникал бы соблазн собрать в Fil-C лишь отдельные файлы, не утруждая себя портированием всего проекта.

бывший профессор компьютерных наук

Сдулся склифасовский.

лучше писать на Расте.

Ловите наркомана!

лучше писать на Расте

Говорила сестрица Алёнушка братцу Иванушке:

- Не пиши, братец, на Расте, небинарной личностью станешь!