А на райзенах кстати, вылетала компиляция и были перезагрузки в linux. Как в linux работает AMD Ryzen 5 1600x

Ну было. Ну поправили. А вот мне щас сказали, что

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

Есть ещё новые Power и прочие интересные архитектуры. А большинство писюков действительно после покупки можно нести сразу на помойку.

Спектр огребли все архитектуры, вот незадача. Да и цена у Power, как у крыла двух крыльев от самолёта.

Это как это?

А разве позволяет? Каким образом? Я вообще не вижу, что из этого исследования можно извлечь.

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

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

Но на всякий случай они предупредили intel о своём исследовании. Мало ли, вдруг есть какой-то неожиданный вектор атаки, о котором они не подумали, а интеловцы догадаются. Intel никак не отреагировала. Вероятно, они тоже не увидели в этом уязвимости. И, выждав responsible disclosure period, авторы опубликовали исследование.

Вот и всё.

Бурю в стакане подняли журналисты, копипастившие друг у друга один и тот же текст про ужасную уязвимость у Intel, но не AMD. При этом никто не написал, в чём состоит уязвимость и чему она угрожает.

Может, это был вброс AMD-шников?

PS: я не исключаю, что какой-то вектор атаки есть, но я его придумать не могу, даже локальный, не говоря уже про удалённый. И в опубликованной работе я такого вектора тоже не вижу.

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

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

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

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

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

proposes an attack,SPOILER, to efficiently exploit thisleakage to speed up the reverse engineering of virtual-to-physical mappings by a factor of 256 from both nativeand JavaScript environments.

И в другом месте:

The state-of-the-art microarchitectural attacks [22, 42] ei-ther rely on knowledge of physical addresses or are signifi-cantly eased by that knowledge. Yet, knowledge of the physi-cal address space is only granted with root privileges. Cacheattacks such asPrime+Probeon the Last-Level Cache (LLC)are challenging due to the unknown mapping of virtual ad-dresses to cache sets and slices. Knowledge about the physicalpage mappings enables more attack opportunities using thePrime+Probe technique.

Если я правильно понимаю, вы всё это читали, но не согласны?

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

Для своего процесса-то позволяет. Думаю, интерес вызывают другие процессы, а так же маппинг ядра данного процесса. Ответы на эти вопросы в доке - есть. Проблема лишь в том, что у меня тоже нет времени её полностью осилить. :) Могу только вот на этот кусок пока сослаться:

SPOILER can track nearby load operationsfrom  a more
privileged security domain  right after acontext switch

То есть, по крайней мере какой-то прогресс в этом отношении достигнут. Насколько существенный - это надо осиливать доку целиком, может, попробую на досуге.

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

Да повторяю: по тому, что джиты в ядро пихать не надо, а пользоваться ASID/PCID - надо. Проблема не архитектур, а совта. Мельтдаун - это архитектурная проблема.

я правильно понимаю что ты нам предлагаешь производительность всего проца оценивать исключительно по достаточно узкоспецифичным векторным задачам в бенчмарках работающих на AVX?

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

хоть потыкай в нас бенчмрками где протестированы процессоры одного ценового сегмента

Из таких знаю только бенчмарки в ANSYS, собственно, это лидер в области FEM, FVM и т.д., остальные догоняют.

Позже найду тесты, с телефона неудобно.

Наркоман

Эээ. А ничего, что синтетика отражает скорость процессора в том числе и при работе с сервером БД и при работе с веб-сервером, и т.п.? Ну и правильно еще учитывать латенси компонентов и т.п. Я ж не порсто так цитатку о кэшах дерганул. Ну, а для AVX-512 никто эпики в здравом уме применять не будет.

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

Хы. Попробуйте отключить у себя в браузере javascript и прожить хоть день в инете :)

Всё время так живу, браузер с JS у меня есть, но на изолированном аккаунте и запускается сильно реже, чем раз в два дня. ЧЯДНТ?

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

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

Ну где и что там ускоряется на 2 порядка? На 2 порядка по сравнению с чем?

Вы мне задаёте этот вопрос с какой целью?

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

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

Для своего процесса-то позволяет.

