Перейти к содержимому
Калькуляторы

Серьезный баг в архитектуре интела?

5 минут назад, Ivan_83 сказал:

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

Но они заявили что у них этого нет и никто ещё не доказал обратного.

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

 

https://www.amd.com/en/corporate/speculative-execution

Но не факт, что это вот всё можно в реальной жизни воплотить. Спасибо за чуть большую внимательность к архитектуре.

Изменено пользователем Aliech

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

42 минуты назад, Aliech сказал:

Типа этого: http://www8.hp.com/us/en/intel-processor-memory-sinkhole.html Так и пофиксили

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

 

Цитата

Спасибо за чуть большую внимательность к архитектуре.

 

Да и туда говна подвезли https://www.phoronix.com/scan.php?page=news_item&px=AMD-PSP-2018-Vulnerability . А я предчувствовал 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

1 час назад, Aliech сказал:

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

Это называется уровень доступа/кольцо защиты.

 

55 минут назад, jffulcrum сказал:

Да и туда говна подвезли https://www.phoronix.com/scan.php?page=news_item&px=AMD-PSP-2018-Vulnerability . А я предчувствовал

Сколько можно повторять - доступ к этой дырке отключается в биосе любой платы где есть этот самый fTPM.

Если нет - можно не ставить драйвер и тогда шансов что кто то кроме рута/админа туда доберётся нет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Т.е если обновить таким макаром микрокод, то патч kpti можно не ставить?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

2 часа назад, myth сказал:

Т.е если обновить таким макаром микрокод, то патч kpti можно не ставить?

KPTI - это для Intel/ARM64 от протечки памяти ядра (Meltdown, протечка памяти промеж кольцами).

Обновление микрокода + патч ядра и цомпелятора - от Spectre (протечки памяти промеж изолированными адресными пространствами внутри пользовательского кольца).

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 11.01.2018 в 19:32, Aliech сказал:

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

Как я понял по уязвимости Spectre:
В память соседнего процесса можно залезть чисто теоретически. Надо иметь соседний процесс с определенными уязвимостями по заранее известному адресу. Что в случае динамической линковки не выйдет. Виртуальную память можно вообще так выделить что пересечений между процессами не будет. Опасность реальная есть только для, например, криптобиблиотек, которые хранят ключи в shared memory. Ну так надо просто переписать такие библиотеки.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

7 минут назад, Tosha сказал:

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

1) вроде как выйдет, только надо перекомпилировать, компилятором с особыми трюками для предотвращения этих вещей.

2) у Chromium есть флаг chrome://flags#enable-site-per-process, включает строгую изоляцию сайтов по отдельным процессам, таким образом даже сейчас зловредный код сможет прочитать данные только с того же таба в котором он сам, но не из других.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Очень тяжело защитить процесс от самого себя. Ошибку контроля границ в спекулятивном коде никак не заткнуть. Процессор не в курсе размеров массивов в принципе. Имхо все "песочницы" внутри процессов придется оформлять в качестве отдельного процесса в итоге.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

"Ошибку контроля границ" легко заткнуть, достаточно никогда не давать индексам/указателям принимать значения выходящие за пределы области памяти, в которой их разрешено использовать. Допустим если есть массив длинной 256 байт, то для него индексы могут принимать значения только от 0 до 255, что соотвествует маске 0xff. Теперь перед использованием индекса можно просто наложить на него маску (index & 0xff) и все, спекулятивное исполнение никогда не наткнется на индекс за пределами массива. Процессор о размерах не в курсе, но компилятор еще как в курсе, даже для таких языков, как С.

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

 

И еще, по Spectre 2 в память соседнего процесса можно залезть без всяких других уязвимостей, если в его коде нет защиты от этого. Типичная программа с высокой вероятностью имеет много кусков кода подходящих для этого. А, кстати, заявления амд, что никто не показал эту уязвимость на их процессорах - это на самом деле называется security through obscurity, т.е. своего рода признание, что они тоже уязвимы, вопрос времени и желания.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

5 часов назад, Tosha сказал:

Очень тяжело защитить процесс от самого себя. Ошибку контроля границ в спекулятивном коде никак не заткнуть. Процессор не в курсе размеров массивов в принципе. Имхо все "песочницы" внутри процессов придется оформлять в качестве отдельного процесса в итоге.

А зачем?

Процесс как то работает внутри, ему не нужны защиты от самого себя со стороны ОС, железа.

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

 

 

3 часа назад, ttttt сказал:

Процессор о размерах не в курсе, но компилятор еще как в курсе, даже для таких языков, как С.

Не надо говорить о том, чего не знаешь.

int size = rand();

int *array = calloc(sizeof(int), size);

Опустим сейчас что rand() тут в целом предсказуем.

И это не считая случая когда по пьяни/обычной тупости там будет написано вместо sizeof(int) что то типа sizeof(char).

 

3 часа назад, ttttt сказал:

А, кстати, заявления амд, что никто не показал эту уязвимость на их процессорах - это на самом деле называется security through obscurity, т.е. своего рода признание, что они тоже уязвимы, вопрос времени и желания.

Сейчас я точно так же могу обвинить тебя лично в чём угодно, и сказать что отсутствие доказательств у меня ничего не значит.

STO это вообще другое, почитай определение.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ну вот зачем споришь о чем не знаешь? У тебя calloc() не может выделить память не зная размера, и этот размер в рантайме можно везде использовать, если понадобится. Есть С компиляторы c bounds checking, которые этот размер и используют. Да хотя вон даже ASAN по твоему откуда размеры берет? Не с неба же.

И security through obscurity - это как раз когда прячут внутренности и объявляют, что никто не показал уязвимость. Но гарантировать отсутствие не могут, потому что прекрасно понимают, что уязвимость точно есть, никто же не заботился о side channel атаках. В общем как АМДшный пиар и делает. Концепция известна давно, как неработающая.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

41 минуту назад, ttttt сказал:

Ну вот зачем споришь о чем не знаешь? У тебя calloc() не может выделить память не зная размера, и этот размер в рантайме можно везде использовать, если понадобится. Есть С компиляторы c bounds checking, которые этот размер и используют. Да хотя вон даже ASAN по твоему откуда размеры берет? Не с неба же.

Там 100500 ограничений на писанину кода в этих компеляторах когда оно работает.

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

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

Я уже не говорю о катастрофических просадках производительности при всём этом.

Собственно RUST вот только для этого и ещё нескольких случаев и реализовали, но он сдохнет, ему нет места.

 

Короче на Си это всё из области фантастики.

 

42 минуты назад, ttttt сказал:

И security through obscurity - это как раз когда прячут внутренности и объявляют, что никто не показал уязвимость. Но гарантировать отсутствие не могут, потому что прекрасно понимают, что уязвимость точно есть, никто же не заботился о side channel атаках. В общем как АМДшный пиар и делает. Концепция известна давно, как неработающая.

https://www.amd.com/en/corporate/speculative-execution?sf178974629=1

Вот тебе пеар АМД, а не твои фантазии.

STO это когда ты делаешь тайну из крипто алгоритма.

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

Тут всё сложнее, мне тоже не нравится что архитектура закрытая, но не нравится - вали с х86.

 

42 минуты назад, ttttt сказал:

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

Да, вот эти работы из 90-х годов: https://pdfs.semanticscholar.org/2209/42809262c17b6631c0f6536c91aaf7756857.pdf

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

16 часов назад, ttttt сказал:

Допустим если есть массив длинной 256 байт, то для него индексы могут принимать значения только от 0 до 255, что соотвествует маске 0xff.

Не спасет, потому как в финальном массиве индекс никогда не выходит за границу, а читается из интересуемой памяти всего 1 байт. Компилятор должен знать какие ограничения на чтение памяти в данной строке. Что очень непросто реализовать, т.к. память выделяется довольно динамично и на этапе компиляции может быть многое не известно.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Я не понимаю, что тебе не понятно. Компиляторы обычно знают где память выделяется, где хранятся метаданные для динамических массивов и т.д., более того эти вещи фундаментально важны для memory safety.
Дальше смотри, если сторонний код не может выйти за область памяти, которую он выделяет, ни явно, ни спекулитявно, то он не может получить доступ к другой памяти процесса ни на прямую, ни через side channel timing атаки. Так понятнее?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

