Meltdown и Spectre — названия двух атак на процессоры Intel/AMD/ARM64/Power

надо показывать, что ты врешь.

каким это образом ты показываешь?

См. выше.

ты привел пример эксплоита, который читает данные?

Я - нет. Специалисты привели: https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with...

Ну вот есть у меня очень нагруженный 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, благо там эксплуатировать уязвимости некому.

См. выше.

посмотрел. увидел:

Spectre is harder to exploit than Meltdown, but it is also harder to mitigate. However, it is possible to prevent specific known exploits based on Spectre through software patches.

это мой поинт через весь тред. так что лжец это ты

посмотрел

Я уже знаю, что ты читаешь выборочно.

лжец это ты

CVE-2017-5753, идиотик.

если у тебя вместо своих мозгов cve - то идиотик это ты

ко-ко-ко эльбрус нинужен

Meltdown и Spectre — названия двух атак на процессоры Intel/AMD/ARM64/Power (комментарий)

Судя по спискам, мой ведроидный процессор подвержен meltdown. Смотрю, что yalp предлагает обновить все используемые мной приложения из гуглплея. У всех даты обновления со 2 по 6 января.
Что-то очково.

тоже подвержено или что?

А KPTI дает раздельные адресные пространства пользователя и ядра для 32-битных приложений?
Т.е. в качестве побочного эффекта теперь 32-битное приложение сможет напрямую адресовать 4 гига вместо 3?

нет, это не связанные вещи

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id...

+ nopti [X86-64] Disable kernel page table isolation

+ pti= [X86_64]

+ Control user/kernel address space

isolation:

+ on - enable

+ off - disable

+ auto - default setting

вот такие пирогиСкатятами

Т.е. KPTI только для x64_64 и 32-битных систем не касается?

Т.е. KPTI только для x64_64

да

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

Мапится. Сплит 3G/1G обычно (3GB - user, 1 GB - kernel).

да, это я облажался. не мапится вся физическая память.

и вот забурлило https://www.ixbt.com/news/2018/01/05/intel-poluchila-tri-iska-v-sud-v-svjazi-...

Уж хотя бы на прокси давали ссылку, а то начинающие конспирологи могут и не понять :)

Meltdown и Spectre — названия двух атак на процессоры Intel/AMD/ARM64/Power (комментарий)
Тут вот ещё один спорщик нарисовался.

ну что за кретины меряют однопоток ?

Не однопоток, а скорость io. Очевидно же!

«работает - не трожь».

«работает эксплоит - не трожь», если точнее

Это не забурлило, это до хрена людей, которые желают заплатив 100 баксов за камень, отщепнусудить у кормораций миллионы. И получается. Дерьмократия-с.

А может ещё дядя майор с паяльником придти и попросить обратиться спекулятивно к массиву по индексу минуя планировщик задач.

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

в котором чтоб при копировании через nfs асинхронно 50гигового файла по FastEthernet система колом не становилась

Какой смысл имеет данное слово? Асинхронно по отношению к чему?

Вот это круто, я на тройке несколько игрушек недопрошёл, а на эмулях играть совсем не то, а тут всё пропатчат, и досовские игры полетят как на родном железе!

Ещё и оптимизировать софт начнут!

2. есть и другие способы атаки на измеримый код

Если есть другие баги, то этот можно не фиксить - гениальная логика(сарказм)

Уж хотя бы на прокси давали ссылку, а то начинающие конспирологи могут и не понять :)

Если не поняли - их время ещё не пришло >_<

the show must go on - http://www.opennet.ru/opennews/art.shtml?num=47866

Прям как обвинения в изнасилованиях в Голивуде...

Уж хотя бы на прокси давали ссылку

Это не спортивно :)

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

В результате при асинхронном копировании засирается I/O буфер гигабайтами данных, которые система не успевает передать по сети и всё становится колом, пока не придёт oomkiller.

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

а расхлёбывать (платить производительностью) потом будем все до единого.

Speculative Execution Exploit Performance Impacts

https://access.redhat.com/articles/3307751

Rick rolling, лол. Причём спёрли мой код.

https://github.com/RealJTG/Meltdown/commit/aa958352457014cfdd91682425d8a2cf9a...

в nfs есть два режима копирования - синхронный и асинхронный (дефолт). В синхронном клиент дожидается ответа от сервера о том, что flush сработал. После этого копируется следующий кусок данных. В асинхронном клиент не дожидается ответа от сервера и шлёт следующий кусок данных сразу же.
В результате при асинхронном копировании засирается I/O буфер гигабайтами данных, которые система не успевает передать по сети и всё становится колом, пока не придёт oomkiller.

