Spoiler — новая уязвимость в процессорах Intel

браузер на специальном ядре

У тебя скорее всего даже иксы не запустятся.

Сложные математические вычисления.IMKL тащит.

на каком-нибудь условном ВПС когда ты хочешь похакать соседей времени достаточно много.

На одном ядре, не параллелящиеся процессы в случае какого-то оптерона и свеженького ксеона - всё верно. В противном случае ложь.

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

Rowhammer закрыли TRR-ом ещё где-то в 2013-ом, не?

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

Мне даже нереалистичные на ум не приходят. Что с этой информацией делать-то?

Загугли бенчмарки в задачах CFD (FVM), FEA и подобных, где идет работа с большим числом матриц. Удивишься.

https://www.tomshardware.com/reviews/amd-ryzen-7-1800x-cpu,4951-10.html

первая ссыль в гугле. Дальше смотреть смысла уже не вижу.

Ты опять продемонстрировал свою некомпетентность. Дело не в библиотеках и шаблонах, а в том, как их использовали. Штеуд делает изначально дефективные процессоры. Только конченный дебил это отрицает.

Короче те кто ищут дыры в железе - мудаки, и убивать их надо при рождении. Гореть им в аду.

Почему они мудаки, а не ты?

У красных есть Spectre. Но дело не в этом. Дело в том, что устранение уязвимостей у красных на уровне софта не бьёт по производительности, чего нельзя сказать про синих.

За амуду давно взялись. Вот только почему-то ещё до всех этих шумих уязвимости находили в основном в штеуде.

Смотрим pdf...

То есть, только 1 строчку из пдф и осилили?

Э... А открыть /proc/self/pagemap не проще?

   Since Linux 4.0 only users with the CAP_SYS_ADMIN capability can get PFNs.
   In 4.0 and 4.1 opens by unprivileged fail with -EPERM.  Starting from
   4.2 the PFN field is zeroed if the user does not have CAP_SYS_ADMIN.
   Reason: information about PFNs helps in exploiting Rowhammer vulnerability.

И главное — нахрена? Я не вижу вектора атаки.

Если вы только 1 строчку из ПДФ осилили, то да, не увидите. Если же хоть немного почитать, то там будут описаны другие техники атак, известные и ранее, которым не хватало именно этой информации для боевого применения. И приведены оценки, во сколько раз сократилась сложность применения этих других атак. И подробно разобран кейс с rowhammer'ом.

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

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

К примеру, HT это разработка АМД, а не Intel.

На самом деле это разработка куда более ранняя. HT это маркетинговое название возможности, предоставляемой процессором. Этот механизм ещё в DEC Alpha был.

На Zen всяко найдётся, но заплатка по производительности не ударит, как всегда.

Вот поэтому ты идёшь нахрен.

Ну да. Во всех тестах кроме одного Rodinia крашнулась, в LAMMPS в большей части тестов чуть быстрее оказался, в FFTW очень сильно отстает в производительности, в Convolution определил в одном тестеиз двух, дальше писать лень, там лишь один из четырех оставшихся тестов за рузеном.

Итого, по совокупности 1800X даже с разгоном сливает i7. А мы вообще-то говорили о Epyc vs Xeon,где разница в пользу Intel ещё очевиднее.

Дальше смотреть смысла уже не вижу.

Действительно, дальше лучше нее смотреть, а то манямирок амудефанатика совсем сломается.

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

Лоооооол

У красных есть Spectre.

Спектре вообще не требует никаких ошибок в дизайне проца. Просто если есть бранч предиктор и нет ASID/PCID, то спектре будет работать. Но ASID/PCID вроде бы есть, а спектре всё равно работает? Причина тому кроется вовсе не в АМД, а в том, что кто-то изъебнулся засунуть джит-компиляторы (BPF) прям в ядро (linux). Кто бы это мог сделать? Точно не АМДшники. АМД себя очень хорошо последнее время показывает, и не надо верить заявлениям в стиле «а вот спектре у них таки работает» - нет, только в линуксе он работает. Даже микросовт джиты в ядро не пихает.

Во всех тестах кроме одного Rodinia крашнулась

Так может, проблемы в самих бенчах?

