The OpenNET Project / Index page

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

Google считает незначительным влияние на производительность патчей для блокирования атак Meltdown и Spectre

05.01.2018 23:26

Компания Google сообщила о внедрении патчей KPTI и retpoline для блокирования атак Meltdown и Spectre на своих Linux-серверах, в том числе обслуживающих поисковую систему, Gmail, YouTube и Google Cloud Platform. Несмотря на то, что теоретически данные патчи приводят к возникновению дополнительных накладных расходов при выполнении системных вызовов, влияние на производительность обоих патчей при реальной нагрузке Google при выполнении большинства задач оценивается как незначительное. Напомним, что в синтетических тестах наблюдалось проседание производительности до 30% и даже до 60%.

Патч KPTI (Kernel Page Table Isolation) нацелен на блокирование уязвимости Meltdown на уровне ядра Linux и основан на идее разделения памяти ядра и пространства пользователя. Патч Retpoline предложен Google для блокирования атаки Spectre и основан на применении специальной последовательности инструкций, исключающей вовлечение механизма спекулятивного выполнения. Кроме модификации ядра, реализация Retpoline также подразумевает применение для сборки специально модифицированного компилятора (GCC, Clang). Кроме Retpoline атака Spectre также может быть блокирована на уровне обновления микрокода CPU.

  1. Главная ссылка к новости (https://security.googleblog.co...)
  2. OpenNews: Раскрыты подробности двух атак на процессоры Intel, AMD и ARM64
  3. OpenNews: Разработчики Linux и Windows работают над закрытием огромной уязвимости в процессорах
Лицензия: CC-BY
Тип: Проблемы безопасности
Ключевые слова: cpu, meltdown, spectre
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (106) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 23:30, 05/01/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –8 +/
    Стало быть, драмы не будет.
     
     
  • 2.10, Петр А (?), 00:32, 06/01/2018 [^] [^^] [^^^] [ответить]  
  • –17 +/
    >> Стало быть, драмы не будет.

    Драма есть уже — вишь, минусаторы страдают.

    Проблема с обеими «уязвимостями» возникает в одной ситуации — когда ПАРАЛЛЕЛЬНОЕ ИСПОЛНЕНИЕ кода оформляется не ручками, с контролем гонок и памяти на уровне исходников, а «хреньворками».

    146% посетителям сего богоспасаемого места — это, как зайцу стоп-сигнал.

     
     
  • 3.13, h31 (ok), 03:22, 06/01/2018 [^] [^^] [^^^] [ответить]  
  • +12 +/
    Давай, оформляй всю необходимую параллельность ручками. Бери исходники, редактируй, отправляй. А я послежу, чтобы ты "хреньворками" не пользовался.

    Для общего развития: спекулятивное выполнение работает на гораздо более низком уровне, чем традиционная многопоточности. С использованием pthreads ты никак не реализуешь спекулятивное выполнение на том уровне, на каком работает процессор, а даже если и сможешь, то накладные расходы на манипуляцию потоками будут гигантскими. Это если говорить про популярные архитектуры ЦПУ, не VLIW.

     
     
  • 4.57, anonymous (??), 20:40, 06/01/2018 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Это ты хорошо так сейчас бисер раскидал.
     
  • 2.37, anomymous (?), 12:25, 06/01/2018 [^] [^^] [^^^] [ответить]  
  • +9 +/
    Драма будет, когда эксплоиты начнут работать in the wild - а PoC'и открыты, и начнутся массовые утечки банковских и персональных данных у хомяков. Вот для этой драмы я попкорна купил уже.
     
     
  • 3.45, Anonymoustus (ok), 15:26, 06/01/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    У тех банков, которые используют мейнфреймы и неуязвимые by design системы, утечек не будет.
     
     
  • 4.47, Аноним (-), 16:10, 06/01/2018 [^] [^^] [^^^] [ответить]  
  • –3 +/
    пока не будет личного вызова для васи с чердака
     
  • 4.55, IB (?), 19:35, 06/01/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Как мэйнфрейм защитит от кражи трояном данных карты с формы при оплате в инет магазине?
    Или паролей от Яндекс-кошелька.
    Смысл - троян установившийся под юзером может читать данные других юзеров / программ / системы.
     
     
  • 5.59, anonymous (??), 21:07, 06/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Он и под текущим юзером дел наворочает.


     
  • 4.67, commiethebeastie (ok), 00:45, 07/01/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    В банках самое убогое ойти.
     
     
  • 5.78, Аноним (-), 15:07, 07/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Еще один аналитик с лора.
     
     
  • 6.92, Аноним (-), 15:42, 08/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    увы, какой безопасник признается, что могла и быть утечка, а нерушимая система при легкой секундной мисконфигурации становится оплотом диверсионной работы
     
  • 5.81, Джон Ленин (?), 15:34, 07/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    GOGLE VAX OpenVMS
     
     
  • 6.86, RobotsCantPoop (?), 20:23, 07/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Не у всех остался VMS, а тем более VAX.
     
     
  • 7.96, Аноним (-), 20:02, 08/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Не у всех остался VMS, а тем более VAX.

    в соседней новости из гзипа выкинули поддержку vms, так что на нём уже особо не погзипуешь

     
     
  • 8.97, Аноним (-), 20:58, 08/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Угу, апдейт для гзипа просто удаляет бинарники gz ungz на этой платформе И заод... текст свёрнут, показать
     
     
  • 9.106, 1 (??), 13:40, 09/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Накладывает патч Бармина же ... текст свёрнут, показать
     
  • 3.49, леон (?), 17:09, 06/01/2018 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > а PoC'и открыты, и начнутся массовые утечки банковских и персональных данных у хомяков.

    Им же нечего скрывать, в чём проблема?

     
  • 3.72, нах (?), 10:15, 07/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    как будто для этого нужны были какие-то еще ыксплоиты http www opennet ru ope... текст свёрнут, показать
     
  • 3.76, Як (?), 13:47, 07/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Многие почему-то забыли о такой мелочи, как производительность. Хорошо оптимизированный сплоит на ассемблере читает память со скоростью 2 кб/с. Вопрос: с какой скоростью будет читать память сплоит на JS и сколько байт он успеет прочесть, прежде чем пользователь все-таки заметит, что браузер уже несколько часов как отожрал полностью одно ядро?
     
     
  • 4.101, лютый жабист__ (?), 07:53, 09/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >прежде чем пользователь все-таки заметит, что браузер уже несколько часов как отожрал полностью одно ядро

    По моим наблюдениям, юзер такое не заметит вообще. Даже на ноутбуке, который начинает громче жужать вентилем. А уж производительность вообще не меняется от плюс-минус одно ядро :)

     
  • 4.103, Джо (?), 09:28, 09/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Насколько я понимаю с такой-же: готовишь js или asm.js такой, которым джитом переводится в требуемый ассемблер и получаешь схожую производительность.
     

  • 1.2, DiabloPC (ok), 23:32, 05/01/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +17 +/
    > Google ... оценивается как незначительное

    А цифры где? А то для гугла и 50% может оказаться "незначительным", кто ж знает что у них там в головах то %)

     
     
  • 2.3, Crazy Alex (ok), 23:56, 05/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Где-то попадалось странное - для более старого интеловского процессора замедления почти не было, а для Coffee Lake было существенно сильнее. Но сходу снова не гуглится
     
     
  • 3.4, незначительно (?), 00:04, 06/01/2018 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > Но сходу снова не гуглится

    Просто запрос "незначительно" отличается.

     
     
  • 4.29, Crazy Alex (ok), 10:46, 06/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Это было что-то англоязычное и там были две конкретные модели процессора - какие-то i7. Ладно, всплывёт если доля истины в этом есть. А если нет - то и чёрт с ним
     
  • 4.31, Crazy Alex (ok), 10:52, 06/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Если намекали на злонамеренность гугла - то я как раз об обратном, если оно так - то на их процессорном парке и правда не должно было сказаться
     
  • 4.33, Аноним (-), 11:16, 06/01/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    в блоге grsec писали о 9% drop на при IPTV раздаче.
     
  • 3.39, Crazy Alex (ok), 12:48, 06/01/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Что-то я плохое курю. Фороникс же: https://www.phoronix.com/scan.php?page=article&item=linux-415-x86pti&num=2

    То есть я где-то в другом месте читал, но тут разница хорошо видна.

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

     
     
  • 4.53, Andrey Mitrofanov (?), 18:22, 06/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > То есть я где-то в другом месте читал, но тут разница хорошо
    > видна.

    На нём же, родном - https://www.phoronix.com/scan.php?page=article&item=linux-415-x86pti&num=1

    Там был, я ж тоже помню!, пассаж типа "вот на 9700xx ой-ёй-ёй,а на более старом 6800zz почти и не заметно". Теперь такого в статье _нет_.

    Микаэль, надо понимать, почитал новости, что оно уже 10-15 лет "того", а не год-два с прошлого Lake-а -- да и исправил уже опубликованного "глубокого анализа".

    [I]" [,,,] here are my initial benchmark numbers on two systems. "

    " I ran tests on a Core i7 8700K "Coffee Lake" system as well as an older Core i7 6800K "Broadwell E" system [...] "

     
  • 3.51, Anonim (??), 17:40, 06/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Но сходу снова не гуглится

    Гугол удалил из выдачи

     
  • 2.6, Mike Lee (?), 00:21, 06/01/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Как раз наоборот. Для гугла 50% это тысячи дополнительных ядер. А для большинства незаметно.
     
  • 2.21, пох (?), 07:20, 06/01/2018 [^] [^^] [^^^] [ответить]  
  • +4 +/
    цифры - они в индексе. И поэтому инвесторы гугля действительно могут спать спокойно.
    Какое количество картонных серверов еще понадобится ввсести дополнительно. чтобы покрыть издержки - им все равно не расскажут (да и не знает никто), и им это неважно.

    Статейка написана ровно ради этих индексов - а то после заявлений всяких вредных личностей они что-то нехорошо заворочались.

    Ну и да - в очередной раз вспоминая о средней длине члена - grsec меряли (и описали, чем) а гугль - "считает". Но инвесторы (да и индустрия) будут слушать гугля, а не каких-то там.

     

  • 1.5, Stop (?), 00:13, 06/01/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    Просто GOOGLE использует старое протухшее железо
     
     
  • 2.8, VINRARUS (ok), 00:23, 06/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Или АМД
     
  • 2.20, лютый жабист__ (?), 07:17, 06/01/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >Просто GOOGLE использует старое протухшее железо

    Да. В google cloud computing все инстансы на древних процах с низкой частотой. Скайлэйк можно выбрать, но далеко не во всех ДЦ.

    Кстати, интересно, почему гуголь не использует амд.

     
     
  • 3.30, Аноним (-), 10:47, 06/01/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Судя по недавним новостям - интель им по-братски дал кредит под 0% на свои commodity-процы.

    А то гляди ка - и Google Project Zero "внезапно" открыл уже известные уязвимости (даже названия присвоили!), и Google Cloud зашевелились (это вообще кто такие?). А главное - сколько шуму: PR-война в самом разгаре. Учитывая, за кем сейчас преимущество в вычислительных мощностях, неудивительно, что гугловцы полируют штеудовский сексуальный орган - чай не дураки, рубить сук на котором сидят.

     
  • 3.98, ACCA (ok), 22:42, 08/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Исторически так сложилось. Pentium III имел самое низкое энергопотребление на операцию.

    200 млн. процессоров, экономия на каждом по 3-5-10 Вт...

    Походу эти Pentium III так и работают там.

     
  • 2.42, Аноним (-), 14:32, 06/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >Просто GOOGLE использует старое протухшее железо

    Проблема появилась с появлением у Штеуда технологии предсказания ветвлений, т.е. в самых первых Пнях.

     

  • 1.7, яя (?), 00:21, 06/01/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    я ставить эту херню не буду. надеюсь будет опция в ядре чтоб не вкомпиливать.
     
     
  • 2.43, Аноним (-), 14:35, 06/01/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Наверняка, будет. Только и эксплойты обязательно будут.
     
  • 2.84, Lev Lybin (?), 17:31, 07/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Уже есть опция загрузки ядра nopti
     

  • 1.9, Аноним (-), 00:31, 06/01/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Эммм, посмотрел, нихрена не понял. Они там пишут свой собственный вариант инструкции call? Как эта магия retpoline работает вообще? Оно защищает если ядро скомпилировали патченным компилятором, который заменяет везде call на какую-то последовательность команд, но в программе пользовательской может быть не заменено же? Хотя, наверное, можно браузер перекомпилять и хотя бы за javascript-эксплоиты быть спокойными...
     
     
  • 2.12, asdasdasd (?), 02:44, 06/01/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Хз как оно работает, но оно не собирается. Собрал их GCC retpoline, собирал ядро и получил кучу undefined reference -_-
     
  • 2.50, Crazy Alex (ok), 17:33, 06/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Да, оно защищает конкретно ядро. Насколько я понимаю, Сама уязвимость позволяет дотянуться какому-то недоверенному коду до данных в том же процессе, в котором он исполняется, так что, в общем-то, патчить надо только тот софт, где такое возможно. Браузер - первый кандидат... но загрублённые таймеры мне как-то больше по вкусу, браузеры и так тормозить умеют слишком хорошо.
     

  • 1.14, dimqua (ok), 05:45, 06/01/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    >атака Spectre также может быть блокирована на уровне обновления микрокода CPU

    Осталось дождаться фиксов от Intel и AMD.

    http://news.stfw.ru/41465-yeto-ne-to-chto-nevozmozhno-ispravit-intel-ne-stane

     
     
  • 2.15, Аноним (-), 05:56, 06/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    IBM POWER тоже вышла обновка
     
  • 2.22, пох (?), 07:23, 06/01/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Осталось дождаться фиксов от Intel и AMD.

    ну, здоровенный апдейт микрокода в rhel три дня назад приполз. Что он на самом деле там фиксит (и не надо ли, кстати, его откатить, если не хочешь потери производительности даже с непатченным ведром) - разумеется, большая коммерческая тайна.

     
     
  • 3.108, Аноним (-), 14:38, 09/01/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >если не хочешь потери производительности даже с непатченным ведром

    Да куй с ней вообще, с производительностью. Вы чо, совсем все нищeброды на третьепнях, штoле? Лучше подумайте, какого западла они могли туда под шумок напихать. И не был ли этот "подшумок" для того и организован.

     

  • 1.16, robot228 (?), 06:01, 06/01/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Супер очевидно что гугл прикрывает *опу интел.
     
     
  • 2.17, Аноним (-), 06:16, 06/01/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Он понимает, что intel не будет возвращать серверную продукцию за 10-лет по всему земному шару вендорам.
     

  • 1.18, Аноним (-), 06:59, 06/01/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Пишут, что не сильно замедляет, но сильно греются процессоры от этих патчей.
     
     
  • 2.23, Аноним (-), 08:28, 06/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Пишут, что не сильно замедляет, но сильно греются процессоры от этих патчей.

    От двойного переключения контекста ЦПУ, больше переключения богу пустынного кремния!!!

     

  • 1.19, KonstantinB (ok), 07:08, 06/01/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Дык, гугловские программисты и так сисколлы экономили. Потому и несильно у них.
     
  • 1.24, Аноним (-), 08:33, 06/01/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    сговор гигантов, нужно поднять продажи, а может сам патч и есть бэкдор мазафака
     
     
  • 2.25, Аноним (-), 08:35, 06/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    intel/nvidia с их маркетингом в каждой щели...
     

  • 1.26, Геймер (?), 08:50, 06/01/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Костыли это, а не патчи. Потому что эти "патчи" реально нихрена ничего не патчат. И то, что программно отключается, может обратно программно включаться. Особенно это касается "патчей" Микрософт, где однозначно оставлена недокументируемая лазейка кому-надо включать мельтдаун, а когда надо отключать.

    Производительность - вопрос вторичный. Потому что процессоры гнилые на уровне их архитекторов - это даже не брак производства. И все последние 20 лет впаривали по сути 286 процессоры с имитацией многозадачности только многогигагерцовые и многядерные.

    Хотя начиная с 386 и заканчивая Пентиум Про плюс Сайрикс и Виа вполне возможно были настоящие многозадачники.

    А хипстерня сожрала Интел МЕ, сожрёт и мельтдаун. Лишь бы только производительность в игрушках не снизилась.

     
     
  • 2.27, Аноним (-), 09:00, 06/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >[оверквотинг удален]
    > Особенно это касается "патчей" Микрософт, где однозначно оставлена недокументируемая
    > лазейка кому-надо включать мельтдаун, а когда надо отключать.
    > Производительность - вопрос вторичный. Потому что процессоры гнилые на уровне их архитекторов
    > - это даже не брак производства. И все последние 20 лет
    > впаривали по сути 286 процессоры с имитацией многозадачности только многогигагерцовые
    > и многядерные.
    > Хотя начиная с 386 и заканчивая Пентиум Про плюс Сайрикс и Виа
    > вполне возможно были настоящие многозадачники.
    > А хипстерня сожрала Интел МЕ, сожрёт и мельтдаун. Лишь бы только производительность
    > в игрушках не снизилась.

    Скорость System I/O в многопотоке на i7 и выше в 2.5 раза ниже! Софтаврные патчи! AES-NI тоже уже неэффективен на SSD.

     
     
  • 3.28, Геймер (?), 09:06, 06/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Я ж и говорю - костыли костыльные, а не патчи. Хорошо что ещё хоть как-то ползают.
     
  • 2.36, Аноним (-), 12:13, 06/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    В игрушках и не снижается, как ни странно, а вот на серверах очень даже заметно.
     
     
  • 3.48, anomymous (?), 16:32, 06/01/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А чего странного. Там условно полтора сискола на кадр.
     
  • 2.68, Анонимный Алкоголик (??), 01:00, 07/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > недокументируемая лазейка кому-надо включать мельтдаун

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

     

  • 1.34, Hellraiser (??), 11:36, 06/01/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    хе-хе, ну раз гугл утверждает, что патчи не влияют на производительность - значит интел может и дальше штамповать defective-by-design камни; все косяки в железе отныне будут преодолеваться патчами в ядрах ОС
     
     
  • 2.38, anomymous (?), 12:28, 06/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > железе отныне будут преодолеваться патчами в ядрах ОС

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

     

  • 1.35, gpyra (?), 11:54, 06/01/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Пускай считает, что хочет. Есть и другие мнения.
     
     
  • 2.80, Аноним (-), 15:16, 07/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Пускай считает, что хочет. Есть и другие мнения.

    И все мнения по весу равнозначны. Ну или твое сильно весомее. Да, мой дорогой аналитек?

     

  • 1.40, anomymous (?), 13:18, 06/01/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +17 +/
    Ну вот есть у меня очень нагруженный Zabbix сервер под Xen с 8 vCPU (2 CPU x 6 реальных ядер на хосте). С проксями снаружи, блекджеком и дамами.

    Number of hosts 7329
    Number of items 284444
    Number of triggers 143874

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

    Что поимел (данные снимал естественно после "прогрева" кэша MySQL и устаканивания опросников Zabbix):

    1. "До": Нагрузка всех 8 ядер плавает от 20 до 70%, в основном из-за скриптов сброса данных в систему графиков.

    userspace - ~20%, system - ~10%, wa/si - ~1-2%, idle - ~60%. MySQL - 120-220%, с выплесками до 400% (как раз из-за сброса данных для графиков). Ядра в полку не упираются, loadavg около 4-5.

    2. "После" (с KPTI): ужОс заметен сразу на графиках в XenServer. Вместо 20-70% имеем от ~50% до "полки" (100%). То есть рост нагрузки на ядра в Zabbix порядка 2 крат (что соответствует 50% падению производительности).

    userspace - ~40%, system - ~40%, idle - ~10%, wa/si - ~1-2%. MySQL - ~200-300%, с выплесками до 480% - т.е. KPTI ощутимо шарахнуло по MySQL. Но не только. В топе стало видно опросники и snmpget (по ~1%). Ядра начали упираться (idle=0), loadavg вырос до 11-12.

    Вот такие дела. Как только выключаем pti (с ядром RHEL можно "на лету") - сразу же возвращаемся практически к значениям "до".

    Итого: заббикс будет летать с pti=off, благо там эксплуатировать уязвимости некому.

     
     
  • 2.41, Аноним (-), 13:53, 06/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Да в многопотоке просадки KPTI значительные, можно уже заказывать сервера на AMD.
     
     
  • 3.44, anomymous (?), 15:11, 06/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Угу :( Там даже не в многопотоке дело, а в куче сисколов. Заббикс - это ж обилие форков, отсылок и получений коротеньких пакетов (icmp, snmp), мелких обращений к БД (соответственно к диску). В общем, практически наихудший для KPTI вариант.
     
     
  • 4.46, Аноним (-), 15:33, 06/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Угу :( Там даже не в многопотоке дело, а в куче сисколов.
    > Заббикс - это ж обилие форков, отсылок и получений коротеньких пакетов
    > (icmp, snmp), мелких обращений к БД (соответственно к диску). В общем,
    > практически наихудший для KPTI вариант.

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

     
     
  • 5.52, Аноним (-), 17:44, 06/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Сейчас прогоняют WireGuard для k8s.
     
  • 2.69, Анонимный Алкоголик (??), 01:49, 07/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > userspace - ~20%
    > userspace - ~40%

    Что-то как-то подозрительно. Из-за чего работа в userspace замедляется?

     
     
  • 3.70, anomymous (?), 09:03, 07/01/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да ничего подозрительного. Просто рост нагрузки размазался между юзерспейсом и кёрнелспейсом, что и не удивительно. Там же целых несколько эффектов:

    1. Увеличение времени входа-выхода в/из сискола. Это по идее должно попадать в sy, но у меня есть сомнения насчёт трамплина (не анализировал, могу ошибаться) - скорее всего время нахождения в трамплине будет зачтено самому процессу и попадёт в us.
    2. Постоянные сбросы TLB однозначно влияют на общее время выполнения кода как в юзерспейсе, так и в ядре. Причём как раз этот эффект слабо предсказуем и зависит как от числа сисколов, так и от активности работы с памятью / разброса адресов при этом. Zabbix в этом плане с его кучей дочерних процессов - опять же худший вариант.
    3. Много мелкого обмена с сетью - много прерываний, а поскольку страницы кёрнелспейса теперь как глобальные не объявляются, появляется проблема с вымыванием TLB после выхода из прерываний.

    PCID/INVPCID у данного конкретного процессора (Xeon X5670) нет, так что каждый сискол или инт сбрасывает TLB целиком. В общем, при таком числе процессов и объёме постоянного рабочего набора (~20 гиг вместе с MySQL) уже не подозрительно :)

     
     
  • 4.75, Аноним (-), 13:20, 07/01/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >PCID/INVPCID у данного конкретного процессора (Xeon X5670) нет

    есть.
    processor       : 0
    vendor_id       : GenuineIntel
    cpu family      : 6
    model           : 44
    model name      : Intel(R) Xeon(R) CPU           X5670  @ 2.93GHz
    ..
    [root@NodeB mm]# grep pcid /proc/cpuinfo
    flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 popcnt aes lahf_lm epb tpr_shadow vnmi flexpriority ept vpid dtherm ida arat

    PCID

     
     
  • 5.77, anomymous (?), 14:05, 07/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Да, наличие PCID не заметил. INVPCID нет. В принципе уже PCID должно быть достаточно, пойду гляну, чего там в ведре от EL наворотили тогда.
     
  • 5.79, anomymous (?), 15:08, 07/01/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Короче да, погорячился я насчёт пользы от PCID/INVPCID. И RH тут не при чём, в ванильном ядре то же самое.
    С PTI процедура переключения контекста очищает оба типа трансляций, то есть всё равно имеем полный флаш, хоть с PCID, хоть без.

    Более того, от PCID без INVPCID даже просто для оптимизации сброса TLB толку не много, каждый флаш в пространстве ядра всё равно приводит к полной инвалидации трансляций для всего юзерспейса.

     
     
  • 6.102, Аноним (-), 08:10, 09/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    что-то странное вы говорите товарищ.

    .macro ADJUST_KERNEL_CR3 reg:req
            /* Clear "KAISER bit", point CR3 at kernel pagetables: */
            andq    $(~KAISER_SWITCH_MASK), \reg
    .endm

    .macro ADJUST_KERNEL_CR3_PCID reg:req
            bts     $X86_CR3_PCID_NOFLUSH_BIT, \reg
            /* Clear "KAISER bit", point CR3 at kernel pagetables: */
            andq    $(~KAISER_SWITCH_MASK_PCID), \reg
    .endm


    обратить внимание на 2 разницы..

     
     
  • 7.104, anomymous (?), 12:16, 09/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Это не единственный момент во всей истории. Почитайте код внимательно :)
     
     
  • 8.105, anomymous (?), 12:19, 09/01/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Особенно всё, что связано с INVPCID и флагом около него Ну и собственно можно д... текст свёрнут, показать
     
  • 2.111, Dmitriy (??), 12:52, 10/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    как вы "на лету" включаете/выключаете KPTI? RHEL7?
     
     
  • 3.112, пох (?), 23:19, 10/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    rhel6. Но мне нравится ход ваших мыслей.

    там, кстати, больше одного переключателя: https://access.redhat.com/articles/3311301

     

  • 1.54, iCat (ok), 18:34, 06/01/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    "Незначительное"... Как-то не утешает...
    Блин! Откуда же такая задница вылезла?!
    ...с 1995 года, оказывается, те, кто знал - читали всё, что хотели...
    Но не это главное. Главное, что сейчас миллионы систем "просядут" на 10-30% производительности, или останутся "открытой книгой" для "умельцев"...
    Или всё-таки "умелец" должен обладать весьма недюжинными возможностями?
    Тогда можно не сильно осторожничать...
    Тем более, что основные браузеры уже сильно затруднили использование этой дурки.
    Лишь бы не впендюривали насильно!
     
     
  • 2.61, ы (?), 22:08, 06/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Достаточно быстро выйдет очередной апдейт wannacry
     

  • 1.56, Maxtor (?), 19:42, 06/01/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Google - враг мой. Вечно врет, непонятно в чем его выгода, ведь правда лежит на поверхности. Проверил свои сервера с этим патчем и без, потеря производительности почти 40%. Значит, "незначительное"?
     
     
  • 2.58, VINRARUS (ok), 20:57, 06/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Google - враг мой. Вечно врет, непонятно в чем его выгода, ведь
    > правда лежит на поверхности. Проверил свои сервера с этим патчем и
    > без, потеря производительности почти 40%. Значит, "незначительное"?

    Прогони игру, по легенде должно полегчать. xD
    ПС: печально, значит размер попы не преувеличен.

     
  • 2.65, Crazy Alex (ok), 00:10, 07/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Вряд ли врут, оно от типа назгрузки сильно зависит. В прицнипе вменяемый софт и так старается лишних сисколлов избегать, может, у гугла это и хорошо получается
     
     
  • 3.82, Аноним (-), 15:43, 07/01/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Redis-Server просел на 50%
     
     
  • 4.83, Andrey Mitrofanov (?), 15:47, 07/01/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Redis-Server просел на 50%

    Продажи инлела поднялись на 100%  </>

     
     
  • 5.85, Маркетинговая макак из Intel (?), 18:13, 07/01/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    1500%
     

  • 1.60, Какаянахренразница (ok), 21:49, 06/01/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Гугл считает незначительным конец света.
     
  • 1.62, commiethebeastie (ok), 22:52, 06/01/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Google спасает NASDAQ.

    Пузыри гораздо толще всех материальных ценностей.

     
  • 1.63, Аноним (-), 22:58, 06/01/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Автопросизовители отзывают автомобили если обнаружена критическая проблема.
     
     
  • 2.87, RobotsCantPoop (?), 20:44, 07/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    А если в бортовых/развлекательных системах стоят процы от интел, линух и есть доступ в дикие интернеты, то что? Почешутся или уязвимость ничто -- продажи всё!
     

  • 1.64, Аноним (-), 23:04, 06/01/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Получается сейчас процессоры лучше не покупать? Нужно дождаться выхода принципиально новых моделей?
     
     
  • 2.66, Crazy Alex (ok), 00:11, 07/01/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Нужно подождать пару недель пока станет всё ясно с AMD, с шансами у них всё в порядке. А "принципиально новых" придётся год ждать как минимум.
     
     
  • 3.95, Oxhorn (?), 19:45, 08/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Да и не факт что через год Intel  пофиксит, они там не идиоты - они знали о проблеме ещё на стадии дизайна,  только вот ничего не делали чтобы не терять в приросте производительности.
     
  • 2.113, Аноним (-), 10:11, 12/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ага, принципиально новых моделей с принципиально новыми дырами :)))
     

  • 1.71, Онаним (?), 09:15, 07/01/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ждём ебилдов... Ubuntu 16.04, апдейтов ведра всё нет и нет :-(
     
     
  • 2.73, Аноним (-), 10:58, 07/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Все плохо https://people.canonical.com/~ubuntu-security/cve/2017/CVE-2017-5754.html

    Source: linux (LP Ubuntu Debian)
    Upstream: pending
    Ubuntu 12.04 ESM (Precise Pangolin): pending
    Ubuntu 14.04 LTS (Trusty Tahr): pending
    Ubuntu 16.04 LTS (Xenial Xerus): pending
    Ubuntu 17.04 (Zesty Zapus): pending
    Ubuntu 17.10 (Artful Aardvark): pending
    Ubuntu 18.04 LTS (Bionic Beaver): pending

     

  • 1.74, Аноним (-), 13:16, 07/01/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    https://forums.aws.amazon.com/thread.jspa?threadID=269858

    А вот пользователи амазона - очень хорошо заметили провал производительности

     
  • 1.88, Анонимный Алкоголик (??), 22:43, 07/01/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Вероятно после патча у Google DOS не случился, а всё остальное им "незначительно"...

     
     
  • 2.89, Andrey Mitrofanov (?), 10:05, 08/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Вероятно после патча у Google DOS не случился, а всё остальное им
    > "незначительно"...

    +кстати, "свежее" прочтение субжа:

    "никто в гугль не может быть уволен за то, что покупает у интель".

     

  • 1.94, Oxhorn (?), 19:41, 08/01/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Конечно незначительная потеря для google, они могут себе позволить потратится на доп сотню серверов.
     
  • 1.99, Аноним2 (?), 00:26, 09/01/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Мне вот интересно, производители всяких ультрабыстрых SSD поправят количество iops'ов в описании к своим продуктам, или соврать ещё на 20-30% такая уж большая проблема для рынка накопителей.
     
     
  • 2.100, Алког (?), 05:16, 09/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Мне вот интересно, производители всяких ультрабыстрых SSD поправят количество iops'ов
    > в описании к своим продуктам, или соврать ещё на 20-30% такая
    > уж большая проблема для рынка накопителей.

    А при чём здесь SSD? (производительность SSD и компъютера с ним - разные вещи).

     

  • 1.109, Аноним (-), 01:00, 10/01/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Торренты активно работают с диском и сетью, значит ли это что теперь запущенный торрент клиент начнет сильно загружать систему? :)
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

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