Где? Может это я туплю, но не вижу где они получают такую информацию. Да и откуда ей взяться-то? Мы же не читаем никакие данные, просто замеряем время доступа к своим же массивам.

to speed up the reverse engineering of virtual-to-physical mappings by a factor of 256

Вот, из этой фразы следует, что, во-первых, ускоряется не rowhammer, а некий «reverse engineering». А, во-вторых, не понятно, ускоряется по сравнению с чем? В таком виде эта фраза ничего не значит.

Так я тоже могу заявить, что моя программа копирует файлы в 1000 раз быстрее. Быстрее чего? Ну, можно же читать/писать файлы по 1 байту, а моя программа читает по 1000 байт за раз.

Пример не совсем надуманный, я так догадываюсь, они имеют ввиду, что можно было искать коллизии кусками по 4к, а они ищут кусками по 1М, отсюда и ускорение в 1М/4к=256 раз.

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

Тут что-то не так. Я давал вам уже 2 ответа на этот вопрос. Во-первых, в случае мельтдауна, достаточно и своего (правда, из числа страниц, не доступных на чтение). Во вторых, вот это:

SPOILER can track nearby load operations from  a more
privileged security domain  right after a context switch

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

Где? Может это я туплю, но не вижу где они получают такую
информацию. Да и откуда ей взяться-то? Мы же не читаем
никакие данные, просто замеряем время доступа к своим же
массивам.

Блин, а почитать слабо что ли? У VIPT кэша могут быть потенциальные алиасы по физ адресам, когда тэг совпадает, а адреса по факту разные. Буду называть их «алиасы», как в статье, хотя это фейковые алиасы - реально физ адреса разнятся, а только лишь тег в VIPT совпал. На разруливание этих алиасов при чтении уходит время, если в реордер буфере есть ещё сторы на алиасовые страницы. В результате, при чтении из разных виртуальных страниц, и засовывая в реордер буфер запись в другие виртуальные страницы, можно посмотреть, алиасятся ли они по тегу кэша, или нет. Это позволяет сказать, это у них в физическом адресе совпадает сколько-то бит. В начале статьи они по 8 совпадающих бит находят. Мне не охота осиливать её полностью, только чтобы ответить вам, сколько они находят бит в конце статьи, учитывая, что вы и ответы-то не особо читаете.

Пример не совсем надуманный, я так догадываюсь, они имеют
ввиду, что можно было искать коллизии кусками по 4к, а они
ищут кусками по 1М, отсюда и ускорение в 1М/4к=256 раз.

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

Т.е. тех гениев, которые видят в алгоритме/архитектуре изъяны и сообщают об этом - убивать? Так давайте вообще запретим указывать на говнокод и говноархитектуру - абы работало.

ну вот к примеру.

Блин, вот привыкнешь, когда аноним херню пишет, а потом приходишь ты и вызываешь когнитивный диссонанс. Спасибо.

не дірявий

Дякую тобі боже що я не iнтель (@) AMD

Вангую проблемы ущербных шебаппов, с полноценным дополнением в палемуне УМВР.

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

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

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

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

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

Тут что-то не так. Я давал вам уже 2 ответа на этот вопрос. Во-первых, в случае мельтдауна, достаточно и своего (правда, из числа страниц, не доступных на чтение).

Своего чего? Не свои же переменные мы будем читать? Их мы итак прочитать можем. Мы же хотим прочитать недоступную нам память других процессов, верно? Для этого мы используем трюк...

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

Речь о том, что вот этого знания у нас нет. И сабжевая атака его не даёт. Да и никто не даёт. Пусть я хочу считать приватный ключ из памяти sshd. Где мне его искать? Я не то что физический, я даже виртуальный адрес этого ключа не знаю.

SPOILER can track nearby load operations from a more
privileged security domain right after a context switch.
Я, конечно, не пояснил пока, какой именно контекст свич они имеют в виду (между разными процессами, или между ядром и юзер-спейсом), но любой из 2 вариантов можно эксплуатировать.

Можно. Были разные атаки на кеш подобного рода и их вариации: Evict+Time, Flush+Reload, CacheBleed, MemJam... Все они по косвенным признакам пытаются угадать, что в это время делают другие процессы в системе. Но что тут нового?

