CHERI memory safety показывает, как hardware architecture может усилить pointer safety без массовой переписки кода. Для architects и SRE это важный пример того, как меняется boundary между hardware, software stack и model of trust.
Когда система растёт, главная проблема часто уже не в изоляции как таковой. Процессы, VM и MMU давно умеют разделять workloads. Сложность начинается там, где двум частям системы нужно не просто быть раздельными, а ещё и безопасно обмениваться данными. Именно в этот момент архитектура упирается в вопрос: как выглядит модель sharing, а не только модель isolation. В CHERI этот вопрос поставлен в центр.
Выбор CHERI выглядит прагматичным. Вместо того чтобы лечить безопасность только на уровне ОС или переписывать приложения, подход переносит часть гарантий в hardware. Появляется hardware-enforced pointer type, где pointer — это не просто число, а capability с bounds, permissions и tag bit. Это даёт spatial and temporal memory safety для C/C++, но с важным компромиссом: система становится строже к способам работы с памятью, зато сохраняет совместимость с существующим кодом. Отдельно стоит отметить, что CHERI не является одной фиксированной ISA. Это набор идей, локализуемый под разные архитектуры, включая AArch64 Morello и CHERIoT для микроконтроллеров.
В реализации важна именно механика, а не лозунги. CHERI-capability хранит адрес и метаданные, включая bounds и permissions. Эти границы не расширяются обратно: они monotonic. Если pointer сузили до поля или подобъекта, восстановить исходный контекст можно только через повторную derivation из другого доверенного указателя. Это хорошо для безопасности, но накладывает дисциплину на codebase и memory model. Есть и тонкость со storage: capability несёт tag bit, который показывает, что значение действительно является pointer. При частичной перезаписи памяти tag очищается, и система больше не трактует данные как capability. Это важная деталь для операций вроде memcpy, где копирование должно быть type-oblivious.
Ещё один слой архитектуры — compartmentalisation. CHERI позволяет заменить дорогие OS-level RPC механизмы более лёгкими и auditable межкомпонентными границами. Это не бесплатное улучшение. Но оно снижает издержки на коммуникацию между частями системы, если сравнивать с более тяжёлыми изоляционными схемами. Для embedded-сценариев это особенно заметно. CHERIoT показывает, что подход масштабируется вниз до microcontrollers и при этом сохраняет source compatibility. Для команд, которые десятилетиями живут с C-кодом, это принципиально: не требуется массовый rewrite, чтобы получить новый уровень контроля над памятью.
С инженерной точки зрения CHERI интересен ещё и тем, что он меняет саму стоимость доверия. Если раньше безопасность часто зависела от договорённостей в коде и дисциплины команды, то здесь часть инвариантов переезжает в silicon. Это не отменяет ошибок, но сужает класс ошибок, которые могут превратиться в нарушение изоляции. При этом система не становится магической. Она требует понимания, как pointer capabilities распространяются, где они сужаются и как ведут себя при копировании или загрузке из памяти.
Для архитекторов здесь есть важный вывод. Безопасность памяти и границы доверия лучше проектировать как часть platform architecture, а не как набор локальных патчей. CHERI предлагает именно такой сдвиг. Это эволюционное улучшение, а не косметическая надстройка: оно меняет модель взаимодействия между hardware, software и trust boundaries. И именно поэтому его стоит рассматривать не как ещё одну security-инициативу, а как архитектурный инструмент для систем, где isolation и sharing должны сосуществовать без хрупких компромиссов.