Aliech Опубликовано 11 января, 2018 (изменено) · Жалоба 5 минут назад, Ivan_83 сказал: Мелтдаун у них не работает, подозреваю что там всё таки чекается разрешён ли доступ к памяти прежде чем поднимать её в кеш и читать в регистр. Или конвеер слишком короткий для таких конструкций. Но они заявили что у них этого нет и никто ещё не доказал обратного. Да, чекается. На привилегированность. В память ядра без привилегий не даёт. Но в память соседнего юзерспейса, как оказалось, можно( https://www.amd.com/en/corporate/speculative-execution Но не факт, что это вот всё можно в реальной жизни воплотить. Спасибо за чуть большую внимательность к архитектуре. Изменено 11 января, 2018 пользователем Aliech Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jffulcrum Опубликовано 11 января, 2018 · Жалоба 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 . А я предчувствовал Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 11 января, 2018 · Жалоба 1 час назад, Aliech сказал: Да, чекается. На привилегированность. В память ядра без привилегий не даёт. Но в память соседнего юзерспейса, как оказалось, можно( Это называется уровень доступа/кольцо защиты. 55 минут назад, jffulcrum сказал: Да и туда говна подвезли https://www.phoronix.com/scan.php?page=news_item&px=AMD-PSP-2018-Vulnerability . А я предчувствовал Сколько можно повторять - доступ к этой дырке отключается в биосе любой платы где есть этот самый fTPM. Если нет - можно не ставить драйвер и тогда шансов что кто то кроме рута/админа туда доберётся нет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
myth Опубликовано 12 января, 2018 · Жалоба Т.е если обновить таким макаром микрокод, то патч kpti можно не ставить? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
snvoronkov Опубликовано 12 января, 2018 · Жалоба 2 часа назад, myth сказал: Т.е если обновить таким макаром микрокод, то патч kpti можно не ставить? KPTI - это для Intel/ARM64 от протечки памяти ядра (Meltdown, протечка памяти промеж кольцами). Обновление микрокода + патч ядра и цомпелятора - от Spectre (протечки памяти промеж изолированными адресными пространствами внутри пользовательского кольца). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Tosha Опубликовано 12 января, 2018 · Жалоба В 11.01.2018 в 19:32, Aliech сказал: Да, чекается. На привилегированность. В память ядра без привилегий не даёт. Но в память соседнего юзерспейса, как оказалось, можно( Как я понял по уязвимости Spectre: В память соседнего процесса можно залезть чисто теоретически. Надо иметь соседний процесс с определенными уязвимостями по заранее известному адресу. Что в случае динамической линковки не выйдет. Виртуальную память можно вообще так выделить что пересечений между процессами не будет. Опасность реальная есть только для, например, криптобиблиотек, которые хранят ключи в shared memory. Ну так надо просто переписать такие библиотеки. А вот память своего процесса защитить не выйдет. Включая потоки. И вот тут надо сильно думать. Особенно над интернет-броузерами. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rm_ Опубликовано 12 января, 2018 · Жалоба 7 минут назад, Tosha сказал: А вот память своего процесса защитить не выйдет. Включая потоки. И вот тут надо сильно думать. Особенно над интернет-броузерами. 1) вроде как выйдет, только надо перекомпилировать, компилятором с особыми трюками для предотвращения этих вещей. 2) у Chromium есть флаг chrome://flags#enable-site-per-process, включает строгую изоляцию сайтов по отдельным процессам, таким образом даже сейчас зловредный код сможет прочитать данные только с того же таба в котором он сам, но не из других. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Tosha Опубликовано 12 января, 2018 · Жалоба Очень тяжело защитить процесс от самого себя. Ошибку контроля границ в спекулятивном коде никак не заткнуть. Процессор не в курсе размеров массивов в принципе. Имхо все "песочницы" внутри процессов придется оформлять в качестве отдельного процесса в итоге. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ttttt Опубликовано 12 января, 2018 · Жалоба "Ошибку контроля границ" легко заткнуть, достаточно никогда не давать индексам/указателям принимать значения выходящие за пределы области памяти, в которой их разрешено использовать. Допустим если есть массив длинной 256 байт, то для него индексы могут принимать значения только от 0 до 255, что соотвествует маске 0xff. Теперь перед использованием индекса можно просто наложить на него маску (index & 0xff) и все, спекулятивное исполнение никогда не наткнется на индекс за пределами массива. Процессор о размерах не в курсе, но компилятор еще как в курсе, даже для таких языков, как С. Песочницы всегда были возможны только в отдельном процессе. А вот фича хрома с отдельными процессами на каждый сайт - не песочница и сама по себе никакой изоляции в контексте данных уязвимостей не дает. Текущая затычка в хроме - это понижение разрешения таймера и отключение фичи, через которую можно смоделировать таймер. Больше будет в хроме 64. И еще, по Spectre 2 в память соседнего процесса можно залезть без всяких других уязвимостей, если в его коде нет защиты от этого. Типичная программа с высокой вероятностью имеет много кусков кода подходящих для этого. А, кстати, заявления амд, что никто не показал эту уязвимость на их процессорах - это на самом деле называется security through obscurity, т.е. своего рода признание, что они тоже уязвимы, вопрос времени и желания. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 12 января, 2018 · Жалоба 5 часов назад, Tosha сказал: Очень тяжело защитить процесс от самого себя. Ошибку контроля границ в спекулятивном коде никак не заткнуть. Процессор не в курсе размеров массивов в принципе. Имхо все "песочницы" внутри процессов придется оформлять в качестве отдельного процесса в итоге. А зачем? Процесс как то работает внутри, ему не нужны защиты от самого себя со стороны ОС, железа. Нет там контроля границ и не нужен он, это опять проблемы процесса. 3 часа назад, ttttt сказал: Процессор о размерах не в курсе, но компилятор еще как в курсе, даже для таких языков, как С. Не надо говорить о том, чего не знаешь. int size = rand(); int *array = calloc(sizeof(int), size); Опустим сейчас что rand() тут в целом предсказуем. И это не считая случая когда по пьяни/обычной тупости там будет написано вместо sizeof(int) что то типа sizeof(char). 3 часа назад, ttttt сказал: А, кстати, заявления амд, что никто не показал эту уязвимость на их процессорах - это на самом деле называется security through obscurity, т.е. своего рода признание, что они тоже уязвимы, вопрос времени и желания. Сейчас я точно так же могу обвинить тебя лично в чём угодно, и сказать что отсутствие доказательств у меня ничего не значит. STO это вообще другое, почитай определение. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ttttt Опубликовано 13 января, 2018 · Жалоба Ну вот зачем споришь о чем не знаешь? У тебя calloc() не может выделить память не зная размера, и этот размер в рантайме можно везде использовать, если понадобится. Есть С компиляторы c bounds checking, которые этот размер и используют. Да хотя вон даже ASAN по твоему откуда размеры берет? Не с неба же. И security through obscurity - это как раз когда прячут внутренности и объявляют, что никто не показал уязвимость. Но гарантировать отсутствие не могут, потому что прекрасно понимают, что уязвимость точно есть, никто же не заботился о side channel атаках. В общем как АМДшный пиар и делает. Концепция известна давно, как неработающая. Вообще все намного хуже с этими уязвимостями, это не конкретные уязвимости, а концепции. Они оставляют много пространства для дальнейших исследований. Еще будет интересно. Уже кто-то говорил о работе по возможным уязвимостям в in-order процессорах со спекулятивным исполнением. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 13 января, 2018 · Жалоба 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Tosha Опубликовано 13 января, 2018 · Жалоба 16 часов назад, ttttt сказал: Допустим если есть массив длинной 256 байт, то для него индексы могут принимать значения только от 0 до 255, что соотвествует маске 0xff. Не спасет, потому как в финальном массиве индекс никогда не выходит за границу, а читается из интересуемой памяти всего 1 байт. Компилятор должен знать какие ограничения на чтение памяти в данной строке. Что очень непросто реализовать, т.к. память выделяется довольно динамично и на этапе компиляции может быть многое не известно. Я не отрицаю что можно компилятором усложнить эксплуатацию уязвимости и почти совсем свести на нет вероятность залезания в чужой процесс, но вот защищать процесс сам от себя никак. Дело в том, что процесс принципиально имеет права на чтение своей памяти. И если процесс исполняет сторонний код - то это код может быть сделан так что обойдет программный контроль границ. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ttttt Опубликовано 13 января, 2018 · Жалоба Я не понимаю, что тебе не понятно. Компиляторы обычно знают где память выделяется, где хранятся метаданные для динамических массивов и т.д., более того эти вещи фундаментально важны для memory safety. Дальше смотри, если сторонний код не может выйти за область памяти, которую он выделяет, ни явно, ни спекулитявно, то он не может получить доступ к другой памяти процесса ни на прямую, ни через side channel timing атаки. Так понятнее? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Sergey Gilfanov Опубликовано 13 января, 2018 · Жалоба 30 минут назад, ttttt сказал: Дальше смотри, если сторонний код не может выйти за область памяти, которую он выделяет, ни явно, ни спекулитявно, то он не может получить доступ к другой памяти процесса ни на прямую, ни через side channel timing атаки. Так понятнее? Эээ. Обсуждаемый баги вроде бы как раз про то, что выделенное не верно - они позволяют при помощи хитрых манипуляций память другого процесса затащить в свое адресное пространство, которое как раз законным образом выделено. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 13 января, 2018 · Жалоба 1 минуту назад, Sergey Gilfanov сказал: Эээ. Обсуждаемый баги вроде бы как раз про то, что выделенное не верно - они позволяют при помощи хитрых манипуляций память другого процесса затащить в свое адресное пространство, которое как раз законным образом выделено. Там скорее дело в том, что можно хитрым способом уговорить процессор затянуть в свой кеш "чужую" память, и хотя он в прямом виде ее вам не отдает (но в некоторых случаях может даже спекулятивно обработать) и подобными, непрямыми методами можно узнать содержимое этого кеша. В свое адресное пространство эта память не затягивается, формально она там уже есть, просто доступа к ней нет(но как оказалось - есть). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ttttt Опубликовано 13 января, 2018 · Жалоба Ну мы сейчас говорим конкретно о bounds check bypass, который Тоша объявил, как невозможный для защиты, это Spectre 1. По нему защита основывается либо на отключении спекулятивного исполнения либо на невозможности спекулятивно выходить за область памяти объектов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Sergey Gilfanov Опубликовано 13 января, 2018 · Жалоба 6 минут назад, ttttt сказал: Ну мы сейчас говорим конкретно о bounds check bypass, который Тоша объявил, как невозможный для защиты, это Spectre 1. По нему защита основывается либо на отключении спекулятивного исполнения либо на невозможности спекулятивно выходить за область памяти. Ну вот 'невозможности спекулятивно выходить за область памяти' - оно точно возможно? Я так понял, проблема как раз в том, то процессор вполне способен решить, что неплохо бы обработать значение из памяти 'конец массива + n', а то что мы на самом деле следим, чтобы такой указатель не сделать и не разименовывать - это уже потом сработает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ttttt Опубликовано 13 января, 2018 · Жалоба Да, оно точно возможно. Это if (i < array_length) { array[ i ] ... } может спекулятивно лезть в массив по любому значению i, но если, например, заменить array[ i ] на array[ i & mask ] то спекулятивно невозможно узнать индекс по которому лезть, пока не применить маску, а после маски уже нельзя лезть куда попало. Это только один из вариантов, можно и без маски, можно использовать какой-нибудь shadow индекс, который никогда не выходит за область памяти массива. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
stalker86 Опубликовано 14 января, 2018 · Жалоба Обновил тут вчера ради интереса 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 ). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jffulcrum Опубликовано 14 января, 2018 · Жалоба 31 минуту назад, stalker86 сказал: не совсем свежими камнями ( E5430 Не совсем свежими - это 10 лет, Launch Date Q4'07 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Tosha Опубликовано 14 января, 2018 · Жалоба 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. Вот точно как я написал может и не сработает. Тут, возможно, надо усложнять операции чтобы процессор точно сразу не знал какое условие будет и начал "гадать". Например, воткнуть перед этим команду, затрагивающую используемый далее в условиях регистр и долгую. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
snvoronkov Опубликовано 14 января, 2018 · Жалоба 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. Никаких глюков пока не замечено. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 14 января, 2018 · Жалоба 6 часов назад, Tosha сказал: и вот какую маску тут можно наложить чтобы это не сработало? Массив test_array задан размером 0xffff. Суходрочка. Смысла в этом нет совсем, ибо в своём приложении ты проверок напихаешь и оно просто станет медленным, а чужое тебя поимеет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ttttt Опубликовано 14 января, 2018 · Жалоба Это компилятор должен пихать или статический анализатор, о борьбе ручками со Spectre конечно можно забыть. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...