O>>Предлагаю элегантное сцуко-решение. Выпилить возможность точного измерениея времени исполнения кода из юзермода путем запрета RDTSD в CR4. Как минимум сделать настраиваемым — кому нужно (всякие там эти.. программисты) — включат. Остальным — софтово эмулировать с дикой погрешностью.
Pzz>И это сразу ударит по коду, который реализует чувствительные ко времени сетевые протоколы в user space.
Это прям таки активная практика юзать rdtsc в юзерможном коде? Думал все нормальные люди юзают API с HPET под капотом.
Но вообще, насколько я понимаю, CR4 можно менять при переключении контекста, таким образом можно сделать настройку хоть per-process.

O>>Думаю такие busy-loopы можно легко детектить шедулером, и, продетектив, — начать им подгаживать. Впрочем, раз "обсуждается", то это наверно тоже уже обсуждалось.
Pzz>А чем, с точки зрения планировщика, такой busy-loop отличается от кода, который майнит биткоин на процессоре?
Детектилка должна не только смотреть на 100% CPU usage, но и в случае любой непонятной ситуации подозрительной активности — смотреть на код под RIP, который исполняется при переключении контекста на подозрительный тред. И реагировать только если обнаружит что там только ин(де)кременты и джампы — то, значится, у нас тут какер.

Здравствуйте, Cyberax, Вы писали:

Есть не подтверждаемый (отказ автора ), что это управляемая утечка для увеличения продаж.
Суть — "саму багу исправить в микрокоде просто, но делать этого не будут, будут стимулировать покупки новых, исправленных процов."

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

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

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

Здравствуйте, Andrew.W Worobow, Вы писали:

AWW>Есть не подтверждаемый (отказ автора ), что это управляемая утечка для увеличения продаж.
AWW>Суть — "саму багу исправить в микрокоде просто, но делать этого не будут, будут стимулировать покупки новых, исправленных процов."

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

AWW>ЗЫ:
AWW>По мне так на уровня ядра ОС это тоже не очень уж сложно фиксится, но это снизит производительность.
AWW>Вообще ожидать подобную уязвимость было надо давно — внутри интеловых процов сейчас буквально своя ОС сидит.

ОС — не в процессоре, а в южном мосту. Это всё-таки отдельный зверь, хоть и обязательный для полной системы.

AWW>Впереди наверное еще интеловое графическое ядро.

В каком смысле? Если GPU, оно давно есть. Если в этой ОС, то для IPMI есть зачатки оного (хотя основное таки в клиентском браузере).

AWW>По мне так давно уже назрел пересмотр архитектуры процессоров, точнее компьютеров.
AWW>Сейчас хеш занял место ОП а ОП занял место дисков, а диски как не трудно предположить, заняли место летнопротяжек.
AWW>И вот поменяв эту архитектуру давно уже пора было отдать на откуп программистам управление хешом, вот и не было бы подобного рода сюрпризов, напоминающих идею защиты — "а мы код ОС никому не покажем, и никто не сломает". Ведь ОСы на эту тему вылизаны за десятилетия. )

Это получится какой-то супер-embedded: компьютер с парой сотен килобайт оперативки (реальной в старом смысле, на static RAM, со скоростью доступа ~1нс) и внешними устройствами разной степени доступности.

Писать под такое, конечно, можно, вспомнив стиль 70-80х (и раньше), но основная часть программистов такому ой не обрадуется. И зачем это нужно, если кэш решает проблемы в >99% случаев?

Здравствуйте, ononim, Вы писали:

O>Это прям таки активная практика юзать rdtsc в юзерможном коде? Думал все нормальные люди юзают API с HPET под капотом.

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

Здравствуйте, Andrew.W Worobow, Вы писали:

AWW>на уровня ядра ОС это тоже не очень уж сложно фиксится, но это снизит производительность.

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

Здравствуйте, Евгений Музыченко, Вы писали:

Pzz>>А чем, с точки зрения планировщика, такой busy-loop отличается от кода, который майнит биткоин на процессоре?

ЕМ>Да хоть бы и ничем. Управление обнаружением и противодействием предоставить администратору — пусть выбирает, что ему милее.

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

Здравствуйте, ononim, Вы писали:

Pzz>>А чем, с точки зрения планировщика, такой busy-loop отличается от кода, который майнит биткоин на процессоре?
O>Детектилка должна не только смотреть на 100% CPU usage, но и в случае любой непонятной ситуации подозрительной активности — смотреть на код под RIP, который исполняется при переключении контекста на подозрительный тред. И реагировать только если обнаружит что там только ин(де)кременты и джампы — то, значится, у нас тут какер.

