Насколько это может быть опасно и какой прирост производительности можно получить, отключив защиту от уязвимостей на серверах, не подключенных к Интернету?

Когда хост-сервер виртуальной машины Linux не имеет доступа к Интернету и используется исключительно в локальной сети и использует относительно хорошо протестированный дистрибутив, такой как Proxmox, насколько опасно было бы отключать все средства устранения уязвимостей с помощью аргумента ядра. mitigations=off?

Кроме того, кто-нибудь проверял, какой прирост производительности можно увидеть, отключив все такие меры?

Это недавно стало для меня вопросом, когда я увидел этот большой хит, который retbleed смягчения создают: https://www.phoronix.com/review/retbleed-benchmark

Это направление мысли расширилось до любопытства относительно того, какие могут быть последствия — как плохие, так и положительные — удаления всех или некоторых средств защиты либо с помощью приведенного выше аргумента ядра, либо путем индивидуального отключения важных средств защиты.

Флаг ядра Linux mitigations=[on|off] — это единственный переключатель, позволяющий легко включать/отключать все доступные средства защиты ядра от аппаратных уязвимостей, как указано здесь. https://docs.kernel.org/admin-guide/hw-vuln/index.html

Влияние этого, конечно, полностью зависит от вашего процессора:

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

• Когда ваш ЦП уязвим для некоторых (есть ли даже ЦП, уязвимые для все из них?) влияние зависит от того, какие именно уязвимости и ваша рабочая нагрузка.

Что касается анализа рисков, это также зависит от вашей рабочей нагрузки и пользовательской базы.

На узле виртуализации, управляемом общедоступным провайдером VPS, гостям доверяют меньше и гораздо больше вероятность того, что они будут вредоносными (или скомпрометированы), чем я ожидал бы на внутреннем узле виртуализации, используемом исключительно моими коллегами.

Например, на наших хостах виртуализации, используемых для конвейеров CI/CD и вычислительных кластеров, все гости недолговечны, развертываются из доверенных образов, работают до пары часов, а затем снова уничтожаются. Там нам нужна вся производительность, которую мы можем получить, и отключить смягчение.

В другом общем кластере мы размещаем более классические рабочие нагрузки консолидации серверов; гости, которые развернуты там, могут (и, скорее всего, будут) работать «вечно», а не часами. Он сочетает в себе рабочие и непроизводственные рабочие нагрузки, а гости управляются командами DevOps, которые не все так усердно исправляют и обновляют свои системы и приложения.
Там риск злонамеренного или скомпрометированного гостя намного выше, возможное снижение производительности для определенных рабочих нагрузок является приемлемым компромиссом, и поэтому там включаются меры по смягчению последствий, и мы ограничиваем, какие флаги ЦП выставляются гостям.