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

Вы просите пруфов, которых сами не предоставляете.

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

Все ваши пруфы - на какое-то объяснение от малопонятных людей, в условном интернет.
У вас нет документации на фичу,

Ну, я же не виноват, что производитель так подробно описал эту опцию: «This item allows you to set different values that may help different software’s performance».

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

Это называется «обоснованное предположение». Шерлок Холмс называл это дедукцией. Я могу объяснить ещё раз, а вы укажете, где я ошибаюсь.

Эти опции созданы, чтобы тесты CB11, CB15 и Aida/Geekbench проходили быстрее. Согласны? А значит они созданы стабильными, чтобы с любой из них ОС загрузилась, и соответствующий тест выполнился. Согласны? Если не верите — есть примеры, опции действительно работают, это не «буллшит».

Вы утверждали, что эти опции только меняют частоты/напряжения? Это не верно — у разных опций частоты и напряжения совпадают. Так что же они меняют?

Моя догадка — микрокод. Другие считают:

It's messing with a couple of hidden registers on the CPU.
The performance bias options rely on setting non-default AMD settings which are disabled by AMD due to instability issues affecting some CPUs.

Итого, мы имеем опции, которые сделаны для ускорения бенчмарков, есть только для AMD/Ryzen-ов, и меняют какие-то недокументированные AMD-шные настройки.

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

Если у вас есть другое объяснение этим опциям — предлагайте. Только не забудьте объяснить, почему эти опции назвали именами бенчмарков.

Про скандал с l1tf писалось в этой ветке не единожды, только не писалось именно о лицензии, которую intel в последствии сократили.

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

И писалось о падении производительности.

Вроде бы, у l1tf было «ничтожное влияние на производительность». Замедления были только для облачных провайдеров, у которых пришлось чистить кеш при переключении VM-ов.

Вы не знаете, как распространяется микрокод, и не в курсе, что в Microsoft он прилетает после того, как прилетает сначала OEM.

OEM прислали апдейт микрокода в microsoft, и те обновили его в винде? То есть «windows update» включает в себя и апдейт микрокода, разве нет?

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

Вообще-то та цитата была ответом конкретно на мои слова:
> «С сабжем поиск делается брут-форс-методом на наборе адресов, отличающихся в физическом адресе на число, кратное 1М.»?
Она им как-то противоречит или опровергает? Если нет, то почему вы ответили:
> «Вот же идиот, таки сморозил, что это один и тот же брут-форс»?
И почему вы затем написали:
> «Разумеется, они берут тот же алгоритм, и натравливают его на тот пул страниц, который до этого «просеяли» с помощью 1М алиасов. Это именно то, что я и говорил»
Eсли это говорили не вы, а я? Или вы не читали то, что я написал?

Woolf и какой-то другой анонимус [...] попросили ВАС самого написать, как это вы собираетесь с помощью meltdown-bnd атаковать отсутствующую инструкцию bound.

Не помню, где они меня об этом просили. Можно ссылку?

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

И по этой ссылке нет ни Woolf-а, ни meltdown-bnd, ни bound.

Серьёзно? А кто такое говорил? Или, может, это ваши фантазии? Там не «некоторые технические различия» были, а полное непонимание.

Ха! Кто говорил? Вы: «Я бы мог объяснить вам технические детали различий». Вы даже свои слова не читаете? ;)

Нет, остановилось много на чём, но только не на этом. Когда покажете публике, как вы meltdown-bnd применяете к отсутствующей bound, тогда, может, можно будет продвинуться

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

Вы думаете, мне действительно нужен с вами диалог в таком ключе?

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

Только вот почему вы этого не признаёте? Что плохого в том, чтобы что-то не знать?

Eсли это говорили не вы, а я? Или вы не читали то, что я
написал?

Вы написали уже много чего. И данная нить пошла вот отсюда: Spoiler — новая уязвимость в процессорах Intel (комментарий)

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

