Здравствуйте, ononim, Вы писали:
O>Можно, но это сильно загрубит разрешение такого измерителя времени. Помни — хакеру нужно измерить время вычитки одного слова из памяти.
Будет капашится в регистрах процессора с умным видом -- это не сильно скажется на времени вычитки.
Здравствуйте, Pzz, Вы писали:
Pzz>Дыра работает в определенном режиме процессора. Можно не использовать этот режим, тогда дыра перестанет работать. Но вызов ядра из пользовательской задачи станет заметно дороже.
Как я понял, сейчас в порядке временной меры тупо отключают отображение ядерных ("верхних") адресов в адресное пространство пользовательских процессов. По сути, полного отключения и не требуется — код и так свободно доступен, а из данных безусловно необходимо отключение только "начальных" областей с глобальными переменными/константами, без которых не получится сколько-нибудь эффективного сканирования структур.
Может статься, что одно только отключение этих ключевых данных (которые вполне можно свести в одну-две страницы), вкупе с какой-нибудь технологией обнаружения спекулятивных атак и противодействия им, позволит свести вероятность успешной атаки к неприемлемо малой величине, которой на практике будет вполне достаточно для большинства систем. Тогда удастся обойтись практически без удорожания.
Здравствуйте, AndrewJD, Вы писали:
AJD>Все равно куча непоняток. Утверждается, что зловред может получать данные из чужого процесса. Вопрос том, как зловред может знать что именно выполняет атакуемый процесс, как заставить его выполнится на том же самом ядре?
Так он туда встроится,в нужные места. Почитайте англ. вики на тему spectre
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Sharov, Вы писали:
C>>> Видимо, Intel сэкономили на битах защиты для кэша первого уровня, в отличие от AMD. Так что для них это получилось намного дороже. S>>Т.е. то, что приташили из kernel-mode нельзя прочитать в user-mode? C>В AMD нельзя, так как в L1 лежат биты защиты, так что их проверка получается дешёвой и синхронной.
Сомневаюсь.
AFAIK кеш работает с физическими адресами, что делает кеширование битов защиты бессмысленным.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>По сути, полного отключения и не требуется — код и так свободно доступен
Не совсем. Код "спрятан" с помощью KASLR. Много уязвимостей не стали эксплоитами из-за этой рандомизации. Баги дают мощный инструмент обхода.
ЕМ>а из данных безусловно необходимо отключение только "начальных" областей с глобальными переменными/константами, без которых не получится сколько-нибудь эффективного сканирования структур.
Структуры интереснее на запись (DKOM). Но в любом случае для обхода DEP/NX надо строить ROP на коде ядра. И тут баги весьма кстати.
Здравствуйте, ononim, Вы писали:
O>Сомневаюсь что прям таки ненадежно. Там можнт быть инкеремент/декремент в цикле (возможно, размотанном цикле), если хакер его будет разбавлять чем то еще, чтоб запутать детектилку — это резко затруднит ему его хакерскую работу. А паттерн вида "тред, который занимается исключительно инкрементом переменной по адресу Х" довольно однозначно определяет наколенный измеритель времени. Возможно, и даже скорее всего, что я недооцениваю фантазию хакеров, но ИМХО количество вариантов таки достаточно ограничено и они таки будут достаточно специфичны для распознания.
Вариантов примерно 100500 миллиардов.
Зачем инкрементировать память ? Регистры. Зачем вообще инкрементировать — будем фрактал рисовать. И фрактал будет отражать состояние линий кеша, опосредовано разумеется. А потом из одного результата выцепим значения 1488 замеров.
Здравствуйте, IID, Вы писали:
C>>>> Видимо, Intel сэкономили на битах защиты для кэша первого уровня, в отличие от AMD. Так что для них это получилось намного дороже. S>>>Т.е. то, что приташили из kernel-mode нельзя прочитать в user-mode? C>>В AMD нельзя, так как в L1 лежат биты защиты, так что их проверка получается дешёвой и синхронной.
IID>Сомневаюсь. IID>AFAIK кеш работает с физическими адресами, что делает кеширование битов защиты бессмысленным.
Здравствуйте, Евгений Музыченко, Вы писали:
Pzz>>Дыра работает в определенном режиме процессора. Можно не использовать этот режим, тогда дыра перестанет работать. Но вызов ядра из пользовательской задачи станет заметно дороже. ЕМ>Как я понял, сейчас в порядке временной меры тупо отключают отображение ядерных ("верхних") адресов в адресное пространство пользовательских процессов. По сути, полного отключения и не требуется
Да. Удар по производительности из-за того, что из-за этого сбрасываются TLB на границе системных вызовов. Потому нет особой разницы что конкретно отключать, тем более, что всё ядро отображается как один кусок.
Здравствуйте, Cyberax, Вы писали:
C>Удар по производительности из-за того, что из-за этого сбрасываются TLB на границе системных вызовов. Потому нет особой разницы что конкретно отключать, тем более, что всё ядро отображается как один кусок.
Подозреваю, что основной удар как раз из-за того, что все одним куском, а TLB лезет прежде всего к коду, который отключать и не требуется.
Вообще, откуда там может быть падение в 20-30%? На мой взгляд, такие тормоза возможны лишь при вызове syscall'ов тысячи раз в секунду, а этим мало кто в здравом уме занимается (пока в голову приходит только предельно реалтаймовый звук).
O>>Сомневаюсь что прям таки ненадежно. Там можнт быть инкеремент/декремент в цикле (возможно, размотанном цикле), если хакер его будет разбавлять чем то еще, чтоб запутать детектилку — это резко затруднит ему его хакерскую работу. А паттерн вида "тред, который занимается исключительно инкрементом переменной по адресу Х" довольно однозначно определяет наколенный измеритель времени. Возможно, и даже скорее всего, что я недооцениваю фантазию хакеров, но ИМХО количество вариантов таки достаточно ограничено и они таки будут достаточно специфичны для распознания. IID>Вариантов примерно 100500 миллиардов. IID>Зачем инкрементировать память ? Регистры.
Блин, какие нафиг регистры? Тебе надо время посчитать для _другого_потока_, работающего на другом ядре.
IID>Зачем вообще инкрементировать — будем фрактал рисовать. И фрактал будет отражать состояние линий кеша, опосредовано разумеется. А потом из одного результата выцепим значения 1488 замеров.
Балабольство. Возьми и посчитай расчетом фрактала время с точностью до вычитки нескольких слов. И не забудь сообщить его соседнему потоку.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, Евгений Музыченко, Вы писали:
C>>Удар по производительности из-за того, что из-за этого сбрасываются TLB на границе системных вызовов. Потому нет особой разницы что конкретно отключать, тем более, что всё ядро отображается как один кусок. ЕМ>Подозреваю, что основной удар как раз из-за того, что все одним куском, а TLB лезет прежде всего к коду, который отключать и не требуется.
"Всё одним куском" как раз экономит TLB. Проблемы в том, что при переключении страниц TLB совсем все сбрасываются.
ЕМ>Вообще, откуда там может быть падение в 20-30%? На мой взгляд, такие тормоза возможны лишь при вызове syscall'ов тысячи раз в секунду, а этим мало кто в здравом уме занимается (пока в голову приходит только предельно реалтаймовый звук).
Файловые системы, базы данных...
Здравствуйте, Cyberax, Вы писали:
ЕМ>>На мой взгляд, такие тормоза возможны лишь при вызове syscall'ов тысячи раз в секунду
C>Файловые системы, базы данных...
Если работа с файлами/базами требует тысяч обращений к ядру каждую секунду — самое время подумать об оптимизации структуры и алгоритмов обработки.
Здравствуйте, ononim, Вы писали:
IID>>Зачем инкрементировать память ? Регистры. O>Блин, какие нафиг регистры? Тебе надо время посчитать для _другого_потока_, работающего на другом ядре.
А зачем тебе инкременты ?
IID>>Зачем вообще инкрементировать — будем фрактал рисовать. И фрактал будет отражать состояние линий кеша, опосредовано разумеется. А потом из одного результата выцепим значения 1488 замеров. O>Балабольство. Возьми и посчитай расчетом фрактала время с точностью до вычитки нескольких слов. И не забудь сообщить его соседнему потоку.
Да вариантов ведь миллиард. Можно даже наоборот сделать: Поток, который трогает кеши, пусть сам что-то пишет в общую память. А поток, который считает условный "фрактал", — юзает эти данные. Самый тупой вариант — "трогающий" кеши пишет по поинтеру, который меняется псевдослучайно тайминговым потоком. Вообще никаких инкрементов нет. Эвристика отвалилась.
ЕМ>Вообще, откуда там может быть падение в 20-30%? На мой взгляд, такие тормоза возможны лишь при вызове syscall'ов тысячи раз в секунду, а этим мало кто в здравом уме занимается (пока в голову приходит только предельно реалтаймовый звук).
Здравствуйте, Sharov, Вы писали:
ЕМ>>такие тормоза возможны лишь при вызове syscall'ов тысячи раз в секунду, а этим мало кто в здравом уме занимается
S>А виртуалки?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>>>На мой взгляд, такие тормоза возможны лишь при вызове syscall'ов тысячи раз в секунду C>>Файловые системы, базы данных... ЕМ>Если работа с файлами/базами требует тысяч обращений к ядру каждую секунду — самое время подумать об оптимизации структуры и алгоритмов обработки.
Чтение сетевого пакета, отправка ответа, дисковые операции с журналом и т.д.
Десятки тысяч операций в секунду получаются легко и непринуждённо.
Здравствуйте, Cyberax, Вы писали:
C>Чтение сетевого пакета, отправка ответа, дисковые операции с журналом и т.д. C>Десятки тысяч операций в секунду получаются легко и непринуждённо.
Для обмена сетевыми пакетами с драйвером до сих пор не придумали прямого способа, вроде разделяемого кольцевого буфера? Мрак. Для звука придумали больше десяти лет назад.
Для звука придумали больше десяти лет назад.
