C>Meltdown специфичен для Intel и позволяет из userspace-процесса прочитать всю физическую память, включая ядро и гипервизор. Защита только через KAISER для Линукса ( https://lwn.net/Articles/741878/ ) или аналогичное изменение для NT. AMD не подвержен конкретно этой уязвимости.
C>Spectre является более общей уязвимостью и полной защиты от неё пока что нет.
Предлагаю элегантное сцуко-решение. Выпилить возможность точного измерениея времени исполнения кода из юзермода путем запрета RDTSD в CR4. Как минимум сделать настраиваемым — кому нужно (всякие там эти.. программисты) — включат. Остальным — софтово эмулировать с дикой погрешностью.

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

C>>Spectre является более общей уязвимостью и полной защиты от неё пока что нет.
O>Предлагаю элегантное сцуко-решение. Выпилить возможность точного измерениея времени исполнения кода из юзермода путем запрета RDTSD в CR4. Как минимум сделать настраиваемым — кому нужно (всякие там эти.. программисты) — включат. Остальным — софтово эмулировать с дикой погрешностью.

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

Пока что наиболее перспективные идеи в текущих обсуждениях выглядят как
1) разделение процессов разных пользователей и разного уровня секьюрности по ядрам или даже физическим камням. (по хостам и не вспоминаю — считаем, уже сделано всеми, кто реально опасается проблем)
2) вынос самых критичных данных в участки RAM, где через MTRR запрещено кэширование
3) Retpoline — фактически, запрет возможности набрать предсказание перехода в чужом коде

O>>Предлагаю элегантное сцуко-решение. Выпилить возможность точного измерениея времени исполнения кода из юзермода путем запрета RDTSD в CR4. Как минимум сделать настраиваемым — кому нужно (всякие там эти.. программисты) — включат. Остальным — софтово эмулировать с дикой погрешностью.
N>Это давно обсуждается, и пока что не получило поддержку: можно, например, из соседнего треда на соседнем ядре крутить пустой цикл и давать показания времени из него.
Думаю такие busy-loopы можно легко детектить шедулером, и, продетектив, — начать им подгаживать. Впрочем, раз "обсуждается", то это наверно тоже уже обсуждалось.

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

O>>>Предлагаю элегантное сцуко-решение. Выпилить возможность точного измерениея времени исполнения кода из юзермода путем запрета RDTSD в CR4. Как минимум сделать настраиваемым — кому нужно (всякие там эти.. программисты) — включат. Остальным — софтово эмулировать с дикой погрешностью.
N>>Это давно обсуждается, и пока что не получило поддержку: можно, например, из соседнего треда на соседнем ядре крутить пустой цикл и давать показания времени из него.
O>Думаю такие busy-loopы можно легко детектить шедулером, и, продетектив, — начать им подгаживать. Впрочем, раз "обсуждается", то это наверно тоже уже обсуждалось.

Угу. Их слишком сложно и ненадёжно отличать от любых CPU-intensive работ, и если начать подгаживать, станет хуже всему.

O>>Думаю такие busy-loopы можно легко детектить шедулером, и, продетектив, — начать им подгаживать. Впрочем, раз "обсуждается", то это наверно тоже уже обсуждалось.
N>Угу. Их слишком сложно и ненадёжно отличать от любых CPU-intensive работ
Сомневаюсь что прям таки ненадежно. Там можнт быть инкеремент/декремент в цикле (возможно, размотанном цикле), если хакер его будет разбавлять чем то еще, чтоб запутать детектилку — это резко затруднит ему его хакерскую работу. А паттерн вида "тред, который занимается исключительно инкрементом переменной по адресу Х" довольно однозначно определяет наколенный измеритель времени. Возможно, и даже скорее всего, что я недооцениваю фантазию хакеров, но ИМХО количество вариантов таки достаточно ограничено и они таки будут достаточно специфичны для распознания.

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

V>

V>
1. Сбрасываем кэш процессора.
   V>
2. Читаем интересную нам переменную из адресного пространства ядра, это вызовет исключение, но оно обработается не сразу.
   V>
3. Спекулятивно делаем чтение из массива, который располагается в нашем, пользовательском адресном пространстве, на основе значения переменной из пункта 2.
   V>
4. Последовательно читаем массив и аккуратно замеряем время доступа. Все элементы, кроме одного, будут читаться медленно, а вот элемент, который соответствует значению по недоступному нам адресу.
   V>

Со эксплуатацией предсказателя переходов примерно понятно, но вот в этом объяснении на Хабре (а также в других местах) говорится что для Meltdown даже этого не нужно. Достаточно условия что исключение произойдет позже чем будет использовано незаконно прочитанное из ядерной памяти значение. Вот у меня глупый вопрос: а почему оно обязательно должно происходить позже? Это какая-то сильно дорогая операция (причем настолько дорогая, что процессор спекулятивно успеет обратиться к памяти и загнать значение в кэш)? Почему так? Интересно насколько просела бы производительность если процессор бы обязательно проверял права до использования значения (или даже до непосредственно чтения)?

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

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

