LINUX.ORG.RU

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

 , , ,


4

4

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


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

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

Deleted

Проверено: Shaman007 ()
Последнее исправление: unfo (всего исправлений: 3)
Ответ на: комментарий от anonymous

Час прошёл, второй, увы! Нет ответа из Москвы...

Приношу свои глубочайшие извинения за задержку.

Так покажите характеристики современных L1/L2 кешей-то!

https://stackoverflow.com/a/19747176 Мотаем к таблице «UPDATE 1», и сразу видим, к примеру, в первой же строке, «Nehalem: 32K, 4-way». Надо ли использовать калькулятор, чтобы понять, что индекс тут за 12 бит выходит?

Интересно, спасибо, не знал. Но, во-первых, это тоже не современный процессор. Во-вторых, там это написано только про кеш инструкций, а мы вроде как про данные. В-третьих, а он VIPT? И, в-четвёртых, не факт, что выходит... На этих процах есть hyper-threading, возможно, он так организован: кеш данных общий, а кеш инструкций раздельный, т.е. у ядра он как бы 32K, по 16К каждому треду, и тогда индекс остаётся 12 бит.

Но это — догадка. Документации по нему я не нашёл. Эти размеры кеша взяты не из документации — их сообщает сам процессор через инструкцию CPUID. Зато я нашёл процессор, который сообщает такой 32K 4-way, и решил проверить, сколько же там на самом деле доступно одному треду.

Идея проверки проста: если по циклу читать один и тот же кусок, то пока он влезает в L1 кеш, он будет читаться быстро. А значит, если увеличивать размер куска, то когда мы вылезем за размер L1 — задержка чтения вырастет. В обычном 32K 8-way хорошо заметен этот всплеск после 32К. Если машина меньше нагружена (или L2 медленный) то всплеск более плавный. Но 32K 4-way выглядит совсем иначе и без нагрузки и с небольшой нагрузкой — всплеск начинается после 16КБ. На 32К-кеш не похоже, а вот на 16К очень даже...

Из всего этого я делаю вывод — там 2x 16K-кеш, по одному на каждый тред, а значит индекс тоже не выходит за 12 бит. Если вы видите ошибку в тесте, имеете ссылку на документацию где это описано, или знаете другой способ это проверить — предлагайте.

Размер ЛИНИИ превышал размер страницы?

Ну да.

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

Давайте я вам ещё из того же патента процитирую:
... it is possible for more than one virtual address within a cache way to map to the same physical address ...
Это, в точности, и есть та самая фраза, которую я приводил

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

Я по тому и сказал, что вы не понимаете, что такое определение. И что оно такие важные моменты не может умалчивать

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

Да только что ведь со ссылкой приводил! Ну урежу до 2 слов, как обычно, для одарённых:
arbitrarily choose virtual addresses with the same set index bits.
Это, собственно, и весь алгоритм.

Это ещё не алгоритм. Сколько адресов надо выбрать? До каких пор выбирать-то? Где условие выхода из алгоритма?

Зачем? Ну, вообще-то, я давал ссылку.

Да просто по той ссылке не написано, что лично вы называете metldown/spectre. Поэтому я и прошу описание не ссылками, а словами.

Тут есть слово Intel, есть слово specific...

А ещё есть слово ARM. То есть оно уже не specific.

И дальше ещё кучу бредятины

Ну так бредятина была не от меня. Вы называете meltdown-ом какую-то intel-специфическую проблему? Но meltdown в той ссылке не специфичен для intel-а, ведь он работает как минимум на ARM-е. То есть либо вы написали бред про «Intel» и «specific», либо вы написали бред, когда сказали, что давали ссылку на ваше описание.

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

Интересно, спасибо, не знал.

А что вообще вы в этом триде знали, можно спросить? :)

Если вы видите ошибку в тесте, имеете ссылку на документацию
где это описано, или знаете другой способ это проверить —
предлагайте.

Давайте предложу вам способ по-проще: https://hackers4hackers.blogspot.com/2012/10/vivt-vipt-and-pipt-caches.html

[    0.000000] CPU: PIPT / VIPT nonaliasing data cache,
VIPT aliasing instruction cache
Это вот linux на АРМах. Ещё вопросы будут?

вам будет очень трудно найти кеш, где размер линии

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

противоположное: «когда тэг совпадает, а адреса по факту
разные».

Анонимус, вам не надоело тупить? Эта фраза объясняет возможность того, что тег совпал, а оффсеты в кеш линии за 12 битами - разные. Из этого может следовать как алиас (когда физ адреса совпали), так и «фейковый алиас» - когда физ адреса НЕ совпали. Главное, что, в обоих случаях тег один, и ничего не определяет. Это и опровергает вашу туфту на тему того, что, если тег совпал, то и физ адреса совпадут. И чётко показывает мой случай: тег совпал, а физ страницы - разные (фейковый алиас). Если там написано «to map to the same physical address using respective page table entries», то, наверное, даже тупому тролю должно быть очевидно, что, в этих page table entries, могут быть и разные адреса? К чему этот пустой тролинг то?

Поэтому дописать «ко всем» было бы неверно.

Допишите так, чтобы было верно. «не ко всем» допишите, или что считаете нужным. Ваше определение было глупым и не корректным. Хотите - поправьте его, хотите - нет, мне оно нафиг не сдалось.

Это ещё не алгоритм. Сколько адресов надо выбрать?

По размеру кеш сета. И с соответствующим выравниванием, разумеется.

До каких пор выбирать-то?

Пока адреса всего кеш сета ни наберём. Ещё вопросы?

Вы называете meltdown-ом какую-то intel-специфическую
проблему?

Пфф, анонимчик, идите в баню... :) Вам говорили лишь то, что на АМД его нет. Если его кто-то и назвал, в результате этого, интел-специфичным на просторах 20-страничного обсуждения (не учтя АРМ, о котором речь изначально вообще не шла), то придираться к этому, по меньшей мере, глупо. И бред в вашем высказывании был тоже про АМД, которое «там в другом месте».

В общем-то, не знаю даже, стоит ли от вас ждать хоть одного письма по существу, или так на микро-придирках и будете выжидать тайм-аут, чтобы слинять от meltdown-bnd? Что вы добиваетесь всеми этими придирками? Никаких ошибок в моих словах они вам найти не помогут. Откосить от meltdown-bnd - тоже. Вы в полной заднице, и я даже представить не могу, что вы могли бы написать по делу, чтобы из этого положения выйти. Ведь про meltdown-bnd, как и про вас, уже все всё поняли, значит, и это для вас не вариант. Но удивите народ, напишите уж хоть что-то осмысленное!

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

До каких пор выбирать-то? Где условие выхода из алгоритма?

Поскольку там написано «arbitrarily choose virtual addresses», то и алгоритм может быть «любым». Хотите - просто возьмите последовательный блок размером с кеш сет (не забудьте выровнять его начало по размеру кеш сета). Хотите - играйтесь с верхними битами. И всё будет работать, коль скоро вы покроете все нижние биты в кол-ве offset+index. По этому, глупо было бы приводить чёткий алгоритм. Тут свободы выбора больше, чем ограничений.

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

Просто размер линии обычно 64 байта, вам будет очень трудно
найти

А я таки найду, ёшкин кот. :) https://github.com/torvalds/linux/commit/15de36a4c3cf33aa4e194bfbff002048aa4a...

Architectures that choose this method of maintaining cache
coherency (MIPS and xtensa currently) are able to use high
memory on cores with aliasing data cache.

_aliasing data cache_. И далее:

The problem:
 VIPT cache with way size larger than MMU page size may
 suffer from aliasing problem
... и далее - примерно то же самое, что я уже цитировал из патента. Тут названы 2 архитектуры, где такое возможно, и которые, при этом, используют cache coloring. Судя по патенту из АРМ и другим источникам, это не всё - есть и процы с такой же фичей, но не использующие кеш колоринг (а использующие аппаратные техники разрешения алиасов). Закапываться в доки конкретных процов ради анонимного троля - не стану. Считаю, что приведённых выше доказательств достаточно.

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

Закапываться в доки конкретных процов ради анонимного
троля - не стану.

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

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

Во-вторых, там это написано только про кеш инструкций, а
мы вроде как про данные.

Э, э, анонимчик! Про данные мы соседнюю ветку ведём, где кеш-линия больше размера страницы MMU. А тут мы обсуждаем ваше утверждение о том, что в VIPT _вообще_ биты индекса за 12 выходить не могут! И это к данным уже совсем никак не относится. А так как я это доказал на примере АМД и Nehalem, а то доказал на примере MIPS и xtensa, то у вас слив сразу по 2 пунктам. И переплетать их в один, ради замыливания, вам не позволено! _Здесь_ речь про dcache не шла, а вот там - да.

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

А что вообще вы в этом триде знали, можно спросить? :)

Ой, много, всего и не перечислить... :)

Давайте предложу вам способ по-проще ... Это вот linux на АРМах.

«Способ по-проще» чтобы сделать что? Чтобы узнать тип или размер того L1-кеша? Так нет, он для intel-ов не работает: dmesg | grep -i vipt возвращает пустой вывод.

Или это был пример того, что на арме есть VIPT-кеши с алиасами? Так тоже нет. Там тот же метод с совпадением младших битов, чтобы этих алиасов избежать, только совпадать должно больше битов, например, не 12, а 14. Они это назвали page coloring, но сути это не меняет — если у пары адресов совпадают младшие биты индекса+смещения в виртуальном адресе, то совпадут и в физическом.