И по этой ссылке нет ни Woolf-а, ни meltdown-bnd, ни bound.

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

Серьёзно? А кто такое говорил? Или, может, это ваши
фантазии? Там не «некоторые технические различия» были, а
полное непонимание.

Ха! Кто говорил? Вы: «Я бы мог объяснить вам технические
детали различий». Вы даже свои слова не читаете? ;)

А кто сказал, что «объяснить технические детали» означает, что там есть «некоторые технические различия»? Из того, что я могу объяснить технические детали, никак не следует, что имеются лишь «некоторые технические различия». Совершенно неграмотно делать такие заключения.

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

Не прокатит. Вашего meltdown-bnd не существует в принципе, пока нет команды bound. Следовательно, ни на какие трольи уловки, позволившие бы вам замылить это чёткое и ясное утверждение, я не пойду. Когда продемонстрируете, что это не так, тогда и поговорим. А предлагать мне обсуждать терминологию несуществующей вещи - нет, спасибо, я откажусь. Можете в этом направлении больше не тролить. Пока ни предъявите намёки на существование атаки meltdown-bnd без bound на стороне жертвы, никаких с вами разглагольствований не будет.

Только вот почему вы этого не признаёте? Что плохого в том,
чтобы что-то не знать?

Это вы себе скажите, применительно к тому, что тег, яко бы, не может совпадать в разных сетах, или к тому, что на VIPT надо брут-форсить эвикшн сет. Кстати, да. Если с тегом всё останется, видимо, как есть (ну не способны вы осилить 2 строчки из вики), то вот по поводу VIPT - воспользуюсь-ка я тактикой Woolf'a: продемонстрируйте, плиз, в паре фраз, технику поиска эвикшн сета на VIPT. Что будем искать, и как? Я вам уже сказал, что тот LLC был PIPT. Вас не устраивает. Отлично, приведите пример с VIPT. Хватит других напрягать - сами поработайте.

что можно было искать коллизии кусками по 4к, а они ищут
кусками по 1М

Да и потом, что значит, «кусками по 1М»? Они ищут кусками по 4К в любом случае. Вот это и пытался вдолбить. И, видимо, не так безуспешно, как казалось - по более поздним сообщениям, вроде, это до вас таки дошло.

А кто сказал, что «объяснить технические детали» означает, что там есть «некоторые технические различия»? Из того, что я могу объяснить технические детали, никак не следует, что имеются лишь «некоторые технические различия». Совершенно неграмотно делать такие заключения.

А я никаких заявлений и не делал. Я дословно и в кавычках процитировал ваши слова. Всё остальное заявляли вы. Так что вы спорите с собой. :)

по поводу VIPT - воспользуюсь-ка я тактикой Woolf'a: продемонстрируйте, плиз, в паре фраз, технику поиска эвикшн сета на VIPT. Что будем искать, и как?

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

Не прокатит. Вашего meltdown-bnd не существует в принципе, пока нет команды bound.

Более того, даже с командой bound он не существует, пока нет описания термина meltdown. А его нет. Точнее, есть, но вы его не скажете.

Но для этого сначала надо выяснить, что же такое meltdown вообще.

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

Но я же предлагал определить термин «meltdown»... Вы уже считаете, что и Meltdown не существует?

Пока ни предъявите намёки на существование атаки meltdown-bnd без bound на стороне жертвы, никаких с вами разглагольствований не будет.

Да поймите же, я не могу «предъявить намёки» (что это вообще значит-то?) пока мы не определим, что такое meltdown. Допустим, я скажу, что для bound-атаки нам надо что-то вроде:

62 0b 0f b6 01 c1 e0 0c 74 f6 0f b6 04 03

Как вы собираетесь обсуждать детали атаки meltdown-bnd, если вы даже сам meltdown в общем описать не можете?