Думаешь, нельзя аккуратно перемешать инкременты с какими-нубудь рассчетами?

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

Ну не говоря уж о том, что дизассемблировать и анализировать на лету интеловский код — не самая простая задача. Там даже команда mov, взятая сама по себе, является тьюринг-полной, и есть опенсорсный Си-компилер, который сишную программу в последовательность mov'ов компилирует, и она даже работает

P.S. Кстати, я полагаю, цикл со счетчиком можно и в видеокарту засунуть.

Здравствуйте, Pzz, Вы писали:

Pzz>И что должна делать моя жена, когда система выплюнет ей соответствующее окошко? И что в этом окошке должно быть написано, чтобы она поняла хотя бы, о чем идет речь?

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

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

Здравствуйте, Евгений Музыченко, Вы писали:

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

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

ЕМ>Даже при реализации "с окошком" сообщение может быть вполне типичным — "обнаружено подозрительное поведение, блокировать/пометить/игнорировать".

Ну и все будут жать "блокировать".

Pzz>>>А чем, с точки зрения планировщика, такой busy-loop отличается от кода, который майнит биткоин на процессоре?
O>>Детектилка должна не только смотреть на 100% CPU usage, но и в случае любой непонятной ситуации подозрительной активности — смотреть на код под RIP, который исполняется при переключении контекста на подозрительный тред. И реагировать только если обнаружит что там только ин(де)кременты и джампы — то, значится, у нас тут какер.
Pzz>Думаешь, нельзя аккуратно перемешать инкременты с какими-нубудь рассчетами?
Можно, но это сильно загрубит разрешение такого измерителя времени. Помни — хакеру нужно измерить время вычитки одного слова из памяти.

Здравствуйте, Pzz, Вы писали:

Pzz>Любая вычислительная задача будет выглядеть, как подозрительная.

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

Pzz>Ну и все будут жать "блокировать".

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

Здравствуйте, ononim, Вы писали:

Pzz>>Думаешь, нельзя аккуратно перемешать инкременты с какими-нубудь рассчетами?
O>Можно, но это сильно загрубит разрешение такого измерителя времени. Помни — хакеру нужно измерить время вычитки одного слова из памяти.

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

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

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Не любая. Типично вычислительные задачи не используют точных таймеров тысячи раз в секунду. А атака на Meltdown имеет практически уникальный паттерн поведения. У Spectre столь явно выраженного паттерна нет, но по косвенным признакам можно определять достаточно точно.

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

Здравствуйте, Pzz, Вы писали:

Pzz>Тут народ предлагает точный таймер заменить счетчиком, который отдельный поток крутит по кругу. Так вот, такой отдельный поток мало чем отличается от потока, который биткоин на процессоре майнит, или делает еще какие-нибудь вычисления. Особенно если к кручению счетчика добавить еще какую-нибудь рассчетную деятельность, для маскировки.

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

O>>Можно, но это сильно загрубит разрешение такого измерителя времени. Помни — хакеру нужно измерить время вычитки одного слова из памяти.
Pzz>Скорость чтения из памяти очень сильно отличается от скорости чтения из кеша. Полагаю, таймер, который считает с точностью до нескольких десятков, если не сотен, команд, является достаточно точным для этой цели.
Pzz>А еще у интела есть такие замечательные команды, которые читают мимо кеша — чтобы кеш не загрязнять ради того, что больше не потребуется. Так вот, предвыборку в кеш они не запускают, но если данные и до них лежат в кеше, небось, ими не брезгуют (это надо бы проверить, это лишь мое предположение). Так вот, если это правда так, такую командочку можно и в цикле запустить...
Брр. Цикл нужен для подсчета времени. Команда чтения из памяти, какая бы она ни была — должна крутиться на другом ядре _вне_ этого цикла.
Распарсить цикл в десяток команд чтобы понять чем занимается подозрительный тред не так уж сложно. В х64 винде SEH через дизасм работает и все щастливы.

Здравствуйте, netch80, Вы писали:

N>ОС — не в процессоре, а в южном мосту. Это всё-таки отдельный зверь, хоть и обязательный для полной системы.

Это совсем отдельная тема для обсуждения, но вовсе эта внутрення ОС не обязательна для полной системы. Кое-где ее сумели отключить (см. например продукцию Tehnoetic). и все работает и без нее, хотя возможно и потеряв часть не особо нужной всем функциональности.

Здравствуйте, ononim, Вы писали:

C>>Обычный барьер не очищает L1-кэш. Он лишь форсирует его синхронизацию.
O>....которая занимает время, равное времени записи в память. То есть разрешение твоего таймера будет заведомо больше самого большого интервала, который нужно измерить, чтобы провести атаку.
Чтение данных из DRAM — это около 300 наносекунд, или около 600 циклов на типичном CPU. Межпроцессорная синхронизация — это около 50 циклов. Более чем достаточно запаса.