Считаю, что приведённых выше доказательств достаточно.

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

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

Ну вот такого тоже не может быть. Не верите — попробуйте привести пример. Я согласен, пусть это будет какой-то несуществующий кеш, не обязательно реальный. Но приведите пример адресов такого нереального кеша. Конкретные числа.

Скажем, есть 32-битный виртуальный адрес 0x12345678, что у вашего кеша в нём будет, индекс, смещение, какому физическому адресу он будет соответствовать, что в этом адресе будет тегом? Напишите эти 4 числа с пояснениями, и сразу станет ясно, я туплю или вы.

Допишите так, чтобы было верно. «не ко всем» допишите, или что считаете нужным. Ваше определение было глупым и не корректным.

Нет, оно как раз было корректным, простым и лаконичным: "множество адресов, обращение к которым вытесняет из данного кеша данный адрес".

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

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

До каких пор выбирать-то?

Пока адреса всего кеш сета ни наберём. Ещё вопросы?
Хотите - просто возьмите последовательный блок размером с кеш сет

Так а сколько это? Например: берём блок адресов, размером минимум с кеш-сет, выбираем в нём адреса в которых младшие биты (в количестве равном длине индекса+смещения, т.е. например 12-бит для 12-битного кеша), и добавляем их в наш эвикшн сет — такой алгоритм годится? А сколько их нужно добавлять? По числу ассоциативности? Или по размеру кеша делённому на размер строки? Или может вдвое больше, ну чтоб наверняка?

И бред в вашем высказывании был тоже про АМД, которое «там в другом месте».

Почему бред? Всё верно. Вы сказали что там «есть слово intel». Я ответил, «ну и что, там есть и слово AMD». И это не объясняет, что же вы называете meltdown.

Если бы тупой анонимный троль сказал _месяц назад_ что-то вроде «но позвольте, такая ситуация для VIPT не характерна.

Месяц назад вы и не писали про линию больше страницы.

Про данные мы соседнюю ветку ведём, где кеш-линия больше размера страницы MMU. А тут мы обсуждаем ваше утверждение о том, что в VIPT _вообще_ биты индекса за 12 выходить не могут!

Да-да, после вашей фразы «могут ли, при современных размерах кешей, биты индекса выходить за 20». Ну, помните, про 20-битный алиасинг в сабже... А сабжевая статья таки про данные, и, кстати, писалась про интелы, а не про армы или мипсы.

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

Ещё вопросы будут?

Вы бы хоть на существующие ответили...

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

Они это назвали page coloring, но сути это не меняет — если
у пары адресов совпадают младшие биты

Вот же тупой анонимный троль! При чём здесь это? Spoiler — новая уязвимость в процессорах Intel (комментарий)

У VIPT-ов они и за 12 не выходят, угадайте, почему? Хотя,
ладно, объясню. А то вы ещё неделю будете делать вид, что
знаете...
Это вы писали, или нет? Вы признаёте, что сморозили очередную чушь? Как же можно быть таким идиотом, чтобы только тупить и передёргивать каждый раз... Мне вот интересно, вы вообще, кроме тролинга, в жизни хоть что-то ещё умеете делать?

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

А вас амнезия замучила?

Определение — это необходимое и достаточное условие того

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

выбираем в нём адреса в которых младшие биты (в количестве
равном длине индекса+смещения, т.е. например 12-бит для 12-
битного кеша),

В которых младшие биты что именно? Хоть дописывайте предложения. Надо чтобы совпадали биты индекса. Это единственное условие. Младшие биты (которые оффсет) можете брать непрерывными блоками, а можете играться со старшими битами - разницы никакой.

А сколько их нужно добавлять? По числу ассоциативности? Или
по размеру кеша делённому на размер строки?

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

Почему бред? Всё верно. Вы сказали что там «есть слово intel».
Я ответил, «ну и что, там есть и слово AMD». И это не
объясняет, что же вы называете meltdown.

Вы троль и дебил. А я уже было подумал, что образумились, и стали по делу говорить... Нет, там был параграф именно с определением мельтдауна. Вы прочесть его не стали утруждаться, и теперь порете неистовую чушь.

Месяц назад вы и не писали про линию больше страницы.

И что из этого следует? Я писал, что совпадение тега не гарантирует совпадение физ адреса. Это так и есть.

Да-да, после вашей фразы «могут ли, при современных размерах
кешей, биты индекса выходить за 20».

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

В целом, я не против обсудить и вообще.

Обсудить что? Вы сморозили чушь, сказав, что биты индекса за 12 не могут вылезать. И ещё, задолго до этого - что совпадение тега гарантирует совпадение физ адресов. Я обе этих глупости опроверг. Правда, вторая из них - не такая уж и глупость, так как такие архитектуры, как выяснилось, редки. Ну будем считать, что вы полторы глупости сморозили, а не две. Разница то? И это только здесь: всё ещё силитесь доказать, что алгоритм поиска эвикшн сета не зависит от типа кеша, что тоже несусветный бред, и тд. От вас один тролинг да тупость. Если не вернётесь в нормальное русло, придётся вам авансом слив засчитать. :)

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

От вас один тролинг да тупость.

Что и не удивительно, когда вас только за meltdown-bnd надо ссаными тряпками гнать. Вы всерьёз думаете меня заболтать, чтобы я про него забыл? :)

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

Нет, там был параграф именно с определением мельтдауна.

О, так это же чудесно! Если там был параграф с определением, то процитируйте его, пожалуйста, и вы наконец-то ответите на мой вопрос.

А вас амнезия замучила?

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

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

Нет, не удовлетворяет. Определению удовлетворяет только случай, когда вытеснение произошло, читайте внимательно: «множество адресов, обращение к которым ВЫТЕСНЯЕТ из данного кеша данный адрес».

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

Это вы писали, или нет? Вы признаёте, что сморозили очередную чушь?

Писал я. В ответ на ваше сообщение про невыход за 20 бит в обсуждении вашей аналогии сабжевой статьи, описывающей 20-битные алиасы в процессорах интел. Чушь не вижу. Или чушь — это описанная там проблема VIPT-кеша? Это было бы странно, ведь вы сами давали ссылку на патч, и патент, описывающий ту же проблему. Или и там тоже чушь?

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

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

Эта фраза не относилась ко всем кешам в мире. А только конкретному обсуждаемому нами случаю. А то вы, может, не знаете, но страницы бывают не только 4кб, и адрес в странице может быть, соответственно, не только 12 бит. Но в сабжевой работе такие случаи не рассматривались, и мы это не обсуждали. Ну, я не обсуждал. А что обсуждали вы — я теперь уже не знаю.

Правда, вторая из них - не такая уж и глупость, так как такие архитектуры, как выяснилось, редки.

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

И что из этого следует? Я писал, что совпадение тега не гарантирует совпадение физ адреса. Это так и есть.

В каком случае так и есть? Приведите любой пример, можно с выдуманным кешем. См. мой вопрос про адрес 0x12345678.

Обсудить что?

Другие архитектуры-же! В которых количество бит индекса+смещения у VIPT-кеша превышает количество бит, которые в виртуальном адресе зависят от физического. Page coloring, как мы уже выяснили, к таким не относится. Есть ли ещё кто-то? Мне, правда, очень интересно, кто и зачем может так делать. Я не вижу для этого ни одной логичной причины.

В которых младшие биты что именно?

Совпадают.

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

Да, отличное описание, я серьёзно. Даже не ожидал от вас таких подробностей. Благодарю. Но...

Но вдруг этого не хватит? Вспомните ваш пример с кешем в старых AMD, которые 2-way 64KB, то есть число ассоциативности 2, но вытеснить надо не только эти две линии, потому что этот же адрес мог быть закеширован в виде алиаса в какой-то другой строке, и останется в кеше после вытеснения этих двух линий.

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

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

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

О, так это же чудесно! Если там был параграф с определением,
то процитируйте его, пожалуйста, и вы наконец-то ответите на
мой вопрос.

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

Определению удовлетворяет только случай, когда вытеснение
произошло, читайте внимательно: «множество адресов,
обращение к которым ВЫТЕСНЯЕТ из данного кеша данный адрес».

Ну и бред, тогда можно и половину эвикшн сета взять: всё равно может вытеснить, а может и нет. :) Ваше определение определяет _множество адресов_. Если я произвёл к ним обращение, а вытеснения не произошло, то проблема либо в множестве адресов, либо в определении. Если я заранее знаю, что множество адресов эвикшн сету соответствует, а вытеснения не произошло, то ваше определение не верно. Удивительно, что приходится такие простые вещи по сто раз объяснять. Короче ясно, определения вы давать не умеете, можете дальше с этим не напрягаться, у меня оно и без вас есть.

Чушь не вижу.

А если очки одеть? И не тупить?

Именно поэтому индекс+смещение в VIPT-кеше ограничено 12 битами
Эта фраза - очевидная чушь.

Это было бы странно, ведь вы сами давали ссылку на патч,
и патент, описывающий ту же проблему. Или и там тоже чушь?

Чушь в вашей голове, тупой троль. И больше ни где. Патент, кстати, совершенно другую проблему описывал, но и там смещение+индекс за 12 выходили. Вообще-то, даже и само смещение выходило, не то, что с индексом.

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

Ну ты просто мудила, простите. Я процитировал про MIPS и xtensa. Ещё один аналогичный тролинг, и ты пойдёшь в жопу перманентно. Хотя нет, уже пойдёшь. Хватит.