Так, анонимус, до свидания. :) И того, никакого meltdown-bnd у вас нет без bound на стороне атакующего, и вы отлично знаете, что спор ваш проигран. Вот и стремитесь замылить тему. Нет уж. Приведите пример атаки так, как сами считаете нужным. Можете из своей же ссылки его скопи/пастить. Мельтдаун это, или нет - разницы никакой! Просто приведите пример атаки meltdown-bnd без инструкции bound на стороне жертвы, и не беспокойтесь о том, окажется ли он мельтдауном, или нет. Если он будет соответствовать описанию атаки meltdown-bnd из приведённой вами ранее ссылки, но, при этом, без инструкции bound на стороне жертвы - это будет засчитано В ЛЮБОМ СЛУЧАЕ! И, после этого героического поступка, я оспаривать принадлежность этой атаки к мельтам даже не стану - это будет, по сути, уже мелочь, по сравнению с тем, что эта атака вообще возможна.

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

С ВИПТом ситуация аналогичная. ВЫ опишите поиск кеш сета на ВИПТ, как сами это понимаете. Но только так, чтобы это был один из алгоритмов, на который вы ранее давали ссылки, например, prime+probe. И обоснуйте, тем самым, ваше идиотское заявление о том, что метод поиска кеш сета от типа кеша не зависит - алгоритм, показанный вами, должен быть одинаково применим как к VIPT, так и к PIPT. А поскольку эта затея изначально идиотская, то мы, зрители, посмеёмся. В общем-то эвикшн сет тут особо и не при чём, по тому, просто опишите поиск кеш сета. Что будем брут-форсить в случае VIPT? Как применим к нему prime+probe? Вот на эти 2 вопроса и ответьте, как минимум. И, если вдруг вам это удастся, определение эвикшн сета мне давать уже всё равно не придётся, а к вопросу оно и не особо относится - найдите любой из кеш сетов. А пока у вас этого нет, вы обычный троль, на которого и время тратить не стоит. :)

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

Да и потом, что значит, «кусками по 1М»? Они ищут кусками
по 4К в любом случае. Вот это и пытался вдолбить.

А почему, интересно, я не наблюдаю реакции на это? Это как понимать? Вы же как раз тут и начали тролить со SPOILERа. Дескать, ничего нового в нём нет, наличие нового сайд-ченнела признавать отказывались. Тупили про поиск большими кусками - я тогда и вмешался, надо было защитить ЛОР от вас. А теперь, как бы, ничего и не было? При том, что мне за ASIDы аж 6 очков насчитали, хотя они даже близко не были основной темой обсуждения. А если ещё повспоминать откровенные тупняки в виде «индекс выбирает кеш линию», и, как бы, ничего? О великий гуру, знаток всех видов атак и повелитель ссылок, а вы не слишком ли обнаглели? :) Сейчас по каждому пункту сольёте, и такое же молчание будет? :)

Зачем вы просите меня уличать вас в ваших ошибках? Мазохизм какой-то...

А почему, интересно, я не наблюдаю реакции на это? Это как понимать? [...] А теперь, как бы, ничего и не было?

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

Итак, моя фраза: «я так догадываюсь, они имеют ввиду, что можно было искать коллизии кусками по 4к, а они ищут кусками по 1М, отсюда и ускорение в 1М/4к=256 раз» — была в первый день моего участия в треде. Я тогда вообще не понял, о чём новость и где уязвимость. Фраза относилась к чьей-то «ускорили rowhammer в 256». И я предположил, что ускорили-то они за счёт того, что искали бОльшими кусками.

Что было на самом деле я понял лишь на следующий день после вашего: «Нового то, что они сумели удлинить алиасинг с 12 до 20 бит». Этой короткой фразы хватило, чтобы мне всё стало ясно, и за неё я вас поблагодарил. А ссылка на то сообщение, и моё, и ваше, было моих в итогах. Так что всё было.

С тех пор прошло... полторы недели до тех ваших фраз «Ох и дебилоид, ещё и с чтением проблемы».

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

