За то, что твой комп будет на X% быстрее, чем Y% других компов

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

Не имеют таких мыслей — да. Но по факту получается именно так.
Ибо ПО делается с рассчетом на актуальное положение вещей. Единствненно что будет некоторый период времени, когда что-то действительно будет тормозить. Но недолго. ПО подтянется. Открутят перделки, уменьшат лимиты и т.д.

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

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

Насколько я понял, из JS _сейчас_ можно сделать то же, что и из нативного кода. Потом, когда отключат SharedArrayBuffer и огрубят таймер, это станет намного сложнее. Ну и патч против собственно Meltdown должен сильно уменьшить опасность.

не кретины а умные люди, чтоб просадку замерить от этих х**фиксов ради интола

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

А vliw нежизнеспособен потому что задача распределения ресурсов NP-полная и не решается в принципе на статическом анализе кода и не решается достаточно эффективно с PGO. Да и живой код с ветвлениями, косвенной адресацией, параллелизмом и зависимостями по данным не способствует эффективной загрузке подобных конвейеров.

не кретины а умные люди

Умные люди не меряют накладные расходы системных вызовов через dd.

Нуу, по крайней мере бы теперь знаешь, что с этим патчем dd проседает в два раза %)

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

Не имеют таких мыслей — да. Но по факту получается именно так.

По факту получается, что ты выбрал незначимый параметр. Можешь еще массу кремния взять - тоже факт.

Да. Это один из бессмысленных «фактов», которые ты любишь.

По факту получается, что ты выбрал незначимый параметр. Можешь еще массу кремния взять - тоже факт.

Ты действительно не понимаешь или прикидываешься? Вроде я достаточно ясно объяснил...

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

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

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

Это ради простоты и доступности теста! глянь яка просадка , в 2 раза почти плиять!

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

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

Вот meltdown потенциально опасен, так как дает возможность любому процессу читать адресное пространство ядра (но не другого процесса)

Другого процесса тоже - вся физическая память отмаплена в ядро. Поэтому Spectre опасен даже с KPTI - если найти в ядре код, который можно померять, можно прочитать память других процессов.

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

а в сочетании с meltdown да - перспективность что-то выгребсти из ядра наличествует.

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

а bpf jit? я просто несмотрел, что это. по слухам тамspectre в чистом виде.

model : 23 model name : Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz

./spectre Reading 40 bytes: Illegal instruction

нет - я просто не смог понять через чтение кода каким образом они обращаются к переменной secret в принципе.

Поэтому Spectre опасен даже с KPTI - если найти в ядре код, который можно померять, можно прочитать память других процессов.

как будто и без спектре такого кода не может быть, паникер и истеричка

Это ради простоты и доступности теста! глянь яка просадка , в 2 раза почти плиять!

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

в 2 раза почти плиять!

Печально, да. Если бы ты еще мог сказать, используются ли у тебя PCID...

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

Кстати, а как с этим в винде? Вот будет прикольно, если такой оверхед в основном в линуксе.

Я на 100% не уверен что вся физическая память размечена и приатачена к каждому экземпляру PageTable. Но если это так - то тогда конечно можно вычитать вообще все что не в свопе ...

есть может под рукой ссылка через какую цепочку чтений памяти можно получить доступ к физической памяти через юзерспэйс и сисколы?

Как думаете, побьёт ли данный пост рекорд страничности?

В windows все тоже самое. Но нужно ждать детальную публикацию єксплоита, возможно есть вероятность залатать не так пагубно для перфоманса (например если там екслоатируется таки исключительные ситуации - то насильно ресетит кеш в обработчике ексепшенов внутри ядра).

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

возможно есть вероятность залатать не так пагубно для перфоманса

или напротив с учетом GDI* и DX*.

время покажет.

думаю, будет работать и на P6 (PPro/P2/P3)

Помните, когда-то давно хакер Крис Касперски (мышихъ) обещал раскрыть уязвимость/закладку в процессорах, а потом уехал в Штаты. Разные околохакерские ресурсы долго спекулировали на эту тему, мол дыра настолько фундаментальная, что достаточно зайти на сайт и вне зависимости от ОС, антивируса и браузера, можно систему поиметь. Насколько я помню он ничего такого и не рассказал так. Хотя я могу и ошибаться. Чем там дело кончилось?

Если они эксплуатировали как раз эти уязвимости, то после закрытие уязвимости утилита от них должна перестать работать. Вот ещё видео https://www.youtube.com/watch?v=yPZmiRi_c-o

$ head -n7 /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 42 model name : Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz stepping : 7 microcode : 0x29