Да, отличное описание, я серьёзно. Даже не ожидал от вас
таких подробностей. Благодарю. Но...

Слушай, анонимус, пошёл ты на хер. :) Ты доказывать будешь и дальше, что от типа кеша поиск эвикшн сета не зависит? Что в VIPT индекс+смещение ограничены 12 битами? Что совпадение тега гарантирует совпадение физ адреса? Что meltdown-bnd возможен без bound на стороне жертвы? Я с таким дебилом впервые общаюсь. И мне это надоело. Если снова не увижу ни одного доказательства по вопросам выше, а увижу один только идиотизм - ответов больше не будет. Ну а так как доказать очевидные глупости невозможно, то вполне очевидно, что ничего умного я не увижу здесь никогда, кроме попыток всё затролить. Следовательно, и ответов больше не будет. :) Счастливо, тупой троль.

Но вдруг этого не хватит? Вспомните ваш пример с кешем в
старых AMD, которые 2-way 64KB, то есть число
ассоциативности 2, но вытеснить надо не только эти две
линии, потому что этот же адрес мог быть закеширован в виде
алиаса в какой-то другой строке, и останется в кеше после
в ытеснения этих двух линий.

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

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

и останется в кеше после вытеснения этих двух линий.

А кого вообще волнует другой сет? Нам надо вытеснять из одного. А алиасы - в другом. Помимо того, что они, разумеется, инвалидируются аппаратно на АМД/интел.

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

Вообще идиотизм. Который, впрочем, от вашего идиотского определения идёт. Хотя, по факту, всё с точностью до наоборот: обращение к искомому адресу гарантированно вытесняет одну из линий эвикшн сета. И тут никаких «если» уже не будет, «а может не с первой попытки» - тоже . В общем, вы даже не понимаете, о чём говорите. Что уже давно понятно, но с каждым разом всё дальше. Я больше на этот бред слушать не буду.

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

Эта фраза не относилась ко всем кешам в мире. А только
конкретному обсуждаемому нами случаю.

Серьёзно? Spoiler — новая уязвимость в процессорах Intel (комментарий)

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

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

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

Ну ты просто мудила, простите.

Беру свои слова назад и извиняюсь. Сколько ни искал, найти не представляется возможным. Значит, придётся ответить на ваши вопросы более полно. Увы, снова потрачу на вас время... :)

Я согласен, пусть это будет какой-то несуществующий кеш, не
обязательно реальный.

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

Ведь если для пары physically tagged адресов совпал тег,
то и адреса совпадут.
Рассмотрим случай, когда 2 процесса обращаются через разные кеш сеты (1 и 2) к каким-либо физ адресам. Предполагается, что у нас кеш линия «длинная», 13 бит. Предположим, что процесс 1 в свой кеш сет 1 замапил дважды одну и ту же физ страницу на последовательные виртуальные адреса (создал алиас внутри одной линии). И процесс 2 сделал то же самое в сете 2. То есть, мы сейчас рассматриваем всего 2 физические страницы, 1 и 2. Физ страница 1 дважды замаплена в процесс 1, а физ страница 2 дважды замаплена в процесс 2, и каждая из этих страниц создаёт алиас в соответствующей кеш линии. Тут уже возможно совпадение тега, и возможно оно в том случае, если эти 2 физические страницы расположены последовательно, и с выравниванием. Тогда они аффектят только бит 12 физ адреса, который у нас в тег не вошёл. Получается, два процесса будут работать в разных сетах, с одним тегом, но с 2 разными физ страницами.

Скажем, есть 32-битный виртуальный адрес 0x12345678, что у
вашего кеша в нём будет, индекс, смещение, какому физическому
адресу он будет соответствовать, что в этом адресе будет
тегом? Напишите эти 4 числа с пояснениями, и сразу станет
ясно, я туплю или вы.

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

Смещение вычислим так: 0x12345678&(0x1000*2-1) = 0x1678 Индекс: (0x12345678>>13)&31 = 2 Тег я написать не могу: он напрямую из вирт адреса не выводится (это ж не VIVT), а берётся из списка тегов. За каждым кеш сетом закреплён список тегов, и тегов в нём по числу ассоциативности. Вычисляется vhint - это некоторая функция от старших адресов вирт адреса, в нашем случае, F(0x12345678>>18). Её результат используется как тег в списке тегов, то есть, через vhint мы находим нужный нам физический тег. Ну или не находим, если, для соответствующего хинта, ничего нет. Тогда это кеш мисс, и спекулятивная ветка на этом заканчиается. А вот если тег через vhint найден, то спекулятивная ветка продолжается, и мы берём данные из соответствующей кеш линии. И начинаем с ними работать, и работаем до тех пор, пока ни завершиться TLB lookup, и окажется, что нас vhint обманул. Тогда это тоже кеш мисс, но появилась дополнительная задержка, так как продетектили мы его слишком поздно - лишь после TLB lookup. То есть, если по vhint'у тег совпал, то имеем доп задержку перед cache miss. Разумеется, аналогия эта примерная. Ничего похожего в том документе не было. Я, кстати, сразу сказал, как привёл эту аналогию, что там про VIPT вообще речь не шла: Spoiler — новая уязвимость в процессорах Intel (комментарий)

В статье нет ни про VIPT, ни про теги, но надо же было как-то
доходчивыми фразами заменить их сложные формулировки.
И это было сказано не через 4 дня, а сразу.

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

Опровергли? Вы опять спорите с собой.

Поймите, анонимус. Изначально я произнёс фразу А: «тэг совпадает, а адреса по факту разные». Потом вы сказали, «Ведь если для пары physically tagged адресов совпал тег, то и адреса совпадут.», и на это я произнёс фразу Б: «Теги могут совпадать в разных кэш сетах, а адреса могут не совпадать». Так вот, фраза Б ни коим образом к фразе А не относилась. Она была лишь произнесена, чтобы оппонировать вашей фразе. Мне не стоило этого делать, надо было просто объяснить, что я не это имел в виду. Но я предпочёл спорить на 2 фронта. А уж когда вы внесли совершенно ложную фразу В: «Именно поэтому индекс+смещение в VIPT-кеше ограничено 12 битами», то эффективно спорить стало совсем невозможно.

Что мы имеем теперь.

Фразу А я объяснил выше через vhints. Грамотнее, конечно, было бы говорить изначально не «тег совпал», а что-то вроде «подходящий тег в сете существовал». Просто я исходил из того, что, чтобы быть спекулятивно выбранным, тег должен с чем-то совпасть. По факту же, совпадает соответствующий тегу ключ в ассоциативном массиве тегов, а не сам тег, но между ключём и тегом соответствие однозначное, так что это лишь терминологический косяк.

Фразу Б я объяснил в терминах вымышленной архитектуры, как вы сами и попросили:

Приведите любой пример, можно с выдуманным кешем. См. мой
вопрос про адрес 0x12345678.
И да, в патенте от АРМ я такую «вымышленную» архитектуру заметил случайно. Нет её там. И по тому, принимаю ваше утверждение, что мне её на практике никогда не найти. Но это и не нужно, так как фраза Б ни к чему, кроме соответствующей вашей фразы, и не относилась. Если вас объяснение в рамках вымышленной архитектуры устраивает, то отлично.

Фразу В я опроверг на примере АМД, да и АРМов таких полно. Кстати, то, что в линуксе про АРМ пишется как non-aliasing VIPT, не означает, что там биты индекса за 12 не выходят. VIPT с аппаратным резолвингом алиасов тоже идентифицируется на АРМах как non-aliasing.

Далее можно приводить список бреда о том, что meltdown-bnd возможен без bound на стороне жертвы, что алгоритм поиска эвикшн сета не зависит от типа кеша, и тд. И тут я тоже считаю всё давно опровергнутым.

Такие вот итоги.

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

Если там был параграф с определением, то процитируйте его, пожалуйста

Я это уже делал.

Наверное, я забыл. Прошу прощения. Дайте, пожалуйста, ссылку на сообщение, где вы процитировали тот параграф.

Ну и бред, тогда можно и половину эвикшн сета взять: всё равно может вытеснить, а может и нет. :)

Если половина сета вытеснит, то да, можно. Если обращение к каким-то адресам сета вытесняет адрес, то это уже эвикшн сет. Даже если обращение к каким-то другим адресам сета его не вытесняет.

Грубо говоря: "Прямоугольный треугольник — это треугольник, в котором один угол прямой (то есть 90 градусов)." Даже если какой-то другой угол в нём не прямой, треугольник всё равно прямоугольный.

Патент, кстати, совершенно другую проблему описывал

Почему же? Цитата из патента:
> it is possible for more than one virtual address within a cache way to map to the same physical address using respective page table entries (i.e. aliasing).
Тут написано: «возможно, что более одного виртуального адреса будут смаплены в тот же физический адрес (т.е. алиасинг)». Я написал: «разные виртуальные адреса, указывающие на один физический». Какая же это «совершенно другая проблема»?

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

Кого заинвалидирует? Каких конфликтов? С кем там будут конфликтовать адреса из эвикшн сета?

А кого вообще волнует другой сет? Нам надо вытеснять из одного. А алиасы - в другом.

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

В общем, вы даже не понимаете, о чём говорите.

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

Это кто писал? Написано, «ни в какой трактовке». А теперь оказывается, что она «не относилась ко всем кешам в мире»...