1800X даже с разгоном сливает i7

Он не позиционируется рядом с i7. Ни на какие мысли не наводит?

Epyc vs Xeon,где разница в пользу Intel ещё очевиднее.

Как раз таки наоборот.

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

Лоооооол

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

А теперь проверку, есть ли право у процессора получать данные делает софт, за счёт чего и все тормоза. Собственно, АМД сумели поправить микрокод, а интел - нет, в силу разных дизайнов. Так что удваиваю.

Ну вот если заплатка не ударит по производительности -> АМД будет быстрее.

АМД сумели поправить микрокод, а интел - нет, в силу
разных дизайнов.

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

АМД мельтдауном не страдали. А исправления вариаций спектра не затронули производительность АМД, а у интела там было весело со всех сторон. Я про l1tf, когда интел там даже бенчмарки хотел запретить после очередного обновления микрокода - уж очень просаживалось.

Ты получаешь деньги за пропаганду в зарплатном окошке Красненьких, поэтому наезжаешь на мой любимый Штеуд!

Не не не. Не платят нам красные (. Мы волонтёры.

Так может, проблемы в самих бенчах?

Если программа не готова для Ryzen, это проблема для покупателей Ryzen.

Он не позиционируется рядом с i7

Разве цифра 7 в названии не означает старшинство в десктопной линейке?

Как раз таки наоборот.

Единственный тест в FVM и FEA, который я нашел, был в ANSYS и там Epyc медленнее более чем в 2 раза.

Я про архитектуру посмеялся.

То есть, только 1 строчку из пдф и осилили?

Нет, просто это была самая ценная строчка. И, кстати, далеко не первая.

Since Linux 4.0 only users with the CAP_SYS_ADMIN capability can get PFNs.

Уже 4 года не актуально, да? Ну так и исследование не актуально, о том и речь. Интересно, но не актуально.

И подробно разобран кейс с rowhammer'ом.

Решение которого было предложено 6 лет назад. И который к этой «уязвимости» отношения не имеет, он работал и без неё, и фиксится вне зависимости от неё.

К примеру, взять тот же meltdown. Там нужно было знание маппинга

Физического маппинга? В meltdown? И зачем оно там было нужно? Там чтение смапленой памяти по её виртуальному адресу, не?

Разве цифра 7 в названии не означает старшинство в десктопной линейке?

Иии? Эти райзены не догнали интел, второе поколение стало не плохим.

Единственный тест в FVM и FEA, который я нашел

ты понимаешь, что там тоже не всё так гладко?

https://www.servethehome.com/intel-is-serving-major-xeon-discounts-to-combat-...

Как бы вот такое говорит явно о том, что эпик дешевле по прроизводительности на бакс, и сильно :)

эпик дешевле по прроизводительности на бакс, и сильно

Конкретно для кейса ANSYS Epyc выходит дороже по производительности на бакс. Для серверов, не предназначенных для вычислений — не знаю, наверно дешевле.

В первую очередь системы продемонстрировали совершенно различную работу с кешем и памятью, обусловленную их принципиально различным строением. Каждое ядро Skylake-SP располагает 1 Мбайт L2-кешем с латентностью 13 тактов (в Broadwell-EP кеш второго уровня имел размер 256 Кбайт и латентность 11 тактов). Общий на процессор L3-кеш формируется из расчёта 1,375 Мбайт на ядро, обладает неинклюзивным (виктимным) принципом работы и имеет среднюю латентность 77 тактов (против 44 тактов ранее).

В процессорах EPYC L2-кеш меньше — всего 512 Кбайт на ядро, но зато его латентность — 12 тактов. Что же касается L3-кеша, то он не общий, как у Intel, а рассредоточен по четырёхъядерным комплексам CCX, которых в каждом кристалле Zeppelin размещено по две штуки. Сам кеш тоже имеет эксклюзивный (виктимный) принцип работы, однако его латентность сильно зависит от того, где расположены запрашиваемые данные — в одном CCX с генерирующим запрос ядром, в соседнем на кристалле, или вообще в другом кристалле. В лучшем случае латентность составляет 35 циклов, в худшем — может быть выше на порядок. Иными словами, несмотря на то, что AMD говорит о L3-кеше как о едином массиве ёмкостью 64 Мбайт, правильно говорить, что он в EPYC имеет формулу 8 x 8 Мбайт.

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

