The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Семь новых атак на механизм спекулятивного выполнения в CPU, opennews (??), 14-Ноя-18, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


147. "Семь новых атак на механизм спекулятивного выполнения в CPU"  +/
Сообщение от пох (?), 15-Ноя-18, 17:28 
> nopti nospectre_v2 nospec

падение производительности, к сожалению, уменьшится, но никуда не девается.
К тому же это ты в линуксном ведре отключил. Теперь давай в qemu/kvm (мне плевать кто там на ком стоял, давай результат), xen, обоих, и 0 и U, virtualbox. Все они необратимо изуродованы якобы-безопасными патчами.

Браузер уж хрен с ним, можно оставить, все равно меньше тормозить они не будут.

Ответить | Правка | К родителю #144 | Наверх | Cообщить модератору

151. "Семь новых атак на механизм спекулятивного выполнения в CPU"  +/
Сообщение от KonstantinB (??), 15-Ноя-18, 19:07 
> падение производительности, к сожалению, уменьшится, но никуда не девается.

Возможно, но на моих задачах в пределах погрешности измерения.

> Теперь давай в...

Kvm у меня там, где производительность некритична, остальное не использую.

Ответить | Правка | Наверх | Cообщить модератору

152. "Семь новых атак на механизм спекулятивного выполнения в CPU"  +/
Сообщение от пох (?), 15-Ноя-18, 19:50 
ну так у гугля вон и с включенным - в пределах...
во всяком случае он так меряет.

> Kvm у меня там, где производительность некритична

ну вот везет. А остальным-то куды бечь от этой "заботы" разработчиков (всего!) ниасиливших #ifdef ?

в том же ядре - миллионы ненужно-настроек, обычно никогда и никем не трогаемых (впрочем, половина вообще никому, кроме автора, может быть, непонятно, для чего и как работает). А тут - -30% к производительности - и нет, никак в условную компиляцию нельзя.


Ответить | Правка | Наверх | Cообщить модератору

189. "Семь новых атак на механизм спекулятивного выполнения в CPU"  –1 +/
Сообщение от Онаним (?), 18-Ноя-18, 11:51 
Ну вот кстати да, задолбался выключать. Выключи в гипервизоре, потом во всех хост-системах. На клиентсайде никуда не денешься, а вот на внутренних системах все эти митигации нахрен не нужны. Кто бы нашептал апстриму сделать одну крутилку навроде x86_all_mitigations=off...
Ответить | Правка | К родителю #147 | Наверх | Cообщить модератору

190. "Семь новых атак на механизм спекулятивного выполнения в CPU"  –1 +/
Сообщение от пох (?), 18-Ноя-18, 13:02 
> Кто бы нашептал апстриму сделать одну крутилку навроде x86_all_mitigations=off...

кто бы нашептал апстримам прочитать наконец главу K&R "директивы препроцессора", и выкинуть все это из исполняемого кода нахрен, а не проверять миллион kernel tunables в самом тяжелом месте контекст-свитчера (впрочем, у линукса там похоже не только миллионы проверок ненужного ненужно, а и часть кода все равно исполняется, не смотря на "отключение" - иначе сложно объяснить, откуда такие потери даже при отключенном)

все равно с уходом редхат куда-то в облачные дали технология "один дистрибутив-  одно ядро" вместо слакварьской игры 92го года "выбери из трехсот одно подходящее" тоже безвозвратно утрачена.

Ответить | Правка | Наверх | Cообщить модератору

194. "Семь новых атак на механизм спекулятивного выполнения в CPU"  –1 +/
Сообщение от Онаним (?), 18-Ноя-18, 14:29 
Да, выключение != возврату производительности на место к старым версиям ядер. Но по крайней мере на 90%...
Ответить | Правка | Наверх | Cообщить модератору

210. "Семь новых атак на механизм спекулятивного выполнения в CPU"  +/
Сообщение от Аноним (208), 19-Ноя-18, 16:26 
> tunables в самом тяжелом месте контекст-свитчера

Чувак, ты видел набор регистров FPU и SIMD хотя-бы? На этом фоне tunables не такие уж ужасные :)

Ответить | Правка | К родителю #190 | Наверх | Cообщить модератору

195. "Семь новых атак на механизм спекулятивного выполнения в CPU"  +/
Сообщение от Онаним (?), 18-Ноя-18, 14:31 
Сейчас пока так, пока новых не накрутили:

nopti nospectre_v2 nospec_store_bypass_disable no_stf_barrier pti=off spectre_v2=off l1tf=off spec_store_bypass_disable=off stf_barrier=off

Для Xen тоже да, есть:

xpti=0 spec-ctrl=no-xen pv-l1tf=0

Ответить | Правка | К родителю #147 | Наверх | Cообщить модератору

196. "Семь новых атак на механизм спекулятивного выполнения в CPU"  –1 +/
Сообщение от Онаним (?), 18-Ноя-18, 14:32 
Дублируются (no) и (=off) потому, что в разных версиях ядер по-разному сделано.
Ответить | Правка | Наверх | Cообщить модератору

199. "Семь новых атак на механизм спекулятивного выполнения в CPU"  –1 +/
Сообщение от пох (?), 18-Ноя-18, 16:33 
> Сейчас пока так, пока новых не накрутили:

мать-мать-мать...
> Для Xen тоже да, есть:

а для kvm ? ;-) Ну, или qemu, я опять не пойму кто там на ком стоит.

интересно, а какой лимит у кернельной командной строки? Включая и встроенный в grub, подозреваю, он первый кончится.

Ответить | Правка | К родителю #195 | Наверх | Cообщить модератору

211. "Семь новых атак на механизм спекулятивного выполнения в CPU"  +/
Сообщение от Аноним (211), 19-Ноя-18, 16:30 
> а для kvm ? ;-) Ну, или qemu, я опять не пойму
> кто там на ком стоит.

А ничего что Xen это таки отдельный гипервизор, который сам ресурсы менеджит на низком уровне, а в случае kvm - это линуксное ядро хоста делает?

Впрочем настолько разбираться в системной архитектуре используемых инструментов великому специалисту по всему и вся конечно же лень.

> интересно, а какой лимит у кернельной командной строки? Включая и встроенный в
> grub, подозреваю, он первый кончится.

Так он кончится только у извращенцев которым пофиг на то что их кредитки-пароли стырят и майнеров понаставят. Это даже большинству хостеров впадлу, потому что кастомеры потом чем-то недовольны оказываются. Так что они поскрипят да и удовольствуются на 5% меньше производительности. Ну и клиенты получат на 5% меньше за ту же сумму, это уж увы.

Ответить | Правка | Наверх | Cообщить модератору

214. "Семь новых атак на механизм спекулятивного выполнения в CPU"  +/
Сообщение от Онаним (?), 19-Ноя-18, 20:05 
Ну на хостинге собственно PTI выключать - да, стрёмно. А вот на серверах БД того же кластера хостинга - почему нет?
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру