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

Такому аллокатору не нужна ни стдлиб, ни куча. Нужен отдельный от стека блок памяти, по типу tread local storage.

> Я так понимаю что идея что идея такая что в heap выделяется
> несколько больших блоков по возможности. Если там что-то иное, будет фрагментация
> памяти, и в хучшем случае довольно серьезный факап перфоманса и оверхед.

Нет дефрагментации, поскольку деаллокация происходит при выходе из области видимости точно так как сейчас со стеком.

>> а потом обвиняют язык в исполнении постороннего кода.
> Эм... ну был бы не stack based overflow а heap based, сильно
> бы полегчало?

Там нет адресов возврата.

> Алсо в современных тулчейнах и сборках стэк обычно NX
> и это напрямую уже неэксплойтабельно.

Это исключает исполнение кода на стеке, но не перезапись адреса возврата и исполнение ROP-цепочек.

>[оверквотинг удален]
> кода зависит.
>> Даже в IA32 с традиционной  адресацией через EBP достаточно просто разделить
>> стеки данных и вызовов.
> Я не знаю детали микроархитектуры IA32 _настолько_ чтобы прикинуть факапы с этого.
> Как минимум мы там точно не хотим чтобы обращение в стек
> было реальным доступом в реальный адрес RAM, т.к. скорость немедленно станет
> полным ацтоем. У этих красавцев видите ли есть хардварный буфер на
> стек как я помню, выделенный для именно этой роли, чтобы это
> все максимально быстро и похоже на clock-freq проца по скорости было.
> Насколько вон то попортит эту механику черт его знает, вам виднее.

На Intel адреса возвратов аппаратно «кешируется» отдельно от данных, которые пишутся рядом с ними в память стека.

>[оверквотинг удален]
> проца где это надо, где mov не поможет. У x86-64 такой
> пересмотр ABI тоже вроде сделали. Классическому x86 это ессно не грозило
> из-за убогого набора регистров. Да и за адресацию он должен умереть
> - relative он не умеет толком, так что вон там какие
> чудесные костылищи с релоками полпрограмы весом ему вбили, чтобы адресное пространство
> хотя-бы не было предсказуемым. А то видите ли предсказуемый выбор целей
> сильно результативнее для атак. Ну и вон там оптимизатор тоже как
> видим линеаризовал факториал до вида когда не надо ему никакого стека.
> Оно это вообще умеет, делая иногда мягко говоря совсем не тот
> код который можно было бы подумать.

Аргументы передаются через регистры, но автоматические переменные - это то что в тебе блока.