> А мне интересно, почему компиляторы автоматические переменные пихают в стек,Насколько я понимаю - потому что это быстрее и без ряда дурных проблем. Ну то-есть разворачивать механику аллокатора на кучу всякой мелочи которую обычно в стек предлагается пихать - сильно убьет скорость. К тому же аллокатор - где то там в жирном стдлибе. А ее может и не быть. И тогда вообще как?
Я так понимаю что идея что идея такая что в heap выделяется несколько больших блоков по возможности. Если там что-то иное, будет фрагментация памяти, и в хучшем случае довольно серьезный факап перфоманса и оверхед.
> а потом обвиняют язык в исполнении постороннего кода.
Эм... ну был бы не stack based overflow а heap based, сильно бы полегчало? Алсо в современных тулчейнах и сборках стэк обычно NX и это напрямую уже неэксплойтабельно.
ЧСХ это все ловить железом в принципе можно, скажем, redzones, вплоть до страницы без доступа после объекта, но не халявно по оверхеду уж очень. А вон там ubsan довольно много чего умеет ловить даже не очень дорого, но все равно не халявно и очень от кода зависит.
> Даже в IA32 с традиционной адресацией через EBP достаточно просто разделить
> стеки данных и вызовов.
Я не знаю детали микроархитектуры IA32 _настолько_ чтобы прикинуть факапы с этого. Как минимум мы там точно не хотим чтобы обращение в стек было реальным доступом в реальный адрес RAM, т.к. скорость немедленно станет полным ацтоем. У этих красавцев видите ли есть хардварный буфер на стек как я помню, выделенный для именно этой роли, чтобы это все максимально быстро и похоже на clock-freq проца по скорости было. Насколько вон то попортит эту механику черт его знает, вам виднее.
> Одно время Intel даже рекомендовала заменять push/pop на mov, ради ускорения.
А в какой-то момент сделал какой-то выделеный костыль в виде буфера стека, чтобы он супербыстро работал. У ARM в этом смысле некоторые вещи логичнее, если аргументов и переменных немного они через регистры идут и там стека как такового может и не юзаться, кроме сохранения/восстановления состояния проца где это надо, где mov не поможет. У x86-64 такой пересмотр ABI тоже вроде сделали. Классическому x86 это ессно не грозило из-за убогого набора регистров. Да и за адресацию он должен умереть - relative он не умеет толком, так что вон там какие чудесные костылищи с релоками полпрограмы весом ему вбили, чтобы адресное пространство хотя-бы не было предсказуемым. А то видите ли предсказуемый выбор целей сильно результативнее для атак. Ну и вон там оптимизатор тоже как видим линеаризовал факториал до вида когда не надо ему никакого стека. Оно это вообще умеет, делая иногда мягко говоря совсем не тот код который можно было бы подумать.
