> https://vk.com/@erthink-risc-v
> https://d-russia.ru/otkrytaja-haljava-i-besplatnyj-syr.html#...
> Чуть позже допишу в ответах здесь.

Спасибо!

Процитирую твои комментарии под http://d-russia.ru/otkrytaja-haljava-i-besplatnyj-syr.html#c... для ещё одной архивной копии "как есть":

---

Леонид Юрьев (Advanced Research @ Positive Technologies) 02.09.2021 в 01:38
Абсолютно точно сформулировано и хорошо изложено. Готов подписаться под каждым абзацем. Как специалист от себя хочу добавить/усугубить пару тезисов в адрес RISC-V:

1. В RISC-V нет ничего хорошего/перспективного при выходе за рамки ниши микроконтроллеров и устройств класса IoT.
Фактически RISC-V — это недопеределанная система команд по мотивам MIPS для применения в простых, низкопроизводительных и дешевых процессорах. За ~10 лет развития можно было-бы ожидать лучшей проработки с меньшим объемов недостатков. Тем не менее, эта ISA (система команд) достаточно неплоха для исходно задуманного назначения — в кофеварках и стиральных машинах.

Однако, если же на основе ISA RISC-V пытаться делать универсальный высокопроизводительный процессор, то почти все ухищрения системы команд RISC-V начнут работать в минус. Конечно, всё это можно преодолеть как в случае с x86 — пройдя путь AMD/Intel и смирившись с уязвимостями класса Spectre/Meltdown, либо просто ограничиться размножением относительно медленных ЦПУ-ядер в одном корпусе, сделав этим принципиально невозможными часть стратегических вариантов использования таких ЦПУ.

2. Реальное преимущество RISC-V только в том, чтобы не делать свой инструментарий кодогенерации и почти не заниматься каким-либо портированием программного обеспечения.
Но здесь есть и обратная сторона — пересаживаясь на готовые решения неизбежно теряешь собственные компетенции и возможность выбора в дальнейшем. Собственно это хорошо освещено в самой статье выше.

3. У RISC-V плохо с безопасностью (поверхностью атаки), а в сравнении с «Эльбрусами» — плохо кошмарно, принципиально и неустранимо. В RISC-V бережно сохранены все слабые места: общий стек для адресов возврата и данных, фон Неймановская (не Гарвардская) архитектура (общая униформная/нетегированная память для команд, данных и стека), коды команд с возможностью эксплуатации ROP-цепочек. Кроме этого, для достижения высокой производительности предполагается использование внеочередного и спекулятивного исполнения инструкций, что (мягко говоря) закладывает фундамент для уязвимостей класса Meltdown/Spectre/L1TF/ZombieLoad и т. п., включая такие потенциально скрытые «дыры» как CVE-2020-12965.

Поэтому попытки, в перспективе, ведущие к использованию RISC-V вместо «Эльбрусов» в критических применениях я расцениваю как вредительство, а умышленное или по-глупости — пусть разбирается следствие.

Леонид Юрьев (Advanced Research @ Positive Technologies) 09.09.2021 в 18:35
Я пришел к выводу, что моя позиция требует подкрепления некоторыми техническими аргументами/пояснениями:

1. Эксплуатация Spectre/Meltdown требует локального доступа. А на Эльбрусах дополнительно еще и возможности конструировать нативный исполнимый код (в памяти или в файлах), так как JIT-ов примерно нет.

2. Уязвимости связанные с выходом за пределы буфера и использованием ROP могут эксплуатировать удаленно достаточно часто. Но на Эльбрусах вероятность их эксплуатации кардинально ниже из-за двойного стека. Причем это без учета возможности использования защиты «тегами», которая может быть использована только в процессах подверженных рискам атаки.

3. Соответственно, на Эльбусах относительно легко защититься от Spectre/Meltdown просто адекватным системным администрированием (например, хотя-бы убрать компиляторы и запретить взводить eXecute бит у файлов). Вероятность же удаленной эксплуатации Spectre/Meltdown через ROP стремиться к нулю. Причем всё это без учета противодействия атакам Spectre/Meltdown со стороны ядра ОС.

Поэтому, я действительно вижу отдельные недостатки, но не вижу принципиальных проблем с безопасностью Эльбрусов, особенно в сравнении с x86, ARM, MIPS и болен-RISC (aka RISC-V).

Леонид Юрьев (Advanced Research @ Positive Technologies) 17.09.2021 в 02:38
Продолжают поступать вопросы и просьбы дать более аргументированные объяснения, в том числе упреки в неподобающем отношении и непонимании устройства RISC-V, враждебности к открытым технологиям, лоббировании интересов МЦСТ и т. п. Поэтому порция ответов и разъяснений по теме RISC-V.

1. О Болден-RISC.
Что касается моего выражения «Болден-RISC» в отношении RISC-V, то в этой шутке есть доля правды. Конечно, с одной стороны, хорошо что есть открытые ISA (Instruction Set Architecture, Архитектура набора команд и/или Спецификация архитектуры процессора за вычетом аппаратных составляющих), IP (Intellectual Property, сложнофункциональные блоки специфицированные на языке описания аппаратурыVerilog, VHDL и т.п) и целые открытые готовые ядра ЦПУ. Но нас ждет «зоопарк ядер» не меньший чем «зоопарк дистрибутивов» Linux, и проблема зависимостей, как по IP, так и по программному коду.