Да, она не имеет смысла ни в какой трактовке. Но «не относилась ко всем кешам в мире» не та фраза, а фраза "У VIPT-ов они и за 12 не выходят", в которой «они» — это адреса, алиасинг которых исследовался в сабжевой статье, которая обсуждалась в той ветке.

Рассмотрим случай, когда 2 процесса обращаются через разные кеш сеты (1 и 2) к каким-либо физ адресам. [...] кеш линия «длинная», 13 бит [...] Тут уже возможно совпадение тега, и возможно оно в том случае, если эти 2 физические страницы расположены последовательно, и с выравниванием.

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

А это уже другая проблема.

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

Тогда это тоже кеш мисс, но появилась дополнительная задержка, так как продетектили мы его слишком поздно - лишь после TLB lookup. То есть, если по vhint'у тег совпал, то имеем доп задержку перед cache miss.

Благодарю за подробное объяснение. В общих чертах идея понятна. Кроме куска:

За каждым кеш сетом закреплён список тегов, и тегов в нём по числу ассоциативности. Вычисляется vhint - это некоторая функция от старших адресов вирт адреса, в нашем случае, F(0x12345678>>18). Её результат используется как тег в списке тегов, то есть, через vhint мы находим нужный нам физический тег.

Эту часть я не понял. В каком списке тегов мы его ищем, в том что закреплён за кеш-сетом? Тогда как по части виртуального адреса мы находим физический тег?

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

Дайте, пожалуйста, ссылку на сообщение, где вы процитировали
тот параграф.

Spoiler — новая уязвимость в процессорах Intel (комментарий) Но опять же, я не буду с вами в этом направлении дискутировать, пока вы ни признаете, что тролили всех с matldown-bnd, а его без bound просто нет.

Если половина сета вытеснит, то да, можно.

Иногда вытеснит, иногда - нет. Как и ваше идиотское определение.

Грубо говоря: «Прямоугольный треугольник — это треугольник,
в котором один угол прямой (то есть 90 градусов).»

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

Я написал: «разные виртуальные адреса, указывающие на один
физический».

Хорошо.

Кого заинвалидирует?

Если вы вытеснили какую-то линию из сета, то все её алиасы в других сетах будут заинвалидированы автоматически.

Да, и среди этих алиасов может быть адрес, который надо
вытеснить.

В смысле? Вы ж, надеюсь, про физический адрес? Ну так, если мы предполагаем, что его аппаратный резолвер алиасов не вытеснил (например, речь не об АМД, а о каком-то РИСКе), то всё равно, он останется только в другом сете. А в нашем - вытеснится. Этого уже достаточно.

Попробую объяснить иначе.

Да не надо мне объяснять иначе. При чём здесь то, что его могут в ту же линию положить? Это вообще к проблеме не относиться. Это относится лишь к вашему идиотскому определению, где может быть «что угодно». В нормальном определении, из эвикшн сета гарантированно вытесняется одна из линий, при обращении к искомому адресу. И всё, тут ни проблем, ни вопросов. А вы можете и дальше мне доказывать, что ваше определение валидно, достаточно, и тд. Я эту чушь слушать не обязан. Давайте сформулирую по-понятнее: эвикшн сет, это набор вирт адресов, на котором можно достигнуть такого состояния, при котором обращение к искомому адресу внутри сета, _гарантированно_ приведёт к вытеснению одной из линий. Как это состояние достигается - в определение не входит. А вы сделали с точностью до наоборот, и пытаетесь вывести определение из техники подготовки сета. Значит, не понимаете ни что такое определение, ни что такое эвикшн сет.

Продолжение в следующем постинге.

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

Но «не относилась ко всем кешам в мире» не та фраза, а
фраза «У VIPT-ов они и за 12 не выходят»

Ой, да ладно.

У VIPT-ов они и за 12 не выходят, угадайте, почему? Хотя,
ладно, объясню. А то вы ещё неделю будете делать вид, что
знаете...
...
Именно поэтому индекс+смещение в VIPT-кеше ограничено 12
битами, ведь эти 12 бит совпадают с физическим адресом. Это
гарантирует, что любой физ.адрес попадёт только в один
кеш-сет.
Вот прям только про конкретный случай и написано, ага. :) Это вы когда про АМД увидели, тогда и стали следы заметать, а потом ещё и АРМы подтянулись, да и вообще, в РИСКах такое много где. Да и для Интела я ссылку привёл, но вы с ней не согласны, а другую искать не охота, если таких кешей и так изобилие.

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

Вот и выпишите! Я вам расписал простейший случай, и максимально подробно. Всего 2 физ страницы, 2 процесса, 2 сета. В каждом сете по алиасу внутри одной линии. 2 физ страницы лежат последовательно, и начало этого блока выровнено на 8К. Всё! Пишите пример, куда уж проще? Но только ответьте сначала на простейший вопрос: вы согласны, что, если у нас линия длиной в 13 бит, то бит номер 12 в тег не попадёт? Если ответ «да», то пишите пример. Если ответ «нет» - обоснуйте.

Благодарю за подробное объяснение. В общих чертах идея
понятна. Кроме куска:

При том, что это - самый важный кусок, без которого идея уж точно не может быть ясна... Крайне странно... Но, раз моя идея ясна, чего же я буду спорить. :)

Эту часть я не понял. В каком списке тегов мы его ищем,
в том что закреплён за кеш-сетом?

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

Тогда как по части виртуального адреса мы находим
физический тег?

Ох, ну снова здорова... Да осильте уже википедию, главу про vhints... Там всё просто: если старшие адреса вирт адреса кешу уже «знакомы», то спекулятивно по ним выбирается и физический тег. Используется хеш фунцкия для подсчёта vhint, потом поиск по ассоциативному массиву физ тегов. И вот если тут есть совпадение («тег совпал по vhint» из моей не слишком хорошей терминологии/аналогии), то тег спекулятивно признаётся верным, и данные из соотв линии выбираются для дальнейшей спекулятивной работы.

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

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

Давайте даже будет 1 процесс, ещё проще. Остальное без изменений. 1 процесс, 2 сета, 2 физ страницы непрерывно, с началом кратным 8К. Страница 1 дважды замаплена в сет 1 в одну и ту же линию (ага, 13 бит линия), страница 2 - так же в сет 2. Распишите! Только не забудьте ответить на вопрос про бит 12. Думаю, и расписывать не придётся, если верно на него ответите.

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

2 физ страницы непрерывно, с началом кратным 8К.

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

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

Дайте, пожалуйста, ссылку на сообщение, где вы процитировали тот параграф.

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

Благодарю. Ещё вопрос, с вашей точки зрения meltdown-bnd этому абзацу удовлетворяет?

Но опять же, я не буду с вами в этом направлении дискутировать, пока вы ни признаете, что тролили всех с matldown-bnd, а его без bound просто нет.

Так его же не я придумал. И не я заявил, что он есть в AMD. Я только повторяю слова авторов. И даже проверить их не могу. На интеле проверил — рабоает, а AMD у меня ни одного нет. У вас есть? Вы проверили?

Иногда вытеснит, иногда - нет. Как и ваше идиотское определение.

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

Если вы вытеснили какую-то линию из сета, то все её алиасы в других сетах будут заинвалидированы автоматически.

Брр... Что? Любое обращение к незакешированному адресу что-то вытеснит из кеша, какую-то строку, в которую его запишут, верно? Хотите сказать, оно вытесняет из кеша не одну строку, а и все строки, в которых могли быть её алиасы? С чего это? Да и зачем?

Вы ж, надеюсь, про физический адрес?

Я про ячейку памяти, ведь нам же её надо вытеснить из кеша? У неё есть физический адрес, и один или более виртуальных адресов.

то всё равно, он останется только в другом сете. А в нашем - вытеснится. Этого уже достаточно.

Как достаточно? Смысл эвикшн-сета в вытеснении адреса из кеша, где бы он ни был. Если эвикшн-сет не вытесняет адрес из кеша, то он перестаёт быть эвикшн-сетом.

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

Но тогда _любой_ одиночный незакешированный адрес — это эвикшн сет, ведь обращение к нему гарантированно приведёт к вытеснению одной из линий кеша.

Вот прям только про конкретный случай и написано, ага. :)

Да. Даже в процитированной вами части написано, что в вирт.адресе от физ.адреса зависит 12 бит, то есть про x86. И я имел ввиду конкретно интел, который был в сабже. А то в ARM-ах страницы бывают и 16KB и 64KB...

да и вообще, в РИСКах такое много где.

Кстати, а много где — это где? А то вы пока привели только пример старых AMD. В остальных, где page coloring, только количество бит другое, а решение то же самое — количество бит индекса+смещения у VIPT-кеша не превышает количества бит, которые в виртуальном адресе зависят от физического.

Я просто не пойму, зачем кто-то всё ещё мог бы так делать — зачем решать алиасы, если их можно не создавать? Это же пустая трата времени, ресурсов и места на кристалле.

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

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

1 процесс, 2 сета, 2 физ страницы непрерывно, с началом кратным 8К.
Страница 1 дважды замаплена в сет 1 в одну и ту же линию (ага, 13 бит линия), страница 2 - так же в сет 2.

Брр... Если у обоих страниц начало кратно 8K, и они лежат последовательно, то размер страницы равен 8К, и они вдвоём не поместятся в одну линию.

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