(если опять на пальцах...) Кеш быстрее обычной памяти. Замеряя скорость чтения памяти можно узнать, в кеше она или нет. Если она уже в кеше — к ней недавно кто-то обращался. А ещё кеш можно чистить (инструкция clflush, например). Итого, если очистить кеш, подождать секунду, затем замерить скорость чтения shared-библиотеки, например libgpg.so, то можно узнать, обращался ли к ней за эту секунду какой-то другой привилегированный процесс чтобы что-то зашифровать.

У VIPT кэша могут быть потенциальные алиасы по физ адресам [...] На разруливание этих алиасов при чтении уходит время, если в реордер буфере есть ещё сторы на алиасовые страницы. В результате, при чтении из разных виртуальных страниц, и засовывая в реордер буфер запись в другие виртуальные страницы, можно посмотреть, алиасятся ли они по тегу кэша, или нет.

С некоторыми ошибками это — описание атаки MemJam: Read-after-write из 2017го. Если повезёт, она позволяет угадать младшие 12 бит адреса, к которым недавно обращались (точнее, там 10 бит, потому что адрес определяется не до байта, а с точностью 32-бита). Но в чём тут вклад spoiler-а?

Это позволяет сказать, это у них в физическом адресе совпадает сколько-то бит. В начале статьи они по 8 совпадающих бит находят. Мне не охота осиливать её полностью, только чтобы ответить вам, сколько они находят бит в конце статьи, учитывая, что вы и ответы-то не особо читаете.

Так, стоп... MemJam угадывает, обращался ли кто-то по адресу, младшие 12 бит которого совпадают с нашим. Она не определяет физический адрес по виртуальному: адреса выровнены по размеру страницы, то есть для 4к-страниц у любого виртуального адреса младшие 12 бит равны младшим 12 битам его физического адреса. Определять нечего!

во фреймах

Я их лет 10 не видел. А может и 15...

Эльбрус, известное дело.

Если бы они так не сопротивлялись собственному распространению...

Речь про iframe, скорее всего.

Эльбрус, известное дело.

Если бы они так не сопротивлялись собственному распространению...

200 штук и он Ваш

http://www.ineum.ru/vk-elbrus-401pc

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

То есть, если вам пересказали пару строчек из предисловия статьи, то это переход в техническое русло?

Мы же хотим прочитать недоступную нам память других
процессов, верно?

Задавая этот вопрос такое кол-во раз, и не понимая ответ, вы всерьёз заставляете меня сомневаться в перспективности траты моего времени на эту затею. :) Я вам уже сто раз сказал, что для мельтдауна мы должны знать маппинг _своей_ виртуальной памяти на физическую, а не чужой. По тому, что ядро примаплено к юзерспейсу сверху. Виртуальное пр-во у них с ядром одно! Если вам это непонятно и с 3 раза, то я закончу на этом.

(на пальцах, если кому интересно) 64-битное ядро мапит себе
всю физическую память

Да при чём тут это? Подумайте о 32битном ядре - у него только 1 гигабайт адресного пр-ва, а у юзерспейса - аж 3. А оперативки может быть 4Гб, если не использовать PAE. Ядру совершенно не обязательно держать замапленной всю физ память, и на 32битной архитектуре это вообще невозможно. Вы совершенно не понимаете тот факт, что у ядра и юзерспейса одно виртуальное адресное пр-во, и именно по этому ядру не требуется мапить всю физ память.

Были разные атаки на кеш подобного рода и их вариации:
Evict+Time, Flush+Reload, CacheBleed, MemJam... Все они по
косвенным признакам пытаются угадать, что в это время
делают другие процессы в системе. Но что тут нового?

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

С некоторыми ошибками это — описание атаки MemJam:
Read-after-write из 2017го.

Я фигею с этих анонимусов: сначала заставят тебя делать пересказ для них, потом ещё будут на ошибки указывать... Это, вообще-то, не ошибки. Просто пытался изложить на пальцах. В статье нет ни про VIPT, ни про теги, но надо же было как-то доходчивыми фразами заменить их сложные формулировки.

Так, стоп... MemJam угадывает, обращался ли кто-то по

