Comments 105
Полной защитой от такого класса атак, наверное, может быть только аппаратная реализация гомоморфного шифрования. Тогда процессор не сможет знать о том, что он вычисляет. (Но будет это делать ооооочень медленно и горячо :).)
UFO just landed and posted this here
И скорее всего, там тоже будут security-дыры подобного масштаба.
Так спецслужбы США проинвестируют разработку, с внедрением на сей раз более хитроумных дыр. С другой стороны закрадывается мысль что уязвимости были оставлены специально, возможно в то время развития процессоров выполнять дополнительные проверки в спекулятивном выполнении сводило на нет все полученное ускорение.
Прошу прощения за нубский вопрос, но есть ли хоть какая-то реальная выгода в закрытии уязвимостей (и принятия пониженной производительности) для владельцев ПК и железных серверов, или практическую ценность уязвимости имеют только в случае виртуализации и размещения машин разных владельцев на одном хосте?
Если на компе выполняется браузер, то есть «выгода» (точнее, отсутствие убытков из-за возможных взломов), так как без javascript/html5 сейчас — никуда не сходишь, практически.
Можно белый список для выполнения JS (правда, остаётся проблема в случае взлома этих сайтов)…
При скорости 1 бит в минуту сложно представить, как можно нанести ущерб. Интересно, если, к примеру, человек выключает компьютер каждую ночь, и всегда держит открытой вкладку браузера со зловредом, то можно возобновлять начатую вчера атаку, или, надо провести полную атаку за одну сессию? Если второй вариант, то как-то это сложно выходит что-то существенное сделать.
PS: Пока у меня складывается впечатление, что все будут страдать ради решения проблемы всяких азуров и авээсов (причем, исключительно их проблемы).
PS: Пока у меня складывается впечатление, что все будут страдать ради решения проблемы всяких азуров и авээсов (причем, исключительно их проблемы).
Интересно, а данные в оперативной памяти всегда хранятся в одних и тех же адресах? Есть ли фрагментация? Может просто достаточно время от времени сдвигать все данные не случайное растоение, тогда и проблем не будет.
Только сразу перестанет работать кеширование, придется пересчитывать таблицы трансляции адресов, пересчитать виртуальную память и указатели…
Попутно придется найти того, кто будет память «тусовать» и учесть, что все это будет занимать шины памяти перегонкой десятков гигабайт в секунду, выжирая электричество и выделяя дофига тепла…
Попутно придется найти того, кто будет память «тусовать» и учесть, что все это будет занимать шины памяти перегонкой десятков гигабайт в секунду, выжирая электричество и выделяя дофига тепла…
1 бит в минуту это для netspectre, класс атак по сети!
В локальном варианте все намного хуже. Так плохо, что специалисты не знают о том, как защититься.
В локальном варианте все намного хуже. Так плохо, что специалисты не знают о том, как защититься.
UFO just landed and posted this here
И получится то же самое замедление производительности, что и при решении на уровне патча микрокода (а так же всё равно решение в браузере не будет полным, «временнОй шум» аппаратуры всё равно будет «протекать» в последовательность выполнения фрагментов приложения). Ведь рандомизировать и замедлить придётся не просто таймеры, а абсолютно ВСЁ, ведь сравнивать скорости различных вычислительных процессов можно и вовсе без таймера (скажем, сравнить, сколько выполнится CSS-анимаций за время отрисовки какого-нибудь хитрого дива, или ещё что-то такое же косвенное).
нужно просто закрывать браузер, когда пользуешься электронными кошельками или конфиденциальной инфой
Для домашних ПК — нет. Через браузер работает слишком медленно, а если вы все подряд на ПК ставите, то есть десятки более простых способов украсть с вашего ПК информацию.
Такое впечатление, что это не «недостаток дизайна», а «фича дизайна». Сложно поверить, что куча людей в разных конторах и с опытом проектирования процессоров, кучей эмуляторов в железе просто «не увидела» такой побочный эффект. Да и АМД своевременно подсуетились с шифрацией памяти, Китай со своими процессорами и своей архитектурой — это тоже понятно.
Когда читал мануалы про 486 процессор в голове был вопрос «спекулятивное исполнение — понятно. Результаты отбрасываются — понятно. Но как они отбрасываются? Не проходит же микрокод и не обнуляет кеши и результаты исполнений...»
Такое впечатление, что каких-то ребят поймали «на горячем», и что бы такой «баг проектирования» не похоронили в каких гостайнах — плеснули в вентилятор, все что можно.
Можно сколько угодно зубоскалить про ФСБ-ФАПСИ & Co с их компьютерами «на лампах», процессорами Байкалам — но какие-то параноики из этих контор все таки оказались правы. Не сильно будет удивительно, если они «были в доле» — знать и молчать, делая вид что не знают…
По факту такой «баг дизайна» означает, что весомая часть безопастности в ИТ — одна большая подстава в планетарном масштабе, в пользу ребят «из АНБ». Прецеденты таких масштабов были и уже не один раз — ослабление криптомеханизмов GSM, слабые генераторы случайных чисел,Windows Bitlocker & EFS и т.д.
Нормальная стратегия: если не можем победить крипто — давайте сделаем так, что бы тупо читать ключи из памяти, а эти лохи путь думают что «дыра в безопастности» прикрыта.
Когда читал мануалы про 486 процессор в голове был вопрос «спекулятивное исполнение — понятно. Результаты отбрасываются — понятно. Но как они отбрасываются? Не проходит же микрокод и не обнуляет кеши и результаты исполнений...»
Такое впечатление, что каких-то ребят поймали «на горячем», и что бы такой «баг проектирования» не похоронили в каких гостайнах — плеснули в вентилятор, все что можно.
Можно сколько угодно зубоскалить про ФСБ-ФАПСИ & Co с их компьютерами «на лампах», процессорами Байкалам — но какие-то параноики из этих контор все таки оказались правы. Не сильно будет удивительно, если они «были в доле» — знать и молчать, делая вид что не знают…
По факту такой «баг дизайна» означает, что весомая часть безопастности в ИТ — одна большая подстава в планетарном масштабе, в пользу ребят «из АНБ». Прецеденты таких масштабов были и уже не один раз — ослабление криптомеханизмов GSM, слабые генераторы случайных чисел,Windows Bitlocker & EFS и т.д.
Нормальная стратегия: если не можем победить крипто — давайте сделаем так, что бы тупо читать ключи из памяти, а эти лохи путь думают что «дыра в безопастности» прикрыта.
Конспирология на марше, как и всегда в последнее время. Есть замечательная поговорка — «что знают двое, знает и свинья». Невозможно объединить в заговоре молчания тысячи разработчиков и службистов, тем более — не только в одной стране, но и одновременно многих из геополитически враждебных стран так, чтобы они "были в доле". Не-воз-мож-но.
Есть замечательная поговорка — «что знают двое, знает и свинья». Невозможно объединить в заговоре молчания тысячи разработчиков и службистов,
Есть прецеденты, когда знают «много поросят» — Энигма во вторую мировую,
GSM
, Безопасность GSM сетей изначально основывалась на принципе «безопасность за счёт неизвестности». И когда в 1998 году алгоритм был вскрыт группой исследователей состоящих из Marc Briceno, Ian Goldberg и David Wagner обранужилась одна занятная особенность: последние 10 бит секретного ключа Ki всегда равнялись нулю. Используя это любопытное свойство, а так же уязвимость COMP128 к «атаке дней рождений» Marc Briceno, Ian Goldberg и David Wagner смогли извлечь секретный ключ Ki из SIM-карты.
Результатом этого исследования стал повсеместный отказ от алгоритма COMP128 и его замена на более надежные модификации COMP128-2 и COMP128-3, технические детали которых держатся в тайне. Хм… вам это ничего не напоминает?
Результатом этого исследования стал повсеместный отказ от алгоритма COMP128 и его замена на более надежные модификации COMP128-2 и COMP128-3, технические детали которых держатся в тайне. Хм… вам это ничего не напоминает?
Ericsson подслушивание
, В феврале 2006 года правительство Греции официально сообщило о факте прослушивания, которое осуществлялось с июня 2004 года по март 2005 года. Все пострадавшие пользовались услугами сотового оператора Vodafone, который использовал оборудование компании Ericsson.
…
Всего прослушке подверглись около сотни мобильных телефонов, среди обладателей которых были также активисты левых организаций и выходцы из арабских стран. Специальный комитет греческого парламента, занимавший расследованием этого дела, отметил причастность к этому скандалу трех сотрудников Vodafone и Ericsson. Их полные имена не были названы.
В отчете парламентского комитета указывалось, что подслушивание было бы невозможным без знания технологий компании Ericsson и без вмешательства внутри сети Vodafone. Однако впоследствии комитет прекратил расследование, сочтя дело слишком технически сложным.
…
Всего прослушке подверглись около сотни мобильных телефонов, среди обладателей которых были также активисты левых организаций и выходцы из арабских стран. Специальный комитет греческого парламента, занимавший расследованием этого дела, отметил причастность к этому скандалу трех сотрудников Vodafone и Ericsson. Их полные имена не были названы.
В отчете парламентского комитета указывалось, что подслушивание было бы невозможным без знания технологий компании Ericsson и без вмешательства внутри сети Vodafone. Однако впоследствии комитет прекратил расследование, сочтя дело слишком технически сложным.
RSA Security заявила о наличии АНБ-бэкдора в своих продуктах
Итак, в их продуктах RSA Data Protection и RSA Bsafe во всю использовался алгоритм Dual EC_DRBG (Dual Elliptic Curve Deterministic Random Bit Generation), сертифицированный NIST (описание). И сертифицированный, как выяснилось, с сюрпризом от агенства национальной безопасности США. То есть, это никакой не random, если вы знаете в чём суть закладки.
Ну и о том, что этот алгоритм может содержать бэкдор, исследователи говорили еще в 2007м году. Что не помешало NIST его сертифицировать. А кипиш начался после опубликованных Сноуденом документов, где явно говорилось о неком стандарте 2006 года.
Dual_EC_DRBG, между прочим, является довольно популярной штуковиной.
Реализован в Windows, начиная с Vista SP1, что делает его самым популярным в мире. Так же, реализация есть в OpenSSL и вообще он похоже пролоббирован в куче продуктов (McAfee, например, но те использовали его только для программ гос сектора). Так что, вычищать от него код придется еще долгое время.
Ну и о том, что этот алгоритм может содержать бэкдор, исследователи говорили еще в 2007м году. Что не помешало NIST его сертифицировать. А кипиш начался после опубликованных Сноуденом документов, где явно говорилось о неком стандарте 2006 года.
Dual_EC_DRBG, между прочим, является довольно популярной штуковиной.
Реализован в Windows, начиная с Vista SP1, что делает его самым популярным в мире. Так же, реализация есть в OpenSSL и вообще он похоже пролоббирован в куче продуктов (McAfee, например, но те использовали его только для программ гос сектора). Так что, вычищать от него код придется еще долгое время.
Почему «много поросят» молчат? патриотизм, деньги, принуждение и т.д.
«Сговорились» — на каждую хитрую #@&* найдется свой болт с левой резьбой. Если ребята покупают в свой Госдеп компы с «дырой в безопастности» — глупо орать об этом на весь мир, если ты можешь через эту «дыру в безопастности» шарится по сети потенциального противника/соперника как по свой собственной…
Чаще всего много поросят молчат, потому что если расскажешь обывателю — никто не поверит, расскажешь знающим — заткнут (либо и так всем известно, либо молчи, не то прибьют).
Так и было до Сноудена, пока не было конфликта, никто не верил. Даже был фильм по мотивам в 1998 (Враг государства).
Так и было до Сноудена, пока не было конфликта, никто не верил. Даже был фильм по мотивам в 1998 (Враг государства).
«Масонская ложа» != «явная лажа»
Я просто напомню кусочек статьи:
Пол Тёрнер, инженер и руководитель основного костяка разработчиков Google, присутствовавший на конференции, рассказал, что никто из членов Project Zero не предупредил об открытии своих коллег; они узнали об этом вместе со всеми.
По факту такой «баг дизайна» означает, что весомая часть безопастности в ИТ — одна большая подстава в планетарном масштабе, в пользу ребят «из АНБ».
Пока что обсуждаемые уязвимости существуют только на бумаге. На данный момент нету даже теоретической возможности их использования на практике, так что не стоит волноваться, с безопасностью все ок и никакой подставы не было.
Касперский сайт заблокировал.
В любом случае, речь не о возможности совершить атаку как таковую. Речь о том, что пока что нету возможности (на сколько я знаю, по крайней мере) использовать эту атаку чтобы реально украсть какие-то полезные данные.
Больше всего в опасности провайдеры облаков. Ибо запущенный ВПС может воровать данные со скоростью 1 байт в минуту (на данный момент, т.к. дыра кардинальная в архитектуре, возможно в будущем и более быстрый взлом). Что равно примерно 500 килобайт в год. Однако если знать откуда тырить, можно взять доступ рута хоста или чего похлеще.
Что равно примерно 500 килобайт в год. Однако если знать откуда тырить, можно взять доступ рута хоста или чего похлеще.
А разве можно указать откуда тырить? Насколько я понимаю, это неконтролируемый процесс. То есть вы получите свои 500кб данных в год, но даже если все это время память была статична, то вероятность того, что это будут какие-то полезные данные… ну крайне мала. Если же учесть, что данные в памяти все таки регулярно обновляются, то вы скорее всего получите куски непонять из чего и как собранные.
Разве не так?
пароли в кэше процессора хранятся уже декодированными, таким образом, если вы знаете хотя бы немного структуру того против чего проводите атаку, то можете довольно точно получить доступ к декодированному паролю и всё сложное шифрование и криптоустойчивость идёт лесом…
Spectre
Согласно этому, большинство Спектральных атак еще вообще не залатаны.
500байт данных только через один метод атак = Netspectre, которому не нужен доступ к запуску на пк.
Для других систем скорость в принципе CPU Speed / byte, что достаточно для быстрого взлома (читай моментального).
Согласно этому, большинство Спектральных атак еще вообще не залатаны.
500байт данных только через один метод атак = Netspectre, которому не нужен доступ к запуску на пк.
Для других систем скорость в принципе CPU Speed / byte, что достаточно для быстрого взлома (читай моментального).
Проверил.
Пишет:
$ Your browser is VULNERABLE to Spectre
$ Please update your browser immediately
Последняя версия Хрома.
Пишет:
$ Your browser is VULNERABLE to Spectre
$ Please update your browser immediately
Последняя версия Хрома.
UFO just landed and posted this here
Vivaldi последней версии, написал что неподвержен. Хром последней версии, написал что подвержен.
Забавно что старый хром, наоборот пишет НЕ подвержен. И старый (ESR) Лис тоже.
Или это из-за того, что процессор AMD? Хотя Spectre вроде и на AMD можно реализовать в отличии от Meltdown.
Или это из-за того, что процессор AMD? Хотя Spectre вроде и на AMD можно реализовать в отличии от Meltdown.
Там в файле https://xlab.tencent.com/special/spectre/js/check.js есть такой код:
if(window.SharedArrayBuffer)
{
output_cache_log(8);
check(8, [88,117,97,110,119,117]);
}
else
{
output_not_info_leak();
}
Любопытно, а процессоры с архитектурой отличной от Интел — MILV Эльбрус-8C, например,
и ARM, подвержены Meltdown и Spectre? И если подвержены то насколько патчи замедляют их? Интеловские процессоры патчи замедляют насколько я понял на ~ 5%, а AMD в среднем на 0.5%-1%.
Устраните спекулятивное выполнение – и это замедлит работу процессора в двадцать раз, сказал Хилл.Но ведь относительно свежие Intel Atom не подвержены этой атаке и при этом не работают в 20 раз медленнее аналогичных процессоров.
Потому что уязвимость не в самом спекулятивном выполнении, а том, что это выполнение оставляет следы. На свежих атомах этих следов меньше либо их ещё не нашли.
Основной след это ведь попадание в кэш? То есть достаточно либо не писать в кэш пока инструкция реально не выполнится, либо откатывать попадание в кэш, если произошел переход и сброс конвейера. Или нет? Ну то есть это конечно изменение архитектуры, но вряд ли кардинальное.
И как Вы это представляете? stackoverflow.com/questions/4087280/approximate-cost-to-access-various-caches-and-main-memory
DRAM намного медленнее даже L3 кеша, не касаясь его скорости.
По сути надо избавляться от кешей вообще.
DRAM намного медленнее даже L3 кеша, не касаясь его скорости.
По сути надо избавляться от кешей вообще.
Зачем? Если инструкция реально выполнилась, то кэширование срабатывает и используется при выполнении следующих инструкций.
А если следующая инструкция? А следующая? И т.д. и т.п.
Данные в кеше — надо очищать каждый раз после каждой операции — значит доступ к памяти нужен постоянно. Тут еще надо будет защитить этот самый доступ от похожих атак. А то можно таймить доступ и выяснять информацию.
Данные в кеше — надо очищать каждый раз после каждой операции — значит доступ к памяти нужен постоянно. Тут еще надо будет защитить этот самый доступ от похожих атак. А то можно таймить доступ и выяснять информацию.
Данные в кеше — надо очищать каждый раз после каждой операции — значит доступ к памяти нужен постоянно.
Так речь не о том, чтобы защищать, а о том, чтобы в кеш не класть. Процессор спекулятивно выполняет операцию которая требует положить => читает память в специальный буфер размером в кеш-линию => к этому моменту инструкция, инициировавшая спекулятивное выполнение, уже выполнилась и можно посмотреть результат => если результат ок, то сбрасываем буфер в кеш
т.о. данные могут попасть в кеш в том и только том случае, если они и должны были туда попасть
Тут проблема в том, что спекулятивно требуется операция чтения.
Есть например запрещенные данные в кеше. По идее если мы посылаем запрос на чтение этих данных с определенной командой и у нас нет доступа — должен прийти отказ. Спекулятивное выполнение производит расчет сразу параллельно пока идет проверка отказ или нет. Доступа нет, отказ приходит и система отвечает, что нет и данные спекулятивные отбрасывает.
Однако проблема в том, что проверка кеша для этого необходима. От скорости ответа и зависит тот байт или не тот.
То есть атака не на запись, а на чтение. Таким образом получается не только кеш, но и всю память прочесть (т.к. процессор спекулятивно-таки получает данные из памяти, до проверки стоит ли или нет)…
Сам факт проверки или какого-либо замедления этого процесса сразу привидет к замедлению быстродействия всей системы.
Иного выхода быть и не может.
Такого типа атаки применялись и ранее, чаще всего они есть в криптографии (тайминг и сайдченел).
Все ускорение процессоров за последнее время (от Intel по-крайней мере) висит на спекулятивном выполнении. Убрать это и мы вернемся во времена Pentium 2-3.
Есть например запрещенные данные в кеше. По идее если мы посылаем запрос на чтение этих данных с определенной командой и у нас нет доступа — должен прийти отказ. Спекулятивное выполнение производит расчет сразу параллельно пока идет проверка отказ или нет. Доступа нет, отказ приходит и система отвечает, что нет и данные спекулятивные отбрасывает.
Однако проблема в том, что проверка кеша для этого необходима. От скорости ответа и зависит тот байт или не тот.
То есть атака не на запись, а на чтение. Таким образом получается не только кеш, но и всю память прочесть (т.к. процессор спекулятивно-таки получает данные из памяти, до проверки стоит ли или нет)…
Сам факт проверки или какого-либо замедления этого процесса сразу привидет к замедлению быстродействия всей системы.
Иного выхода быть и не может.
Такого типа атаки применялись и ранее, чаще всего они есть в криптографии (тайминг и сайдченел).
Все ускорение процессоров за последнее время (от Intel по-крайней мере) висит на спекулятивном выполнении. Убрать это и мы вернемся во времена Pentium 2-3.
Как я понял из описания атак, проблема в том, что в кэш попадают элементы из памяти атакующего, которые зависят от значения по защищенному адресу. Атакующий потом их все читает и измеряет время доступа. Сами инструкции на чтение, но помещение в кэш это запись. То есть если не записывать в кэш прочитанные значения пока не произойдет реальное выполнение, то атакующий получит одно и то же время доступа для всех элементов, они попадут в кэш только во время этой проверки.
Не, не PIII и уж тем более не PII. Кто-то похоже забыл, насколько это давно и медленно. И на самом деле, даже сказать, что на 10 лет назад — слукавить. Если убрать кэши разрушится почти-мгновенный доступ к памяти, но DDR-4 сегодня работает на четырёх гигагерцах с латентностью в сотню наносекунд. Это очень быстро по сравнению с PIII, у которых L3-кеш был примерно такого уровня. К тому же это освободит кристал от «лишней» сущности, что позволит развести дополнительные линии шины, хотя это и потребует значительной переделки. Всё это крайне сильно замедлит существенное число соверменного софта, особенно браузеры с вордами из-за активного использования разного рода виртуальных машин, которые без cpu-speed кэша не очень поворотливые, но тем не менее… Память в те времена была о-очень медленная, сейчас SSD накопители быстрее оперативной памяти того времени, так что дизайн кеша действительно может изменится, но прямо сейчас. Атака сейчас сложная к применению и только в лабораторных условиях, но со временем тулзы подрастут, а скрипты поумнеют, так что вполне возможно ожидать довольно скоро такой способ атаки от любого скрипт-кидди, а это уже проблема, и даже не только для AWS, но вообще для любого. И всё это может привести к полному пересмотру дизайна кэша.
Что до пересмотра спекулятивной логики, так это в том, что нет причин её изгонять. Дело не столько в том, что это дьявол, скрывающийся в деталях, сколько в том, что это скорее его адвокат, прикрывающий принципиальную тупость 95% населения: никто не есть фон Нейман в программировании, кроме пары нёрдов в свитерах с оленями, так что будет очень тяжело объяснить, что теперь надо программировать многопоточно, а потому 99% из вас будут расстреляны за ненадобностью, а остальные 1% клонированы, иначе нас ждёт финансовый коллапс.
Что до пересмотра спекулятивной логики, так это в том, что нет причин её изгонять. Дело не столько в том, что это дьявол, скрывающийся в деталях, сколько в том, что это скорее его адвокат, прикрывающий принципиальную тупость 95% населения: никто не есть фон Нейман в программировании, кроме пары нёрдов в свитерах с оленями, так что будет очень тяжело объяснить, что теперь надо программировать многопоточно, а потому 99% из вас будут расстреляны за ненадобностью, а остальные 1% клонированы, иначе нас ждёт финансовый коллапс.
То есть атака не на запись, а на чтение.
Если вы не можете спекулятивно положить данные в кеш (а при описанном выше подходе они будут лежать в буфере, из которого читать нельзя кроме как для сброса буфера в кеш, но не в кеше), то вы и не можете их оттуда прочитать.
Так что проблема не в том что процессор читает данные из кеша. Проблема именно в том, что он их туда спекулятивно кладет. Те данные, которые при "прямом" выполнении туда бы никогда не попали.
Все ускорение процессоров за последнее время (от Intel по-крайней мере) висит на спекулятивном выполнении. Убрать это и мы вернемся во времена Pentium 2-3.
Так и не надо убирать спекулятивное выполнение, надо убрать спекулятивное кеширование.
Естественно, какое-то замедление будет — но только в том случае, когда у вас вычисление условия для ветвления длиннее чтения из памяти.
А буффер в данном случае как защищен? Буфер жеж будет либо L1 либо L2
А буффер в данном случае как защищен? Буфер жеж будет либо L1 либо L2
Буфер — тут это не кеш, а специальная подсистема, в которой хранится ровно один кеш лайн перед сбросом в кеш в случае спекулятивного исполнения.
Если происходит чтение из памяти, не находящейся в кеше, вне спекулятивного исполнения — кешлайн читается в кеш (то есть ничего не меняется), если во время спекулятивного исполнения — кешлайн читается в буфер и сбрасывается из буфера в кеш после того, как операция, из-за которой он туда прилетел, стала неспекулятивной.
Читать из буфера нельзя, в принципе.
Амд быстрее/безопасней?
Авиры смогут как-то бороться с пооблемой?
Авиры смогут как-то бороться с пооблемой?
АМД безопасней в некотором плане. Но спектру все подвержены в том или ином виде процы связанные со спекулянтством.
Антивири к этому не имеют отношения. Фактически это прямой доступ к ring0 из browser javascript. Решается латанием дыр (по сути запретом выполнения определенных вещей, например в firefox уменьшили разрешение gettime() колов) в компиляторах и интерпретаторах, оси и др.
Антивири к этому не имеют отношения. Фактически это прямой доступ к ring0 из browser javascript. Решается латанием дыр (по сути запретом выполнения определенных вещей, например в firefox уменьшили разрешение gettime() колов) в компиляторах и интерпретаторах, оси и др.
Там не в прямом чтении дело. А в том что в процессе подбора байт проверка происходит либо быстро либо медленно, в зависимости от того, какой байт подошел. Если тот же байт то отказ приходит быстрее нежели не тот.
У меня на Phnom II X4 не такая уж и большая разница в прокачке DDR2 и L3, даже сам латенси больше выглядит.
Да фиг с ним — пусть попадает, если после этого не доступно «третьей стороне».
Процесс-владелец данных <-> Процессор.
Процесс-владелец данных <-> Процессор.
Правильно ли понимаю — спекулятивные вычисления нужны, чтобы исправить косяки неэволюционирующих языков программирования, не расчитанных на параллельные вычисления? Иными словами — железные хаки?
Нет. Логика проще — если есть 3 варианта ветвления кода, исполнить сразу 3, не дожидаясь решения. Когда решение будет принято — уже все 3 ветки будут исполнены, остается выбрать только одну из веток, согласно принятому решения.
Например: вы еще не пришли домой и не решили, что хотите на ужин, а подруга уже и пиво в холодильник поставила, и борщ сварила, и оладок с вареньем напекла, и горничной нарядилась — вам осталось только выбрать «чего изволите» :)
Например: вы еще не пришли домой и не решили, что хотите на ужин, а подруга уже и пиво в холодильник поставила, и борщ сварила, и оладок с вареньем напекла, и горничной нарядилась — вам осталось только выбрать «чего изволите» :)
И уволить горничную с борщом
А можете продолжить пример, объяснив в таком виде суть этих атак?
… «горничной» сказали, что закрыв дверь — все в безопастности и никто не зайдет. А «тот парень» открыл дверь, зашел и сожрал борщ, выпил пиво и что-то непотребное сделал с «горничной». В лучшем случае — останетесь голодным.
«тот парень» подсмотрев, что ваша девушка пошла в магазин и взяла пиво «гинесс», прикупила одежку горничной, купила свеклу, варенье и муку… сделал соответствующие выводы… что вам это нравиться
и в следующий раз выгнав девушку, сам переоделся горничной, сварил борщ, пожарил оладьи и на видное место поставил пиво, что бы когда вы пришли домой, обрадовавшись пивку не сразу сообразили, что горничная-то не та…
короче по поведению вашей девушки, кто-то может подобрать ключ к вам -)
и в следующий раз выгнав девушку, сам переоделся горничной, сварил борщ, пожарил оладьи и на видное место поставил пиво, что бы когда вы пришли домой, обрадовавшись пивку не сразу сообразили, что горничная-то не та…
короче по поведению вашей девушки, кто-то может подобрать ключ к вам -)
Ну а дальше, узнав что вы сегодня будете борщ, девушка выбрасывает оладушки в мусор. И там их находит (и ворует) злобный хакер.
понимаете вы, разумеется, неправильно. И проблема (неэффективное использование кеша инструкций при ветвлениях), и её решение (спекулятивное выполнение) — на уровне железа, двумя уровнями ниже любых яп. Параллельно или нет, но совсем без ветвлений ни одну практическую задачу не решить.
Ну, всё равно спекулятивное выполнение похоже на грязный хак, а не на решение. Выполнять кучу инструкций, чтобы их выбрасывать? Неужели нельзя иначе?
Ну, всё равно не ясно — чем ужасны условия? Неужели на вычисление условия нужно больше времени, чем на выполнение целой кучи инструкций?
Разъясние плиз на указанном примере принцип. Как правило условия нужны, ежели решение принимаеся во время выполнения, а знач и функции мы заранее не вычислим, ибо нужная инфа ещё не загружена.
if(x) {
get_file(a, b, c);
big_func(a, b, c); // Processing one hour
else {
get_file(e, f, g);
another_big_func(e, f, g); // Processing one hour
}
// x, a, b, c, e, f, g -- are known in runtime
Разъясние плиз на указанном примере принцип. Как правило условия нужны, ежели решение принимаеся во время выполнения, а знач и функции мы заранее не вычислим, ибо нужная инфа ещё не загружена.
Проблема в наличие конвейера в современных процессорах. Обработка команд, если так можно выразиться, начинается сильно заранее их непосредственного «выполнения». Поэтому пока не получен результат if-а (пусть даже самого простого вычислительно), конвейеру пришлось бы простаивать без дела. А потом, когда исход условия прояснился бы, пришлось «раскочегаривать» конвейер заново, и ждать, пока нужная ветвь пройдёт все его стадии. Как я понимаю, в нынешних процессорах длина конвейера захватывает десятки команд.
А так процессор может спекулятивно предположить результат if-а и заняться подготовкой на конвейере какой-либо ветви впрок. Поэтому к моменту разрешения условия всё уже готово без простоя.
И ещё замечу, что дело не сложности или простоте условия, а в том, что его значение не может быть вычислено ранее определённого момента.
А так процессор может спекулятивно предположить результат if-а и заняться подготовкой на конвейере какой-либо ветви впрок. Поэтому к моменту разрешения условия всё уже готово без простоя.
И ещё замечу, что дело не сложности или простоте условия, а в том, что его значение не может быть вычислено ранее определённого момента.
Как бы без реальных вычислений? Ну, например, конвертация машинных инструкций в низкоуровневые инструкции микропроцессора и прочее? Ибо чтобы реально выполнить функции из примера нам нужна инфа, получаемая лишь после проверки условия! А раз нету реальной инфы — знач нету и угрозы?
И ещё, не является ли неравномерная нагрузка процессора — проблемой «линейных» языков программирования? И как её решить без спекуляции?
Решение ну явно некрасивое ;-)
И ещё, не является ли неравномерная нагрузка процессора — проблемой «линейных» языков программирования? И как её решить без спекуляции?
Решение ну явно некрасивое ;-)
Ибо чтобы реально выполнить функции из примера нам нужна инфа, получаемая лишь после проверки условия! А раз нету реальной инфы — знач нету и угрозы?
А на это есть алгоритмы пресказания ветвления — один из самых охраняемых «секретов фирмы». В последних процессорах пытаются приделать для этого нейронные сети, как раз потому что разное ПО с разным поведением сильно влияет на «утилизацию вычислительных ресурсов» и штрафы за ошибки предсказания.
Дабы уменьшить штрафы — и загружают все что может пригодится «на всякий случай»
рассмотрим простые инструкции на современных процах, например умножение вещ. чисел одинарной точности, для skylake: latency = 4, CPI = 0.5. Это значит, что за один такт процессор может засунуть в конвеер две инструкции умножения, но результат выполнения каждой из них будет доступен только через четыре такта. Теперь предположим, что мы между этими двумя операциями вставим условный переход, что-то типа:
В общем случае нам понадобится дождаться вычисления результата a (4 такта), посчитать условие (1-2 такта), и если мы не уходим в холодную ветку можно просто считать дальше, но с проверкой 7 тактов вместо 1.
А если выполнять спекулятивно — одновременно считается x и перепроверяется, что холодную ветку выполнять на самом деле не надо. И там либо всё ок и к моменту перепроверки уже несколько тактов насчитано (а сама проверка словно ничего и не стоила), либо насчитано несколько тактов вхолостую и надо прыгать в холодную ветку. Уязвимости как раз и используют результат этих холостых вычислений
п.с. на истину в последней инстанции не претендую, если где не прав — поправляйте
float a = b * c;
if (a > d) // допустим, это холодная ветка
return 0;
float x = y * z;
// Считаем дальше...
В общем случае нам понадобится дождаться вычисления результата a (4 такта), посчитать условие (1-2 такта), и если мы не уходим в холодную ветку можно просто считать дальше, но с проверкой 7 тактов вместо 1.
А если выполнять спекулятивно — одновременно считается x и перепроверяется, что холодную ветку выполнять на самом деле не надо. И там либо всё ок и к моменту перепроверки уже несколько тактов насчитано (а сама проверка словно ничего и не стоила), либо насчитано несколько тактов вхолостую и надо прыгать в холодную ветку. Уязвимости как раз и используют результат этих холостых вычислений
п.с. на истину в последней инстанции не претендую, если где не прав — поправляйте
Спасибо! Но вы привели как раз параллелизуемый пример — a и x можно считать независимо. В моём примере, вычисления не прараллелизуемы — файлы загружены после проверки — ну, например, x нужно чтобы решиь, какие файлы загружать. И функции можно вызвать лишь после проверки. Но и если бы вся инфа была загружена заранее — выполнение функции (по условию) — час, выполняя лишнюю функцию, проц бы выполнил безумно много лишней работы ;-)
В общем на низком уровне — умножение и прочее — всё хорошо, а на высоком уровне? Ежели у вас b, с, y и z — матрицы 1000 x 1000, или вызовы функции, выполняющейся часы?
Хм, а раньше early exit как раз и был призван избавить мир лишних вычислений! А щаз, получается, все компилеры наплевали на порядок инструкций.
В общем на низком уровне — умножение и прочее — всё хорошо, а на высоком уровне? Ежели у вас b, с, y и z — матрицы 1000 x 1000, или вызовы функции, выполняющейся часы?
Хм, а раньше early exit как раз и был призван избавить мир лишних вычислений! А щаз, получается, все компилеры наплевали на порядок инструкций.
На лицо несоответствие модели ЯП — железу. Хорошо, ежели программа выполняется именно так, как она написана. Не правильнее было бы явно указывать, какие куски программы можно выполнять параллельно, а какие нельзя?
Есть и для этого инструментарий давно как и на уровне оптимизации в компиляторе, так и на уровне языков/библиотек.
Так процессору все равно заняться нечем — данных нет, кода нет. блоки вычисления и конвейры стоят пустые. Почему бы их не занять чем-то, что в будущем может окупиться? Так сказать «инвестиции свободных ресурсов в возможное светлое будущее»
Но и если бы вся инфа была загружена заранее — выполнение функции (по условию) — час, выполняя лишнюю функцию, проц бы выполнил безумно много лишней работы ;-)
Так процессору все равно заняться нечем — данных нет, кода нет. блоки вычисления и конвейры стоят пустые. Почему бы их не занять чем-то, что в будущем может окупиться? Так сказать «инвестиции свободных ресурсов в возможное светлое будущее»
UFO just landed and posted this here
UFO just landed and posted this here
По виртуальным машинам непонятно. Если XEN выделяет целое ядро ВМ и только ей, то у нее нет возможности пробраться в другие ВМ или в корневую ОС.
Упсъ… а вот тут и проблема. У машины как таковой нет, а у процессора есть. Процессор просто помещает кусок памяти из процесса одной ВМ в кеш который общий то для всех, а в процесс другой ВМ эток кусок памяти отбражается.
Что-то я даже и не догадался, что у ядер общий кеш.
Да, свой «собственный» кэш у ядра только 1го уровня (L1).
L2 в большинстве случаев, а L3 вообще всегда делятся с другими ядрами процессора и изоляции данных обеспечить не могут.
L2 в большинстве случаев, а L3 вообще всегда делятся с другими ядрами процессора и изоляции данных обеспечить не могут.
У меня Athlon ii X3 вообще без L3 кэша. Я застрахован от этих атак?
От Meltdown — точно. От Spectre — c высокой вероятностью.
Правда кэш тут не причем. Просто Meltdown уязвимости вообще в процессорах AMD нет за счет отличающейся архитектуры. А Spectre сложнее реализовать.
Структура кэш же важна при делении процессора «с соседями» — если к началу ветки вернуться, обсуждали работу на серверах и облачных вычислениях. Когда один физический процессор делится между несколькими разными клиентам разными системами виртуализации и один из клиентов может с помощью этих уязвимостей пытаться «выуживать» информацию из работающего софта у «соседей».
Правда кэш тут не причем. Просто Meltdown уязвимости вообще в процессорах AMD нет за счет отличающейся архитектуры. А Spectre сложнее реализовать.
Структура кэш же важна при делении процессора «с соседями» — если к началу ветки вернуться, обсуждали работу на серверах и облачных вычислениях. Когда один физический процессор делится между несколькими разными клиентам разными системами виртуализации и один из клиентов может с помощью этих уязвимостей пытаться «выуживать» информацию из работающего софта у «соседей».
Не нужно никакого нового процессора.
Достаточно простой, очевидный и безусловно надежный способ уже описан в патентной заявке.
Пока сложно сказать у кого будет патентный приоритет, но разработчики Эльбруса в курсе.
Поэтому надеюсь что приоритет будет за ними.
Достаточно простой, очевидный и безусловно надежный способ уже описан в патентной заявке.
Пока сложно сказать у кого будет патентный приоритет, но разработчики Эльбруса в курсе.
Поэтому надеюсь что приоритет будет за ними.
Можно отказаться от out-of-order, и вообще от суперскаларности, а для закрузки конвеера использовать гипертрединг с большим количество нитей.
Еще можно хостить не нативные приложения, а байткод, котовый верифицировать на экслуотацию известных уязвимостей.
Еще можно хостить не нативные приложения, а байткод, котовый верифицировать на экслуотацию известных уязвимостей.
Еще можно хостить не нативные приложения, а байткод, котовый верифицировать на экслуотацию известных уязвимостей.
Это скрестить сигнатурный анализатор с JIT-компилятором? Так МС вас опередила — на уровне компилятора с 2003 года нельзя дергать системные функции без критериев безопастности (явного размера данных), в .Net встроены декларативные механизмы безопастности, в для нативных приложений используются манифесты. Это решило часть проблем. Что делать с остальным — пока не очень понятно.
UFO just landed and posted this here
Мне кажется, что x86 это навсегда! Уж насколько Itanium был лучше, и то умер.
Насколько я понимаю, многозадачность современных системах реализована на уровне процессора. Т.е. в процессор уже заложено разграничение между процессами на доступ к ресурсам и т.д. В чём проблема подписывать данные в кэше идентификатором процесса? Процесс что-то вычислял, получал данные из своей области памяти и часть данных отпечаталась в кэш. Потом пришёл другой процесс со своей памятью и своими данными — зачем вообще процессор тратит время на поиск в области кеша, в которую этот новый процесс ничего не писал? «Ну а что, а вдруг?» Что стоит изолировать данные в кеше между процессами? Так и кеш будет работать быстрее — не потратит время на поиск данных там, где их нет и быть не может, и безопасность будет выше.
Я слабо представляю, как работают современные процессоры, но неужели нельзя вместо «не читать лишние данные» и «очищать кэш после каждой операции» пойти немного другим путём — «очищать в кэше только те данные, которые не должны были туда попасть»? Можно даже какое-то микроядро прикрутить, которое только и занимается тем, что чистить кэш от «некорректных» данных. Процессор же на каком-то этапе отбрасывает результаты вычислений. Пусть где-нить записывает что-то типа «я тут немного погорячился, почисти тут и тут».
Да, производительность немного упадёт, но не нужно будет изобретать «процессор совершенно нового типа».
Или у меня искажённые представления, и программы постоянно лезут в недоступные области памяти, «разгоняя» друг друга за счёт кэширования?
Да, производительность немного упадёт, но не нужно будет изобретать «процессор совершенно нового типа».
Или у меня искажённые представления, и программы постоянно лезут в недоступные области памяти, «разгоняя» друг друга за счёт кэширования?
Я слабо представляю, как работают современные процессоры, но неужели нельзя вместо «не читать лишние данные» и «очищать кэш после каждой операции» пойти немного другим путём — «очищать в кэше только те данные, которые не должны были туда попасть»?
Нюанс в том, как именно организована память и ее адресация. Физическая адресация. Кеш вычитывает данные не побайтово, а целыми кусками/страницами.
Такая логика имеет смысл по нескольким причинам причинам:
- исполнимый код расположен одним непрерывным куском в памяти,
- обрабатываемые данные с большой степенью вероятности расположены последовательно
- сменить физическую адресацию памяти занятие не дешевое само по себе (на планках памяти DDR4 CAS Latencies 14- 20 t, DDR3 CL9-CL11 t )
Если тонким слоем «размазать» данные по памяти — производительность сильно упадет.
«очищать в кэше только те данные, которые не должны были туда попасть»
По дизайну именно так и задумано «не должно попасть» — все нарезано на странички, каждая со своими пометками, все помещено в какой-то контекст, свои таблицы трансляции и т.д.
А по факту — весьма странный «баг дизайна»
То есть архитектура процессора не подверженного Spectre и Meltdown ещё не разработана? А как же тогда заявление про Ice Lake на Wiki?
It is expected that Ice Lake will have in-silicon mitigations for the Meltdown and Spectre hardware vulnerabilities
UFO just landed and posted this here
Sign up to leave a comment.
Для устранения Spectre и Meltdown, возможно, придётся создать процессор совершенно нового типа