SL>>... продвижения на рынки нового процессора?
SL>>https://ru.wikipedia.org/wiki/Эльбрус-16С

С>Нет, это новый старт для IBM Power. Я бы не отказался от такого десктопа.

Вроде как Spectre аукнулся и на Power-ах: RedHat, IBM

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

C>>Spectre является более общей уязвимостью и полной защиты от неё пока что нет.
O>Предлагаю элегантное сцуко-решение. Выпилить возможность точного измерениея времени исполнения кода из юзермода путем запрета RDTSD в CR4.
Не поможет. Обходится тупо и просто:

volatile long long int counter = 0;
// Thread 1
while(true) { counter++; }

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

kl> Вот у меня глупый вопрос: а почему оно обязательно должно происходить позже? Это какая-то сильно дорогая операция (причем настолько дорогая, что процессор спекулятивно успеет обратиться к памяти и загнать значение в кэш)? Почему так? Видимо, Intel сэкономили на битах защиты для кэша первого уровня, в отличие от AMD. Так что для них это получилось намного дороже.

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

SL>>... продвижения на рынки нового процессора?
SL>>https://ru.wikipedia.org/wiki/Эльбрус-16С
С>Нет, это новый старт для IBM Power. Я бы не отказался от такого десктопа.
Все современные out-of-order системы подвержены Spectre. Включая Power и прочие SPARC.

O>>Предлагаю элегантное сцуко-решение. Выпилить возможность точного измерениея времени исполнения кода из юзермода путем запрета RDTSD в CR4.
C>Не поможет. Обходится тупо и просто:
C>volatile long long int counter = 0;
C>// Thread 1
C>while(true) { counter++; }
Сейчас ловить и мешать софтово, в будущем — хардварно гарантировать некогерентность кешей при модификации переменной без явных барьеров (есть правда вопрос, что делать с hyper threading).
Просто возможность такого точного измерения времени открывает просто кучу потенциальных проблем, о которых никто не подозревает.
Я лично уже примерно лет 10 жду когда кто нить найдет микрофонный эффект в тактовом генераторе какой нить распространенной железяки, входяшей в состав компа, что позволит организовать прослушку софтово из жаваскрипта.

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

C>>Не поможет. Обходится тупо и просто:
C>>volatile long long int counter = 0;
C>>// Thread 1
C>>while(true) { counter++; }
O>Сейчас ловить и мешать софтово, в будущем — хардварно гарантировать некогерентность кешей при модификации переменной без явных барьеров (есть правда вопрос, что делать с hyper threading).
Я специально написал "volatile". Все барьеры есть. Разрешения более чем достаточно для точных таймеров.

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

O>>Сейчас ловить и мешать софтово, в будущем — хардварно гарантировать некогерентность кешей при модификации переменной без явных барьеров (есть правда вопрос, что делать с hyper threading).
C>Я специально написал "volatile". Все барьеры есть. Разрешения более чем достаточно для точных таймеров.
volatile барьеров не ставит. Я имею ввиду для процессора. А с барьером время исполнения инкремента будет таким, что вся конструкция станет непригодна для целей атаки.

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

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

C>>Я специально написал "volatile". Все барьеры есть. Разрешения более чем достаточно для точных таймеров.
O>volatile барьеров не ставит.
Вообще-то, ставит.

O>Я имею ввиду для процессора. А с барьером время исполнения инкремента будет таким, что вся конструкция станет непригодна для целей атаки.
И с барьером тоже будет всё нормально. Максимум придётся статистику посчитать.

C>>Поезд уехал. Да и глупо таким образом пытаться защиту делать.
O>Время исполнения это просто супер-толстый канал для кучи разных side-channel уязвимостей, причем не только настолько хардварных как сабж. Затыкать каждую — это как лодку делать из решета.
Кроме времени исполнения есть ещё потребление питания, занятость шины памяти, прямые пробы на DRAM contention и т.д.

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

Более правильным будет убирание side-channel с помощью железных мер. Типа переключаемого кэша, эксклюзивной аренды шины и т.д. Железячники уже думают.

C>>>Я специально написал "volatile". Все барьеры есть. Разрешения более чем достаточно для точных таймеров.
O>>volatile барьеров не ставит.
C>Вообще-то, ставит.
Сюрприз-сюрприз:
GCC 5.4:
инкремент volatile int переменной через ++:

  400710:    8b 05 36 09 20 00        mov    0x200936(%rip),%eax        # 60104c <counter>
  400716:    83 c0 01                 add    $0x1,%eax
  400719:    89 05 2d 09 20 00        mov    %eax,0x20092d(%rip)        # 60104c <counter>
  40071f:    eb ef                    jmp    400710