за ASIDы аж 6 очков насчитали

Я не очки считал, а показал, что вы, прошу прощения, как попугай, повторяете термин, смысл которого не знаете, или который имеет лично для вас какое-то собственное значение. И показал это для того, чтобы было понятно, почему я прошу вас описать meltdown/spectre — потому что не хочу повтора ситуации с asid-ами.

Что касается тега, не понимаю вашу тупость. Вроде, в каком-то из писем вы соизволили написать его определение из википедии. Амнезия замучила?

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

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

ВЫ опишите поиск кеш сета на ВИПТ, как сами это понимаете. Но только так, чтобы это был один из алгоритмов, на который вы ранее давали ссылки, например, prime+probe.

Вы сейчас опять глупость сказали. Вы попросили меня описать поиск эвикшн сета алгоритмом, «например», prime+probe. Вот только prime+probe не ищет эвикшн сет.

определение эвикшн сета мне давать уже всё равно не придётся

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

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

Это — простой вариант. Есть оптимизации в зависимости от задачи, они описаны в сабже в секции «5.1 Efficient Eviction Set Finding». Этот алгоритм работает и для VIPT и для PIPT кеша по построению алгоритма — он выходит только когда сет построен. Разница только в размере кеша и количестве адресов, которые придётся перебрать.

Если вы с таким алгоритмом не согласны — давайте свой. Но теперь вам придётся дать его для моего определения эвикшн сета.

Ваш ход.

Забавно, что те догадки были близки к цели: новых уязвимостей
и правда не нашли, а

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

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

А я вам дал цитату от сотрудника АМД, который как раз этот вопрос и проясняет:

Adding a ASID-like tag to the prediction tables would vastly
increase their size.

Вроде, я всё уже описал в ответе на сообщение

Это был пустой тролинг от вас, а не ответ. Кто писал вот это? Spoiler — новая уязвимость в процессорах Intel (комментарий)

совпадение тега в VIPT-кеше гарантирует совпадение физ.адресов

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

Ну ладно, пофантазировали, и хватит. А теперь нормальное определение: https://vwzq.net/papers/evictionsets18.pdf

Technically, an eviction set is a collection of (virtual)
addresses that contains at least as many elements that map
to a specific cache set as the cache has ways.

А ваше «определение» по определению корректным быть не может. Оно просто идиотское. В каждый конкретный момент времени, для данного адреса может вообще не быть адресов, его вытесняющих. Кеш использует различные политики вытеснения линий, и, если политика данного кеша подготовила для вытеснения другую линию, а не ту, где ваш адрес находится, то вам не удастся её переубедить, и заставить вытеснить именно нужный вам адрес. Это может сработать лишь с нескольких попыток, после вытеснения нескольких других линий. В общем же случае, гарантировано лишь вытеснение одной из линий данного сета, но заранее неизвестно (без знания соотв алгоритма), какой именно.

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

Если вы с таким алгоритмом не согласны — давайте свой. Но
теперь вам придётся дать его для моего определения эвикшн
сета.

Щазз! Конечно. :) И для вашего определения эвикшн сета, и для вашего определения кеша, где линия выбирается индексом, и для вашего чего там ещё... А где мне посмотреть на разработанный вами процессор, о гуру? :)

Ваш ход.

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

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

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

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

И да, кстати... так как по meltdown-bnd вы вообще в этот раз не отписались

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

Но, при этом, такой пропозл, вполне возможно, таки запилят в Zen2.

Скорее всего, запилят. Если у intel-а будет, то и amd не захотят отставать.

Ни про какие «адреса, у которых младшие биты совпадают» вы ТАМ не писали.

Там не писал, это были итоги. Там я только вкратце написал ответ, и процитировал вашу фразу, на которую был этот ответ: «У VIPT кэша могут быть потенциальные алиасы по физ адресам, когда тэг совпадает, а адреса по факту разные».

Это вы выдумали уже потом, чтобы не признавать очевидную лажу.

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

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

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