Понятно. Я не знаю может ли ядро проследить за размером буфера или же это целиком на совести приложения, но прекрасно знаю что если одно приложение перестало влезать в память, то свопится будет всё.

А «для firefox» украдено у corsix: https://github.com/corsix/meltdown-poc

Не пугай людей, и то и другое требуют наличия страницы в L1 кэше.

n order to provide more detail, Red Hat’s performance team has categorized the performance results for Red Hat Enterprise Linux 7, (with similar behavior on Red Hat Enterprise Linux 6 and Red Hat Enterprise Linux 5), on a wide variety of benchmarks based on performance impact:

Measureable: 8-19% - Highly cached random memory, with buffered I/O, OLTP database workloads, and benchmarks with high kernel-to-user space transitions are impacted between 8-19%. Examples include OLTP Workloads (tpc), sysbench, pgbench, netperf (< 256 byte), and fio (random I/O to NvME).

Modest: 3-7% - Database analytics, Decision Support System (DSS), and Java VMs are impacted less than the “Measurable” category. These applications may have significant sequential disk or network traffic, but kernel/device drivers are able to aggregate requests to moderate level of kernel-to-user transitions. Examples include SPECjbb2005, Queries/Hour and overall analytic timing (sec).

Small: 2-5% - HPC (High Performance Computing) CPU-intensive workloads are affected the least with only 2-5% performance impact because jobs run mostly in user space and are scheduled using cpu-pinning or numa-control. Examples include Linpack NxN on x86 and SPECcpu2006.

Minimal: Linux accelerator technologies that generally bypass the kernel in favor of user direct access are the least affected, with less than 2% overhead measured. Examples tested include DPDK (VsPERF at 64 byte) and OpenOnload (STAC-N). Userspace accesses to VDSO like get-time-of-day are not impacted. We expect similar minimal impact for other offloads.

NOTE: Because microbenchmarks like netperf/uperf, iozone, and fio are designed to stress a specific hardware component or operation, their results are not generally representative of customer workload. Some microbenchmarks have shown a larger performance impact, related to the specific area they stress.

И ещё раз: https://github.com/paboldin/meltdown-exploit

Если есть другие баги, то этот можно не фиксить - гениальная логика(сарказм)

ты не понимаешь в чем мой поинт. _корректно_ написанное ПО без багов spectre не аффектит. это полностью подтверждают авторы исходного исследования:

However, it is possible to prevent specific known exploits based on Spectre through software patches.

следовательно нет уязвимости spectre, может быть только кривой софт, да и то пока список уязвимого софта жиденький. почему cve применило термин «уязвимость» я не знаю, я днище знакомый с си и ядром только в своих радиолюбительских поделках которые сам спаял с SoC на базе arm9 с ядром из sdk, не мне обсуждать терминологию безопасников, я в этом нуль, но с точки зрения меня как простого юзера - уязвимости нет, нет никакого универсального кода, который позволяет обходить гарантированную процессором защиту и читать чужую память, как в случае с мельдонием.

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

However, it is possible to prevent specific known exploits based on Spectre through software patches.

ты не понимаешь в чем мой поинт. _корректно_ написанное ПО без багов spectre не аффектит

Приложение «2» не должно читать память «1» независимо ни от качества «1», ни от качества «2».

в таком случае тебе следует прекратить использование компьютеров, ведь в приложении 1 всегда может не быть проверки buffer overflow или выхода за границу массива

в таком случае тебе следует прекратить использование компьютеров

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

ведь в приложении 1 всегда может не быть проверки buffer overflow или выхода за границу массива

Это касается только особо привилегированного кода. Приложение от рута упадёт/повредит себя(«2»). Оно не залезет в «1». Это только ядро и его модули могут подобное, но пока что, к счастью, не нужно запускать непроверенные ядра и модули.

Я пытаюсь аргументировать, что эти подозрения откровенно глупы, но к сожалению не могу этого сделать без увода в «запрещенную тематику». К сожалению, не в состоянии понять, почему «у них» закладок точно нет, а «у нас» 100% есть обязательно. Это какой-то навязчивый синдром у товарищей.

почему «у них» закладок точно нет

Есть и это всем хорошо известно

Создай отдельную тему.

Хорошо известные закладки - это уже не закладки.

Какие? Я не слышал о таком. Ты про те, что выглядят как ошибки проектирования?

перетащи это дерьмо в толкс плз как-нибудь. или в клуб

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

https://www.computerworld.ru/news/Intel-obeschaet-zaplaty-obespechivayuschie-...

Но ни слова о том есть ли различия в ситуации с 32 и 64 битными системами.