> RISCV поддерживается опенсорсными тулчейнами и уже есть поддержка нескольких SoC в майнлайне.
> Очень способствует уверенности в светлом будущем архитектуры.Как уже много раз писал, RISC-V прекрасен для своего первоначального предназначения (простых встраиваемых применений типа стиралок и кофеварок, но не путать с IoT).
А дальше начинает фигня, напомню: Как у "чистого риска" нет явного указателя стека и какой-либо защиты стека.
При этом ABI вроде-бы входит в спеку архитектуры и предусматривает распределение регистров.
Поэтому де-факто имеет один стек, где данные смешаны с адресами возврата, плюс "опенсорсные тулчены" которые иначе не умеют, плюс весь системный софт где это захардкожено.
В результате "новая перспективная архитектура" принципиально уязвима для ROP как относительно дремучие x86, ARM и т.п.
Ниже копипаста по этой теме.
---
Основная моя претензия к RISC-V в том, что в новой "допеределенной" архитектуре сохранено всё необходимое для эксплуатации ошибок "выход за пределы буфера на стеке" и ROP.
Отдельная тонкость в том, что в RISC-V (и традиционно во всех "берклиевских рисках") нет аппаратного стека в явном виде "как в x86", а стек фактически определяется в ABI - можно поменять соглашение об использовании регистров (занять ещё один под указатель второго стека), и проблемы не будет.
Поэтому получается, что непосредственно у самих ЦПУ на базе RISC-V на уровне аппаратуры более-менее хорошо, как минимум по этому вопросу. А все проблемы на стороне ПО. Однако, если посмотреть на RISC-V как на "экосистему", то она "одностековая", причем соглашение об использовании регистров прописано в спецификации ISA.
Решить проблему действительно можно сменой ABI, но если это не начать делать «вчера», то будет как с x86 (конечно, не совсем так, но снежный ком будет расти). Но кто и как это будет делать не понятно. Точнее говоря, уже понятно что разработчики ПО уже поставлены перед выбором:
- либо отказаться от готовой инфраструктуры и самим "пилить" все задачи связанные с изменением ABI (от доработки компиляторов до перепортирования софта);
- либо всеми силами не замечать проблему, и убеждать себя и всех и что её нет.
Очевидно что RISC-V тут не более дырявый чем остальные архитектуры с одним стеком. Однако:
1) разделение стеков существенно уменьшает вероятность/риски эксплуатации ошибок переполнения буферов размещенных на стеке.
2) своевременное лечение проблемы даже "в лоб" было-бы почти бесплатным, как по затратам, так и по быстродействию (занимаем еще один регистр из 31).
3) в RISC-V ISA для инструкций JAL и JALR явно специфицированы автоматическое выполнение push/pop в RAS (return-address stack), т.е. «уши» аппаратного стека всё-таки торчат, но и нет проблем отделить RAS от SP с данными.
4) ничего не сделано, а напротив сформировано сугубо одностековое ABI и инфраструктура.
Суммарно получается: что есть дыра, которую точно следовало-бы заткнуть, была возможность сделать это бесплатно, но дыра бережно сохранена и сделано всё, чтобы затруднить её устранение = это у меня вызывает озабоченность, особенно когда предлагают заменять "неперспективные Эльбрусы" на "прогрессивные RISC-V".
