Кто кодил на мнемонике ассемблера 80x386/586/686 знает, что при передаче инструкций и указателей на конвейер в процессорах Intel они никак не проверяются (просто либо исполняются либо возвращается исключение, либо происходит остановка конвейера, операция Halt) — проблема давняя и уходит глубоко корнями в историю.
Сейчас процессорами проверяется только пометка страниц памяти NX битом неисполнения и контекст упавляющих контрольных регистров (CR), при восстановлении контекста исполнения кода содержащегося в странице памяти. При этом не все ядра используют весь блок регистров CR и не все кольца привелегий (всего 4, от 0 до 3 в числовом представлении регистра), задаваемые регистром CR0, в т.ч. ядро Linux и ядро Windows, которые используют только два кольца, ring0 для пространства привелегий ядра (модулей ядра, драйверов и некоторых резидентных демонов) и ring3 для остальных пользовательских приложений, что во многом обусловдено требованием переносимости ядер на другие аппаратные процессорные архитектуры.
Кольца привелегий были введены впервые программно в ОС Multics, предшественнице Unix, разработанной также в Bell Labs в 1960-x годах. Ядро Multics поддерживало программно 64 кольца (http://www.multicians.org/mgr.html#ring, http://www.multicians.org/protection.html), но аппаратно железо того времени поддерживало только 8 колец.

Поэтому не нужно забывать, что сборка ядра Linux должна быть с поддержкой nx-bit и security модулями (SELinux, AppArmor), и патч-сетом grsecurity (включая патч PaX).
В этом случае лучше использовать микро-дистрибутив Alpine Linux (лучше даже в Docker контейнере) для создания безопасного окружения.

Патч ядра Linux GRSecuruty позволяет выполнять более строгие проверки страниц памяти в ядре, но в корне не решает проблему.

В процессорах AMD конвейер и спекулятивное эвристическое предсказание переходов для оптимизации циклов проверяют инструкции и указатели, и исполняют их согласно уровню привелегий, контексту безопасности управляющих регистров, поэтому архитектурных проблем у них нет — https://lkml.org/lkml/2017/12/27/2

Удивительно, что до реализации поддержки всех аппаратных возможностей контроля безопасности при исполнении кода, которые представляют современные процессоры, в реализации ядер ОС дошли только сейчас.

Многие IT издания и СМИ пишут о данных уязвимостях как исключительно аппаратных, ставя в вину Intel и нанося ущерб репутации компании, и при том не разделяя особенности аппаратной реализации и её программную поддержку со стороны ядер ОС и не вникая даже в суть, т.е. практически все СМИ пишут только об аппаратной архитектурной проблеме, но никто не акцентирует внимания на программной поддержке колец привелегий, контексте безопасности при сохранении/восстановлении состояния регистров при исполнении кода, пометке страниц памяти и защите сегментов памяти от записи/изменения кода или исполнения данных в них.
Это вызвало уже ответную реакцию и критику со стороны самой Intel - https://newsroom.intel.com/news/intel-responds-to-security-r.../

© https://t.me/technologique/1224