Иди ты со своим memjam. :)

младшие 12 бит которого совпадают с нашим. Она не определяет
физический адрес по виртуальному: адреса выровнены по
размеру страницы, то есть для 4к-страниц у любого
виртуального адреса младшие 12 бит равны младшим 12 битам
его физического адреса. Определять нечего!

А эти расширили алиасы до 20 бит, и, соответственно, определять появилось что: 8 бит в диапазоне от 12 до 20. Да ещё и кучу бонусных задач выполнили, типа теста на последовательное расположение страниц, какие-то маппинги из адресов ядра получить смогли, и тд.

EPYC FALE

почему бы уже не рассмотреть EPYC вместо Xeon?

чобы был ещё один EPYC FALE? ;-)

вот за что люблю ЛОР - 1 анонимус спорит с другим ;-)

вот за что люблю ЛОР - 1 анонимус спорит с другим ;-)

Ставишь то на кого?

Я же говорю, у нас серьёзный городской сайт майнил биткоины.

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

Например так - это «серьёзный городской сайт» (я про «эту страну»). И туда же все «серьезное» гос. и около гос. Это же аксиома, которой уже больше десяти лет. По большому счету это вариант «Семь нянек».

А так, view-source: хотя бы. И да, я действительно просматривал как минимум главную страницу каждого сайта, который регулярно посещаю.

Скажите, а вы все новые бинарники перед запуском дизасемблируете или как есть бинарник прочитываете? А если есть сомнения сурсы целиком прочитываете перед тем как собрать?

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

Доаптимизировались ))))))))))))

Лож пи#$!* и провокация

Либо запускаю не парясь

Многие запускали трукрипт... Многие запускали openssl...

Сорцы иногда по верхам поглядываю

Вы это серьезно? Даже «Hello World» может оказаться совсем не маленьким.

Небольшой пример. Для меня вот прямо свежак, на который убил дофига времени. Strongswan «внезапно» (как у них принято), изменил поведение с версии 5.6.1 на 5.6.2 (место перехода выяснено было уже методом подбора) никакой инфы в changelog об этом нет, гуля тоже не очень помогла, полный дэбаг лог тоже не спасает. А вот теперь вопрос: Сколько времени нужно на «по верхам поглядываю» в сурсах, что бы не то что бы найти точно место, но хотя бы косвенно «догадаться» о предполагаемом месте решения?
Если интересно, задача вполне тривиальная, сервер, в конфиге два соединения, один psk+l2tp, второй ipsec серты c xauth или fakexauth. Вроде же ничего сверхестественного. И до 5.6.2 при соединении с psk норм его и выбирал, что в принципе логично.

Вы это серьезно?

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

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

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

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

То есть, если вам пересказали пару строчек из предисловия статьи, то это переход в техническое русло?

Всяко лучше, чем холивар intel vs amd на базе собственной веры.

для мельтдауна мы должны знать маппинг _своей_ виртуальной памяти на физическую, а не чужой. [...] Вы совершенно не понимаете тот факт, что у ядра и юзерспейса одно виртуальное адресное пр-во

Я это отлично понимаю. И для такого мелтдауна не нужно знание маппинга, достаточно виртуального адреса. А речь шла о вашей фразе:

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

Я знаю только одну атаку, для которой в meltdown-е надо знать маппинг виртуальных адресов в физические — чтение данные других процессов из смапленной ядром физической памяти. Именно она и была описана выше. Если это не она... можете описать на пальцах, или ссылкой на pdf, ту атаку, где для meltdown-а нужно знание маппинга виртуальных адресов в физические?

Я фигею с этих анонимусов: сначала заставят тебя делать пересказ для них, потом ещё будут на ошибки указывать...

Да не обижайтесь вы, я ни на какие ошибки не указывал, и даже не придирался, что «если таги совпадают, то физ.адреса не могут отличаться, потому что „PT“ в VIPT значит Physically Tagged, и совпадение тегов гарантирует совпадение физ.адреса». Я понял, что это упрощённое описание. Просто я отметил, что ошибки в нём есть, на случай если кто-то ещё будет читать. А описание неплохое, в принципе, по нему легко опознался MemJam:RaW.

[...]

[...]