У разных программ один физический адрес может мапиться в разный виртуальный. А VIPT-кеш индексируется по виртуальному адресу. И если разные виртуальные адреса, указывающие на один физический, попадут в разные кеш-сеты, то одна программа может изменить одну строку кеша, а другая — другую, и потом будет непонятно, как их объединять. Эта проблема VIPT-кеша называется «aliasing problem». Именно поэтому индекс+смещение в VIPT-кеше ограничено 12 битами, ведь эти 12 бит совпадают с физическим адресом. Это гарантирует, что любой физ.адрес попадёт только в один кеш-сет.

Ну ладно, пофантазировали, и хватит. А теперь нормальное определение

Это не определение. Определение там в секции «III.A. Defining Eviction Sets», и написано там:

sequentially accessing all elements of an eviction set for X will ensure that X is not cached afterwards

Перевожу: "последовательное обращение ко всем элементам эвикшн сета для X обеспечит вытеснение X из кеша". И смотрим моё: "множество адресов, обращение к которым вытесняет из данного кеша данный адрес". Надо же, совпадает. Удачно я пофантазировал. :-)

и алгоритм тут не нужен ВООБЩЕ НИКАКОЙ. Это был стёб.

Я понял, что это был стёб. Просто вы ошиблись. Да, алгоритм тривиален. Но он всё равно нужен. ВСЕГДА. Чтобы получить что-угодно — нужно что-то сделать. Последовательность действий для получения чего-угодно — это и есть алгоритм. Иначе не бывает.

А ваше «определение» по определению корректным быть не может. Оно просто идиотское.

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

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

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

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

Удастся. В эвикшн-сете не один адрес. Не вытесню первым, вытесню следующим.

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

А кто говорил, что попытка одна? В этом и смысл эвикшн-сета. Если бы можно было вытеснить с одной попытки, то это был бы не «эвикшн-сет», а «эвикшн-адрес».

Ах, ну да, вы ж уверены, что кеш линия индексом выбирается...

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

Щазз! Конечно. :) И для вашего определения эвикшн сета, и для вашего определения кеша, где линия выбирается индексом, и для вашего чего там ещё...

Я просил вас дать определение, вы отказались. Пришлось мне его сочинить вместе с алгоритмом. И если другого алгоритма нет, то получается, что мой — единственно верный.

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

А смысл? Если там у вас слив, то больше и обсуждать, по сути, нечего будет. Чего из пустого в порожнее переливать, начните уж с главного. :)

Там не писал, это были итоги. Там я только вкратце написал
ответ

Не занимайтесь демагогией. Вот полная хронология событий. Моё сообщение: Spoiler — новая уязвимость в процессорах Intel (комментарий)

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

Ошибка. Линию позволяет выбрать не «тег», а «индекс».

Не потом, а за неделю до этого.

Это ваше письмо пришло в 17:17:09, а то, где про индекс - в 5:51:23 той же даты. Ну успели что-то почитать за день, поздравляю. Только про индекс пруф не дали, от собственных слов не отказались. А продолжили тролить нижними битами. Так не годится - пойдёте в жопу. :)

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

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

Я понял, что это был стёб. Просто вы ошиблись. Да, алгоритм
тривиален. Но он всё равно нужен. ВСЕГДА.

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

А кто говорил, что попытка одна?

Самая очевидная интерпретация вашего глупого определения об этом и говорила. Кто говорил, что НЕ одна? В вашем определении ничего не было про кол-во попыток. Да это и не важно. Вы по сути хоть что-нибудь скажите уже наконец.

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

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

У VIPT-ов они и за 12 не выходят, угадайте, почему?

По тому, что так написано в википедии? :)

Хотя, ладно, объясню. А то вы ещё неделю будете делать вид,
что знаете...

http://www.freepatentsonline.com/8417915.html

