Бандитский Петербург.

Весь город этой хренью увешан. Доступ к почте/аккаунту в мессенджере и т.д. и т.п.

Да, это уже видел, но большое спасибо за ответ. Просто всё-таки немного странно, что технология достаточно старая (и даже как минимум один раз её уже обходили), а интересных исследований [уровня DC/CCC] в паблике до сих пор не видно. Всё, что пока удалось накопать самому:
https://www.youtube.com/watch?v=LheNo5Z98s8
https://www.sentinelone.com/blog/apple-os-x-zero-day-vulnerability-can-bypass-system-integrity-protection/

технология конечно есть, но будем откровенны, она как и пароль на UEFI отламываема by design на аппаратном уровне, потому и исследований минимум. грубо говоря овчинка выделки не стоит. отключение SIP на уровне перезаписать NVRAM по сути можно реализовать в большинстве  ядерных сплойтов. те если смотреть с точки зрения и ПО и железа, то нет смысла в отламывании исключительно SIP, разве что отключение SIP без перезапуска и это задача в стиле подготовить N патчей для N ядер.

Имхо trusted computing требует создания архитектуры с нуля. На данный момент большинство платформ так или иначе укатываемо. Вот и живём с почти с десятком финальных и окончальных патчей от meltdown.

Очень интересные мысли. Сейчас пишу статью про новые перспективные архитектуры. Может, у тебя есть материал какой-то , который ,на твой взгляд , описывает модель новой trusted computing архитектуры? Или можешь написать тут более конкретно по поводу этого , углубиться?(процитирую в статье)

хм, я не думаю, что такие материалы есть - это слишком фундаметально и как следствие нет и речи о рентабельности как таковой. тот же Bunny делал Novena https://www.crowdsupply.com/sutajio-kosagi/novena однако, чтобы такие разработки появились, да еще и в открытом доступе, потребуется появление человека уровня Илона Маска, но в полупроводниковой индустрии. и если говорить на чистоту, то полупроводниковая индустрия как таковая находится в сфере влияния гос сектора. отсюда и ряд проблем развития отрасли. тот же Intel ведь на госконтрактах сидел с самого начала и до сегодняшних дней.

я бы в принципе сам почитал чужие мысли на тему. да и в этом чате есть ряд людей, кто может больше и лучше меня написать про железо. я же все-таки человек из мира ПО и проектированием процессоров не занимался. чтобы решиться на подобного масштабы задачи надо быть по хорошему ебанутым человеком. от себя добавлю пару тем,  которые мне кажутся перспективными на данный момент, но требаю колоссальной  переосмысления вычисления техники. прежде всего мне кажется перспективной разработка ВТ на основе троичной логики. подобные высказывания вы можете найти и у Эдгара Дейкстры. как ни странно, но 1, 0, -1  позволяют упростить решение ряда задач, но требуют более глубокого понимания программирования, что в наше время в принципе нах никому не упало. в связи с чем как мне кажется было бы очень классно реализовать поддержку высокоуровнего языка программирования на уровне процессора. я имею вввиду, что работа с указателями и кучей возможна средствами CPU, что позволит решить ряд проблем с безопасностью в том числе. из разработок в этой области я хочу отметить Эль-90 отечественный и Java CPU от Sun. В эту сторону и надо развивать архитектуру вычислительной техники. Решение ряда проблем из области ИБ происходит автоматом при переходе на подобного рода архитектуру. ну те использования разных стеков под данные и код можно встретить еще на заре компьютеров.

@iDoka @sadkobogatiygost @Zaf0d @Des333 @netbug @twilightfeel я бы их мнение послушал. люди из мира FPGA, как-никак больше и лучше знакомы со спецификой проектирования железа. я же скорее программист, который нет-нет да и работает на низком уровне по мере востребованности оного.

еще дополню немного. есть тот же Risc V https://www.anandtech.com/show/15036/sifive-announces-first-riscv-ooo-cpu-core-the-u8series-processor-ip

звучит как CISC, там как раз хотели поддержку высокоуровневого языка сделать в процессоре. Проблема в том, что отлаживать RTL намного сложне, а если найдется какая-то уязвимость, то устранить ее будет очень сложно.
Ну и большой декодер инструкций ведет к большому потреблению, низкой скорости, большому размеру кристалла

когда появился первый ARM, это был прорыв по многим характеристикам

нет я точно не про CISC. я про RISC архитектуру изначально заточенную под ООП. те отдельный регистр под указатель на объект, отдельный под указатель на цепочку наследуемых классов, ну и alloc/free на уровне опкодов.

...такой, что начиная с 80486 (1989 год), начали разделять внешние инструкции и микрокод

ARM по такому же пути идет.

Только базовый набор команд трогать запрещает.

для этого его сначала пришлось раздуть немного)

если не дунуть, чуда не произойдет

просто CISC имхо уже точно в жопе, а для RISC наконец самое время