Нового то, что они сумели удлинить алиасинг с 12 до 20 бит

О! Вот за это спасибо. При беглом просмотре текста я этого не заметил. Теперь, перечитывая ещё раз .pdf-ку, всё стало на свои места.

Итого: Есть давно известная штука: обращения к разным адресам мешают друг другу и вызывают небольшую задержку, если адреса отличаются на 4кб (совпадают младшие 12 бит). Этот потенциальный конфликт адресов (false dependency) документирован, и использовался в разных атаках «подглядывания» за чужими процессами в попытках угадать, чем они занимаются.

Вот, в этой работе ребята заметили странное недокументированное свойство процессора — ещё большую задержку, если физические адреса отличаются на 1МБ (совпадение 20 бит вместо 12). Они и сами не уверены, чем оно вызвано, так и написали, что оно неизвестное, но обнаруживаемое ("unknown, but observable aliasing behavior based on the physical address").

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

1М-конфликт вызывает задержку чуть больше, чем 4к-конфликт, что позволяет ускорить элементы существующих атак, такие как MemJam:RaW, reverse-engineering перед RowHammer-ом (не сам RowHammer, а этап reverse-engineering-а перед ним), поиск eviction set и contiguous memory detection нужные для некоторых атак, и т.д.

Новых уязвимостей они не нашли. Это выдумка журналистов. Все баги были известны и раньше.

PS: если я всё ещё ошибаюсь — пусть коллега-анонимус меня поправит.

Значит по этой причине процессоры AMD не подвержены подобным уязвимостям?

Подобным уязвимостям подвержены все процессоры, имеющие кеш. Просто интелы популярнее, и для них идею проверили в первую очередь. И журналисты про них больше пишут. А в общем:

We present a consistent and extensible systematization of transient execution attacks, i.e., Spectre, Meltdown, Foreshadow, and related attacks.
We demonstrate all attacks in our classification tree through practical proofs-of-concept with vulnerable code patterns evaluated on CPUs of Intel, ARM, and AMD.

Я знаю только одну атаку, для которой в meltdown-е надо
знать маппинг виртуальных адресов в физические — чтение
данные других процессов из смапленной ядром физической
памяти.

А, ок, только не совсем понятна актуальность такой атаки, учитывая, что на 32битных ядрах такого нет, и что память процессов «не стабильна» - перемещается по физ адресам и уходит в свап. Если актуальность такой атаки может быть подтверждена ссылкой, то я совсем не против. :) Я же больше про обход KASLR говорил.

«если таги совпадают, то физ.адреса не могут отличаться,
потому что „PT“ в VIPT значит Physically Tagged, и
совпадение тегов гарантирует совпадение физ.адреса».

Стоп, почему эта фраза взята в кавычки? Я-то точно такой фигни не писал. Или это цитата откуда-то ещё? Можно ли ссылку на оригинал сего опуса?

Я понял, что это упрощённое описание.

И всё-таки, цитата приписывается мне, похоже... Нет уж. :)

Новых уязвимостей они не нашли. Это выдумка журналистов.
Все баги были известны и раньше.

Они, собственно, и не говорят, что нашли уязвимость. Они говорят, что нашли новый _сайд ченнел_, позволяющий ускорить различные техники атак на порядки. Я согласен, что не корректно называть это новой уязвимостью. Но если это актуализирует какую-то из старых, то, в целом, преувеличение можно считать допустимым для не-технических информационных ресурсов (aka LOR).

ещё большую задержку, если физические адреса отличаются на 1МБ

Я бы сказал, наоборот, совпадают в рамках 1Мб (а отличаются на гораздо больше, чем 1Мб).

1М-конфликт вызывает задержку чуть больше, чем 4к-конфликт,
что позволяет ускорить элементы существующих атак

Выглядит как фигня, а не упрощение материала. При чём тут, задержка чуть больше? Главное, что она вообще измерима. И по ней мы прикидываем совпадение новых 8 бит физ адреса. Знание совпадений этих бит и приводит к ускорениям атак на несколько порядков. А не задержки...

1М-конфликт вызывает задержку чуть больше, чем
4к-конфликт,
что позволяет ускорить элементы существующих атак