Но ранее вы писали «если тег через vhint найден, то спекулятивная ветка продолжается, и мы берём данные из соответствующей кеш линии» — если тег с линией не связан, то из какой линии мы берём данные? Из линии, соответствующей... чему?

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

Мне не понятна сама логика. Если тег определяется по vhints (по старшим битам вирт.адреса), и этот тег за линией не закреплён... то зачем в вашей архитектуре вообще нужны теги и vhints? И как вы выбираете линию?

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

Благодарю. Ещё вопрос, с вашей точки зрения meltdown-bnd
этому абзацу удовлетворяет?

Я уже сказал, что на этот вопрос отвечать не буду, пока вы не признаете, что никакого meltdown-bnd на АМД по-просту нет, пока нет bound на стороне жертвы.

И не я заявил, что он есть в AMD.

Именно вы заявили, что ему bound на стороне жертвы не нужен. Точнее, в явном виде вы это не заявили, так как и сами знаете, что вас бы тут же уличиле во лжи. По этому, сказали только вот это: Spoiler — новая уязвимость в процессорах Intel (комментарий)

> Кстати, а вы вообще давно видели инструкцию bound в ядре,
> или в юзерспейсе, пусть даже в 32-битном?

Я также никогда не встречал инструкции F0 0F C7 C8. Значит ли
это, что в старых пнях не было «F00F»-бага?
Это был тупой тролинг. Как, впрочем, и всё остальное от вас.

Нет, не иногда. В моём определении какое-то обращение
вытеснит

Какое именно по счёту? В треугольнике один из 3 улов прямой. А у вас - один из скольких? Особенно учитывая ваше же высказывание о том, что они одну и ту же линию могут всё время вытеснять.

Брр... Что? Любое обращение к незакешированному адресу что-то
вытеснит из кеша, какую-то строку, в которую его запишут,
верно?

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

Хотите сказать, оно вытесняет из кеша не одну строку, а и все

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

Продолжение дальше...

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

Как достаточно? Смысл эвикшн-сета в вытеснении адреса из кеша,

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

Да. Даже в процитированной вами части написано, что в
вирт.адресе от физ.адреса зависит 12 бит, то есть про x86.
И я имел ввиду конкретно интел, который был в сабже. А то в
ARM-ах страницы бывают и 16KB и 64KB...

Да и 4К - тоже бывают, представьте себе. :) Как и на интеле бывают _не_ 4К. Так что не надо, разницы никакой. И там и там есть разные страницы, и везде есть по 4К.

Я просто не пойму, зачем кто-то всё ещё мог бы так делать —

Вот к ним вопросы: https://marc.info/?l=linux-arm-kernel&m=127921293300352&w=2 И да, даже non-aliasing там означает лишь, что алиасы резолвятся аппаратно (что написано по этой же ссылке, в цитате).

Брр... Если у обоих страниц начало кратно 8K, и они лежат
последовательно, то размер страницы равен 8К, и они вдвоём не
поместятся в одну линию.

Что, опять на тупость перешли? 2 страницы по 4К лежат последовательно, и начало этого блока (из 2 страниц) выровнено на 8К (а не на 4, как могло бы быть).

если тег с линией не связан, то из какой линии мы берём
данные? Из линии, соответствующей... чему?

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

то зачем в вашей архитектуре вообще нужны теги и vhints?
И как вы выбираете линию?

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

Но тогда _любой_ одиночный незакешированный адрес — это
эвикшн сет, ведь обращение к нему гарантированно приведёт к
вытеснению одной из линий кеша.

Разумеется, вытесняемая линия должна тоже целиком принадлежать нашему сету. К такой мелочи и придираться глупо. Ну ладно, во фразу «_гарантированно_ приведёт к вытеснению одной из линий» добавить «нашего сета». А по факту то? Кроме мелких придирок и тролинга - опять ничего?

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

Я уже сказал, что на этот вопрос отвечать не буду, пока вы не признаете, что никакого meltdown-bnd на АМД по-просту нет, пока нет bound на стороне жертвы.

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

Какое именно по счёту? В треугольнике один из 3 улов прямой. А у вас - один из скольких?

Из стольких, сколько там адресов. Один из адресов сета. Также как в треугольнике — один из углов.

нет, имел в виду, конечно, что инвалидируются алиасы записываемой строки.

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

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

Во-вторых, я говорю про алиасы вытесняемого адреса, а не алиасы адресов сета.

А не соблаговолите ли уточнить, откуда у эвикшн сета вообще возьмутся алиасы?

Ниоткуда, но они могут быть у адреса, который надо выяснить.

Разумеется, вытесняемая линия должна тоже целиком принадлежать нашему сету.

Вот тут я полностью потерял мысль. У меня вытесняемый адрес не принадлежит сету, ну, может принадлежать, но не должен. Иначе для чего тогда _такой_ эвикшн сет? Чтобы вытеснить один из адресов этого же эвикшн сета? А зачем?

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

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

Как и на интеле бывают _не_ 4К.

На intel x86? Разве там не везде 4к, а всякие large/huge pages идут только дополнительно к 4к-страницам?

Вот к ним вопросы: https://marc.info/?l=linux-arm-kernel&m=127921293300352&w=2 И да, даже non-aliasing там означает лишь, что алиасы резолвятся аппаратно (что написано по этой же ссылке, в цитате).

Почему к ним, откуда им знать, зачем так сделано, и так ли сделано. Может быть на аппаратном уровне эти алиасы вообще не создаются. Они же написали «it behaves like PIPT», так может там и нет никаких алиасов, и всё сделано как в интелах.

Кстати, забавно, спустя 7 лет они же и выпилили aliasing detection: https://github.com/torvalds/linux/commit/3689c75af2 потому что оказалось, что эта информация не всегда соответствует фактической микроархитектуре.

2 страницы по 4К лежат последовательно, и начало этого блока (из 2 страниц) выровнено на 8К

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

набор тегов закреплён за сетом. За тегом закреплён вэй. За ним - уже линия.

То есть цепочка такова: по вирт.адресу находим кеш-сет и vhint, по vhint-у в кеш-сете находим тег, по тегу в наборе тегов кеш-сета находим вэй, по вэю - линию. Верно?

Но тогда зачем такая длинная цепочка, почему vhint не указывает прямо на линию? И что происходит, когда заканчивается TLB Lookup? Как проверяется, правильную мы линию читаем или нет?

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

Ну тогда я не могу этого признать.

Не можете признать - покажите атаку (по определению из той вашей статьи). Не можете показать - идите в жопу. Куда уж проще?

Из стольких, сколько там адресов.

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

Во-вторых, я говорю про алиасы вытесняемого адреса, а не
алиасы адресов сета.

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

Ниоткуда, но они могут быть у адреса, который надо выяснить.

Адрес, который вытесняется - и есть адрес атакующего. Он вытесняется по аксессу жертвы к одному из адресов сета.

У меня вытесняемый адрес не принадлежит сету,

Я уже давно понял, что у вас один бред. Все вытесняемые адреса принадлежат сету. Как и вытесняющий, иначе не вытеснит.

Иначе для чего тогда _такой_ эвикшн сет? Чтобы вытеснить
один из адресов этого же эвикшн сета? А зачем?

Чтобы потом пройтись по всем линиям, померить их тайминг, и посмотреть, вытеснялась ли хоть одна. Вы вообще не шарите? Это пустая трата времени. Ликбезов больше не будет.

Вот для подобных атак и нужен эвикшн сет

Оо, да вы очень умный, я смотрю.

Кстати, забавно, спустя 7 лет они же и выпилили aliasing
detection

Ага, спасибо за ссылку:

Instead, assume the I-cache is always aliasing if it
advertises a VIPT policy.
Ещё вопросы?

то у линии должно быть два тега, а не один.

Ага, то есть, мой вопрос про бит 12 троль «не заметил». Хорошо, объясняю в последний раз. Биты тега не могут пересекаться с битами оффсета, иначе понадобилось бы несколько тегов. Если у нас бит 12 в тег не входит, то кеш сможет класть в одну линию те физ страницы, у которых различается только этот бит. Если же различается не только этот бит - будет класть в разные линии. Надо будет ассоциативности добавить нашему гипотетическому кешу. :)

То есть цепочка такова:

Да.

Но тогда зачем такая длинная цепочка, почему vhint не
указывает прямо на линию?

Как он может указывать на линию, если это просто хеш? Он вообще ни на что не указывает, его можно только использовать как ключ при поиске в ассоциативном массиве. Да и тег примерно так же работает: ключ, в виде физ адреса, используется для поиска тега в ассоциативном массиве. Сам тег - это не физ адрес, а просто структура данных, в которой, в частности, есть номер вэя. Вот именно этот тэг, а не его ключ в виде физ адреса, и находится по vhintу. Так что можете считать, что сразу линия находится, если вам так проще.

Короче, как я понимаю, никаких вопросов по существу больше нет? Тогда у вас слив по всем пунктам, и, поскольку вы так и не показали meltdown-bnd без bound, я не вижу смысла разжёвывать вам что-то ещё. Вы только тупите, и за месяц не поняли вообще ничего. Думаю, больше на вас время тратить не стоит.

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

Все вытесняемые адреса принадлежат сету. Как и вытесняющий,
иначе не вытеснит.

Кэш сету. А эвикшн сету вытесняющий адрес может и не принадлежать. Это на случай мелких придирок...

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

Это ещё почему, если сами говорили, что у вас одну и ту же линию могут всё время вытеснять? То есть, может вообще не получиться, а может и с первого раза...