инкремент volatile int переменной через __sync_add_and_fetch:

  400710:    f0 83 05 34 09 20 00 01     lock addl $0x1,0x200934(%rip)        # 60104c <counter>
  400718:    eb f6                    jmp    400710

O>>Я имею ввиду для процессора. А с барьером время исполнения инкремента будет таким, что вся конструкция станет непригодна для целей атаки.
C>И с барьером тоже будет всё нормально. Максимум придётся статистику посчитать.
Удачи ее считать если у тебя разрешение таймера будет хуже необходимой разницы. Кроме того, есть стойкое подозрение что использование memory-barrier'а в цикле просто убьет саму атаку на корню.

C>>>Поезд уехал. Да и глупо таким образом пытаться защиту делать.
O>>Время исполнения это просто супер-толстый канал для кучи разных side-channel уязвимостей, причем не только настолько хардварных как сабж. Затыкать каждую — это как лодку делать из решета.
C>Кроме времени исполнения есть ещё потребление питания, занятость шины памяти, прямые пробы на DRAM contention и т.д.
Нене. Все это требует физического подключения логическим анализатором. Сценарии атак нужно разделять. Мы тут про атаку когда хакер может запускать свой код на машине и не более того.

C>Пытаться перекрыть атаки с помощью запрета точного времени в машине с разделяемой памятью — это как раз затыкание дыр. Способы взять статистически точное время будут находиться примерно постоянно.
C>Более правильным будет убирание side-channel с помощью железных мер. Типа переключаемого кэша, эксклюзивной аренды шины и т.д. Железячники уже думают.
side-channel через канал времени лучше всего убить убив этот самый канал, то есть — загрубив потенциально возможные результаты измерения времени. То что я выше предложил — только один способ. Второй может быть например "дрыгать" частоту ядер рандомом. Тут в принципе ничего особенного нету — динамическим изменением частоты никого не удивишь нынче, речь о том чтоб ее дрыгать _всегда_ и часто в целях секурности. Вплоть до рандомизации скважности тактового генератора. Решения, типа понаставлять везде в ядре LFENCE — это просто затычки в решете.

ЗЫ Есть тут у меня одна смутная ассоциация с неопределенностью Гейзенберга. Ох, не случайно она захардкожена в этой Вселенной.

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

O>инкремент volatile int переменной через __sync_add_and_fetch:
Ну хорошо, пусть будет явный барьер в виде инструкции. Смысл не меняется.

C>>И с барьером тоже будет всё нормально. Максимум придётся статистику посчитать.
O>Удачи ее считать если у тебя разрешение таймера будет хуже необходимой разницы. Кроме того, есть стойкое подозрение что использование memory-barrier'а в цикле просто убьет саму атаку на корню.
Я могу повторять пробу много раз, так что статистически даже намного менее точный таймер будет достаточен.

C>>Кроме времени исполнения есть ещё потребление питания, занятость шины памяти, прямые пробы на DRAM contention и т.д.
O>Нене. Все это требует физического подключения логическим анализатором. Сценарии атак нужно разделять. Мы тут про атаку когда хакер может запускать свой код на машине и не более того.
Не требует, кроме питания. Остальное можно косвенно обнаружить.

C>>Более правильным будет убирание side-channel с помощью железных мер. Типа переключаемого кэша, эксклюзивной аренды шины и т.д. Железячники уже думают.
O>side-channel через канал времени лучше всего убить убив этот самый канал, то есть — загрубив потенциально возможные результаты измерения времени.
Это невозможно. Проще перейти на in-order выполнение, да и быстрее оно будет, чем 100500 затычек.

O>>инкремент volatile int переменной через __sync_add_and_fetch:
C>Ну хорошо, пусть будет явный барьер в виде инструкции. Смысл не меняется.
Меняется. Эта инструкция форсит синхронизацию кэша и памяти. То есть ее исполнение в бэкграунде просто ломает атаку, которая основана на том что время доступа к кэшу != время доступа к памяти.

C>>>И с барьером тоже будет всё нормально. Максимум придётся статистику посчитать.
O>>Удачи ее считать если у тебя разрешение таймера будет хуже необходимой разницы. Кроме того, есть стойкое подозрение что использование memory-barrier'а в цикле просто убьет саму атаку на корню.
C>Я могу повторять пробу много раз, так что статистически даже намного менее точный таймер будет достаточен.
Ты можешь повторять пробу бесконечное количество раз, но если результат операций меньше разрешения таймера — усреднив свою статистику ты просто получишь значение разрешния таймера и не более того.
Давай более приближенный к жизни пример. Вот у тебя есть команда ping, и так повелось, что она умеет выдавать результат с точностью до 10 мсек. Как ты с нее помощью определишь какой из двух хостов к тебе ближе, учитывая что round-trip-time до одного из них — 1мсек, до другого — 2мсек?

