LINUX.ORG.RU
ФорумTalks

Есть что на тему оптимизации недавних патчей к CPU?

 ,


0

3

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

Между тем, например, для meltdown нужно вызвать исключение обращением к недоступному адресу. Значит напрашивается, что можно было бы чистить кэш не всякий раз при переключении, а только после исключений. Тогда урон производительности был бы, наверное малозаметный, хотя некоторый оверхед пришелся был на усложнение алгоритма переключения.

Что там, идут среди разработчиков обсуждения в этом или другом направлении? Просто до сих пор мало интересовался их кухней и найти среди горы тредов сходу не смог.

P.S. А есть точный список процессоров, для которых Intel уже выпустила обновления микрокода?

★★★★★

Последнее исправление: praseodim (всего исправлений: 2)
Ответ на: комментарий от Iron_Bug

Я вот сижу и не понимаю зачем это стало распространяться на кеш. И пусть даже так. Чего вдруг при очистки кеша вдруг упала надёжность защищённого режима?

Serg_HIS
()
Ответ на: комментарий от Iron_Bug

Я так понимаю, эта уязвимость позволяет читать практически случайные обрывки данных. Хотя конечно их можно потом анализировать и вытягивать какой-то профит.

Serg_HIS
()
Ответ на: комментарий от Serg_HIS

ну, ядро обнуляет страницы при возврате их юзеру, а проц кэш не обнуляет. если ядро будет обнулять кэш, то весь смысл кэша пропадёт.

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

Я понял почему появилась уязвимость

«Для процессора Intel Core i7 глубина конвейера составляет 14 стадий.»

14 переходов однако... там да - начудить можно много и даже может по сети отправить :)

Serg_HIS
()
Ответ на: комментарий от Serg_HIS

вот проблема как раз в том, что «какие-то обрывки данных» - это по большей части мусор. учитывая, что на серверах с базами и прочих важных машинах никто не запускает левый код, то опасность такой атаки сильно преувеличена. вероятность есть. но она очень мала.

Iron_Bug ★★★★★
()
Ответ на: комментарий от Serg_HIS

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

Я сам работал на куче контор с типом разработки. «Мы это уже вчера продали, через 3 часа уже нужно показывать» (дословно).

Serg_HIS
()
Ответ на: комментарий от Serg_HIS

С оговоркой, что мы узнаём о том что именно нужно показывать за 3 часа до показа.

Serg_HIS
()
Ответ на: комментарий от Serg_HIS

такая же фигня. мы в разработке железа натурально прятали от манагеров прототипы. потому что могли схапать со стола недоделанную плату и продать. поэтому в отчётах откровенно врали про процент сделанного, пока не убеждались, что оно действительно работает как надо и не придётся потом где-нибудь в Бразилии отлаживать железо на ходу.

я чуть ли не с войной против манагеров продавливала тесты качества плат и интеграционные тесты серверов.

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 1)
Ответ на: комментарий от Serg_HIS

«Мы это уже вчера продали, через 3 часа уже нужно показывать» (дословно).

Даже микрософт с этого начался, вначале продали ibm ось и бейсик, а после чего нашли ось.

Aber ★★★★★
()
Ответ на: комментарий от Iron_Bug

мы в разработке железа натурально прятали от манагеров прототипы.

Да ва просто везло с типом разработки.

У нас обычно ночью (в Украине ночь) в Америке манагер по продажам списывался с заказчиком и на всё хотелки заказчика говорил «Okay!». Писал письмо маркетологам в нашем филиале, потом довольный какой он молодец и как он много напродавал ложился спать.

А для нас это новые не вписывающиеся в парадигму приложения фичи.

Продажник в Америке герой что сумел продать «машину времени» и «гравилёт». А мы тупые ленивые мудаки, что у нас вылазят бока при демке заказчику днём на боевом среваке. И «гравилёт бурит землю», и «машина времени взрывается ядерным грибом» задевая сотни других заказчиков.

Serg_HIS
()
Ответ на: комментарий от Serg_HIS

В итоге журят программеров и бывало что увольняли тестеров.

Serg_HIS
()
Ответ на: комментарий от Serg_HIS

у нас было похуже. когда один начальник, не имеющий технического образования, подписал допсоглашение, что все машины будут иметь IP44. причём без удорожания проекта. он вообще понятия не имел, что это за цифирки. оказалось, что товарищи сэкономили на системе пожаротушения и вместо стандартной для всяких там помещений с электроникой газовой системы поставили обычные брызгалки на потолке. и чтобы эти брызгалки не попортили им аппаратуру, решили добавить «маленькое» требование IP44. начальник не глядя подписал. а мы потом переделывали все корпуса и разъёмы.

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 3)
Ответ на: комментарий от Iron_Bug

или наоборот

Наоборот.

первое от второго не зависит

Только сделать дырявый, но влагозащищённый корпус несколько затруднительно.

redgremlin ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.