Vladimir Karantaev/personal channel

Spectre приходит в RISC‑V
Долгое время микроархитектурные атаки семейства Spectre воспринимались прежде всего как проблема мира x86 и Arm. Это было объяснимо: именно на этих платформах спекулятивное исполнение стало стандартным механизмом повышения производительности — и одновременно источником утечек, которые возникают «между строк» выполнения программы.
Новая работа Spectre on RISC‑V Silicon: Attacks and Defenses on Commercial Out-of-Order Processors показывает, что RISC‑V больше нельзя считать сторонним наблюдателем этой истории.
Ранее исследования Spectre для RISC‑V почти полностью были сосредоточены на открытых академических ядрах. Теперь объектом анализа стали коммерчески доступные out-of-order процессоры — SiFive P550 и T‑Head Xuantie C910/C920. Авторы системно проверили 13 конфигураций атак и подтвердили уязвимость к основным вариантам Spectre: PHT, BTB, RSB и STL.
Особенно показателен не сам факт уязвимости, а её практическое измерение. Исследователи продемонстрировали сценарий, в котором через BPF можно извлекать данные из памяти ядра Linux. Иными словами, речь идёт не о теоретическом свойстве модели процессора, а о воспроизводимом риске для реального аппаратного и программного стека.
Главный урок статьи состоит в том, что безопасность спекулятивного исполнения нельзя «добавить» на одном уровне. Она должна строиться как система:
На уровне ISA необходимы ясные, стандартизированные механизмы управления спекуляцией.
На уровне микроархитектуры нужны проверяемые свойства предикторов, буферов и других shared resources.
Компиляторы должны уметь корректно генерировать защитные конструкции.
Операционные системы — применять их в критических путях ядра.
Разработчики платформ и приложений — учитывать реальную конфигурацию процессора и firmware, а не только название ISA.
Сегодня в RISC‑V нет стандартизированного барьера спекулятивного исполнения с архитектурной гарантией. Обычный fence упорядочивает обращения к памяти, но не обещает остановить speculative execution. Это важное различие: защита, которая работает на одном ядре, не обязана работать на другом.
Статья также напоминает, что зрелые механизмы защиты из x86 и Arm нельзя переносить в RISC‑V механически. Retpoline, compiler hardening, kernel barriers и BPF JIT требуют самостоятельной адаптации, тестирования и, в некоторых случаях, переосмысления.
Хорошая новость в том, что это уже не просто диагностированная проблема. В RISC‑V International действует рабочая группа по speculation barriers, которая занимается созданием архитектурно определённого механизма ограничения спекулятивного исполнения — с понятной семантикой, тестами и поддержкой в системном ПО.
По мере того как RISC‑V входит в облака, телеком, IoT и другие security-critical среды, вопрос звучит уже не так: «Подвержен ли RISC‑V Spectre?»
Гораздо важнее другой: «Готовы ли мы проектировать и защищать RISC‑V системы с учётом этой реальности?»
Статья:
https://www.usenix.org/conference/usenixsecurity26/presentation/gerlach
Рабочая группа RISC‑V International:
https://riscv.atlassian.net/wiki/spaces/SXXX/pages/272629762/Speculation+Barriers+-+Proposal+of+Work

#RISCV
Посмотрел воркшоп “Hands-on Introduction to CHERI” (RISC‑V Summit Europe 2026, Hardware track).
Спикеры:
Alfredo Mazzinghi (CHERI Alliance)
Marno van der Maas, John Thomson (lowRISC)
Видео: https://youtu.be/yCPQpMY5rzg
Воркшоп дает концентрированное практическое введение в архитектурную модель CHERI (Capability Hardware Enhanced RISC Instructions) и экосистему CHERIoT.
Основные технические акценты:
Capability-based addressing: указатели расширены метаданными (bounds, permissions, provenance), что обеспечивает spatial и referential memory safety на уровне ISA
Enforcement на аппаратном уровне: предотвращение out-of-bounds доступа, use-after-free и pointer forging
Fine-grained compartmentalization: изоляция компонентов через capabilities без существенного overhead традиционных механизмов
Практическая часть демонстрирует:
работу с CHERI-расширениями в C/C++ (capability pointers, restricted bounds)
поведение runtime при нарушении memory safety (hardware exceptions)
перенос существующего кода в модель capability-safe исполнения
Отдельный блок посвящен CHERIoT:
lightweight RTOS для embedded-систем
capability-driven изоляция компонентов прошивки
пример архитектуры безопасного IoT firmware с разделением на compartments
Материалы:
https://drive.google.com/drive/folders/1oVc1cFinXq6XzMjRJXgnxAz9pqsc74K3
Getting started:
https://lowrisc.github.io/sonata-software/doc/getting-started.html
Хорошая демонстрация того, как перенос гарантий безопасности (memory safety, isolation) на уровень архитектуры позволяет радикально снизить класс уязвимостей, характерных для C/C++ систем.

Интересные новости из мира RISC-V и HWRoT:
https://cheri-alliance.org/the-leading-root-of-trust-now-integrates-cheri-security-technology/
https://lowrisc.org/news/opentitan-earl-grey-2-to-support-cheri-and-pqc/ - дорожная карта и фичи