Правда ли, что Meltdown и Spectre слишком фундаментальны для того, чтобы выпустить для них патч? Один эксперт считает именно так.
Как определить и исправить такие ошибки, как Spectre и Meltdown? Этот вопрос был самой горячей темой среди энтузиастов микропроцессоров в этом году. На одном из главных академических событий индустрии, конференции Hot Chips, эксперты согласились, что окончательное решение проблемы может потребовать – да, ещё больше разговоров.
На встрече в Купертино профессора Марка Хилла из Висконсинского университета попросили порассуждать о последствиях атак по сторонним каналам или атак на спекулятивное выполнение команд у современных процессоров, которые изготавливают компании ARM, Intel, и другие. Он перечислил такие решения, как специализированные ядра, сброс кэша при смене контекста и бизнес-идеи вроде увеличения платы за эксклюзивные виртуальные машины.
Но реальным ответом, как сказал он и другие выступающие, будет улучшение сотрудничества разработчиков софта и оборудования – и, возможно, полная переработка сегодняшних микропроцессоров.
Как целая индустрия чипов получила удар исподтишка
Информацию о Meltdown и Spectre неожиданно раскрыли в конце 2017 года, незадолго до того, как эти уязвимости должны были формально, по-тихому раскрыть на CES в январе 2018 года. Их обнаружила команда поиска уязвимостей нулевого дня из Google, Google Project Zero. Атаки пользуются такой возможностью современных микропроцессоров, как спекулятивное выполнение команд, когда процессор, по сути, «угадывает», какую ветвь инструкций нужно выполнять. Пол Тёрнер, инженер и руководитель основного костяка разработчиков Google, присутствовавший на конференции, рассказал, что никто из членов Project Zero не предупредил об открытии своих коллег; они узнали об этом вместе со всеми.
В течение 20 лет разработчики микропроцессоров считали, что неверная «догадка» просто отбрасывает данные, не создавая рисков для безопасности. Они ошибались, что и доказали атаки по сторонним каналам.
С практической точки зрения это означает, что одна вкладка браузера может просматривать содержимое другой, или одна виртуальная машина может заглядывать в другую. Это побудило производителей процессоров, в частности, Intel, совместно с Microsoft, выпустить исправляющие положение программы, или заплатки. Это наиболее эффективный способ защиты вашего ПК от Spectre, Meltdown, или любых других последующих атак, например, Foreshadow.
К счастью, проверка такой информации требует времени — в некоторых случаях, довольно много. NetSpectre, способный удалённо воспользоваться уязвимостью Spectre, можно использовать для взлома облачного сервиса или удалённой машины. С одной стороны, данные могут утекать не быстрее 1 бита в минуту, как говорит Джон Хеннесси, знаменитый разработчик микропроцессоров, член совета директоров Alphabet. С другой стороны, среднее время между взломом сервера и обнаружением этого факта составляет 100 дней, добавил он – что может дать уязвимости время поработать.
Процессоры Intel следующего поколения, вероятно, не смогут полностью исправить первый вариант Spectre, как сказал Хеннесси, несмотря на то, что разработка мер по устранению этого недостатка начнётся этой осенью, в проекте нового процессора Xeon, Cascade Lake.
Патчить или переделывать?
ARM, Intel, AMD и другие гиганты индустрии могут исправить проблему, приняв необходимые меры довольно быстро, добавил Хилл. Но для полного устранения проблемы могут потребоваться более фундаментальные изменения, сказал он.
«В долгосрочной перспективе встаёт вопрос, как правильно описать этот процесс, чтобы потенциально полностью устранить проблему, — сказал Хилл. – Или нам придётся относиться к ней как к преступлениям, которые мы только пытаемся сдерживать».
Спекулятивное выполнение команд – одна из причин, по которым микропроцессор, а следовательно, и ПК, достигли рекордных продаж, отметил участник конференции Джон Мастерс, архитектор компьютерных систем из Red Hat. Но такое выполнение расценивали как «волшебный чёрный ящик», сказал он, без соответствующих вопросов со стороны пользователей или клиентов. Этот джинн уже тоже выпущен из бутылки. Устраните спекулятивное выполнение – и это замедлит работу процессора в двадцать раз, сказал Хилл.
Среди предложенных Хиллом решений – изолирование элемента предсказания ветвления, добавление рандомизации, реализация улучшенной защиты оборудования. Одним решением может быть добавление более медленных и безопасных режимов исполнения; другим – разделение механизма исполнения команд между «быстрыми ядрами» и «безопасными ядрами». Он также предложил бизнес-решения, среди которых увеличение стоимости виртуальных машин – вместо разделения ресурсов оборудования между несколькими виртуалками, облачный провайдер мог бы обеспечивать эксклюзивный доступ. Наконец, Хилл отметил, что атаки вроде Spectre могут также привести к возрождению ускорителей: логики фиксированного назначения, оптимизированной для одной задачи, и не полагающейся на спекуляции.
Но фундаментальным решением этой проблемы была бы полная переработка архитектуры, сказал Хилл. Архитектура компьютера определяет, как процессор выполняет набор инструкций программы при помощи арифметических устройств, устройств для работы с плавающей запятой, и прочих. Сегодняшние чипы были разработаны для удовлетворения требований оригинальной модели. Но если базовая архитектурная модель имеет фундаментальный недостаток, сказал он, возможно, пришло время для новой модели. Иначе говоря, Spectre и Meltdown – это не баги, а недостатки в дизайне современных чипов, из-за чего может потребоваться новая модель.
В итоге участники конференции сошлись на простых истинах, вроде той, что оборудование необходимо разрабатывать, помня о программном обеспечении, и наоборот – и обе стороны должны усиливать безопасность. «Часто бывает так, что разработчики оборудования создают какую-то прекрасную машину, и мы прекращаем говорить о ней, или разработчики ПО говорят – ну, это же железо, мне-то что до него. Пора это прекращать», — сказал Мастерс.
Комментарии (101)
serg_deep
08.09.2018 12:17+6Всегда так кажется что проще взять и сделать всё по новому, только стоить это будет немерено.
krab90
09.09.2018 06:02Так спецслужбы США проинвестируют разработку, с внедрением на сей раз более хитроумных дыр. С другой стороны закрадывается мысль что уязвимости были оставлены специально, возможно в то время развития процессоров выполнять дополнительные проверки в спекулятивном выполнении сводило на нет все полученное ускорение.
algotrader2013
08.09.2018 13:40+2Прошу прощения за нубский вопрос, но есть ли хоть какая-то реальная выгода в закрытии уязвимостей (и принятия пониженной производительности) для владельцев ПК и железных серверов, или практическую ценность уязвимости имеют только в случае виртуализации и размещения машин разных владельцев на одном хосте?
vasimv
08.09.2018 15:54Если на компе выполняется браузер, то есть «выгода» (точнее, отсутствие убытков из-за возможных взломов), так как без javascript/html5 сейчас — никуда не сходишь, практически.
Massacre
08.09.2018 20:23Можно белый список для выполнения JS (правда, остаётся проблема в случае взлома этих сайтов)…
algotrader2013
08.09.2018 20:47+1При скорости 1 бит в минуту сложно представить, как можно нанести ущерб. Интересно, если, к примеру, человек выключает компьютер каждую ночь, и всегда держит открытой вкладку браузера со зловредом, то можно возобновлять начатую вчера атаку, или, надо провести полную атаку за одну сессию? Если второй вариант, то как-то это сложно выходит что-то существенное сделать.
PS: Пока у меня складывается впечатление, что все будут страдать ради решения проблемы всяких азуров и авээсов (причем, исключительно их проблемы).dimonoid
08.09.2018 23:52Интересно, а данные в оперативной памяти всегда хранятся в одних и тех же адресах? Есть ли фрагментация? Может просто достаточно время от времени сдвигать все данные не случайное растоение, тогда и проблем не будет.
Lofer
09.09.2018 00:10Только сразу перестанет работать кеширование, придется пересчитывать таблицы трансляции адресов, пересчитать виртуальную память и указатели…
Попутно придется найти того, кто будет память «тусовать» и учесть, что все это будет занимать шины памяти перегонкой десятков гигабайт в секунду, выжирая электричество и выделяя дофига тепла…dimonoid
09.09.2018 00:15Ок, этим можно заниматься раз в сутки специально для серверов, в ночное время. На более коротком промежутке времени уязвимость не актуальна, тк не известен сам адрес пароля, или на что идет атака.
equand
09.09.2018 00:481 бит в минуту это для netspectre, класс атак по сети!
В локальном варианте все намного хуже. Так плохо, что специалисты не знают о том, как защититься.
0xd34df00d
10.09.2018 02:40Это вполне может решаться на уровне браузера огрублением таймеров и прочими рандомизациями из этой серии.
napa3um
10.09.2018 21:30И получится то же самое замедление производительности, что и при решении на уровне патча микрокода (а так же всё равно решение в браузере не будет полным, «временнОй шум» аппаратуры всё равно будет «протекать» в последовательность выполнения фрагментов приложения). Ведь рандомизировать и замедлить придётся не просто таймеры, а абсолютно ВСЁ, ведь сравнивать скорости различных вычислительных процессов можно и вовсе без таймера (скажем, сравнить, сколько выполнится CSS-анимаций за время отрисовки какого-нибудь хитрого дива, или ещё что-то такое же косвенное).
0xd34df00d
10.09.2018 22:48Только в этом случае оно получится только в рамках браузера, а не ещё и компилятора, IDE и числодробилки вдовесок.
napa3um
10.09.2018 23:25Для разработчика не проблема поработать и на уязвимой машине с нормальной скоростью (и с соблюдением гигиены), а у конечного пользователя кроме браузера уже и не осталось ничего :).
nidalee
09.09.2018 07:11Для домашних ПК — нет. Через браузер работает слишком медленно, а если вы все подряд на ПК ставите, то есть десятки более простых способов украсть с вашего ПК информацию.
Lofer
08.09.2018 14:07-5Такое впечатление, что это не «недостаток дизайна», а «фича дизайна». Сложно поверить, что куча людей в разных конторах и с опытом проектирования процессоров, кучей эмуляторов в железе просто «не увидела» такой побочный эффект. Да и АМД своевременно подсуетились с шифрацией памяти, Китай со своими процессорами и своей архитектурой — это тоже понятно.
Когда читал мануалы про 486 процессор в голове был вопрос «спекулятивное исполнение — понятно. Результаты отбрасываются — понятно. Но как они отбрасываются? Не проходит же микрокод и не обнуляет кеши и результаты исполнений...»
Такое впечатление, что каких-то ребят поймали «на горячем», и что бы такой «баг проектирования» не похоронили в каких гостайнах — плеснули в вентилятор, все что можно.
Можно сколько угодно зубоскалить про ФСБ-ФАПСИ & Co с их компьютерами «на лампах», процессорами Байкалам — но какие-то параноики из этих контор все таки оказались правы. Не сильно будет удивительно, если они «были в доле» — знать и молчать, делая вид что не знают…
По факту такой «баг дизайна» означает, что весомая часть безопастности в ИТ — одна большая подстава в планетарном масштабе, в пользу ребят «из АНБ». Прецеденты таких масштабов были и уже не один раз — ослабление криптомеханизмов GSM, слабые генераторы случайных чисел,Windows Bitlocker & EFS и т.д.
Нормальная стратегия: если не можем победить крипто — давайте сделаем так, что бы тупо читать ключи из памяти, а эти лохи путь думают что «дыра в безопастности» прикрыта.DoctorMoriarty
08.09.2018 14:25+6Конспирология на марше, как и всегда в последнее время. Есть замечательная поговорка — «что знают двое, знает и свинья». Невозможно объединить в заговоре молчания тысячи разработчиков и службистов, тем более — не только в одной стране, но и одновременно многих из геополитически враждебных стран так, чтобы они "были в доле". Не-воз-мож-но.
Lofer
08.09.2018 14:54-3Есть замечательная поговорка — «что знают двое, знает и свинья». Невозможно объединить в заговоре молчания тысячи разработчиков и службистов,
Есть прецеденты, когда знают «много поросят» — Энигма во вторую мировую,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, технические детали которых держатся в тайне. Хм… вам это ничего не напоминает?equand
08.09.2018 15:28+2Чаще всего много поросят молчат, потому что если расскажешь обывателю — никто не поверит, расскажешь знающим — заткнут (либо и так всем известно, либо молчи, не то прибьют).
Так и было до Сноудена, пока не было конфликта, никто не верил. Даже был фильм по мотивам в 1998 (Враг государства).
skorokhod
09.09.2018 00:51Я просто напомню кусочек статьи:
Пол Тёрнер, инженер и руководитель основного костяка разработчиков Google, присутствовавший на конференции, рассказал, что никто из членов Project Zero не предупредил об открытии своих коллег; они узнали об этом вместе со всеми.
Druu
08.09.2018 15:27По факту такой «баг дизайна» означает, что весомая часть безопастности в ИТ — одна большая подстава в планетарном масштабе, в пользу ребят «из АНБ».
Пока что обсуждаемые уязвимости существуют только на бумаге. На данный момент нету даже теоретической возможности их использования на практике, так что не стоит волноваться, с безопасностью все ок и никакой подставы не было.
equand
08.09.2018 15:29xlab.tencent.com/special/spectre/spectre_check.html
Проверьтесь.Druu
08.09.2018 15:58Касперский сайт заблокировал.
В любом случае, речь не о возможности совершить атаку как таковую. Речь о том, что пока что нету возможности (на сколько я знаю, по крайней мере) использовать эту атаку чтобы реально украсть какие-то полезные данные.equand
08.09.2018 16:15Больше всего в опасности провайдеры облаков. Ибо запущенный ВПС может воровать данные со скоростью 1 байт в минуту (на данный момент, т.к. дыра кардинальная в архитектуре, возможно в будущем и более быстрый взлом). Что равно примерно 500 килобайт в год. Однако если знать откуда тырить, можно взять доступ рута хоста или чего похлеще.
Druu
08.09.2018 18:09Что равно примерно 500 килобайт в год. Однако если знать откуда тырить, можно взять доступ рута хоста или чего похлеще.
А разве можно указать откуда тырить? Насколько я понимаю, это неконтролируемый процесс. То есть вы получите свои 500кб данных в год, но даже если все это время память была статична, то вероятность того, что это будут какие-то полезные данные… ну крайне мала. Если же учесть, что данные в памяти все таки регулярно обновляются, то вы скорее всего получите куски непонять из чего и как собранные.
Разве не так?Pyhesty
08.09.2018 18:29пароли в кэше процессора хранятся уже декодированными, таким образом, если вы знаете хотя бы немного структуру того против чего проводите атаку, то можете довольно точно получить доступ к декодированному паролю и всё сложное шифрование и криптоустойчивость идёт лесом…
Druu
08.09.2018 20:38таким образом, если вы знаете хотя бы немного структуру того против чего проводите атаку, то можете довольно точно получить доступ к декодированному паролю
Каким образом-то? Вы же просто случайные байты памяти читаете, которые еще и меняются.
equand
08.09.2018 18:33Spectre
Согласно этому, большинство Спектральных атак еще вообще не залатаны.
500байт данных только через один метод атак = Netspectre, которому не нужен доступ к запуску на пк.
Для других систем скорость в принципе CPU Speed / byte, что достаточно для быстрого взлома (читай моментального).
Alcpp
09.09.2018 15:31Проверил.
Пишет:
$ Your browser is VULNERABLE to Spectre
$ Please update your browser immediately
Последняя версия Хрома.sumanai
09.09.2018 21:34+1У меня наоборот, не подвержен уязвимости, FF на ОС, у которой отключены все эти патчи. В общем фигня всё это, что через яваскрипт.
Vilgelm
09.09.2018 21:55Vivaldi последней версии, написал что неподвержен. Хром последней версии, написал что подвержен.
Mad__Max
10.09.2018 03:32Забавно что старый хром, наоборот пишет НЕ подвержен. И старый (ESR) Лис тоже.
Или это из-за того, что процессор AMD? Хотя Spectre вроде и на AMD можно реализовать в отличии от Meltdown.michael_vostrikov
10.09.2018 06:01Там в файле 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(); }
wikipro
08.09.2018 15:39Любопытно, а процессоры с архитектурой отличной от Интел — MILV Эльбрус-8C, например,
и ARM, подвержены Meltdown и Spectre? И если подвержены то насколько патчи замедляют их? Интеловские процессоры патчи замедляют насколько я понял на ~ 5%, а AMD в среднем на 0.5%-1%.chupasaurus
08.09.2018 15:49+1В Эльбрусе поддерживаются спекулятивные вычисления, так что Meltdown там вполне возможен, а вариации Spectre зависят от реализации защиты кешей/памяти.
Yo1
10.09.2018 23:12в эльбрусе вроде был некий защищенный режим, когда вместе с кодом некий таг процесса передавался. вполне возможно таг спасет…
stalinets
08.09.2018 16:21+1Устраните спекулятивное выполнение – и это замедлит работу процессора в двадцать раз, сказал Хилл.
Но ведь относительно свежие Intel Atom не подвержены этой атаке и при этом не работают в 20 раз медленнее аналогичных процессоров.huhen
08.09.2018 17:11+1Потому что уязвимость не в самом спекулятивном выполнении, а том, что это выполнение оставляет следы. На свежих атомах этих следов меньше либо их ещё не нашли.
michael_vostrikov
08.09.2018 18:37+1Основной след это ведь попадание в кэш? То есть достаточно либо не писать в кэш пока инструкция реально не выполнится, либо откатывать попадание в кэш, если произошел переход и сброс конвейера. Или нет? Ну то есть это конечно изменение архитектуры, но вряд ли кардинальное.
equand
08.09.2018 18:46И как Вы это представляете? stackoverflow.com/questions/4087280/approximate-cost-to-access-various-caches-and-main-memory
DRAM намного медленнее даже L3 кеша, не касаясь его скорости.
По сути надо избавляться от кешей вообще.michael_vostrikov
08.09.2018 19:00Зачем? Если инструкция реально выполнилась, то кэширование срабатывает и используется при выполнении следующих инструкций.
equand
08.09.2018 19:21А если следующая инструкция? А следующая? И т.д. и т.п.
Данные в кеше — надо очищать каждый раз после каждой операции — значит доступ к памяти нужен постоянно. Тут еще надо будет защитить этот самый доступ от похожих атак. А то можно таймить доступ и выяснять информацию.Druu
08.09.2018 20:51+1Данные в кеше — надо очищать каждый раз после каждой операции — значит доступ к памяти нужен постоянно.
Так речь не о том, чтобы защищать, а о том, чтобы в кеш не класть. Процессор спекулятивно выполняет операцию которая требует положить => читает память в специальный буфер размером в кеш-линию => к этому моменту инструкция, инициировавшая спекулятивное выполнение, уже выполнилась и можно посмотреть результат => если результат ок, то сбрасываем буфер в кеш
т.о. данные могут попасть в кеш в том и только том случае, если они и должны были туда попасть
equand
09.09.2018 00:44Тут проблема в том, что спекулятивно требуется операция чтения.
Есть например запрещенные данные в кеше. По идее если мы посылаем запрос на чтение этих данных с определенной командой и у нас нет доступа — должен прийти отказ. Спекулятивное выполнение производит расчет сразу параллельно пока идет проверка отказ или нет. Доступа нет, отказ приходит и система отвечает, что нет и данные спекулятивные отбрасывает.
Однако проблема в том, что проверка кеша для этого необходима. От скорости ответа и зависит тот байт или не тот.
То есть атака не на запись, а на чтение. Таким образом получается не только кеш, но и всю память прочесть (т.к. процессор спекулятивно-таки получает данные из памяти, до проверки стоит ли или нет)…
Сам факт проверки или какого-либо замедления этого процесса сразу привидет к замедлению быстродействия всей системы.
Иного выхода быть и не может.
Такого типа атаки применялись и ранее, чаще всего они есть в криптографии (тайминг и сайдченел).
Все ускорение процессоров за последнее время (от Intel по-крайней мере) висит на спекулятивном выполнении. Убрать это и мы вернемся во времена Pentium 2-3.michael_vostrikov
09.09.2018 06:42Как я понял из описания атак, проблема в том, что в кэш попадают элементы из памяти атакующего, которые зависят от значения по защищенному адресу. Атакующий потом их все читает и измеряет время доступа. Сами инструкции на чтение, но помещение в кэш это запись. То есть если не записывать в кэш прочитанные значения пока не произойдет реальное выполнение, то атакующий получит одно и то же время доступа для всех элементов, они попадут в кэш только во время этой проверки.
Deerenaros
09.09.2018 07:05Не, не PIII и уж тем более не PII. Кто-то похоже забыл, насколько это давно и медленно. И на самом деле, даже сказать, что на 10 лет назад — слукавить. Если убрать кэши разрушится почти-мгновенный доступ к памяти, но DDR-4 сегодня работает на четырёх гигагерцах с латентностью в сотню наносекунд. Это очень быстро по сравнению с PIII, у которых L3-кеш был примерно такого уровня. К тому же это освободит кристал от «лишней» сущности, что позволит развести дополнительные линии шины, хотя это и потребует значительной переделки. Всё это крайне сильно замедлит существенное число соверменного софта, особенно браузеры с вордами из-за активного использования разного рода виртуальных машин, которые без cpu-speed кэша не очень поворотливые, но тем не менее… Память в те времена была о-очень медленная, сейчас SSD накопители быстрее оперативной памяти того времени, так что дизайн кеша действительно может изменится, но прямо сейчас. Атака сейчас сложная к применению и только в лабораторных условиях, но со временем тулзы подрастут, а скрипты поумнеют, так что вполне возможно ожидать довольно скоро такой способ атаки от любого скрипт-кидди, а это уже проблема, и даже не только для AWS, но вообще для любого. И всё это может привести к полному пересмотру дизайна кэша.
Что до пересмотра спекулятивной логики, так это в том, что нет причин её изгонять. Дело не столько в том, что это дьявол, скрывающийся в деталях, сколько в том, что это скорее его адвокат, прикрывающий принципиальную тупость 95% населения: никто не есть фон Нейман в программировании, кроме пары нёрдов в свитерах с оленями, так что будет очень тяжело объяснить, что теперь надо программировать многопоточно, а потому 99% из вас будут расстреляны за ненадобностью, а остальные 1% клонированы, иначе нас ждёт финансовый коллапс.
Druu
09.09.2018 10:16То есть атака не на запись, а на чтение.
Если вы не можете спекулятивно положить данные в кеш (а при описанном выше подходе они будут лежать в буфере, из которого читать нельзя кроме как для сброса буфера в кеш, но не в кеше), то вы и не можете их оттуда прочитать.
Так что проблема не в том что процессор читает данные из кеша. Проблема именно в том, что он их туда спекулятивно кладет. Те данные, которые при "прямом" выполнении туда бы никогда не попали.
Все ускорение процессоров за последнее время (от Intel по-крайней мере) висит на спекулятивном выполнении. Убрать это и мы вернемся во времена Pentium 2-3.
Так и не надо убирать спекулятивное выполнение, надо убрать спекулятивное кеширование.
Естественно, какое-то замедление будет — но только в том случае, когда у вас вычисление условия для ветвления длиннее чтения из памяти.equand
09.09.2018 10:46А буффер в данном случае как защищен? Буфер жеж будет либо L1 либо L2
Druu
09.09.2018 11:10А буффер в данном случае как защищен? Буфер жеж будет либо L1 либо L2
Буфер — тут это не кеш, а специальная подсистема, в которой хранится ровно один кеш лайн перед сбросом в кеш в случае спекулятивного исполнения.
Если происходит чтение из памяти, не находящейся в кеше, вне спекулятивного исполнения — кешлайн читается в кеш (то есть ничего не меняется), если во время спекулятивного исполнения — кешлайн читается в буфер и сбрасывается из буфера в кеш после того, как операция, из-за которой он туда прилетел, стала неспекулятивной.
Читать из буфера нельзя, в принципе.Diordna
09.09.2018 21:42Амд быстрее/безопасней?
Авиры смогут как-то бороться с пооблемой?equand
10.09.2018 00:37АМД безопасней в некотором плане. Но спектру все подвержены в том или ином виде процы связанные со спекулянтством.
Антивири к этому не имеют отношения. Фактически это прямой доступ к ring0 из browser javascript. Решается латанием дыр (по сути запретом выполнения определенных вещей, например в firefox уменьшили разрешение gettime() колов) в компиляторах и интерпретаторах, оси и др.
equand
10.09.2018 00:34Там не в прямом чтении дело. А в том что в процессе подбора байт проверка происходит либо быстро либо медленно, в зависимости от того, какой байт подошел. Если тот же байт то отказ приходит быстрее нежели не тот.
Vitalley
09.09.2018 04:15У меня на Phnom II X4 не такая уж и большая разница в прокачке DDR2 и L3, даже сам латенси больше выглядит.
arielf
08.09.2018 20:41+1Правильно ли понимаю — спекулятивные вычисления нужны, чтобы исправить косяки неэволюционирующих языков программирования, не расчитанных на параллельные вычисления? Иными словами — железные хаки?
Lofer
08.09.2018 20:58+6Нет. Логика проще — если есть 3 варианта ветвления кода, исполнить сразу 3, не дожидаясь решения. Когда решение будет принято — уже все 3 ветки будут исполнены, остается выбрать только одну из веток, согласно принятому решения.
Например: вы еще не пришли домой и не решили, что хотите на ужин, а подруга уже и пиво в холодильник поставила, и борщ сварила, и оладок с вареньем напекла, и горничной нарядилась — вам осталось только выбрать «чего изволите» :)Fen1kz
08.09.2018 23:25А можете продолжить пример, объяснив в таком виде суть этих атак?
Lofer
08.09.2018 23:31… «горничной» сказали, что закрыв дверь — все в безопастности и никто не зайдет. А «тот парень» открыл дверь, зашел и сожрал борщ, выпил пиво и что-то непотребное сделал с «горничной». В лучшем случае — останетесь голодным.
Pyhesty
08.09.2018 23:43+2«тот парень» подсмотрев, что ваша девушка пошла в магазин и взяла пиво «гинесс», прикупила одежку горничной, купила свеклу, варенье и муку… сделал соответствующие выводы… что вам это нравиться
и в следующий раз выгнав девушку, сам переоделся горничной, сварил борщ, пожарил оладьи и на видное место поставил пиво, что бы когда вы пришли домой, обрадовавшись пивку не сразу сообразили, что горничная-то не та…
короче по поведению вашей девушки, кто-то может подобрать ключ к вам -)
Antervis
09.09.2018 03:22понимаете вы, разумеется, неправильно. И проблема (неэффективное использование кеша инструкций при ветвлениях), и её решение (спекулятивное выполнение) — на уровне железа, двумя уровнями ниже любых яп. Параллельно или нет, но совсем без ветвлений ни одну практическую задачу не решить.
arielf
09.09.2018 04:14Ну, всё равно спекулятивное выполнение похоже на грязный хак, а не на решение. Выполнять кучу инструкций, чтобы их выбрасывать? Неужели нельзя иначе?
Salabar
09.09.2018 10:40Можно выпилить из ЯП позднее связывание и заменить все интерфейсы на switch-case. Тогда VLIW-процессоры перестанут быть бесполезным мусором, а проблема скорости исполнения программ перестанет быть проблемой по сравнению со скоростью написания.
Antervis
09.09.2018 14:39во-первых, switch почти во всех случаях реализуется через условные переходы. Во-вторых, VLIW процессоры не застрахованы от алгоритмов с условными переходами в рантайме.
imanushin
10.09.2018 01:55+1по сравнению со скоростью написания
Вы забыли добавить слово «компиляторов». Java/.Net/JS программы ведь не надо переписывать.
arielf
09.09.2018 19:43Ну, всё равно не ясно — чем ужасны условия? Неужели на вычисление условия нужно больше времени, чем на выполнение целой кучи инструкций?
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
Разъясние плиз на указанном примере принцип. Как правило условия нужны, ежели решение принимаеся во время выполнения, а знач и функции мы заранее не вычислим, ибо нужная инфа ещё не загружена.Tyusha
09.09.2018 20:18+1Проблема в наличие конвейера в современных процессорах. Обработка команд, если так можно выразиться, начинается сильно заранее их непосредственного «выполнения». Поэтому пока не получен результат if-а (пусть даже самого простого вычислительно), конвейеру пришлось бы простаивать без дела. А потом, когда исход условия прояснился бы, пришлось «раскочегаривать» конвейер заново, и ждать, пока нужная ветвь пройдёт все его стадии. Как я понимаю, в нынешних процессорах длина конвейера захватывает десятки команд.
А так процессор может спекулятивно предположить результат if-а и заняться подготовкой на конвейере какой-либо ветви впрок. Поэтому к моменту разрешения условия всё уже готово без простоя.
И ещё замечу, что дело не сложности или простоте условия, а в том, что его значение не может быть вычислено ранее определённого момента.arielf
09.09.2018 21:47Как бы без реальных вычислений? Ну, например, конвертация машинных инструкций в низкоуровневые инструкции микропроцессора и прочее? Ибо чтобы реально выполнить функции из примера нам нужна инфа, получаемая лишь после проверки условия! А раз нету реальной инфы — знач нету и угрозы?
И ещё, не является ли неравномерная нагрузка процессора — проблемой «линейных» языков программирования? И как её решить без спекуляции?
Решение ну явно некрасивое ;-)Lofer
09.09.2018 23:24Ибо чтобы реально выполнить функции из примера нам нужна инфа, получаемая лишь после проверки условия! А раз нету реальной инфы — знач нету и угрозы?
А на это есть алгоритмы пресказания ветвления — один из самых охраняемых «секретов фирмы». В последних процессорах пытаются приделать для этого нейронные сети, как раз потому что разное ПО с разным поведением сильно влияет на «утилизацию вычислительных ресурсов» и штрафы за ошибки предсказания.
Дабы уменьшить штрафы — и загружают все что может пригодится «на всякий случай»
Antervis
10.09.2018 00:57+1рассмотрим простые инструкции на современных процах, например умножение вещ. чисел одинарной точности, для skylake: latency = 4, CPI = 0.5. Это значит, что за один такт процессор может засунуть в конвеер две инструкции умножения, но результат выполнения каждой из них будет доступен только через четыре такта. Теперь предположим, что мы между этими двумя операциями вставим условный переход, что-то типа:
float a = b * c; if (a > d) // допустим, это холодная ветка return 0; float x = y * z; // Считаем дальше...
В общем случае нам понадобится дождаться вычисления результата a (4 такта), посчитать условие (1-2 такта), и если мы не уходим в холодную ветку можно просто считать дальше, но с проверкой 7 тактов вместо 1.
А если выполнять спекулятивно — одновременно считается x и перепроверяется, что холодную ветку выполнять на самом деле не надо. И там либо всё ок и к моменту перепроверки уже несколько тактов насчитано (а сама проверка словно ничего и не стоила), либо насчитано несколько тактов вхолостую и надо прыгать в холодную ветку. Уязвимости как раз и используют результат этих холостых вычислений
п.с. на истину в последней инстанции не претендую, если где не прав — поправляйтеarielf
10.09.2018 01:54Спасибо! Но вы привели как раз параллелизуемый пример — a и x можно считать независимо. В моём примере, вычисления не прараллелизуемы — файлы загружены после проверки — ну, например, x нужно чтобы решиь, какие файлы загружать. И функции можно вызвать лишь после проверки. Но и если бы вся инфа была загружена заранее — выполнение функции (по условию) — час, выполняя лишнюю функцию, проц бы выполнил безумно много лишней работы ;-)
В общем на низком уровне — умножение и прочее — всё хорошо, а на высоком уровне? Ежели у вас b, с, y и z — матрицы 1000 x 1000, или вызовы функции, выполняющейся часы?
Хм, а раньше early exit как раз и был призван избавить мир лишних вычислений! А щаз, получается, все компилеры наплевали на порядок инструкций.
arielf
10.09.2018 02:01На лицо несоответствие модели ЯП — железу. Хорошо, ежели программа выполняется именно так, как она написана. Не правильнее было бы явно указывать, какие куски программы можно выполнять параллельно, а какие нельзя?
Lofer
10.09.2018 02:06Есть и для этого инструментарий давно как и на уровне оптимизации в компиляторе, так и на уровне языков/библиотек.
Но и если бы вся инфа была загружена заранее — выполнение функции (по условию) — час, выполняя лишнюю функцию, проц бы выполнил безумно много лишней работы ;-)
Так процессору все равно заняться нечем — данных нет, кода нет. блоки вычисления и конвейры стоят пустые. Почему бы их не занять чем-то, что в будущем может окупиться? Так сказать «инвестиции свободных ресурсов в возможное светлое будущее»
0xd34df00d
10.09.2018 03:07Те куски, о которых тут речь, куда мельче отдельных строк и даже инструкций программы (см. ?ops, конвертация во внутреннее RISC-представление, вот это всё).
Там, кстати, свои забавные баги бывают. ЕМНИП одно время одно из относительно недавних поколений процов считали, что, условно,
xor eax, eaxимеет зависимость по данным отeax, хотя где-то со второго пня процессоры умеют распознавать этот паттерн как зануление регистра и тупо мапятeaxна нулевой/обнулённый регистр.
0xd34df00d
10.09.2018 03:04+1На указанном примере это смысла действительно не имеет. Спекулятивное исполнение куда важнее для того, что называется tight loops.
Например, для большого ArrSize,
for (int i = 0; i < ArrSize; ++i) { // handle i if (!(i % 10)) // special handling for i = 10k }
Более того, вам даже внутри цикла условий не нужно, чтобы ощутить профит от спекулятивного исполнения: сам цикл — тоже условие, в конце концов (
if predicate goto loop). И вам не нужно дожидаться окончания текущей итерации цикла, если следующая итерация от текущей не зависит (умножение матриц там, всё такое, ага).
А для выбора того, какой файл читать, это всё нафиг не нужно, да.
vics001
08.09.2018 20:50По виртуальным машинам непонятно. Если XEN выделяет целое ядро ВМ и только ей, то у нее нет возможности пробраться в другие ВМ или в корневую ОС.
Lofer
08.09.2018 21:07Упсъ… а вот тут и проблема. У машины как таковой нет, а у процессора есть. Процессор просто помещает кусок памяти из процесса одной ВМ в кеш который общий то для всех, а в процесс другой ВМ эток кусок памяти отбражается.
vics001
08.09.2018 22:09Что-то я даже и не догадался, что у ядер общий кеш.
Mad__Max
08.09.2018 22:36Да, свой «собственный» кэш у ядра только 1го уровня (L1).
L2 в большинстве случаев, а L3 вообще всегда делятся с другими ядрами процессора и изоляции данных обеспечить не могут.masv
09.09.2018 22:36У меня Athlon ii X3 вообще без L3 кэша. Я застрахован от этих атак?
Mad__Max
10.09.2018 03:51От Meltdown — точно. От Spectre — c высокой вероятностью.
Правда кэш тут не причем. Просто Meltdown уязвимости вообще в процессорах AMD нет за счет отличающейся архитектуры. А Spectre сложнее реализовать.
Структура кэш же важна при делении процессора «с соседями» — если к началу ветки вернуться, обсуждали работу на серверах и облачных вычислениях. Когда один физический процессор делится между несколькими разными клиентам разными системами виртуализации и один из клиентов может с помощью этих уязвимостей пытаться «выуживать» информацию из работающего софта у «соседей».
yleo
09.09.2018 14:06-3Не нужно никакого нового процессора.
Достаточно простой, очевидный и безусловно надежный способ уже описан в патентной заявке.
Пока сложно сказать у кого будет патентный приоритет, но разработчики Эльбруса в курсе.
Поэтому надеюсь что приоритет будет за ними.
potan
09.09.2018 16:19-1Можно отказаться от out-of-order, и вообще от суперскаларности, а для закрузки конвеера использовать гипертрединг с большим количество нитей.
Еще можно хостить не нативные приложения, а байткод, котовый верифицировать на экслуотацию известных уязвимостей.Lofer
09.09.2018 19:00+1Еще можно хостить не нативные приложения, а байткод, котовый верифицировать на экслуотацию известных уязвимостей.
Это скрестить сигнатурный анализатор с JIT-компилятором? Так МС вас опередила — на уровне компилятора с 2003 года нельзя дергать системные функции без критериев безопастности (явного размера данных), в .Net встроены декларативные механизмы безопастности, в для нативных приложений используются манифесты. Это решило часть проблем. Что делать с остальным — пока не очень понятно.
0xd34df00d
10.09.2018 03:09Еще можно хостить не нативные приложения, а байткод, котовый верифицировать на экслуотацию известных уязвимостей.
Ща, пять сек, только задачу останова дорешаю.
inferrna
09.09.2018 20:17Насколько я понимаю, многозадачность современных системах реализована на уровне процессора. Т.е. в процессор уже заложено разграничение между процессами на доступ к ресурсам и т.д. В чём проблема подписывать данные в кэше идентификатором процесса? Процесс что-то вычислял, получал данные из своей области памяти и часть данных отпечаталась в кэш. Потом пришёл другой процесс со своей памятью и своими данными — зачем вообще процессор тратит время на поиск в области кеша, в которую этот новый процесс ничего не писал? «Ну а что, а вдруг?» Что стоит изолировать данные в кеше между процессами? Так и кеш будет работать быстрее — не потратит время на поиск данных там, где их нет и быть не может, и безопасность будет выше.
sumanai
09.09.2018 21:43+1В чём проблема подписывать данные в кэше идентификатором процесса?
Уже, гуглить PCID.
«Ну а что, а вдруг?»
Так и есть. Есть общесистемные библиотеки, разделяемые данные.
Так и кеш будет работать быстрее — не потратит время на поиск данных там, где их нет и быть не может, и безопасность будет выше.
Медленнее, потому что придётся учитывать ещё один параметр. Кеш реализован в железе, и тут дополнительыне параметры только портатят транзисторный бюджет.
equand
10.09.2018 00:41Сейчас программно так и реализовали (KPTI), по сути ОС загружает и выгружает данные из кеша, когда они больше не нужны.
Однако ускорение от спекуляции в том как раз таки, что доступ разрешен спекулятивному выполнению.
Darth_Malok
10.09.2018 07:36+1Я слабо представляю, как работают современные процессоры, но неужели нельзя вместо «не читать лишние данные» и «очищать кэш после каждой операции» пойти немного другим путём — «очищать в кэше только те данные, которые не должны были туда попасть»? Можно даже какое-то микроядро прикрутить, которое только и занимается тем, что чистить кэш от «некорректных» данных. Процессор же на каком-то этапе отбрасывает результаты вычислений. Пусть где-нить записывает что-то типа «я тут немного погорячился, почисти тут и тут».
Да, производительность немного упадёт, но не нужно будет изобретать «процессор совершенно нового типа».
Или у меня искажённые представления, и программы постоянно лезут в недоступные области памяти, «разгоняя» друг друга за счёт кэширования?Lofer
10.09.2018 11:46Я слабо представляю, как работают современные процессоры, но неужели нельзя вместо «не читать лишние данные» и «очищать кэш после каждой операции» пойти немного другим путём — «очищать в кэше только те данные, которые не должны были туда попасть»?
Нюанс в том, как именно организована память и ее адресация. Физическая адресация. Кеш вычитывает данные не побайтово, а целыми кусками/страницами.
Такая логика имеет смысл по нескольким причинам причинам:
- исполнимый код расположен одним непрерывным куском в памяти,
- обрабатываемые данные с большой степенью вероятности расположены последовательно
- сменить физическую адресацию памяти занятие не дешевое само по себе (на планках памяти DDR4 CAS Latencies 14- 20 t, DDR3 CL9-CL11 t )
Если тонким слоем «размазать» данные по памяти — производительность сильно упадет.
«очищать в кэше только те данные, которые не должны были туда попасть»
По дизайну именно так и задумано «не должно попасть» — все нарезано на странички, каждая со своими пометками, все помещено в какой-то контекст, свои таблицы трансляции и т.д.
А по факту — весьма странный «баг дизайна»
napa3um
Полной защитой от такого класса атак, наверное, может быть только аппаратная реализация гомоморфного шифрования. Тогда процессор не сможет знать о том, что он вычисляет. (Но будет это делать ооооочень медленно и горячо :).)