30 минут назад, ttttt сказал:

Дальше смотри, если сторонний код не может выйти за область памяти, которую он выделяет, ни явно, ни спекулитявно, то он не может получить доступ к другой памяти процесса ни на прямую, ни через side channel timing атаки. Так понятнее?

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

1 минуту назад, Sergey Gilfanov сказал:

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ну мы сейчас говорим конкретно о bounds check bypass, который Тоша объявил, как невозможный для защиты, это Spectre 1. По нему защита основывается либо на отключении спекулятивного исполнения либо на невозможности спекулятивно выходить за область памяти объектов.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

6 минут назад, ttttt сказал:

Ну мы сейчас говорим конкретно о bounds check bypass, который Тоша объявил, как невозможный для защиты, это Spectre 1. По нему защита основывается либо на отключении спекулятивного исполнения либо на невозможности спекулятивно выходить за область памяти.

Ну вот 'невозможности спекулятивно выходить за область памяти' - оно точно возможно? Я так понял, проблема как раз в том, то процессор вполне способен решить, что неплохо бы обработать значение из памяти 'конец массива + n', а то что мы на самом деле следим, чтобы такой указатель не сделать и не разименовывать - это уже потом сработает.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Да, оно точно возможно. Это if (i < array_length) { array[ i ] ... } может спекулятивно лезть в массив по любому значению i, но если, например, заменить array[ i ] на array[ i & mask ] то спекулятивно невозможно узнать индекс по которому лезть, пока не применить маску, а после маски уже нельзя лезть куда попало. Это только один из вариантов, можно и без маски, можно использовать какой-нибудь shadow индекс, который никогда не выходит за область памяти массива.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Обновил тут вчера ради интереса 1 из тазиков с oldold stable дебианом на ядро с фиксами spectre ( linux-image-3.2.0-4-amd64 3.2.96-2  -> linux-image-3.2.0-5-amd64  3.2.96-3)
и словил 100500 упсов вида

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887106

 

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

 

Причём на тестовой виртуалке не воспроизводится. Похоже сломали работу с некоторыми не совсем свежими камнями ( E5430 ).

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

31 минуту назад, stalker86 сказал:

не совсем свежими камнями ( E5430

Не совсем свежими - это 10 лет, Launch Date Q4'07

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

19 часов назад, ttttt сказал:

а после маски уже нельзя лезть куда попало

Там же не прямое чтение. 

if (i < len)  if (test_addr < mem_limit) res = test_array[0xffff && (i + 256*test_addr[0])]

if (test_addr < mem_limit)  - это то что вставил компилятор для проверки что мы не вылазим за доступную память, чисто условно.

сначала это тренируется на доступных данных, а потом ставится i > len  и процессор на автомате исполняет все старые ветки исполнения плюя на проверки. Потом молча откатывает и переделывает. Но данные то уже в кэше...

и вот какую маску тут можно наложить чтобы это не сработало?   Массив test_array задан размером 0xffff.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

2 часа назад, stalker86 сказал:

Похоже сломали работу с некоторыми не совсем свежими камнями ( E5430 ).

Видимо, что-то необычное в настройках?

 

# cat /proc/cpuinfo |grep Xeon|head -1
model name    : Intel(R) Xeon(R) CPU           X5650  @ 2.67GHz
# uname -a
Linux timeshift 3.2.0-5-amd64 #1 SMP Debian 3.2.96-3 x86_64 GNU/Linux
# uptime
 16:23:07 up 5 days,  7:16,  1 user,  load average: 3,74, 3,49, 3,56

Запущен Flussonic. Никаких глюков пока не замечено.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

6 часов назад, Tosha сказал:

и вот какую маску тут можно наложить чтобы это не сработало?   Массив test_array задан размером 0xffff.

Суходрочка.

Смысла в этом нет совсем, ибо в своём приложении ты проверок напихаешь и оно просто станет медленным, а чужое тебя поимеет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.