Я про архитектуру посмеялся.

А чего смешного, если у всех х86 процов уже давно внутри RISC, и обвязка поверх него, для эмуляции х86? И обвязка эта далеко не маленькая, состоящая из jit-компиляторов и кучи другой фигни, где обязательно есть место багам и уязвимостям.

Конкретно я пояснил в цитатке про кэш. Так что если софт правильно оптимизировать - всё может оказаться совсем не так. Ну и под эпики планировщик надо править, таки дела.

Физического маппинга? В meltdown? И зачем оно там было нужно?
Там чтение смапленой памяти по её виртуальному адресу, не?

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

Решение которого было предложено 6 лет назад. И который к
этой «уязвимости» отношения не имеет, он работал и без неё

Они разобрали это как пример ускорения эксплойта на 2 порядка. У них там перечислены и другие техники, для которых эта инфа актуальна, но уже без детального разбора. Не мне судить, какие из этих техник актуальны до нынешних времён, но если даже допустить, что никакие - всё равно, количество бывших техник атаки, нуждающихся в этой инфе, велико. А значит, скорее всего, будущие техники атаки уже будут основываться на этом исследовании, и быстрее работать. Но опять же, кто докажет, что все техники, что они перечислили как ускоренные их алгоритмом, уже не актуальны? Сомневаюсь, что это так. И только вы один тут утверждаете обратное - может, время попросить у вас пруф?

А чего смешного, если у всех х86 процов уже давно внутри RISC, и обвязка поверх него, для эмуляции х86? И обвязка эта далеко не маленькая, состоящая из jit-компиляторов и кучи другой фигни, где обязательно есть место багам и уязвимостям.

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

А исправления вариаций спектра не затронули
производительность АМД

По тому, что, насколько я знаю, и исправлениями-то не являлись. Просто ввели барьерные инструкции, позволяющие сбросить бранч-предиктор. Пользы от которых около нуля, когда есть ASID/PCID, и НЕТУ джитов в ядре... То есть, по сути, АМД скорее перестраховались, чем что-либо исправили. Я не к тому, что в АМД не может быть багов. Просто нельзя микрокод апдейт воспринимать как признание уязвимости в проце - это в корне не верно. Большинство людей воспринимают ситуацию именно так: микрокод апдейт был, значит, была и уязвимость. Но такой подход только мешает вендорам выпускать микрокод апдейты, так как это сразу же удар по репутации, хотя причины и нет.

Если бы это было так

Что значит «если»? В любой википедии написано, что это так.

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

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

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

Так l1tf таким образом и исправляли. И не только его.

Ну вот с этим моментом я не достаточно успел разобраться в теме, спасибо.

Малыш, а ты обновил свое железо?

Да эпик сольёт там, где надо AVX-512 и без него никак. Всё остальное там на уровне. Но, с другой стороны, AVX-512 это весьма, так сказать, нишевые инструкции. Очень нишевые.

Т.е. у эпика тупо нет инструкций AVX-512. В случае с AVX-256 эпики покажут производительность сравнимую с Интел в пределах погрешности. Плюс просадка по частоте там много ниже, чем у интел опять же.

В целом да, но это чтение памяти ядра. Чтобы найти в ядре что-то полезное, надо хотя бы знать, что ты читаешь. [...] И вот тут инфа о физ адресах даёт для этого доп информацию.

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

Они разобрали это как пример ускорения эксплойта на 2 порядка.

Да с чего ж вы это взяли-то? Ну где и что там ускоряется на 2 порядка? На 2 порядка по сравнению с чем?

И только вы один тут утверждаете обратное - может, время попросить у вас пруф?

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

Может это я туплю и что-то не понимаю? Начнём с простого, это уязвимость про «critical information about physical page mappings to user space processes», верно? Что именно она даёт?

Она позволяет определить физический адрес по виртуальному? Нет, не позволяет. Тогда какую критическую информацию она предоставляет?

Нет, не позволяет

Это как это?

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