пока что всё Unclear.

Ну я это и имелл виду что это не чисто рабочий эксплоит (типа читает /etc/shadow на CentOS 7 из под простого юзера). Это новый тип атак, про который раньше никто и не задумывался что его можно както применить и от него нужно защищаться.

А на тайминговых атаках по кешу били демки где перехватывали AES256 ключи от работающего ssh и gnupg ...

есть может под рукой ссылка через какую цепочку чтений памяти можно получить доступ к физической памяти через юзерспэйс и сисколы?

В хедпосте есть линки на сайт, где выложены статьи. Думаю, сейчас это самое подробное описание.

И я пошёл спать спокойно.

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

ссылки на демки есть?

Только идиоты используют 512 байтные блоки обмена. Попробуй намерять с 1 байтом - падение будет в 4 раза.

// b.

Крис Касперски (мышихъ) обещал раскрыть уязвимость/закладку в процессорах. Чем там дело кончилось?

Его похоронили.

Анонимность и уязвимости в процессорах Intel (комментарий)

как в воду глядел

Гуглить нужно, но там все просто нету никакого чтения из чужого процеса. Во вредносную программу подгружается системная libcrypt которую используют и gnupg и openssh и которая собственно и реализует AES256 (и кучу других шифров). У AES256 есть статическая таблица перестановок - которая шарится между всеми процесами которые ее подгружают вместе с libcrypt.so. Далее вреднасная программа мониторит какие области таблици из libcrypt.so постоянно попадают в кеш и на основе этого анализа предполагает какой используется ключ для AES256 (но там ключ не точный получался, максимум 98% бит совпадала с реальным ключем - но тоже неплохо).

Его похоронили.

Я про то, рассказал ли он что-то или нет? Просто он (или это так раздували) обещал тогда эпичную дыру в процах от интела. И вот эта новая дыра более чем эпичная. Может быть это про одно и тоже.

У AES256 есть статическая таблица перестановок - которая шарится между всеми процесами которые ее подгружают вместе с libcrypt.so. Далее вреднасная программа мониторит какие области таблици из libcrypt.so постоянно попадают в кеш и на основе этого анализа предполагает какой используется ключ для AES256 (но там ключ не точный получался, максимум 98% бит совпадала с реальным ключем - но тоже неплохо).

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

интересно, можно ли ядерное шифрование через branch prediction buffer поломать из юзерспейса безо всякого spectre?

Попробуй mfence или lfence перед rdtsc:

			_mm_mfence();
			time1 = __rdtsc(); /* READ TIMER */

			_mm_mfence();
			time2 = __rdtsc() - time1; /* READ TIMER & COMPUTE ELAPSED TIME */

Мне замена rtdscp на rtdsc тоже сломала PoC, с mfence снова заработало.

rtdsc, в отличие от rtdscp, может свободно переупорядочиваться (процессором) с другими инструкциями и меряет непонятно что. mfence/lfence этому препятствует.

там типичные ошибки переполнения — гуглятся на ура.

Печально, да. Если бы ты еще мог сказать, используются ли у тебя PCID...

Процессор то свежий и поддерживает, а вот использует ли не знаю. В конфиге ядра есть настройка соответствующая?

$ cat /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 art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault invpcid_single pti intel_pt tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt xsaveopt xsavec xgetbv1 xsaves dtherm arat pln pts hwp hwp_notify hwp_act_window hwp_epp
...

Честно говоря, я не знаю, как это проверить. Теоретически, если PCID есть, оно используется. В dmesg не упоминается?

ничего похожего не видно

PoC для Meltdown

На Github'е уже есть куча всяких PoC для Meltdown/Spectre, но вот какой выбрать из них?

• https://github.com/search?o=desc&q=meltdown&s=updated&type=Reposi...
• https://gist.github.com/search?utf8=✓&q=meltdown

Вот первый попавшийся заявленный для Linux x86_64

https://github.com/corsix/meltdown-poc

Если бы ты еще мог сказать, используются ли у тебя PCID...

Ещё бы способ (доступный для всех) определения этого PCID кто-нибудь подсказал.

$ cpuid | grep INVPCID
      INVPCID instruction                      = false
      INVPCID instruction                      = false
      INVPCID instruction                      = false
      INVPCID instruction                      = false

Кто-то может пояснить, почему INVPCID есть в выхлопе, а PCID нет?

// Core i3 370m

pcid в /proc/cpuinfo

Вопрос, используется ли он. Если с ним падение почти в 2 раза - это совсем печально.