Жизнь после Meltdown и Spectre dl // 07.01.18 18:55
Пыль, поднятая вокруг случившегося на неделю раньше запланированного обнародования информации об уязвимостях Meltdown (CVE-2017-5754) и Spectre (CVE-2017-5753 и CVE-2017-5715), чуть улеглась, так что можно делать некоторые оценки сложившейся ситуации.
[Не забывайте при копировании материала указывать полный адрес источника: //bugtraq.ru/rsn/archive/2018/01/01.html]
Счастливчикам, выпавшим на прошедшей неделе из новостного потока, имеет смысл ознакомиться с весьма доходчивым описанием Олега Артамонова. Если совсем коротко и на пальцах, принципиальный источник всех проблем кроется в сочетании механизма спекулятивного выполнения команд и предсказания ветвлений с использованием процессорного кэша.
В случае Meltdown ситуация усугубляется игнорированием процессором во время этого самого спекулятивного выполнения команд прав доступа к памяти (из тех соображений, что операция все равно откатится), в результате чего любой процесс может, используя оценку времени косвенного доступа к памяти, фактически прочитать всю память системы, в том числе и критичные блоки, обычно нормальным процессам недоступные. Под раздачу с Meltdown попали все процессоры Intel семейств Core и Xeon, процессоры iOS-устройств и пока широко не используемый Cortex-A75.
Хорошая новость - Meltdown может быть закрыта на уровне ОС, что и произошло во всех последних патчах. Плохая новость - исправление чревато ростом накладных расходов на системные вызовы, который может привести к падению производительности от 1-2% до 20-30%, а также росту потребляемой энергии (TDP) на 10-15%. Поскольку уязвимость локальная, обычным пользователям достаточно применять стандартные правила компьютерной гигиены и не запускать все подряд (тёмным пятном тут остается выполнение JavaScript, но производители браузеров уже озаботились загрублением оценок времени доступа к памяти). А вот всевозможным хостерам и облачным провайдерам придется срочно озаботиться. И их же сильнее всего затронет падение производительности после применения патчей (вот отличный пример).
В случае со Spectre с одной стороны всё не так больно, поскольку использовать её гораздо сложней (идея заключается во влиянии на спекулятивное выполнение команд в атакуемом процессе c последующим анализом попадания данных в кэш). С другой стороны, она уже носит фундаментальный характер и проявляется практически во всех современных процессорах. Ответ на вопрос "кому волноваться?" тут такой же, как с Meltdown. При этом надо понимать, что мы имеем дело с новым классом атак, использование которого почти наверняка не ограничится двумя описанными случаями и будет сочетаться с другими векторами атак. Что забавно, один из способов борьбы со Spectre сводится к усложнению определения атакующим типовых фрагментов кода, подходящих для использования, что слегка напоминает способы борьбы полиморфных вирусов с определением антивирусами.
Subj, почитал "доходчивое описание Олега Артамонова", и до меня так и не дошло, к сож.
Итак, спекулятивное исполнение произошло, но неудачно из-за MMU, результаты отброшены, конвейер сбросился. Результат какбэ в кеше, но напрямую мы его вытащить не можем... и как-то его вытаскивают... КАК? Непонятно.
Косвенно и мучительно:01.02.18 01:45 Автор: dl <Dmitry Leonov>
> Итак, спекулятивное исполнение произошло, но неудачно из-за > MMU, результаты отброшены, конвейер сбросился. Результат > какбэ в кеше, но напрямую мы его вытащить не можем... и > как-то его вытаскивают... КАК? Непонятно.
Косвенно и мучительно:
"Наше приложение начинает читать адреса от 0 и выше в собственном адресном пространстве (имеет полное право), замеряя время, требующееся на чтение каждого адреса, и читая их не по порядку, чтобы не натренировать тот же спекулятивный доступ
На адресе 98 время доступа вдруг оказывается в несколько раз ниже, чем на других адресах
Таким образом мы понимаем, что кто-то уже недавно читал что-то по этому адресу, в результате чего он попал в кэш. Кто бы это мог быть? Ах, да, это наш дорогой процессор. По адресу 15000, соответственно, лежит значение 98."
О как... Спасибо!05.02.18 12:18 Автор: HandleX <Александр М.> Статус: The Elderman
подробно о проекте
Анализ криптографических сетевых...