C>>Подумай сам:
C>>

C>> Time: [ 1 2 3 4 5 6 7 8 9 10 ] [ 1 2 3 4 5 6 7 8 9 10 ]
C>>             ping start -> *      * <- ping end
C>>

O>Ненене, Дэвид Блейн. В моем эксперименте начало отсчета таймера привязано к началу операции.
Кто такую ересь сказал? У меня таймер будет в соседнем потоке, метрономно касаться определённого участка кэша.

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

O>Понятно, ты значит никогда не пинговал виндой до версии ХР или уже забыл как оно там. Так вот, поясню — там никогда пинг не возвращал 0 мсек. Он, сцуко, ВСЕГДА выдавал для всех локальных компов 10 мсек. И никакой статистикой нельзя было определить находится хост через один свич или через два свича от тебя.
Очевидно, что ping в Винде не разрабатывался для того, чтобы обойти ограничения таймера. Там, скорее всего, и потоков-то не было.

C>>Тут вот ещё предложили атаковать сетевыми пакетами. Их точности тоже достаточно на скорости в 10Gb.
O>Предложить можно что угодно Я предлагаю атаковать почтовыми голубями.
Предлагай. Только вот что с 10G Ethernet делать будем?

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

Проще перейти тогда на in-order и не заниматься сексом с мозгом.

Здравствуйте, Cyberax, Вы писали:

Pzz>>Казалось бы, если в адресном пространстве процесса "ненужных" страниц совсем не присутствует, а не как сейчас, они присутствуют, но в запрещенном виде, то с помощью spectre ни до чего лишнего и не дотянешься...
C>Проблема в том, что определённые последовательности кода (в основном, проверки границ) внутри syscall'ов можно эксплуатировать из userspace. Это не требует никаких дыр в безопасности — процессор просто исполняет код внутри ядра, а зловредный шпион наблюдает за кэшем из userspace.

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

Здравствуйте, Cyberax, Вы писали:

C>>>Обычный барьер не очищает L1-кэш. Он лишь форсирует его синхронизацию.
O>>....которая занимает время, равное времени записи в память. То есть разрешение твоего таймера будет заведомо больше самого большого интервала, который нужно измерить, чтобы провести атаку.
C>Чтение данных из DRAM — это около 300 наносекунд, или около 600 циклов на типичном CPU. Межпроцессорная синхронизация — это около 50 циклов. Более чем достаточно запаса.

Откуда такие цифры? Например, DDR3-1600 (опорная тактовая 800MHz) с таймингами 9-9-9-28 имеет 35 наносекунд (28/0.8) на самый длинный вариант чтения — закрытие одной из предыдущих открытых строк (копирование из буферной строки на SRAM в модуле DRAM в основной массив) и открытие новоуказанной (кэширование в буферную строку SRAM). Прохождение через все цепочки кэшей и контроллеров чуть-чуть добавляет, но не сильно. Тут ты преувеличил на порядок; это всё равно дохрена, но уже не 600 тактов, а только около 120.
И да, лучше говорить "тактов", это не английский.
Во времена DDR1...DDR2 обычно писали про ~200 тактов, когда процессоры уже набрали 3-4GHz тактовой, а память была медленнее (например, в знаменитой статье Дреппера про память); сейчас 100-150 тактов; прогресс за 15 лет с временем переоткрытия строки от 50-70 нс до нынешних 25-40 это грандиозный прогресс, как оказалось.
Вот если строка не открывается, а уже открыта — тогда быстрее будет (потребуется CAS latency, в приведённом примере это 9 тактов опорной частоты DRAM => 11.25 нс; реально ну 15, ну с натяжкой 20; соответственно 40-60 тактов). Но предсказать, попадёт в ту же строку или нет, не так просто — северные мосты любят перемешивать линии шины адреса в зависимости от выбранного расклада памяти. В принципе, на нынешнем железе можно предполагать, что младшие 10-15 линий адреса не подвергнутся такому перемешиванию; это сходно с размером страницы виртуальной адресации, так что надо рассчитывать и на такие времена.

Запаса получается в 3-4 раза (при переоткрытии строки), или совсем чуть-чуть при той же строке DRAM, а не 12. Общий уровень успешности принципиально не меняется, но давай не пугать нереальными цифрами...
(Это я не считал, сколько занимает синхронизация кэшей. Может, и там не так страшно.)

C>Впрочем, даже в твоём сценарии я смогу сделать измерение. Просто делаем его 20 раз для того, чтобы накопить время.

Угу.