A virtually indexed and physically tagged memory is described
having a cache way size which can exceed the minimum page
table size such that aliased virtual addresses VA within the
cache way can be mapped to the same physical address PA.
Aliasing management logic permits multiple copies of the
data from the same physical address to be stored at different
virtual indexes within the cache within given or different
cache ways.

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

Пара уточнений к тексту выше:

Патент от АРМа, по ссылке выше, подан ещё аж в 2005 году.

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

А уникальность тега пропадает

... как и уникальность тегируемой им физ страницы, разумеется. А то ещё придерётесь.

и потом будет непонятно, как их объединять. Эта проблема
VIPT-кеша называется «aliasing problem».

Умничка какой, википедию таки почитал, но непонятно стало, как же кеш линии объединить. :) Нашёл ликбез, специально для вас: https://cs.stackexchange.com/a/32302

Вон сколько способов борьбы с этой проблемой, оказывается, существует! Образовывайтесь. :)

специально для вас: https://cs.stackexchange.com/a/32302
При теперешних размерах кешей, указанное вами ограничение никому не нужно. Патент от АРМа, по ссылке выше, подан ещё аж в 2005 году.
Так что давно уже они за 12 бит выходят.

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

Вот, например, в том патенте предлагают на каждый read в случае cache miss смотреть в алиасные сеты и копировать (или переносить) строку оттуда, а на каждый write смотреть в алиасные сеты и, если там такая же строка, записывать write и туда тоже. Круто. Только, если мы всё равно смотрим по всем алиасным сетам, быстрее положить все линии в один сет, и сэкономить на копированиях/перемещениях.

Ошибка. Линию позволяет выбрать не «тег», а «индекс».

По-моему, всё просто и ясно: вы несли чушь.

Да, формально, в этой фразе я не прав. Я просто пытался попасть в вашу терминологию, и понять, что же вы называете тегом. Ещё раз, уже в десятый, наверное? Это — ветка обсуждения вашей фразы: «У VIPT кэша могут быть потенциальные алиасы по физ адресам, когда тэг совпадает, а адреса по факту разные». И эта фраза не имеет смысла. Ни в какой трактовке.

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

А по поводу тега, я сразу сказал, что моя аналогия - примерная.

Сразу — это через 4 дня? А это была аналогия чего? Может вы сначала свою фразу объясните? Я до сих пор не понял, что она означала.

Или вы согласны, что ваша фраза — чушь? Если так, то и моя фраза про индекс тоже не будет иметь смысла.

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

То есть в их определении написано «последовательное обращение», а в моём написано просто «обращение к которым», и это вы считаете основной сутью? Потому что в нём нет слова «последовательно»? А как ещё можно обращаться ко множеству адресов? Параллельно?

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

Почему к каждому? Может же хватить и одного обращения.

Так и где, за этой демагогией, пруф того, что алгоритм для поиска эвикшн сета не зависит от типа кеша?

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

Вместо этого, одна демагогия да придирки.

Демагогия и придирки пока что только от вас. Вы сначала зачем-то сами попросили указать на ваши ошибки, а затем, не признав ни одной, ищете где бы придраться к моим словам... При этом ни определений meltdown/spectre, ни определений эвикшн-сета, ни алгоритм его получения вы не дали, а когда я придумал свои, вас он тоже не устроил, однако свой вариант вы всё равно не назвали.

Вас Woolf уже давно попросил дать технику атаки meltdown-bnd

Меня не просил.

Вообще я собирался это обсудить, но теперь не вижу смысла — не с кем обсуждать. Вам квалификации на написание эксплоита не хватит, вы даже словами описать meltdown/spectre не смогли, а больше в треде никого не осталось. Эх... Похоже, пора подбить итоги последней беседы с Woolf-ом и заканчивать.

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

Да уж конечно. Если у вас размер ВИПТа больше, чем размер страницы помноженный на ассоциативность кеша, то алиасы там неизбежны. Достаточно просто посмотреть характеристики современных L1/L2 кешей, чтобы понять, что это именно так. И вот ещё цитата: https://superuser.com/questions/745008/whats-the-difference-between-physical-...