Открытость ISA, расширяемость и доступность готовых IP, приводит к появлению массы как стартапов, так и отделов разработки собственных ЦПУ со «стартаперским духом» — когда важно быстро-быстро показать первый результат, а какие-то неудобные вопросы/проблемы замести под ковер с обещанием «потом всё порешаем, когда доплывём».

Среди таких вопросов — небезопасность RISC-V. Конечно RISC-V нельзя назвать более дырявым чем другие ISA в своих сегментах. Но для меня несколько странно/неожиданно, что в RISC-V бережно сохранено всё необходимо для эксплуатации всех традиционных ошибок/дыр (см далее).

Да, пожалуй, у меня есть определенное «профессиональное искажение». Тем не менее, свободно-бесплатная раздача ISA и ядер с явными (сохраненными) проблемами с безопасностью — всё-таки начинает выглядеть как сыр в мышеловке.

При этом я (пока) не встречал человека на позиции ЛПР, который-бы понимал все сложности и проблемы связанные с управлениями вышеназванными зависимостями, уже планировал бизнес-процессы и жизненный цикл устройств/продукции с учетом необходимости отслеживания ошибок/проблем/уязвимостей и (соответственно) необходимости обновлений и замены/отзыва проблемных устройств.

Так вот, совокупность всего вышеописанного, вместе с создаваемым хайпом, позволяю себе называть «Болден-RISC».

—

2. Об упреках в беспочвенности критики «одного стека» RISC-V.

Суть в том, что в RISC-ах в явном виде в аппаратуре нет стека «как на x86». Стек специфицируется/реализуется на уровне ABI (Appication Binary Interface) посредством назначения ролей регистрам и соглашения о вызове функций, а инструкции push, pop, call и ret отсутствуют на уровне аппаратуры в явном виде и являются макросами и/или псевдоиструкциями. Программное обеспечение может реализовать поверх ISA один, два или сколько угодно стеков. Поэтому предъявлять претензии к набору команд RISC-V по поводу одного стека необоснованно — вроде-бы всё верно, но…

Собственно говоря, программно реализовать два стека, т.е. отделить данные (и потенциально уязвимые буфера на стеке) от адресов возврата, можно на всех архитектурах (имеющих косвенную адресацию), включая x86, ARM, MIPS и т.д. Принципиально ничего невыполнимого нет (но будут нюансы), разница только в объеме накладных расходах, трудоёмкости реализации и (не)привязке к возможностям и/или контролю аппаратуры.

Если возможно программно реализовать два стека на чуть менее чем любой архитектуре ЦПУ и это, прежде всего, связано со сменой ABI, то «количество стеков» — это атрибут ABI? Либо ABI (может именно этот аспект) является какой-то значимой частью архитектуры как экосистемы?

Говоря что у RISC-V один стек, я знаю о возможности его разделить сугубо программно сменой ABI. Однако, если смотреть на «экосистему архитектуры» RISC-V:

— Представлен только «одностековый» вариант ABI и всей экосистемы;

— Явно определено reg(sp) == reg(x2), push/pop в/из RAS для jalr;

— Нет упоминания о втором sp для передачи большого кол-ва аргументов и хранения локальных данных, отдельно от RAS;

— Для разделения стеков требуется специфицировать ABI, поправить компилятор(ы)/toolchain и доперепортировать софт.

Поэтому я критикую RISC-V как одно-стековую архитектуру подверженную ROP: не предусмотрено какое-либо разрешение/запрещения переходов/возвратов к командам, нет само-синхронизации кодирования команд переменной длины.

С другой стороны, на x86 тоже можно сменить ABI, разделить стек, многократно снизив этим риск эксплуатации уязвимостей. Подобное разделение приведёт к некоторой потери плотности кода, в основном из-за заметы push на mov [reg + offset] при подготовке/передачи аргументов. Но для рынка это давно табу из-за слома совместимости и необходимости допиливать тонны софта.

AMD разрабатывали AMD64 как расширение ISA более 20 лет назад, думая о time-to-market и минимизации непохожести с x86_32. Ожидаемо, что тогда не думали про два стека. Но с RISC-V принципиально иначе: потеря эффективности минимальная (занимаем один регистр), а слома ABI вообще могло не быть.

Поэтому мне не ясны (не очевидны) причины, по которым для RISC-V специфицировано только «одностековое» ABI и «бережно сохранено всё необходимое для ROP и эксплуатации традиционных ошибок выхода за пределы буфера на стеке».

Более того, на эту ситуацию стоит посмотреть под другим углом:

— Для разделения стеков адресов возврата и данных в RISC-V не требуется что-либо менять на уровне системы команда или аппаратуры. Поэтому, даже если «одностековость» будет признана регулятором как проблема безопасности, то не будет повода в чем-либо упрекнуть разработчиков и производителей ЦПУ на основе RISC-V, а отдуваться придеться разработчикам ПО.

— А со стороны разработчиков ПО это выглядит так: либо отказаться от «готовой открытой инфраструктуры с поддержкой сообщества», менять ABI, своими силами создавать альтернативный инструментарий и дорабатывать/портировать ПО, либо пытаться убедить себя и всех, что риски незначительны и никаких проблем с безопасностью нет…

—

По-хорошему нужно следовать принципу «критикуешь — предлагай». Поэтому я постараюсь подготовить статью по мотивам всех подобных комментариев, но уже с предложениями по созданию альтернативной защищенной архитектуры на основе RISC-V.

---