Производительность, по всей видимости, упадет из-за отказа от спекулятивного выполнения кода, да.
Пока единственный патч - это отказ не от "спекулятивного" выполнения кода (от него никто не откажется - ибо это краеугольный камень высокой производительности всех ныне существующих процессоров), а от маппинга ядра ОС в память каждого пользовательского процесса (на процессорах Intel).
Первый вопрос:
- Зачем этот маппинг делался?
- Для увеличения быстродействия, т.к. на каждый "чих" в пользовательском процессе требующий обращение к ядру (прерывание, системный вызов) - нужно было полностью менять контекст (TLB, содержимое памяти), а с этим трюком контекст нужно менять только при переключении от одного приложения к другому. При интенсивных запросах к ядру - очень прибавляло скорости переключения.
Второй вопрос:
- Как так маппить в адресное пространство пользовательского процесса данные ядра? А как же безопасность? Ведь непривилегированный процесс тогда будет иметь доступ к памяти ядра?
- На этот случай существует механизм АППАРАТНОЙ (на более низком уровне) защиты памяти, что не позволит обратиться к защищенной памяти - просто напросто при такой попытке выполнение остановится и сработает исключение, всё защищено АППАРАТНО, никакой софт не сможет обойти АППАРАТНУЮ защиту в железе.
И наконец вся мякотка:
- Так в чём проблема?
- Как оказалось дело в том, что процессор НЕ ВСЕГДА проверяет, а имеет ли исполняемый в данное время код обращаться к определенной ячейке памяти. Например - при "спекулятивном" (out-of-order) выполнении, рассчитывая на то, что проверка будет выполнена позже. Делается это я не знаю для чего, но предполагаю - для того чтобы было "дёшево и сердито", нужно быстрее забить свободные блоки, чтобы не простаивали и повысить производительность. В итоге "дооптимизировались" до того, что может возникнуть (в обычном коде крайне маловероятная) ситуация, когда проверка ВООБЩЕ не осуществляется ни на одном из этапов. Это случай Meltdown - суть уязвимости максимально упрощённо: на первой стадии при "спекулятивном" выполнении кода, происходит чтение из ячейки памяти ("защищенной") и данные оказываются в кэше процессора, на второй стадии эти данные ловким трюком из кэша вытаскиваются. Это ошибка конкретно Intel, для AMD во вчерашнем обновлении ядра linux этот фикс отключен по умолчанию.
Со Spectre (два типа атаки) всё сложнее - там действительно придётся совать палки в колёса "спекулятивного" исполнения (см. ниже)
поскольку эти самые спекулятивные запросы процессоров "в будущее" как раз себя на таких задачах показывают
На будущее планируется (на текущий день единственный существующий план) внести изменения в код всех критических приложений и компиляторов, а также в микрокод процессоров, для того чтобы максимально уменьшить утечку данных при "спекулятивном" выполнении, будут вставляться ложные циклы для "загрязнения" кэша и т.д. Планы космического масштаба прямо... А пока единственное исправление - это отказ от маппинга ядра в память пользовательских процессов (только для Intel, см. выше). Теперь постепенно будут менять весь софт, вносить новые изменения в ядро ОС и микрокод процессора, ну и конечно перелопачивать архитектуру будущих процессоров.
P.S. И да, эти конкретные ошибки позволяют только ЧИТАТЬ защищенную память, но не изменять её, выполнять произвольный код и т.д.
, чего и всем желаю.