Ну не всё же время? Рано или поздно другая линия вытеснится. Я лишь говорю, что если у нас 4-way кэш, то 4 адреса в эвикшн сете может не хватить.

Вытесняемый адрес, точнее вытесняемая линия - и есть адреса сета. И алиасов в них, очевидно, нет.

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

Все вытесняемые адреса принадлежат сету. Как и вытесняющий, иначе не вытеснит.
Кэш сету. А эвикшн сету вытесняющий адрес может и не принадлежать. Это на случай мелких придирок...

Благодарю за это уточнение. Это не мелкая придирка. Я действительно решил, что во фразе «вытесняемая линия должна тоже целиком принадлежать нашему сету» вы имели ввиду эвикшн сет.

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

Ага, спасибо за ссылку:
Instead, assume the I-cache is always aliasing if it advertises a VIPT policy.

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

И, да, это I-cache! Я поясню ещё раз. Мы обсуждаем, где решается aliasing problem, при которой один физический адрес может попасть в разные строки кеша, их могут одновременно изменить, и этот конфликт придётся как-то решать. Так вот, в I-cache не пишут! Из него только читают. И даже если ОС полностью забьёт на алиасы, там нет aliasing problem! Поэтому можно 7 лет не замечать, что ядро неправильно детектит тип кеша.

Ещё вопросы?

Да вопрос, в общем-то, не изменился. Вы писали «Достаточно просто посмотреть характеристики современных L1/L2 кешей чтобы понять, что [...] алиасы там неизбежны.» Вот мне и стало интересно, в каких ещё современных процессорах до сих пор решают aliasing problem вместо того, чтобы её не создавать. Где ещё количество бит индекса+смещения у VIPT-кеша превышает количество бит, которые в виртуальном адресе зависят от физического.

Мы посмотрели intel, amd и arm. Оказалось, что даже в ARM-е алиасы в кеше были только в ARMv6, да и там решались тем же page coloring-ом, то есть опять нужное число битов вирт.адреса определялось по физическому. А в современных армах алиасы только в кеше инструкций, где нет aliasing problem. По сути, все основные архитектуры мы просмотрели, осталась только экзотика. Но мне даже для ARM-ов не удалось найти, как именно там было сделано аппаратное разрешение алиасов, если оно там и было.

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

В каком смысле «в разные линии»? И каждая линия будет использована наполовину? А что будет во второй половине линии?

Как он может указывать на линию, если это просто хеш? Он вообще ни на что не указывает, его можно только использовать как ключ при поиске в ассоциативном массиве.

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

Короче, как я понимаю, никаких вопросов по существу больше нет?

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

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

Ну не всё же время? Рано или поздно другая линия вытеснится.

Но вы сказали, «Из стольких, сколько там адресов.» Откуда такая гарантия, что попыток по кол-ву адресов - хватит? Может, в 20 раз больше понадобится, если одна и та же линия вытесняется? Короче, идите бредить в другое место.

Но могут быть алиасы не у линии, а у адреса.

Это ещё что за новая бредятина? У одного адреса из линии? А у остальных, типа, нет? Да шли бы вы, тупой троль.

Благодарю за это уточнение. Это не мелкая придирка. Я
действительно решил, что во фразе «вытесняемая линия должна
тоже целиком принадлежать нашему сету» вы имели ввиду эвикшн
сет.

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

Вытесняемый адрес принадлежит кеш сету, но, при алиасном
кеше, может принадлежать нескольким

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

Так вот, в I-cache не пишут! Из него только читают. И даже
если ОС полностью забьёт на алиасы, там нет aliasing
problem!

Ой, да конечно. :) Вам никто не мешает замапить один и тот же блок кода на разные вирт адреса, проекзекьютить его, чтобы запрефетчить в i-cache, а потом, в одном из этих блоков переписать его через d-cache. Та же самая проблема.

В каком смысле «в разные линии»? И каждая линия будет
использована наполовину?

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

Это просто была мелкая оптимизация для вашей архитектуры.

Мне не нужно от вас мелких оптимизаций. Мне нужно, чтобы вы перестали тупить. Что, впрочем, невозможно.

Например «что происходит, когда заканчивается TLB Lookup,
как проверяется, правильную мы линию читаем или нет?»

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

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

Вот мне и стало интересно, в каких ещё современных
процессорах до сих пор решают aliasing problem

В мипсах, например: http://lkml.iu.edu/hypermail/linux/kernel/0610.2/2037.html

D-cache VIPT, I-cache VIPT
This is by far the most common on any MIPS designed since '91.
A variant of these caches has hardware logic to detect cache
aliases and
fix them automatically and therefore is equivalent to PIPT even
though they are not implemented as PIPT.
«A variant of these caches» - то есть, даже не все. Ну и в xtensa то же самое. А в АРМах - у них всегда в d-cache есть логика резолвинга алиасов, и только i-cache алиасится без аппаратного резолвинга. То есть, по видимому, в том примере, как я привёл выше (когда кто-то через d-cache инвалидирует один из алиасов на код), придётся вручную искать все алиасные линии i-cache, стобы их зафлушить.

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

Не на половину. Будет брать следующую виртуальную страницу.

... а если она не подходит по тегу, то см. Spoiler — новая уязвимость в процессорах Intel (комментарий) То есть, операционка должна будет следить, чтобы последовательно клались только такие адреса. Если же операционка не уследила - virtual coherency exception. Ну это как вариант. Придумать можно и другие реализации.

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

вообще может быть PIPT-ом.

И на что эта ссылка?

I think PIPT does not mean VIPT non-aliasing even
though their functionality is similar.
Isn't there any functionality difference?
And..in this case, isn't there any problems?
Крайне авторитетно и информативно. Да и вообще, вряд ли кто будет делать L1 как PIPT, ведь тогда нельзя в параллель с tlb lookup туда запрос давать, не говоря уже о спекулятивных механизмах типа vhints.

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

«Из стольких, сколько там адресов.» Откуда такая гарантия, что попыток по кол-ву адресов - хватит?

Это гарантия моего алгоритма: адреса добавляются в эвикшн сет до тех пор, пока не вытеснит.

Это ещё что за новая бредятина? У одного адреса из линии? А у остальных, типа, нет? Да шли бы вы, тупой троль.

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

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

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

никто не мешает замапить один и тот же блок кода на разные вирт адреса, проекзекьютить его, чтобы запрефетчить в i-cache, а потом, в одном из этих блоков переписать его через d-cache. Та же самая проблема.

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

Термин «cache aliasing» относится только к алиасам в одном кеше. Проблема маппинга одинаковых адресов в разные кеши называется «cache coherence», и её мы ещё не обсуждали. Но она бывает при любом типе кеша, например, в многоядерных системах, где у каждого ядра свой кеш, и разные ядра работают с одной областью памяти.

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

А что будет в линии, если следующей виртуальной страницы нет, если в неё ничего не смаплено?

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

Ха, хорошая попытка! Позволяет выкрутиться из многих проблем. Но вопрос не только к операционке: а процессор-то что делать будет? Что реально будет в линии, и как процессор решит, что туда писать, куда она указывает, и можно ли использовать эти данные?

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

Очевидно, что проверяется это легко: если нашёл ту же линию - хорошо. Если ничего не нашёл по физ адресу - то это была не та линия.

Но как именно? Узнали физ.адрес, а дальше? Как зная физ.адрес мы определим, та ли это линия?

вообще может быть PIPT-ом.

И на что эта ссылка? ... вряд ли кто будет делать L1 как PIPT

На фразу:
> [kernel] printed like following
> 'CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache'
> actually, Samsung S5PV310(cortex-A9) has PIPT d-cache
То есть ядро пишет не тип кеша, а то, как оно с ним работает.

В мипсах, например... Ну и в xtensa

Xtensa же требует какой-нибудь page coloring от ОС, то есть там алиасы не создаются. Разве там есть аппаратный ресолв алиасов? А именно по MIPSам нашлось, что там для борьбы с L1-алиасами добавляли поля в L2. L2, очевидно, медленнее, чем L1, отсюда «небольшое» замедление («small difference in the clock rate you are able to achieve») и «some penalty for data cache accesses».

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

http://lkml.iu.edu/hypermail/linux/kernel/0610.2/2037.html

Кстати, в целом тот тред согласен со мной, и ещё менее лестно отзывается о создателях процессоров с алиасами и о том, что с ними надо сделать:

> Castration. That's the best solution. We don't want those people procreating.

Сравните с вашим «алиасы там неизбежны, достаточно просто посмотреть характеристики современных L1/L2 кешей».

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

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

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

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

Уважаемый идиот, я вам специально дальше разжевал, что линии из i-cache, в таком сценарии, потом придётся флушить вручную. Так вот, если зафлушить только одну, а её алиасы оставить - будет ровно та же самая проблема. Но до вас не дошло... Увы.

А что будет в линии, если следующей виртуальной страницы
нет, если в неё ничего не смаплено?

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

Ха, хорошая попытка! Позволяет выкрутиться из многих
проблем.

Хотел сказать, что проблемы тут только у вас, так как вы лишь тупите, и до сих пор не признали слив по meltdown-bnd... Но, раз мозгов у вас нет, то и проблем нет тоже.

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

С тегом и так хранится куча служебных бит. В нашем случае потребуется 4 доп бита на линию, как я описал выше. Тут проблемы нет ни малейшей.

