В RISC-V намеренно оставлена дыра?
Основная моя претензия к 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".
#riscv #e2k #elbrsu #Эльбрус #ИБ #ИнформационнаяБезопасность #InformationSecurity