LINUX.ORG.RU

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

 ,


0

3

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

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

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

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

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

alexmaru ()

К тому же возрастает температура процессора из-за его большей активности.

Неужели так важен именно рост температуры процессора, а не его причина, а именно: рост потребляемой электроэнергии. В следствие чего уже увеличение нагрева, счетов за электроэнергию, износа полупроводниковых материалов.

gag ★★★★★ ()

Теперь likely()/unlikely() макросы, которые часто можно видеть в ядре, надо будет программистам научиться использовать самим и в повседневном ПО, ибо даже в AMD: https://lists.opensuse.org/opensuse-security-announce/2018-01/msg00004.html

This new firmware disables branch prediction on AMD family 17h processor to mitigate a attack on the branch predictor that could lead to information disclosure from e.g. kernel memory

Вот только где кроме C и C++ есть возможность вручную указывать вероятность? Не говоря уже о том, что даже макросами можно покрыть только самые простые случаи.

gag ★★★★★ ()

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

Было бы неплохо, если бы интел их выпустила официально, а не по каким-то каналам со своими крупными клиентами. Как-то они попали в SuSE, RedHat, наверное, от них уже в Debian. А на официальной страничке всё как и раньше.

Latest: 17.11.2017 https://downloadcenter.intel.com/search?keyword=linux microcode

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

Вот только где кроме C и C++ есть возможность вручную указывать вероятность?

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

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

по паре примитивных эвристических правил

И эти правила не отключили? Интересно тогда, что же отключили. Цитата сверху:

This new firmware disables branch prediction on AMD family 17h processor...

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

На гиктаймсе вроде так вкратце описано:

  1. Процессор в спекулятивном режиме читает значение по адресу 15000. Пусть там будет лежать, например, 98.
  2. Процессор читает значение, лежащее по адресу 98.
  3. От MMU приходит ответ о невалидности адреса 15000.
  4. Процессор сбрасывает конвейер и вместо значения, лежащего по адресу 98, выдаёт нам ошибку.
  5. Наше приложение начинает читать адреса от 0 и выше в собственном адресном пространстве (имеет полное право), замеряя время, требующееся на чтение каждого адреса, и читая их не по порядку, чтобы не натренировать тот же спекулятивный доступ
  6. На адресе 98 время доступа вдруг оказывается в несколько раз ниже, чем на других адресах

Таким образом мы понимаем, что кто-то уже недавно читал что-то по этому адресу, в результате чего он попал в кэш. Кто бы это мог быть? Ах, да, это наш дорогой процессор. По адресу 15000, соответственно, лежит значение 98.

Вроде бы в п.4 программа таки ловит в явном виде исключение.

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

И эти правила не отключили?

я так понял, отключили совсем.

я, походу, тебя не так понял

MyTrooName ★★★★★ ()

nopti же и не будет потери производительности.

onon ★★★ ()

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

Говорят, что эппол впилил эти патчи еще в декабре - никто ничего и не заметил. Вангую, что на десктопах будет всем пофиг.

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

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

P.S. Посмотрел бенчмарки, в куче тестов разница с/без патча как статистическая погрешность, или как заметили в комментах на phoronix, выглядит как незначительный регрес после очередного релиза ядра. Выдыхаем, учитывая что уязвим даже coffee-lake патчи не выкинут лет пять точно, так что пока пользователи intel в безопасности.

Aber ★★ ()

Kristian Köhntopp в G+:

In Amazon, PV instances have horrible performance. people need to switch to HVM

In our testing, 3.10 and KPTI is a trash fire. We see up to fifty percent degradation.

4.14 KPTI with PCID holds up nicely, hardly any degradation compared to 3.10 unmitigated.

This is CentOS 7

И вот отсюда https://groups.google.com/forum/m/#!topic/mechanical-sympathy/L9mHTbeQLNU :

The «pcid» CPU feature is now a critical performance item for the Meltdown fixes (KAISER / PTI).