Очевидно, что проверяется это легко: если нашёл ту же
линию - хорошо. Если ничего не нашёл по физ адресу - то
это была не та линия.

Но как именно? Узнали физ.адрес, а дальше? Как зная
физ.адрес мы определим, та ли это линия?

Упроротый тупой троль, перечитайте ещё раз процитированный вами же фрагмент. Я не собираюсь вам по сто раз один и тот же ответ повторять.

На фразу:

От кого? Там что, пруфы есть? Давайте дальше ссылки на письма непонятно от кого.

Xtensa же требует какой-нибудь page coloring от ОС, то
есть там алиасы не создаются.

Но создать их можно. Кстати, кеш колоринг можно использовать и с аппаратным резолвингом алиасов. Просто чтобы их не плодить - всяко быстрее будет. Так что наличие или отсутствие аппаратного резолвинга никак из этого не выводится, да и не важно в данном случае. Важно, что биты индекса выходят за 12.

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

Молодец, возьми с полки пирожок. И так, я объяснил тупому тролю, что, в современных процах, полно кешей как с аппаратным резолвингом алиасов, так и без него? Тогда продолжайте тупить в другом месте.

Сравните с вашим «алиасы там неизбежны, достаточно просто
посмотреть характеристики современных L1/L2 кешей».

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

Кстати, из того форума непонятно, они собираются кастрировать тех, кто создаёт алиасы без аппаратного резолвинга, с ним, или и тех, и других? Думаю, только о первых шла речь. А у нас речь шла о любых алиасах, когда бит индекса выходит за 12.

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

линии из i-cache, в таком сценарии, потом придётся флушить
вручную.

Инвалидировать, а не флушить. На случай очередных придирок.

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

я вам уже тысячу раз объяснил, что в вытесняемых адресах алиасов не будет. Алиасы же вытесняющего адреса никого не волнуют. Эвикше сет нужен, чтобы одну из наших линий вытеснил атакуемый. Вы не понимаете ни хрена.

Действительно, не понимаю. То что вы описываете — это prime set, особый, частный случай эвикшн сета, используемый в атаке prime+probe. Он не подходит ни под моё определение, ни под то определение эвикшн сета, на которое ссылались вы. Да и конструируется он иначе, под конкретные процессоры с известным типом и механизмом работы кеша.

я вам специально дальше разжевал, что линии из i-cache, в таком сценарии, потом придётся флушить вручную... будет ровно та же самая проблема.

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

Тогда очевидно, что к этой части кеш линии вообще обращений не будет - MMU не пропустит.

У нас же обращение по вирт.адресу, ещё до ответа от MMU.

Тут особой проблемы то нет, единственное, придётся хранить, вместе с тегом, несколько доп битиков. Среди них - младший бит физ адреса для каждой из страниц

Вот как раз тут и проблема. Вы сочиняли архитектуру, где теги совпадают, а адреса разные. Но «несколько доп битиков» делают тег длиннее и он перестаёт совпадать. О чём я и говорил в «совпадение тега гарантирует совпадение физ.адресов»

Упроротый тупой троль, перечитайте ещё раз процитированный вами же фрагмент. Я не собираюсь вам по сто раз один и тот же ответ повторять.

А вы сами-то читали? Я специально цитировал же. Там написано «нашёл по физ адресу», и я спросил как именно он искал по физ.адресу. Там этого нет, что перечитать-то?

От кого? Там что, пруфы есть? Давайте дальше ссылки на письма непонятно от кого.

Пруфы-то я и искал, когда нашёл это письмо. А «от кого» — это вы хорошо спросили. Там прямо в письме написано:
> Kukjin Kim <***@samsung.com>, Senior Engineer,
> SW Solution Development Team, Samsung Electronics Co., Ltd.

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

Смотря как сделан этот аппаратный ресолвинг. Он ведь срабатывает на каждый кеш мисс, не важно, есть алиасы или нет, он будет их искать, тратя процессорные ресурсы. Если бы это было хоть немного выгодно, то всякие intel/amd делали бы так в каждом процессоре.

С другой стороны кеш-колоринг тоже не бесплатный. Он тормозит выделение/освобождение, и создаёт очень сложные проблемы при высокой занятости памяти, когда заканчиваются страницы какого-то цвета. Из-за этого Линус издавна был против cache coloring, ведь это замедляло работу.

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

Так что наличие или отсутствие аппаратного резолвинга никак из этого не выводится, да и не важно в данном случае. Важно, что биты индекса выходят за 12.

За 12 выходят. Но не выходят за количество битов, которое в виртуальном адресе зависит от физического.

И так, я объяснил тупому тролю, что, в современных процах, полно кешей как с аппаратным резолвингом алиасов, так и без него?

Если «современными процессорами» считать не intel/amd, а умирающий mips и xtensa, то да, объяснил...

И где же ошибка в этой моей фразе, о тупой троль?

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

проблемы тут только у вас, так как вы лишь тупите, и до сих пор не признали слив по meltdown-bnd...

Доберёмся и до мелтдаунов. Мы почти закончили существующие темы. С алгоритмом вы, похоже, уже не спорите. Осталось только убедить вас, что в выдуманной архитектуре физ.адреса тоже совпадут.

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

Он не подходит ни под моё определение

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

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

Это под какое же, если не секрет?

Почему именно вручную? Нормальные процессоры сами заботятся
о когерентности кеша.

То есть, по вашему, если создать алиасы в i-cache, как я описал выше, а потом переписать один из них через d-cache, то i-cache, без аппаратного резолвинга алиасов, тем не менее их все найдёт и проинвалидирует автоматически? Полагаю, пруфы можно и не пытаться просить? :)

У нас же обращение по вирт.адресу, ещё до ответа от MMU.

Тьфу ты, дурик, по чтению - да, а по записи - нет. :) А то дороговато будет «портить» кеш линию спекулятивно, а потом восстанавливать. Соответственно, даже никакие биты присутствия не понадобится. Префетчим всегда 2 последовательные физ страницы, спекулятивно их и отдаём. Когда физ адрес провалидирован через TLB, тогда, если не та страница - префетчим нужную...

Но «несколько доп битиков» делают тег длиннее и он
перестаёт совпадать.

Пуууфф... Вообще-то, я вам уже пытался намекнуть, что тег - это не только ключ поиска в CAM, которым является vhint или кусок физ адреса. По этому ключу находят структуру данных, где есть номер вея, и куча служебных бит о состоянии линии. Таким образом, добавив в эту структуру (а не к ключу! не к ключу поиска структуры!!! поймите уже хоть это!) туда 2 битика, мы ни коим образом не создадим 2 тега! Мы даже структуру данных тега при этом не увеличим, так как там резервных бит и так полно: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0464f/BABDIJAD...

Тег, при этом, не «перестаёт совпадать», так как ключ поиска у нас всё тот же, без бита 12! Что непонятно то?

О чём я и говорил в «совпадение тега гарантирует совпадение
физ.адресов»

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

Продолжение ниже...

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

А вы сами-то читали? Я специально цитировал же. Там написано
«нашёл по физ адресу», и я спросил как именно он искал по
физ.адресу.

Нет, прошлый вопрос звучал «Как зная физ.адрес мы определим, та ли это линия?», и на него я ответил. Если у вас теперь новый тупой вопрос, «как искал», то отвечаю: используя старшую часть физ адреса (от бита 13 и до конца) в качестве ключа поиска в CAM.

Там прямо в письме написано:

И что это доказывает? Некий SW Solution инженер спросил в списке рассылки, есть ли отличия у PIPT и aliasing VIPT. Очевидно, будь у него хоть малейшее отношение к HW Dev Team, он бы такую фигню в публичных рассылках не узнавал...

Не тормозит только кеш с высокой ассоциативностью без
алиасов.

Высокая ассоциативность, очевидно, тоже тормозит. Почему-то её обычно не делают больше 8.

За 12 выходят. Но не выходят за количество битов, которое
в виртуальном адресе зависит от физического.

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

Если «современными процессорами» считать не intel/amd, а
умирающий mips и xtensa, то да, объяснил...

И для АМД нашёл, и для Интел (но с ним только для i-cache нашёл) - достаточно.

Ошибка не во фразе, а в оценке ситуации. По-вашему «алиасы
неизбежны»

Нет, тупой идиот, там не было оценки ситуации. Алиасы неизбежны, когда выполняются указанные выше условия по размеру и ассоциативности. Всё.

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

То есть, ваша клоунада и тупые вопросы приведут к убеждению меня в чём либо? Или, может, в один прекрасный день вы перестанете тупить, и начнёте уже «убеждать»? :) Даже не знаю, дождусь ли этого, или вас тут забанят раньше. :)

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

И для АМД нашёл, и для Интел (но с ним только для i-cache
нашёл)

И для арм, конечно, тоже.

Доберёмся и до мелтдаунов. Мы почти закончили существующие
темы.

Звучит как ультиматум... Хорошо, давайте я сделаю вид, что признал всю вашу чушь по предыдущим темам, и вы, наконец, откроете мне тайну мироздания о meltdown-bnd. :) Блин, с какими же укурками иногда приходится дело иметь...

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

и вы, наконец, откроете мне тайну мироздания о
meltdown-bnd. :)

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

Так что, либо давайте meltdown-bnd, либо ваши глупости таки окажутся в этом триде последним письмом...

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

Всё, о чём вы когда-либо говорили - не более, чем клоунада,
увы.

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

