Компания Google сообщила (https://security.googleblog.com/2018/01/more-details-about-m...) о внедрении патчей KPTI и retpoline для блокирования атак Meltdown и Spectre (https://www.opennet.me/opennews/art.shtml?num=47856) на своих Linux-серверах, в том числе обслуживающих поисковую систему, Gmail, YouTube и Google Cloud Platform. Несмотря на то, что теоретически данные патчи приводят к возникновению дополнительных накладных расходов при выполнении системных вызовов, влияние на производительность обоих патчей при реальной нагрузке Google при выполнении большинства задач оценивается как незначительное. Напомним, что в синтетических тестах наблюдалось (https://www.opennet.me/opennews/art.shtml?num=47849) проседание производительности от 5% до 30% и даже 60%.Патч KPTI (https://lwn.net/Articles/738975/) (Kernel Page Table Isolation) нацелен на блокирование уязвимости Meltdown на уровне ядра Linux и основан на идее разделения памяти ядра и пространства пользователя. Патч Retpoline (https://support.google.com/faqs/answer/7625886) предложен Google для блокирования атаки Spectre и основан на применении специальной последовательности инструкций, исключающих вовлечение механизма спекулятивного выполнения. Кроме модификации ядра, реализация Retpoline также подразумевает применение для сборки специально модифицированного компилятора (GCC (https://lkml.org/lkml/2018/1/3/871), Clang (https://reviews.llvm.org/D41723)).
URL: https://security.googleblog.com/2018/01/more-details-about-m...
Новость: http://www.opennet.me/opennews/art.shtml?num=47864
Стало быть, драмы не будет.
>> Стало быть, драмы не будет.Драма есть уже — вишь, минусаторы страдают.
Проблема с обеими «уязвимостями» возникает в одной ситуации — когда ПАРАЛЛЕЛЬНОЕ ИСПОЛНЕНИЕ кода оформляется не ручками, с контролем гонок и памяти на уровне исходников, а «хреньворками».
146% посетителям сего богоспасаемого места — это, как зайцу стоп-сигнал.
Давай, оформляй всю необходимую параллельность ручками. Бери исходники, редактируй, отправляй. А я послежу, чтобы ты "хреньворками" не пользовался.Для общего развития: спекулятивное выполнение работает на гораздо более низком уровне, чем традиционная многопоточности. С использованием pthreads ты никак не реализуешь спекулятивное выполнение на том уровне, на каком работает процессор, а даже если и сможешь, то накладные расходы на манипуляцию потоками будут гигантскими. Это если говорить про популярные архитектуры ЦПУ, не VLIW.
Это ты хорошо так сейчас бисер раскидал.
Драма будет, когда эксплоиты начнут работать in the wild - а PoC'и открыты, и начнутся массовые утечки банковских и персональных данных у хомяков. Вот для этой драмы я попкорна купил уже.
У тех банков, которые используют мейнфреймы и неуязвимые by design системы, утечек не будет.
пока не будет личного вызова для васи с чердака
Как мэйнфрейм защитит от кражи трояном данных карты с формы при оплате в инет магазине?
Или паролей от Яндекс-кошелька.
Смысл - троян установившийся под юзером может читать данные других юзеров / программ / системы.
Он и под текущим юзером дел наворочает.
В банках самое убогое ойти.
Еще один аналитик с лора.
увы, какой безопасник признается, что могла и быть утечка, а нерушимая система при легкой секундной мисконфигурации становится оплотом диверсионной работы
GOGLE VAX OpenVMS
Не у всех остался VMS, а тем более VAX.
> Не у всех остался VMS, а тем более VAX.в соседней новости из гзипа выкинули поддержку vms, так что на нём уже особо не погзипуешь
Угу, апдейт для гзипа просто удаляет бинарники gz ungz на этой платформе.
И заодно форматирует диск C ...
Накладывает патч Бармина же
> а PoC'и открыты, и начнутся массовые утечки банковских и персональных данных у хомяков.Им же нечего скрывать, в чём проблема?
> и начнутся массовые утечки банковских и персональных данных у хомяковкак будто для этого нужны были какие-то еще ыксплоиты.
http://www.opennet.me/opennews/art.shtml?num=47613
(напоминаю - оно сливает и счета, и персональные данные - разьве что cvv коды _вроде_бы_ не - ну, пока обезьянка где-нибудь не ошиблась и не перепутала стиль. И складывает их в незащищенные акаунты бестолковых и безмозглых менеджеров в гугле, яндексе, и стапицста индусских лавочках)И чего - его хотя бы с сайта сбербанка убрали? А, ню-ню.
И как ваш попкорн - не засох еще нафиг за два месяца-то?драма будет у страдальцев, прикованных к докерам и прочей контейнерной шелухе, которые (без всяких на то оснований) полагали ее средством дополнительной изоляции, а не средством перекладывания ответственности на никого.
Многие почему-то забыли о такой мелочи, как производительность. Хорошо оптимизированный сплоит на ассемблере читает память со скоростью 2 кб/с. Вопрос: с какой скоростью будет читать память сплоит на JS и сколько байт он успеет прочесть, прежде чем пользователь все-таки заметит, что браузер уже несколько часов как отожрал полностью одно ядро?
>прежде чем пользователь все-таки заметит, что браузер уже несколько часов как отожрал полностью одно ядроПо моим наблюдениям, юзер такое не заметит вообще. Даже на ноутбуке, который начинает громче жужать вентилем. А уж производительность вообще не меняется от плюс-минус одно ядро :)
Насколько я понимаю с такой-же: готовишь js или asm.js такой, которым джитом переводится в требуемый ассемблер и получаешь схожую производительность.
> Google ... оценивается как незначительноеА цифры где? А то для гугла и 50% может оказаться "незначительным", кто ж знает что у них там в головах то %)
Где-то попадалось странное - для более старого интеловского процессора замедления почти не было, а для Coffee Lake было существенно сильнее. Но сходу снова не гуглится
> Но сходу снова не гуглитсяПросто запрос "незначительно" отличается.
Это было что-то англоязычное и там были две конкретные модели процессора - какие-то i7. Ладно, всплывёт если доля истины в этом есть. А если нет - то и чёрт с ним
Если намекали на злонамеренность гугла - то я как раз об обратном, если оно так - то на их процессорном парке и правда не должно было сказаться
в блоге grsec писали о 9% drop на при IPTV раздаче.
Что-то я плохое курю. Фороникс же: https://www.phoronix.com/scan.php?page=article&item=linux-41...То есть я где-то в другом месте читал, но тут разница хорошо видна.
edit: и, как обычно, у него в тестах бардак - там ssd разные, в результате что имнно влияет непонятно, но скорее таки более медленный ssd просто не даёт достаточную нагрузку. Так что версия насчёт разницы в процессорах сомнительна
> То есть я где-то в другом месте читал, но тут разница хорошо
> видна.На нём же, родном - https://www.phoronix.com/scan.php?page=article&item=linux-41...
Там был, я ж тоже помню!, пассаж типа "вот на 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 [...] "
> Но сходу снова не гуглитсяГугол удалил из выдачи
Как раз наоборот. Для гугла 50% это тысячи дополнительных ядер. А для большинства незаметно.
цифры - они в индексе. И поэтому инвесторы гугля действительно могут спать спокойно.
Какое количество картонных серверов еще понадобится ввсести дополнительно. чтобы покрыть издержки - им все равно не расскажут (да и не знает никто), и им это неважно.Статейка написана ровно ради этих индексов - а то после заявлений всяких вредных личностей они что-то нехорошо заворочались.
Ну и да - в очередной раз вспоминая о средней длине члена - grsec меряли (и описали, чем) а гугль - "считает". Но инвесторы (да и индустрия) будут слушать гугля, а не каких-то там.
Просто GOOGLE использует старое протухшее железо
Или АМД
>Просто GOOGLE использует старое протухшее железоДа. В google cloud computing все инстансы на древних процах с низкой частотой. Скайлэйк можно выбрать, но далеко не во всех ДЦ.
Кстати, интересно, почему гуголь не использует амд.
Судя по недавним новостям - интель им по-братски дал кредит под 0% на свои commodity-процы.А то гляди ка - и Google Project Zero "внезапно" открыл уже известные уязвимости (даже названия присвоили!), и Google Cloud зашевелились (это вообще кто такие?). А главное - сколько шуму: PR-война в самом разгаре. Учитывая, за кем сейчас преимущество в вычислительных мощностях, неудивительно, что гугловцы полируют штеудовский сексуальный орган - чай не дураки, рубить сук на котором сидят.
Исторически так сложилось. Pentium III имел самое низкое энергопотребление на операцию.200 млн. процессоров, экономия на каждом по 3-5-10 Вт...
Походу эти Pentium III так и работают там.
>Просто GOOGLE использует старое протухшее железоПроблема появилась с появлением у Штеуда технологии предсказания ветвлений, т.е. в самых первых Пнях.
я ставить эту херню не буду. надеюсь будет опция в ядре чтоб не вкомпиливать.
Наверняка, будет. Только и эксплойты обязательно будут.
Уже есть опция загрузки ядра nopti
Эммм, посмотрел, нихрена не понял. Они там пишут свой собственный вариант инструкции call? Как эта магия retpoline работает вообще? Оно защищает если ядро скомпилировали патченным компилятором, который заменяет везде call на какую-то последовательность команд, но в программе пользовательской может быть не заменено же? Хотя, наверное, можно браузер перекомпилять и хотя бы за javascript-эксплоиты быть спокойными...
Хз как оно работает, но оно не собирается. Собрал их GCC retpoline, собирал ядро и получил кучу undefined reference -_-
Да, оно защищает конкретно ядро. Насколько я понимаю, Сама уязвимость позволяет дотянуться какому-то недоверенному коду до данных в том же процессе, в котором он исполняется, так что, в общем-то, патчить надо только тот софт, где такое возможно. Браузер - первый кандидат... но загрублённые таймеры мне как-то больше по вкусу, браузеры и так тормозить умеют слишком хорошо.
>атака Spectre также может быть блокирована на уровне обновления микрокода CPUОсталось дождаться фиксов от Intel и AMD.
http://news.stfw.ru/41465-yeto-ne-to-chto-nevozmozhno-isprav...
IBM POWER тоже вышла обновка
> Осталось дождаться фиксов от Intel и AMD.ну, здоровенный апдейт микрокода в rhel три дня назад приполз. Что он на самом деле там фиксит (и не надо ли, кстати, его откатить, если не хочешь потери производительности даже с непатченным ведром) - разумеется, большая коммерческая тайна.
>если не хочешь потери производительности даже с непатченным ведромДа куй с ней вообще, с производительностью. Вы чо, совсем все нищeброды на третьепнях, штoле? Лучше подумайте, какого западла они могли туда под шумок напихать. И не был ли этот "подшумок" для того и организован.
Супер очевидно что гугл прикрывает *опу интел.
Он понимает, что intel не будет возвращать серверную продукцию за 10-лет по всему земному шару вендорам.
Пишут, что не сильно замедляет, но сильно греются процессоры от этих патчей.
> Пишут, что не сильно замедляет, но сильно греются процессоры от этих патчей.От двойного переключения контекста ЦПУ, больше переключения богу пустынного кремния!!!
Дык, гугловские программисты и так сисколлы экономили. Потому и несильно у них.
сговор гигантов, нужно поднять продажи, а может сам патч и есть бэкдор мазафака
intel/nvidia с их маркетингом в каждой щели...
Костыли это, а не патчи. Потому что эти "патчи" реально нихрена ничего не патчат. И то, что программно отключается, может обратно программно включаться. Особенно это касается "патчей" Микрософт, где однозначно оставлена недокументируемая лазейка кому-надо включать мельтдаун, а когда надо отключать.Производительность - вопрос вторичный. Потому что процессоры гнилые на уровне их архитекторов - это даже не брак производства. И все последние 20 лет впаривали по сути 286 процессоры с имитацией многозадачности только многогигагерцовые и многядерные.
Хотя начиная с 386 и заканчивая Пентиум Про плюс Сайрикс и Виа вполне возможно были настоящие многозадачники.
А хипстерня сожрала Интел МЕ, сожрёт и мельтдаун. Лишь бы только производительность в игрушках не снизилась.
>[оверквотинг удален]
> Особенно это касается "патчей" Микрософт, где однозначно оставлена недокументируемая
> лазейка кому-надо включать мельтдаун, а когда надо отключать.
> Производительность - вопрос вторичный. Потому что процессоры гнилые на уровне их архитекторов
> - это даже не брак производства. И все последние 20 лет
> впаривали по сути 286 процессоры с имитацией многозадачности только многогигагерцовые
> и многядерные.
> Хотя начиная с 386 и заканчивая Пентиум Про плюс Сайрикс и Виа
> вполне возможно были настоящие многозадачники.
> А хипстерня сожрала Интел МЕ, сожрёт и мельтдаун. Лишь бы только производительность
> в игрушках не снизилась.Скорость System I/O в многопотоке на i7 и выше в 2.5 раза ниже! Софтаврные патчи! AES-NI тоже уже неэффективен на SSD.
Я ж и говорю - костыли костыльные, а не патчи. Хорошо что ещё хоть как-то ползают.
В игрушках и не снижается, как ни странно, а вот на серверах очень даже заметно.
А чего странного. Там условно полтора сискола на кадр.
> недокументируемая лазейка кому-надо включать мельтдаунТак у вас недокументированная лазейка есть все дампы свои выкладывать в публичный доступ. Регулярно...
хе-хе, ну раз гугл утверждает, что патчи не влияют на производительность - значит интел может и дальше штамповать defective-by-design камни; все косяки в железе отныне будут преодолеваться патчами в ядрах ОС
> железе отныне будут преодолеваться патчами в ядрах ОСЯ бы, чессгря, нафиг выкинул KPTI из ванильного ядра, и пусть ССЗБ в интелях пилят их сами или отзывают процы. Причём второе сильно вероятнее. По сути эти патчи оказались злом - продолбавший вендор теперь имеет возможность и дальше клепать глюкодром.
Пускай считает, что хочет. Есть и другие мнения.
> Пускай считает, что хочет. Есть и другие мнения.И все мнения по весу равнозначны. Ну или твое сильно весомее. Да, мой дорогой аналитек?
Ну вот есть у меня очень нагруженный 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, благо там эксплуатировать уязвимости некому.
Да в многопотоке просадки KPTI значительные, можно уже заказывать сервера на AMD.
Угу :( Там даже не в многопотоке дело, а в куче сисколов. Заббикс - это ж обилие форков, отсылок и получений коротеньких пакетов (icmp, snmp), мелких обращений к БД (соответственно к диску). В общем, практически наихудший для KPTI вариант.
> Угу :( Там даже не в многопотоке дело, а в куче сисколов.
> Заббикс - это ж обилие форков, отсылок и получений коротеньких пакетов
> (icmp, snmp), мелких обращений к БД (соответственно к диску). В общем,
> практически наихудший для KPTI вариант.а кто-нибудь сетевое типа Openvpn тестил? там тоже гоняется каждый пакет через kernel-userspace-kernel
интересно, насколько там просело
Сейчас прогоняют WireGuard для k8s.
> userspace - ~20%
> userspace - ~40%Что-то как-то подозрительно. Из-за чего работа в userspace замедляется?
Да ничего подозрительного. Просто рост нагрузки размазался между юзерспейсом и кёрнелспейсом, что и не удивительно. Там же целых несколько эффектов:1. Увеличение времени входа-выхода в/из сискола. Это по идее должно попадать в sy, но у меня есть сомнения насчёт трамплина (не анализировал, могу ошибаться) - скорее всего время нахождения в трамплине будет зачтено самому процессу и попадёт в us.
2. Постоянные сбросы TLB однозначно влияют на общее время выполнения кода как в юзерспейсе, так и в ядре. Причём как раз этот эффект слабо предсказуем и зависит как от числа сисколов, так и от активности работы с памятью / разброса адресов при этом. Zabbix в этом плане с его кучей дочерних процессов - опять же худший вариант.
3. Много мелкого обмена с сетью - много прерываний, а поскольку страницы кёрнелспейса теперь как глобальные не объявляются, появляется проблема с вымыванием TLB после выхода из прерываний.PCID/INVPCID у данного конкретного процессора (Xeon X5670) нет, так что каждый сискол или инт сбрасывает TLB целиком. В общем, при таком числе процессов и объёме постоянного рабочего набора (~20 гиг вместе с MySQL) уже не подозрительно :)
>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 aratPCID
Да, наличие PCID не заметил. INVPCID нет. В принципе уже PCID должно быть достаточно, пойду гляну, чего там в ведре от EL наворотили тогда.
Короче да, погорячился я насчёт пользы от PCID/INVPCID. И RH тут не при чём, в ванильном ядре то же самое.
С PTI процедура переключения контекста очищает оба типа трансляций, то есть всё равно имеем полный флаш, хоть с PCID, хоть без.Более того, от PCID без INVPCID даже просто для оптимизации сброса TLB толку не много, каждый флаш в пространстве ядра всё равно приводит к полной инвалидации трансляций для всего юзерспейса.
что-то странное вы говорите товарищ..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 разницы..
Это не единственный момент во всей истории. Почитайте код внимательно :)
Особенно всё, что связано с INVPCID и флагом около него.
Ну и собственно можно даже просто патч, изменяющий механику системного вызова.
как вы "на лету" включаете/выключаете KPTI? RHEL7?
rhel6. Но мне нравится ход ваших мыслей.там, кстати, больше одного переключателя: https://access.redhat.com/articles/3311301
"Незначительное"... Как-то не утешает...
Блин! Откуда же такая задница вылезла?!
...с 1995 года, оказывается, те, кто знал - читали всё, что хотели...
Но не это главное. Главное, что сейчас миллионы систем "просядут" на 10-30% производительности, или останутся "открытой книгой" для "умельцев"...
Или всё-таки "умелец" должен обладать весьма недюжинными возможностями?
Тогда можно не сильно осторожничать...
Тем более, что основные браузеры уже сильно затруднили использование этой дурки.
Лишь бы не впендюривали насильно!
Достаточно быстро выйдет очередной апдейт wannacry
Google - враг мой. Вечно врет, непонятно в чем его выгода, ведь правда лежит на поверхности. Проверил свои сервера с этим патчем и без, потеря производительности почти 40%. Значит, "незначительное"?
> Google - враг мой. Вечно врет, непонятно в чем его выгода, ведь
> правда лежит на поверхности. Проверил свои сервера с этим патчем и
> без, потеря производительности почти 40%. Значит, "незначительное"?Прогони игру, по легенде должно полегчать. xD
ПС: печально, значит размер попы не преувеличен.
Вряд ли врут, оно от типа назгрузки сильно зависит. В прицнипе вменяемый софт и так старается лишних сисколлов избегать, может, у гугла это и хорошо получается
Redis-Server просел на 50%
> Redis-Server просел на 50%Продажи инлела поднялись на 100% </>
1500%
Гугл считает незначительным конец света.
Google спасает NASDAQ.Пузыри гораздо толще всех материальных ценностей.
Автопросизовители отзывают автомобили если обнаружена критическая проблема.
А если в бортовых/развлекательных системах стоят процы от интел, линух и есть доступ в дикие интернеты, то что? Почешутся или уязвимость ничто -- продажи всё!
Получается сейчас процессоры лучше не покупать? Нужно дождаться выхода принципиально новых моделей?
Нужно подождать пару недель пока станет всё ясно с AMD, с шансами у них всё в порядке. А "принципиально новых" придётся год ждать как минимум.
Да и не факт что через год Intel пофиксит, они там не идиоты - они знали о проблеме ещё на стадии дизайна, только вот ничего не делали чтобы не терять в приросте производительности.
Ага, принципиально новых моделей с принципиально новыми дырами :)))
Ждём ебилдов... Ubuntu 16.04, апдейтов ведра всё нет и нет :-(
Все плохо https://people.canonical.com/~ubuntu-security/cve/2017/CVE-2...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
https://forums.aws.amazon.com/thread.jspa?threadID=269858А вот пользователи амазона - очень хорошо заметили провал производительности
Вероятно после патча у Google DOS не случился, а всё остальное им "незначительно"...
> Вероятно после патча у Google DOS не случился, а всё остальное им
> "незначительно"...+кстати, "свежее" прочтение субжа:
"никто в гугль не может быть уволен за то, что покупает у интель".
Конечно незначительная потеря для google, они могут себе позволить потратится на доп сотню серверов.
Мне вот интересно, производители всяких ультрабыстрых SSD поправят количество iops'ов в описании к своим продуктам, или соврать ещё на 20-30% такая уж большая проблема для рынка накопителей.
> Мне вот интересно, производители всяких ультрабыстрых SSD поправят количество iops'ов
> в описании к своим продуктам, или соврать ещё на 20-30% такая
> уж большая проблема для рынка накопителей.А при чём здесь SSD? (производительность SSD и компъютера с ним - разные вещи).
Торренты активно работают с диском и сетью, значит ли это что теперь запущенный торрент клиент начнет сильно загружать систему? :)