LINUX.ORG.RU

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

 , , ,


4

5

Снова спекулятивное исполнение инструкций в процессорах Intel пятого поколения (сегодня это все выпускаемые процессоры Intel) привело к обнаружению уязвимости, названной исследователями «Spoiler». Грубо говоря, эта уязвимость основана на особенностях работы с DRAM, исследователи утверждают, что атака может быть применена через JavaScript браузера. Известных способов устранения сегодня не существует.


Примечательно, что компания Intel была предупреждена о существовании уязвимости ещё 1 декабря 2018 года, однако, не предприняла никаких действий. Исследователи не смогли реализовать атаку ни на каких других процессорах: ни на чипах AMD, ни каких-либо ещё в связи с различными внутренними архитектурами процессоров. По словам исследователей, уязвимость может быть исправлена только архитектурно и у Intel, по различным оценкам, может уйти на это около 5 лет.

>>> Подробности



Проверено: Shaman007 ()

Ответ на: комментарий от Thero

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

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

anonymous ()
Ответ на: комментарий от A-234

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

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

anonymous ()
Ответ на: комментарий от RTP

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

Quasar ★★★★★ ()
Ответ на: комментарий от Woolf

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

Quasar ★★★★★ ()
Ответ на: А где уязвимость-то? от anonymous

Re: А где уязвимость-то?

Смотрим 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. Там нужно было знание маппинга (теперь оно есть), и возможность нужную страницу по-быстрому в кэш занести (этого пока так и нет). То есть, мельтдауну они помогли сильно, но, как я понял, боевых эксплойтов с ним всё равно пока не ожидается. Но были и другие техники, которые теперь переидут из разряда теоретических в разряд боевых.

anonymous ()
Ответ на: комментарий от unixnik

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

Quasar ★★★★★ ()
Ответ на: комментарий от Woolf

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

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

Quasar ★★★★★ ()
Ответ на: комментарий от Woolf

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

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

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

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

anonymous ()
Ответ на: комментарий от Quasar

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

Лоооооол

anonymous ()
Ответ на: комментарий от Quasar

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

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

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

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

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

Woolf ()
Ответ на: комментарий от anonymous

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

Лоооооол

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

anonymous ()
Ответ на: комментарий от anonymous

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

Woolf ()
Ответ на: комментарий от Woolf

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

Woolf ()
Ответ на: комментарий от Woolf

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

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

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

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

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

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

anonymous ()
Ответ на: Re: А где уязвимость-то? от anonymous

Re: А где уязвимость-то?

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

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

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

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

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

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

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

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

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

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

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

Woolf ()
Ответ на: комментарий от Woolf

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

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

anonymous ()
Ответ на: комментарий от Woolf



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

Woolf ()
Ответ на: комментарий от anonymous

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

Woolf ()
Ответ на: Re: А где уязвимость-то? от anonymous

Re: А где уязвимость-то?

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

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

anonymous ()
Ответ на: Re: А где уязвимость-то? от anonymous

Re: А где уязвимость-то?

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

anonymous ()
Ответ на: комментарий от Woolf

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

Thero ★★★★★ ()
Ответ на: комментарий от Thero

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

Woolf ()
Ответ на: комментарий от Woolf

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

Woolf ()
Ответ на: Re: А где уязвимость-то? от anonymous

Re: А где уязвимость-то?

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

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

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

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

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

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

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

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

anonymous ()