AMD's Athlon, which used physical tagging with virtual indexing,
provided a separate set of tags for coherence probes and alias
detection. Since three virtual-only address bits are used for
indexing, seven alternative sets had to be probed for possible
aliases on a miss.

Сначала мне показалось, вы имели ввиду aliasing problem,
но там всё ровно наоборот

Ну да, конечно, именно это вы и думали, особенно учитывая, что моя следующая фраза там же была:

Буду называть их "алиасы", как в статье, хотя это фейковые
алиасы - реально физ адреса разнятся, а только лишь тег в VIPT
совпал.

Тогда я решил, может вы тегом называете индекс. И попытался
вас исправить.

Написав

Ошибка. Линию позволяет выбрать не «тег», а «индекс».

Сразу — это через 4 дня?

Когда до эвикшн сетов дело дошло, тогда аналогия и стала не применима. А до этого, вполне себе.

А это была аналогия чего? Может вы сначала свою фразу
объясните? Я до сих пор не понял, что она означала.

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

Потому что в нём нет слова «последовательно»?

По тому, что нет слов «последовательно _ко всем_». По вашему «определению» достаточно и к одному. Но это не так.

Я же конкретный алгоритм дал, он работает и для VIPT и для
PIPT. Вы не согласны?

Из того, что вы какой-то идиотский алгоритм дали, разве следует, что алгоритм поиска эвикшн сета не зависит от типа кеша? Если для ВИПТа он, вообще, тривиальный, и не требует никакого перебора? Как вы сами и сказали недавно. Сколько дурака-то валять будете? Если не зависит, попробуйте тот самый, тривиальный алгоритм, применить к PIPT. А ладно, чего с тролями спорить... http://palms.ee.princeton.edu/system/files/SP_vfinal.pdf

Constructing an eviction set for the virtually-indexed L1 cache
is trivial: the attacker has full control of thevirtual address
space, and can arbitrarily choose virtual addresses with the
same set index bits. In contrast, the LLC is physically indexed.

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

Слив защитан. При чём, по всем пунктам... Жаль. Думал, что-то по-интереснее будет, чем пустой тролинг и жалкие попытки замылить тему, вместо того, чтобы хоть что-то по делу сказать.

Да уж конечно. Если у вас размер ВИПТа больше, чем размер страницы помноженный на ассоциативность кеша, то алиасы там неизбежны. Достаточно просто посмотреть характеристики современных L1/L2 кешей, чтобы понять, что это именно так.

Так покажите характеристики современных L1/L2 кешей-то! А то я куда ни гляну — везде одинаковый «странично-ассоциативный» кеш (назовём его так, если знаете другое название ­— предлагайте).

И вот ещё цитата: https://superuser.com/questions/745008/whats-the-difference-between-physical-...

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

AMD's Athlon, which used physical tagging with virtual indexing, provided a separate set of tags for coherence probes and alias detection. Since three virtual-only address bits are used for indexing, seven alternative sets had to be probed for possible aliases on a miss. Since this could be done while waiting for a response from the L2 cache, this did not add latency and the extra set of tags could also be used for coherence requests which were more frequent given the exclusivity of the L2 cache.

Кстати, эта цитата — ложь. Даже если всё остальное в цитате правда, то это снижало скорость L1-кеша до скорости L2, то есть добавляло задержку.

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

При любом раскладе такой вариант выходит медленнее. Согласны?

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

Размер ЛИНИИ превышал размер страницы? Я уже боюсь и спрашивать, а что вы в таком случае называете «линией» и «страницей»?

По тому, что нет слов «последовательно _ко всем_». По вашему «определению» достаточно и к одному. Но это не так.

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

Из того, что вы какой-то идиотский алгоритм дали, разве следует, что алгоритм поиска эвикшн сета не зависит от типа кеша?

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