Выглядит как фигня, а не упрощение материала. При чём тут,
задержка чуть больше?

Может, вы имели в виду, что она больше, и по тому отличима от 4К алиаса, и по этому её вообще можно эксплуатировать? А проэксплуатировав её, можно получить данные о 8 битах адреса, «что позволяет ускорить элементы существующих атак»? Так сказать, пытаюсь натянуть вашу невнятную фразу на имеющийся каркас. :)

PS: если я всё ещё ошибаюсь — пусть коллега-анонимус меня
поправит.

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

И так, суть работы состоит в том, что парни сумели более-менее надёжно (по результатам многочисленных измерений тайминга с последующим статистическим анализом результатов) отличить 1Мб алиасинг от ранее известного 4К алиасинга. Эта возможность их отличать даёт совершенно новый канал утечки информации о 8 битах физического адреса, столь необходимый для различных известных ранее атак.

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

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

Стоп, почему эта фраза взята в кавычки? Я-то точно такой фигни не писал. Или это цитата откуда-то ещё?

А, это просто фраза, которую я не написал, но мог бы, если бы хотел попридираться к слову «тег». Ведь если для пары physically tagged адресов совпал тег, то и адреса совпадут.

Выглядит как фигня, а не упрощение материала. При чём тут, задержка чуть больше? Может, вы имели в виду, что она больше, и по тому отличима от 4К алиаса, и по этому её вообще можно эксплуатировать?

Ну да.

Она применяется так же, как 4k-задержка, в тех же атаках, что и 4k-задержка. Но так как она детектит совпадение 20-бит вместо 12-бит — нужно перебирать меньше адресов, что ускоряет некоторые элементы этих атак.

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

Но только по своим адресам. То есть облегчает не эксплуатацию, а проверку памяти на стабильность. Грубо говоря, можно проверять память браузерным rowhammer-тестом на javascript, вместо перезагрузки компа в memtest. Эксплуатировать это для повышения привилегий не получится, не этим методом, и не из javascript.

Найдена возможность подглядывания маппинга ядра, что помогает при обходе KASLR.

Для маппинга они просто в /proc/self/pagemap смотрят.

Но если это актуализирует какую-то из старых, то, в целом, преувеличение можно считать допустимым для не-технических информационных ресурсов (aka LOR).

Нет! Не допустимое! С этим я и спорю. Уязвимость — новая, когда для её устранения надо принимать новые меры. А тут этого нет.

Нет даже нового вектора атаки. Всё, от чего защитились раньше, не сработает и сейчас. Это лишь мелкая оптимизация — если старая атака на вас работала за 40 секунд, то со «спойлером» она сработает за 10 секунд.

Это как назвать язык С «новой уязвимостью», потому что на нём быстрее писать эксплоиты, чем на ассемблере.

Ведь если для пары physically tagged адресов совпал тег,
то и адреса совпадут.

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

Но так как она детектит совпадение 20-бит вместо 12-бит —
нужно перебирать меньше адресов, что ускоряет некоторые
элементы этих атак.

Брр, что за туманные формулировки, всё время из-за них складывается впечатление, что вы ничего не понимаете. :) При чём тут меньше адресов, если, как вы уже сами говорили, 4К алиасы вообще ничего не говорят про физ адреса, так как младшие 12 бит всё равно с вирт адресом совпадут? И использовалось это совсем для других целей. А вот когда они вышли за эти 12 бит, то сразу получили _новый_ сайд ченнел, который вот прям про 8 бит физ адреса инфу выдаёт. Это то понятно? :) Вроде, раньше было понятно, а по последним фразам - вроде и не понятно. :)

Для маппинга они просто в /proc/self/pagemap смотрят.

Да это они просто сверялись с ним, ну. А я всё вот про это:

SPOILER can track nearby load operationsfrom  a more
privileged security domain  right after acontext switch.

Нет! Не допустимое! С этим я и спорю. Уязвимость — новая,
когда для её устранения надо принимать новые меры. А тут
этого нет.

А я ведь сказал, «если это актуализирует какую-то из старых уязвимостей». Если же нет, то тогда вопрос закрыт.

Ну зашибись же. А то делают SGX всякие.