Из-за влияния мер защиты от Spectre на производительность многие сисадмины начинают задумываться о целесообразности установки патчей.
Как ни удивительно, меры, реализованные разработчиками для предотвращения эксплуатации нашумевших уязвимостей класса Spectre, стали настоящей головной болью для многих системных администраторов, поскольку некоторые из них существенно влияют на производительность систем. К примеру, инструкция Single Thread Indirect Branch Predictors (STIBP) уменьшает производительность PHP-серверов на 30%, в результате многие администраторы начинают задумываться о целесообразности установки патчей.
Уязвимости Meltdown и Spectre, о которых впервые стало известно в начале января 2018 года, позволяют злоумышленникам обойти механизмы изоляции памяти в большинстве современных процессоров и получить доступ к паролям, фотографиям, документам, электронной почте и другим конфиденциальным данным.
За прошедший год системные и сетевые администраторы неоднократно призывали разработчиков Linux реализовать возможности для отключения некоторых мер защиты, обосновывая просьбы тем, что угроза пока является теоретической и может быть нейтрализована с помощью реализации мер защиты периметра. Команда проекта Linux пошла навстречу пользователям и реализовала ряд опций, позволяющих отключить защиту.
К примеру, в выпусках ядра Linux 4.15, 4.17 и 4.19 были добавлены параметры "nospectre_v2","nospec_store_bypass_disable" и "nospectre_v1", позволяющие отключить защиту от Spectre v2 (CVE-2017-5715), Spectre v4 (CVE-2018-3639) и Spectre v1 (CVE-2017-5753) соответственно. Недавно в ядре Linux появился параметр PR_SPEC_DISABLE_NOEXEC, предотвращающий запуск дочернего процесса в ситуации, когда меры защиты от Spectre все еще активированы, несмотря на прекращение выполнения родительского процесса.
Как полагает ряд экспертов в области кибербезопасности, для некоторых процессов защита от Spectre просто не требуется, а влияние патчей на производительность значительно превышает их пользу, особенно в закрытых средах, куда не может проникнуть вредоносный код, например, на рендер-фермах (кластер для рендеринга компьютерной графики), физически изолированных суперкомпьютерах или других системах, где не используется сторонний код.