Если для ВИПТа он, вообще, тривиальный, и не требует никакого перебора?

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

Свой я написал. Я его считаю тривиальным. И он подходит для PIPT кеша, по крайней мере так считают в сабжевой статье.

Не трепались бы уже, а переходили к meltdown-bnd.

Не трепались бы уже, а то от вас каждое второе предложение — оскорбление. Лучше бы написали, что вы называете meltdown и spectre. А то обсуждать-то нечего...

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

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

Ну ошиблись AMD-шники, огребли с этим кучу проблем

Ну ошибся анонимус (сто раз подряд), огрёб кучу проблем...

При любом раскладе такой вариант выходит медленнее.
Согласны?

Даже отвечать не буду на фигню. Мне вам надо не это доказать. Напишите свои замечания к тому коменту.

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

Ну да.

Я уже боюсь и спрашивать, а что вы в таком случае называете
«линией» и «страницей»?

Давайте я вам ещё из того же патента процитирую:

A problem arises in virtually indexed and physically tagged
memories when the size of a cache way exceeds the minimum
page size. In these circumstances, 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). One known way of dealing with this

В моём определении не написано, ни «ко всем», ни «к одному».

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

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

Опять тупите? Алгоритм из сабжа применялся к PIPT. Идиотским я называю его лишь в применении к VIPT.

Если он тривиален, то напишите его наконец!

Да только что ведь со ссылкой приводил! Ну урежу до 2 слов, как обычно, для одарённых:

arbitrarily choose virtual addresses with the same set index
bits.

Лучше бы написали, что вы называете meltdown и spectre.

Зачем? Ну, вообще-то, я давал ссылку. А в ответ получил бред: Spoiler — новая уязвимость в процессорах Intel (комментарий)

То есть оно уже не specific. Да и слово AMD там тоже есть,
в другом месте.

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

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

Хорошо, анонимчик, хорошо! Подбейте итоги беседы с Woolf'ом! Но Show must go on! Требую продолжения вашей клоунады. :)

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

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

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

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

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

Так покажите характеристики современных 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», либо вы написали бред, когда сказали, что давали ссылку на ваше описание.

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

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

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

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

[    0.000000] CPU: PIPT / VIPT nonaliasing data cache,
VIPT aliasing instruction cache

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

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

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

Анонимус, вам не надоело тупить? Эта фраза объясняет возможность того, что тег совпал, а оффсеты в кеш линии за 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, как и про вас, уже все всё поняли, значит, и это для вас не вариант. Но удивите народ, напишите уж хоть что-то осмысленное!

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

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

Просто размер линии обычно 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

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

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

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

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

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

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

Давайте предложу вам способ по-проще ... Это вот 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-битный алиасинг в сабже... А сабжевая статья таки про данные, и, кстати, писалась про интелы, а не про армы или мипсы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Совпадают.

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

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

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

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

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

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

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

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

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

Чушь не вижу.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

«У VIPT кэша могут быть потенциальные алиасы по физ адресам,
когда тэг совпадает, а адреса по факту разные». И эта фраза
не имеет смысла. Ни в какой трактовке.

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

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

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

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

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

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

Скажем, есть 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, ни про теги, но надо же было как-то
доходчивыми фразами заменить их сложные формулировки.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Грубо говоря: "Прямоугольный треугольник — это треугольник, в котором один угол прямой (то есть 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 мы находим нужный нам физический тег.

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

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

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

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

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

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

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

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

Хорошо.

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

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

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

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

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

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

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

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

Ой, да ладно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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? И как вы выбираете линию?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Да. Даже в процитированной вами части написано, что в
вирт.адресе от физ.адреса зависит 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?
И как вы выбираете линию?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Instead, assume the I-cache is always aliasing if it
advertises a VIPT policy.

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

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

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

Да.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вот мне и стало интересно, в каких ещё современных
процессорах до сих пор решают 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.