Вот объяснял-объяснял про vhints, а в ответ «Благодарю за подробное объяснение. В общих чертах идея понятна. Кроме куска: ... Тогда как по части виртуального адреса мы находим физический тег?» Пиляяять... Ну отправил в википедию читать, чего второй раз объяснять то. Думал, прочитал. Но через пару дней: «почему vhint не указывает прямо на линию?» Пипец. Начинаю объяснять, что vhint - не указатель, а ключ поиска. Объясняю про САМ, про тег... А в ответ: «Это просто была мелкая оптимизация для вашей архитектуры.» Какая, к чёрту, оптимизация? Ну да пофиг, про ассоциативный массив ведь, вроде, понял: «Но у этого ассоциативного массива же есть значение. Вот оно и может указывать на линию.» - и то хлеб. Сойдёт, думал. Данные тега ведь и правда указывают на вэй - пускай думает, что на линию, разница не велика...

И на тебе: «Но «несколько доп битиков» делают тег длиннее и он перестаёт совпадать.» Хоть стой, хоть падай: все объяснения про ассоциативный массив и ключ поиска коту под хвост... И так - изо дня в день. Тупость да клоунада. Товарищ анонимус, да вы почему до сих пор не в клубе анонимных алкоголиков то? :) Но меня отпуск зовёт. На вашу чушь больше тратить время не получится. Надеюсь, вас тут кто-нибудь другой пошугает. Не годится давать возможность всяким алконавтам тролить людей на технических форумах.

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

Это под какое же, если не секрет?

Вы давали ссылку на https://vwzq.net/papers/evictionsets18.pdf где в секции «III.A. Defining Eviction Sets» есть определение.

То есть, по вашему, если создать алиасы в i-cache, как я описал выше, а потом переписать один из них через d-cache, то i-cache, без аппаратного резолвинга алиасов, тем не менее их все найдёт и проинвалидирует автоматически? Полагаю, пруфы можно и не пытаться просить? :)

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

Тьфу ты, дурик, по чтению - да, а по записи - нет. :)

А кто говорил про запись? Или читать из несмапленой страницы уже можно?

Соответственно, даже никакие биты присутствия не понадобится. Префетчим всегда 2 последовательные физ страницы, спекулятивно их и отдаём. Когда физ адрес провалидирован через TLB, тогда, если не та страница - префетчим нужную...

Тут я опять потерял мысль. Прямо дислексия какая-то. Ну сколько ж раз просил — напишите в числах. Давайте я начну...

Страница 4к. Вирт.адрес 0x12345678 в вирт.странице 0x12345000. Её физ.адрес 0xABCDE000. Что лежит в линии кеша? Какие «2 последовательные физ страницы»? 0xABCDE000 и 0xABCDF000? Какой тут будет тег и какие «доп битики»? Как процессор по вирт.адресу определит, какая половина линии «нужная»? Напишите числа, у вас ведь хорошо получалось...

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

Вы ранее подтвердили, что у вас «по вирт.адресу находим кеш-сет и vhint, по vhint-у в кеш-сете находим тег, по тегу в наборе тегов кеш-сета находим вэй, по вэю - линию». Где и как в этой цепочке участвуют ваши «2 битика»? Опишите исправленную архитектуру.

используя старшую часть физ адреса (от бита 13 и до конца) в качестве ключа поиска в CAM.

На всякий случай уточню, во фразе «от бита 13» вы считаете биты от 0 или от 1?

Что ж мне по крупицам из вас ответы вытаскивать приходится... Сами свою же идею никак не опишете, а потом жалуетесь на «клоунаду».

И что это доказывает?

Это отвечает на ваш вопрос.

Некий SW Solution инженер спросил в списке рассылки, есть ли отличия у PIPT и aliasing VIPT. Очевидно, будь у него хоть малейшее отношение к HW Dev Team, он бы такую фигню в публичных рассылках не узнавал...

Этого он не спрашивал.

Высокая ассоциативность, очевидно, тоже тормозит. Почему-то её обычно не делают больше 8.

Она не тормозит — она электричество жрёт и процессор греет. Её сложно сделать так, чтобы она не жрала в 8 раз больше. Но как-то делают...

При использовании cache coloring? А какое вообще отношение программный механизм - cache coloring - имеет к обсуждаемым нами аппаратным аспектам работы кеша?

Но без cache coloring или аналога таким процессором не пользуются. Или что мы в таком случае обсуждаем?

Биты индекса выходят за биты размера страницы MMU - вот что важно с точки зрения аппаратуры. «алиасы тут неизбежны».

Алиасы «неизбежны», но тем не менее из-за кеш колоринга их нет. Странная «неизбежность»...

И для АМД нашёл, и для Интел (но с ним только для i-cache нашёл) - достаточно.

Не факт, что нашли. Пруфов вы не давали. Для интела я проверил — не подтвердилось, AMD у меня нет, проверить не могу. У вас есть? Проверили?

Кстати, вы считаете процессоры десятилетней давности «современными»? И, да, мы про aliasing problem, которая есть только при записи, которой нет в i-cache.

И для арм, конечно, тоже.

Там где PIPT-кеш?

Нет, тупой идиот, там не было оценки ситуации. Алиасы неизбежны, когда выполняются указанные выше условия по размеру и ассоциативности.

Там не было условий, там было «достаточно просто посмотреть характеристики современных L1/L2 кешей». Оказалось не так и просто, до сих пор смотрим.

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

где в секции «III.A. Defining Eviction Sets» есть
определение.

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

Пруфы чего? Причём тут вообще алиасы? Алиасы — в пределах
одного кеша.

Вот идиот, я же сто раз сказал, как создать алиасы в i-cache. Замапить один кусок кода в разные места, и заэкзекьютить каждый маппинг, чтобы запрефетчился. Сколько ж тупить можно?

А кто говорил про запись? Или читать из несмапленой
страницы уже можно?

Спекулятивно - да. Как мы знаем, все так и делают. :)

Какие «2 последовательные физ страницы»? 0xABCDE000 и
0xABCDF000?

Как вариант, я предложил спекулятивно брать 2 последовательные страницы. По этому, сначала именно так. Но в моём примере 2 последовательные вирт страницы мапят одну физ страницу, по этому, со временем, в одной линии будет дважды лежать 0xABCDE000, а в другой - дважды 0xABCDF000 (после прихода ответов от TLB).

Какой тут будет тег

Одинаковый (0xabcde000 для обеих линий).

и какие «доп битики»?

0 0 для первой линии, и 1 1 для второй.

Как процессор по вирт.адресу определит, какая половина
линии «нужная»?

Биты оффсета, как известно, напрямую из вирт адреса берутся. Соответственно, бит 12 и будет определять «нужную половину». Что непонятно то?

Где и как в этой цепочке участвуют ваши «2 битика»?

Я вам уже привёл даже ссылку на tag data. Вот там и лежат.

Опишите исправленную архитектуру.

Относительно чего исправленную? Её никто не правил.

На всякий случай уточню, во фразе «от бита 13» вы считаете
биты от 0 или от 1?

От 0.

Этого он не спрашивал.

I think PIPT does not mean VIPT non-aliasing even
though their functionality is similar.
Isn't there any functionality difference?
And..in this case, isn't there any problems?

Ещё враки будут? «non-aliasing», в случае АРМ, как мы уже знаем, означает и аппаратный резолвинг алиасов тоже.

Она не тормозит

Иди читай википедию уже...

However, increasing associativity more than four does not
improve hit rate as much

Но как-то делают...

Кто делает в L1 более 8 вэев?

Но без cache coloring или аналога таким процессором не
пользуются.

В i-cache - спокойно. Или, если это унифицированный кэш, то для инструкций, опять же, можно cache coloring не использовать. Алиасы в обоих случаях можно создать. Так что кеш колоринг - не панацея, и для нас главное, что биты индекса выходят за размер страницы MMU. И таких архитектур полно.

Не факт, что нашли. Пруфов вы не давали.

https://www.amd.com/system/files/TechDocs/43042.pdf

64-Kbyte 2-Way Associative ECC-Protected L1 Data Caches

Для интела я проверил — не подтвердилось

Ну да, проверять будет тот, кто считает, что кэш линию индекс выбирает. :)

И, да, мы про aliasing problem, которая есть только при
записи, которой нет в i-cache.

Во первых, есть. Во вторых, для АМД это и d-cache тоже. Для интела - не знаю, может быть только i-cache.

Там где PIPT-кеш?

Даже если верить вашему «пруфу», где чел спрашивает о различиях, так даже там он лишь пишет, что это конкретный чип самсунга так сделан. Я же вам давал пруфы от людей из ARM, ссылавшихся на лид архитектора. И на патент от того же АРМ. Поди по-лучше пруф, чем какой-то вопрос на форуме. Соответственно, вне зависимости от того, что делает самсунг, на АРМах алиасы есть, и, для d-cache, резолвятся аппаратно.

Там не было условий, там было «достаточно просто посмотреть
характеристики современных L1/L2 кешей»

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

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

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

Кто делает в L1 более 8 вэев?

Сам уже нашёл: ARM940T так делает. Но, при этом, не для увеличения размера кэша. И i-cache и d-cache там по 4К. БольшИх кэшей с высокой ассоциативностью пока не нашёл, а вот с алиасами - полно.

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

по тегу в наборе тегов кеш-сета находим вэй

Нет, по ключу тега (коим является кусок физ адреса либо vhint) находим tag data, а там номер вея.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.