For KVM virtual machines this means you need to make careful choice of CPU models to ensure guest OS get the 'pcid' feature. For libvirt / KVM configuration this means choosing one of the «Haswell», «Haswell-noTSX», «Broadwell», «Broadwell-noTSX», «Skylake-Client» or «Skylake-Server» CPU models, or using the host-model / host-passthrough modes. Other named CPU models («Westmere», «Ivybridge», etc) all lack 'pcid'. Look at '/proc/cpuinfo' in the guest to double-check it sees 'pcid'. Of course your physical host CPUs need to support this.

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

Прочитал про PCID, оказывается он может хранить идентификаторы 4096 процессов, т.е. с большим колличеством процессов PCID не будет работать. Интересно как это будет у vps хостеров. Прямо сейчас у меня в системе 300 процессов, следовательно если говорить про хостинг openvz контейнеров, то 10 контейнеров на одну машину может потянуть, а что там будет с настоящей виртуализацией?

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

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

https://kernelnewbies.org/Linux_4.14#Longer-lived_TLB_Entries_with_PCID

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

nopti же и не будет потери производительности.

Если бы всё так просто: что делать с изменениями в микрокоде без соответствующих «noXXX» переключателей? См. пример с AMD выше.

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

Как я понял, эксплоиты для spectre действительно не требуют вызова исключений (вернее оно незаметно происходит при спекулятивном исполнении). А вот meltdown вроде все же требует. Если конечно, все правильно понял, в чем уже сомневаюсь.

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

А теперь оказывается, что к тому же ещё и SUSE всё сообщество попутало. Очевидно, полностью AMD branch prediction не отключили:

Но официального от AMD до сих пор не нахожу.

gag ★★★★★ ()

Вообще удивительно, что в технологиях изобретённых около 30 лет назад до сих пор могут существовать баги уровня пробития защищённого режима.

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

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

ну да, попробуй почитать адреса из кернела и посмотри, как тебе ошибка не придёт.

Посмотрел бенчмарки, в куче тестов разница с/без патча как статистическая погрешность

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

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

так эти технологии не такие древние. как раз древние-то процы не подвержены этой фигне. это в погоне за маркетингом понаделали багов.

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

как раз древние-то процы не подвержены этой фигне

А вот знающие люди говорят, что Spectre существует с 1967 года.

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

так эти технологии не такие древние

ну например конвееры и кеш были уже в i486. Предсказание переходов в первом Pentium.

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

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

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

в 67-м году ещё машинные залы были и безопасность была не нужна

facepalm.bmp

В этих машинных залах, внезапно, стояли машины коллективного пользования - идеальная среда для Spectre. Безопасность не нужна, ага.

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

на кэш это не распространялось. причём вплоть до относительно последних процессоров.

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

В этих машинных залах, внезапно, стояли машины коллективного пользования

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

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

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

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

В этих машинных залах, внезапно, стояли машины коллективного пользования

весь «коллектив» был сотрудниками какого-то НИИ. и то не все, а только отдел программистов.

Все честнейшие люди, и скрывать им (и от них) было нечего. Ну да, ну да.

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

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

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

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

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

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

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

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

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

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

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

да. но не кому попало. и стоило это огромного бабла. и код набивали на перфолентах специально обученные тётки.

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

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

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

Нет. Если ты при помощи спекулятивного исполнения можешь указать процессору читать данные, к которым у тебя нет доступа, то они останутся в кэше. А содержимое кэша ты можешь «угадать» замером времени доступа к памяти.

Помоему пни первые только до первого разветвления

Суперскалярное исполнение, являющееся основой Spectre, появилось в Pentium Pro.

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

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

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

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

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

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

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

уже в 60-х конторы продавали машинное время для исполнения чужих программ.

да. но не кому попало

Конечно. Только тем, кто мог заплатить.

я ещё работала на огромных холодильниках с терминалами. там в принципе нет безопасности

На холодильниках - может быть. Но на ЕС она была, да и на СМ - тоже.

tailgunner ★★★★★ ()
Ответ на: комментарий от 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 ()
Ответ на: комментарий от Iron_Bug

ну да, попробуй почитать адреса из кернела и посмотри, как тебе ошибка не придёт.

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

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

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

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

а дальше случайном порядке обращаемся ко всем элементам нашего массива замиряя время доступа

Я наверное отстал от жизни. А как собственно замерять время доступа?

Serg_HIS ()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)