C>>>Кроме времени исполнения есть ещё потребление питания, занятость шины памяти, прямые пробы на DRAM contention и т.д.
O>>Нене. Все это требует физического подключения логическим анализатором. Сценарии атак нужно разделять. Мы тут про атаку когда хакер может запускать свой код на машине и не более того.
C>Не требует, кроме питания. Остальное можно косвенно обнаружить.
Демагогия.. КРоме того атака на все остальное опять же требует точного измерения времени.

C>>>Более правильным будет убирание side-channel с помощью железных мер. Типа переключаемого кэша, эксклюзивной аренды шины и т.д. Железячники уже думают.
O>>side-channel через канал времени лучше всего убить убив этот самый канал, то есть — загрубив потенциально возможные результаты измерения времени.
C>Это невозможно. Проще перейти на in-order выполнение, да и быстрее оно будет, чем 100500 затычек.
Это возможно, и да, будет быстрее чем 10005000 затычек в виде KPTI, LFENCE тут и там и еще фиг знает чего.

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

C>>Ну хорошо, пусть будет явный барьер в виде инструкции. Смысл не меняется.
O>Меняется. Эта инструкция форсит синхронизацию кэша и памяти. То есть ее исполнение в бэкграунде просто ломает атаку, которая основана на том что время доступа к кэшу != время доступа к памяти.
Обычный барьер не очищает L2-кэш. Он лишь форсирует его синхронизацию.

C>>Я могу повторять пробу много раз, так что статистически даже намного менее точный таймер будет достаточен.
O>Ты можешь повторять пробу бесконечное количество раз, но если результат операций меньше разрешения таймера — усреднив свою статистику ты просто получишь значение разрешния таймера и не более того.
Неверно.

O>Давай более приближенный к жизни пример. Вот у тебя есть команда ping, и так повелось, что она умеет выдавать результат с точностью до 10 мсек. Как ты с нее помощью определишь какой из двух хостов к тебе ближе, учитывая что round-trip-time до одного из них — 1мсек, до другого — 2мсек?
Элементарно. От одного из хостов отсчёты менее 10 мсек будут приходить чаще, чем от другого.

Подумай сам:

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

Далее собираем статистику и считаем какой хост чаще попадает в два отсчёта таймера.

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

C>>Не требует, кроме питания. Остальное можно косвенно обнаружить.
O>Демагогия.. КРоме того атака на все остальное опять же требует точного измерения времени.
Тут вот ещё предложили атаковать сетевыми пакетами. Их точности тоже достаточно на скорости в 10Gb.

C>>Это невозможно. Проще перейти на in-order выполнение, да и быстрее оно будет, чем 100500 затычек.
O>Это возможно, и да, будет быстрее чем 10005000 затычек в виде KPTI, LFENCE тут и там и еще фиг знает чего.
KPTI сам по себе не нужен, он закрывает вполне конкретную дыру в Intel, которой нет в том же AMD.

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

O>>Меняется. Эта инструкция форсит синхронизацию кэша и памяти. То есть ее исполнение в бэкграунде просто ломает атаку, которая основана на том что время доступа к кэшу != время доступа к памяти.
C>Обычный барьер не очищает L1-кэш. Он лишь форсирует его синхронизацию.
....которая занимает время, равное времени записи в память. То есть разрешение твоего таймера будет заведомо больше самого большого интервала, который нужно измерить, чтобы провести атаку.

O>>Ты можешь повторять пробу бесконечное количество раз, но если результат операций меньше разрешения таймера — усреднив свою статистику ты просто получишь значение разрешния таймера и не более того.
C>Неверно.
Верно. Наверно

O>>Давай более приближенный к жизни пример. Вот у тебя есть команда ping, и так повелось, что она умеет выдавать результат с точностью до 10 мсек. Как ты с нее помощью определишь какой из двух хостов к тебе ближе, учитывая что round-trip-time до одного из них — 1мсек, до другого — 2мсек?
C>Элементарно. От одного из хостов отсчёты менее 10 мсек будут приходить чаще, чем от другого.
Беда в том что они все будут приходить 10 мсек. Если округление в большую сторону, и все 0 — если в меньшую

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>

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

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

C>>>Не требует, кроме питания. Остальное можно косвенно обнаружить.
O>>Демагогия.. КРоме того атака на все остальное опять же требует точного измерения времени.
C>Тут вот ещё предложили атаковать сетевыми пакетами. Их точности тоже достаточно на скорости в 10Gb.
Предложить можно что угодно Я предлагаю атаковать почтовыми голубями.

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

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

C>Это невозможно. Проще перейти на in-order выполнение, да и быстрее оно будет, чем 100500 затычек.

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