Комментарии 265
Звучит так, как будто процессоры AMD не подвержены уязвимости из-за того, что они просто медленнее и успевают дождаться ответа mmu о некорректности вызова адреса памяти. Но вот сейчас замедлят Intel до их уровня — и будет ок.
Не холивара ради :)
Не холивара ради :)
Или что MMU у них работает по другой логике и поэтому отрабатывает быстрее. Или что-то ещё, кто ж нам расскажет-то (нет, ну я знаю пару-тройку людей, которые наверное могли бы, но они ж мне расскажут только если я сначала в письменной форме пообещаю вам не рассказывать).
Причём на самом деле возможна и ситуация, что уязвимость у них столь же реальна, просто эксплоиту её надо отрабатывать быстрее или чуть иначе — но я в целом к этому отношусь как к маловероятному варианту.
Причём на самом деле возможна и ситуация, что уязвимость у них столь же реальна, просто эксплоиту её надо отрабатывать быстрее или чуть иначе — но я в целом к этому отношусь как к маловероятному варианту.
Причём на самом деле возможна и ситуация, что уязвимость у них столь же реальна, просто эксплоиту её надо отрабатывать быстрее или чуть иначе — но я в целом к этому отношусь как к маловероятному варианту.
Вот это, кстати, самое интересное. Потому что не очень верится в столь большие различия в архитектуре процессоров у самых заклятых друзей.
они ж мне расскажут только если я сначала в письменной форме пообещаю вам не рассказывать
Жаль, очень жаль.
Вот это, кстати, самое интересное. Потому что не очень верится в столь большие различия в архитектуре процессоров у самых заклятых друзей.
Ну почему, вот я вижу гипотетический сценарий, в котором процессор успевает прочитать первый адрес, но пока он читает второй (там же оба процесса медленные, он же их по первому разу читает из ОЗУ) — к нему прибегает MMU с воплями, и проц прерывает выполнение, в итоге не донося результат до кэша.
Это не какое-то грандиозное архитектурное отличие, это в общем-то нюансы реализации, на которые до сих пор никто мог даже не обращать особого внимания, а выбирать их исходя из длины конвейера, архитектуры MMU, архитектуры контроллера памяти и архитектуры чёрта в ступе.
Короч, либо архитекторам AMD несказанно повезло, или они что-то предполагали с самого начала, лет надцать назад.
Ждём про Spectre, там всё чудесатее, и непонятно вообще можно ли его эксплуатировать на реальных системах.
Ждём про Spectre, там всё чудесатее, и непонятно вообще можно ли его эксплуатировать на реальных системах.
Что случается, если переменная x оказывается расположенной не просто за пределами конкретного массива, а вообще за пределами доступной данному процессу памяти? Процессор всё равно выполняет вторую строку кода.
Ну AMD сообщает, что их процессоры как раз корректно отрабатывают это исключение поэтому и не подвержены meltdown. Т.е. атака по таймингу есть, а вот вылазки за адресное пространство — нет. В связи с этим вам, возможно, правильнее использовать "процессоры Intel" вместо "процессоры" — в статье и комментариях.
Да там уже не только Intel, ARM тоже отметился.
Ну я просто за справедливость: если разность в производительности/энергоэффективности Intel vs AMD последние 15 лет была обусловлена тем, что Intel забивала на bounds check до последнего момента, то сейчас справедливо было бы уточнять, что не все процессоры выполняют вторую строку кода (а скоро никто не будет).
Я когда-то читал статью по устройству кешей в процессорах, из неё я точно помню что у INTEL и AMD работа кеша отличается довольно принципиально. Причем там же было предположение о возможности нынешней уязвимости на интеловских процессорах. Как-то они лихо срезали углы в ущерб безопасности но повысили быстродействие. Но это было достаточно давно, саму статью естественно не помню, читал её почти по диагонали — тогда это было просто интересно. Видимо тогда резонанс просто не получился ибо предполагали что уязвимость слишком сложная для реализации.
Если успели сходить только по первому (невалидному) адресу, то всё равно можно оценить, например — по изменению объёма наших закешированных данных.
насколько понял из пейпера, это и пытались сделать — просто вероятность паршивая
насколько понял из пейпера, это и пытались сделать — просто вероятность паршивая
Так а кто ж даст кэш взвесить?
Если я все правильно понял, то за один раз возможно проверить байт по интересующему адресу на совпадение с одним значением (на 0 для простоты). Значит, реализуя тот же трюк второй раз, проверяем на 1. Итого, не более чем за 256 проверок будет получен результат. Где я налажал с рассуждениями?
В https://lkml.org/lkml/2017/12/27/2 представитель amd Tom Lendacky писал, что все операции доступа в память, в т.ч. спекулятивные у амд проверяют уровни доступа (и отключил kpti для amd — https://github.com/torvalds/linux/commit/694d99d40972f12e59a3696effee8a376b79d7c8):
The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode
when that access would result in a page fault.
Кто-нибудь знает, как закрытие уязвимости повлияет на тот или иной конкретный софт?
Лично меня интересуют:
Браузеры (конкретно — Опера)
2д редакторы графики: Illustrator, InDesign, Photoshop
WinRAR
Лично меня интересуют:
Браузеры (конкретно — Опера)
2д редакторы графики: Illustrator, InDesign, Photoshop
WinRAR
На пользовательский десктопный софт в среднем по больнице повлияет мало, т.к. он в основном занимается своими делами, а ядро системы дёргает мало, ибо зачем оно ему.
Но, конечно, возможны исключения.
Но, конечно, возможны исключения.
Исключения — работа с гигабитной сетью или nvme ssd
nvme ssd
Ну-ка, ну-ка? Я как раз присматриваюсь к nvme ssd, хочу улучшить рабочую станцию. Есть подробности?
От патча для meltdown для интела страдают все системные вызовы без исключения. Обычно это не является большой проблемой, но к системным вызовам также относятся работа с дисками и с сетью.
Пострадали все без исключения приложения, работающие с дисками, но обычно это выражается просто в увеличении загрузки процессора. В случае с nvme ssd проц и так в некоторых ситуациях был бутылочным горлышком при работе с диском, поэтому у них просела производительность. Я встречал отзывы, что скорость линейных чтения/записи упала до двух раз в бенчмарках. Про случайных доступ не знаю, но думаю, что он (т.к. ограничителем все же до сих пор выступает диск) просел не настолько много.
Пострадали все без исключения приложения, работающие с дисками, но обычно это выражается просто в увеличении загрузки процессора. В случае с nvme ssd проц и так в некоторых ситуациях был бутылочным горлышком при работе с диском, поэтому у них просела производительность. Я встречал отзывы, что скорость линейных чтения/записи упала до двух раз в бенчмарках. Про случайных доступ не знаю, но думаю, что он (т.к. ограничителем все же до сих пор выступает диск) просел не настолько много.
Для большинства рабочих задач просто любой ссд — уже сильно улучшение. Просто данный патч отьедает кусочек от каждого запроса к диску. А когда у вас ssd, он их может ОЧЕНЬ много переварить. В результате у вас загружен проц там, где раньше не был.
Sprint Layout — до патча МС 0:58, после патча МС-время запуска 1:11,7. Это с библиотекой макросов, замеры на i5-4210
Я патч убрал в конце концов.
Я патч убрал в конце концов.
Такой новогодний подарок принесли… что все ресурсы гудят уже как ульи с пчёлами обсуждая эту тему. Потому что такое не каждый день прилетает.
Ждём про Spectre, спасибо :)
Ждём про Spectre, спасибо :)
Большинство ресурсов, кстати, те ещё мудаки. Все эти желтушные новости про потерю производительности в два раза после обновления приводят к тому, что люди отключают обновления, а потом происходит WannaCry и все ноют какой Windows плохой и дырявый.
Сам гугл так же выпустил статью про то, что много спекулятивных статей и на их серверах «незначительное» изменение производительности.
security.googleblog.com/2018/01/more-details-about-mitigations-for-cpu_4.html
security.googleblog.com/2018/01/more-details-about-mitigations-for-cpu_4.html
Большинство ресурсов написали статьи без разъяснения и с посылом «шеф, всё пропало!». А всё потому что там основном писатели, а не люди которые понимают что происходит. И это печально.
Сейчас пошли статьи о том, что топ-менеджмент знал и сливали акции. Опять эти все вбросы и желтизна. Толкового материала как здесь, просто единицы.
Сейчас пошли статьи о том, что топ-менеджмент знал и сливали акции. Опять эти все вбросы и желтизна. Толкового материала как здесь, просто единицы.
На данном этапе я бы просто игнорировал все заявления причастных компаний, которые не сопровождаются конкретными цифрами.
Intel там вообще уже пообещал чуть ли не к обеду микрокод выпустить, который придёт и молча исправит всё. Неизвестно что конкретно, неизвестно как конкретно, но точно-точно всё исправит.
Intel там вообще уже пообещал чуть ли не к обеду микрокод выпустить, который придёт и молча исправит всё. Неизвестно что конкретно, неизвестно как конкретно, но точно-точно всё исправит.
Вроде как они написали, что еще выпьют валерьянки на выходных и начнут поставку микрокода на следующей неделе и он будет полноценно работать на системах выпущенных за последние 5 лет (PCID?).
Вот как начнут — так и посмотрим, что он там делать будет.
Из описания уязвимостей никаким очевидным образом не следует, как это можно закрыть микрокодом без падения производительности, а заявление Интела — это просто образчик политкорректности и обтекаемости, PR-отдел такое должен в рамочку на стенку вешать и учиться.
Особенно если вспомнить их предыдущее заявление, выполненное в стиле «а чо сразу мы-то?».
Из описания уязвимостей никаким очевидным образом не следует, как это можно закрыть микрокодом без падения производительности, а заявление Интела — это просто образчик политкорректности и обтекаемости, PR-отдел такое должен в рамочку на стенку вешать и учиться.
Особенно если вспомнить их предыдущее заявление, выполненное в стиле «а чо сразу мы-то?».
Да это все бизнес. Те, у кого есть голова на плечах, умеют читать между строк и играть между струн.
Мне без разницы как закроют. Нужно будет сегодня покопаться в коде примера спектра и пробовать заменить victim_function на что-то что сможет читать определенную область памяти. Сомневаюсь, что у меня получится, но попытка не пытка.
Мне без разницы как закроют. Нужно будет сегодня покопаться в коде примера спектра и пробовать заменить victim_function на что-то что сможет читать определенную область памяти. Сомневаюсь, что у меня получится, но попытка не пытка.
Архитектура систем подразумевает, что вы разносите процессы по серверам в соответствии с требуемыми ресурсами.
На синтетических тестах у вас действительно могут быть просадки на 30%, но на реальной системе, даже на той, которая активно использует системные вызовы, у вас будет просадка меньше, есть еще сеть, память, и все это будет влиять. В масштабах датацентров класса GCP, AWS, FB доля таких сервером далеко не подавляющая, что и приводит к общей потери производительности измеряемой числами порядка единиц процентов. Под удар попадут клиенты, у которых основная масса серверов оказалась подвержена деградации производительности, но думаю, что таких довольно мало.
На синтетических тестах у вас действительно могут быть просадки на 30%, но на реальной системе, даже на той, которая активно использует системные вызовы, у вас будет просадка меньше, есть еще сеть, память, и все это будет влиять. В масштабах датацентров класса GCP, AWS, FB доля таких сервером далеко не подавляющая, что и приводит к общей потери производительности измеряемой числами порядка единиц процентов. Под удар попадут клиенты, у которых основная масса серверов оказалась подвержена деградации производительности, но думаю, что таких довольно мало.
Сеть и доступ к ссд как раз наибольшее падение и показывает.
Вы плохо понимаете, что происходит. ВСЕ нагруженные системы mysql, oracle, postgress паказывают 15% падение, а для многих 10% разницы это разница между живой и мертвой системой.
Просто никому не нужна паника.
Вы плохо понимаете, что происходит. ВСЕ нагруженные системы mysql, oracle, postgress паказывают 15% падение, а для многих 10% разницы это разница между живой и мертвой системой.
Просто никому не нужна паника.
Вы можете показать это на падение на уровне всей инфраструктуры компании/проекта? Я еще понимаю, когда вся система закручена на ERP на SAP или Oracle и есть только пользовательские клиенты, но зачастую, сервера БД, хоть и критичны, но составляют далеко не большинство, даже внутри огромных компаний.
И я на это смотрю с опыта работы в очень большой компании.
И я на это смотрю с опыта работы в очень большой компании.
Я лично видел, как система падала от того, что ее поставили на процессор на 200мгц и 2мб кеша меньше, чем стояла до этого(и не падала).
В базах данных расстояние от «успевает нормально» до «пошла увеличиватся очередь» буквально проценты.
В базах данных расстояние от «успевает нормально» до «пошла увеличиватся очередь» буквально проценты.
Это как-то отменяет то, что написал я? Вы приводите крайний случай, в реальности же не доверять данным гугла об изменении общей нагрузки предпосылок нет.
Все это уже давно описано и собрано в методологии. Есть понятия планирования ресурсов, которые учитывают управление рисками. И в данном случае мы имеем рисковый случай, все остальное зависит от качества управления компанией. А крайние случаи будут всегда, и тут еще вилами по воде писано, что дешевле и проще: накатить патч, протестировать нагрузку и заказать один-два сервера или потратить несколько сотен человеко часов на разруливание проблемы в корявом софте.
Все это уже давно описано и собрано в методологии. Есть понятия планирования ресурсов, которые учитывают управление рисками. И в данном случае мы имеем рисковый случай, все остальное зависит от качества управления компанией. А крайние случаи будут всегда, и тут еще вилами по воде писано, что дешевле и проще: накатить патч, протестировать нагрузку и заказать один-два сервера или потратить несколько сотен человеко часов на разруливание проблемы в корявом софте.
Процессор сбрасывает конвейер и вместо значения, лежащего по адресу 98, выдаёт нам ошибку.
По моему процессор в этом случае не выдает ошибку, а процесс получает сигнал segmentation fault и аварийно завершается. Разве не так ?
Ну, процесс же откуда-то получает этот Segmentation Fault?
У любого процессора есть набор прерываний, которыми он реагирует на подобные действия, ОС их обрабатывает и выдаёт по носу приложению (ну или предпринимает иные действия).
На примере Cortex-M в силу их простоты сравнительной хорошо видно, как это работает. Там у младших (M0) на все случаи жизни единственное прерывание — Hard Fault, у которого наивысший приоритет и которое нельзя замаскировать, а в M3 уже начинается разделение на BusFault (лезем по несуществующему адресу), MemFault (лезем по неразрешённом нам адресу, там зачатки управления памятью уже есть), UsageFault (пытаемся выполнить мусор вместо инструкции), которые ПО может отрабатывать по отдельности, решая, что ему с этим делать.
Собственно, даже пример вспомнил, как приложение лезет не в свою область памяти, но при этом корректно всё разруливает. Мы это используем, например, на Cortex-M3 для определения объёмов памяти, наличия всякой периферии и т.п. — просто маскируем прерывание BusFault, лезем по нужному адресу, если флажок BusFault встал, то там ничего нет, ставим отметку, что сюда не ходи, работаем дальше.
У любого процессора есть набор прерываний, которыми он реагирует на подобные действия, ОС их обрабатывает и выдаёт по носу приложению (ну или предпринимает иные действия).
На примере Cortex-M в силу их простоты сравнительной хорошо видно, как это работает. Там у младших (M0) на все случаи жизни единственное прерывание — Hard Fault, у которого наивысший приоритет и которое нельзя замаскировать, а в M3 уже начинается разделение на BusFault (лезем по несуществующему адресу), MemFault (лезем по неразрешённом нам адресу, там зачатки управления памятью уже есть), UsageFault (пытаемся выполнить мусор вместо инструкции), которые ПО может отрабатывать по отдельности, решая, что ему с этим делать.
Собственно, даже пример вспомнил, как приложение лезет не в свою область памяти, но при этом корректно всё разруливает. Мы это используем, например, на Cortex-M3 для определения объёмов памяти, наличия всякой периферии и т.п. — просто маскируем прерывание BusFault, лезем по нужному адресу, если флажок BusFault встал, то там ничего нет, ставим отметку, что сюда не ходи, работаем дальше.
А разве в intel процессорах segmentation fault можно перехватить ?
Segfault — это же на уровне системы почти обычное прерывание, 13-й номер, кто-то же его должен обработать? Может или нет пользовательский код отнять его обработку у ОС — это вопрос к ОС, не к процессору. Вот пишут, что и под линуксом с виндой вполне можно.
По ссылке что-то слишком длинно расписано.
«Перехват» segfault делается через конструкцию __try __except (называется structured exception handler, SEH) в msvc и через sigaction(SIGSEGV) (посмотрите man sigaction) в unix-подобных системах. Из обработчика SIGSEGV, если не хотите завершать процесс, можно выпрыгнуть назад в основной код с помощью longjmp().
«Перехват» segfault делается через конструкцию __try __except (называется structured exception handler, SEH) в msvc и через sigaction(SIGSEGV) (посмотрите man sigaction) в unix-подобных системах. Из обработчика SIGSEGV, если не хотите завершать процесс, можно выпрыгнуть назад в основной код с помощью longjmp().
Когда вы видите окошко типа «программа упала, не хотите ли отправить отчет такой-то матери», это с большой вероятностью выполняется обработчик SIGSEGV.
Процесс прибивается принудительно, если он не выставил собственный обработчик.
Процесс прибивается принудительно, если он не выставил собственный обработчик.
Достаточно обернуть всю работу с этим значением в, условно,
if (likely(false)) {
}Процессор послушно прогреет кэш если спровоцировать branch misprediction, даже если этот код никогда не выполнится.
>>> кроме микроконтроллеров
Ура! Мой Arduino UNO неуязвим!
Ура! Мой Arduino UNO неуязвим!
Я не понимаю мотивации людей, которые обнародовали эту дыру. На мой взгляд это их действия превратили поведение алгоритма в опасную уязвимость. Ну нашли вы уязвимость, быстро стало ясно что затрагивает она все современные процессоры и ее нельзя устранить, так зачем об этом кричать? Без этой огласки знали бы о ней единицы специально обученных людей и и уязвимость коснулась бы единиц. Теперь же в ближайшее время в открытом доступе появятся уже готовые жаваскрипты крадущие логины, пароли и бог знает что. Мотивация детей, «смотрите какие мы умные, мы такую дыру нашли». Здесь действия этих людей принесут принесут вред, а не сама эта уязвимость.
уязвимость коснулась бы единиц
Или миллионов, если бы кто-то из специально обученных людей решил бы выпустить свежего симпатичного червячка. И на заделывание этой дыры тогда ушли бы не сутки, как в случае с типичными софтовыми дырками, а месяцы.
Security through obscurity не работает. Не сегодня — завтра кто-нибудь докопался бы. Вон покойный Касперски ещё в 2008 писал (PDF).
Думать так — очень большая ошибка. Всё равно что скрывать симптомы и делать вид, что всё нормально. Вместо того что бы признать болезнь и заняться лечением.
Вообще это обычная практика у white hat. Нашли уязвимость -> уведомили ответственных -> подождали патча (или какое-то время)-> обнародовали. Если не обнародовать, то у ответственных пропадает стимул что-то исправлять.
И кстати есть инфа (достоверность правда не известна), что производители процессоров были уведомлены еще в июне.
Вообще это обычная практика у white hat. Нашли уязвимость -> уведомили ответственных -> подождали патча (или какое-то время)-> обнародовали. Если не обнародовать, то у ответственных пропадает стимул что-то исправлять.
И кстати есть инфа (достоверность правда не известна), что производители процессоров были уведомлены еще в июне.
KAISER еще раньше начали делать: https://github.com/IAIK/KAISER (https://gruss.cc/files/kaiser.pdf JUNE 3, 2017), уже пару месяцев их патч адаптировали к включению в ядро. Были посты https://cyber.wtf/2017/07/28/negative-result-reading-kernel-memory-from-user-mode/ и http://pythonsweetness.tumblr.com/post/169166980422/the-mysterious-case-of-the-linux-page-table.
О баге подробно написал The Register, из-за информацию огласили раньше (на неделю?), чем планировали: https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/
There is presently an embargoed security bug impacting apparently all contemporary [Intel] CPU architectures
https://www.theregister.co.uk/2018/01/04/intel_meltdown_spectre_bugs_the_registers_annotations/
Intel and other vendors had planned to disclose this issue next week when more software and firmware updates will be available. However, Intel is making this statement today because of the current inaccurate media reports.
We were gonna say something next week, but those bastards at The Register blew the lid on it early so
The preferred phrase at present is "coordinated disclosure." "Responsible disclosure" suggests the media and security researchers have been irresponsible for reporting on this issue before Intel was ready to go public. Once we get into assigning blame, that invites terms like "responsible microarchitecture design" or "responsible sales of processors known to contain vulnerabilities" or "responsible handling of security disclosures made last June."
Отличительная и ключевая особенность этой уязвимости — невозможность устранения, по-сути это не болезнь, ошибка или недоделка, это архитектурная особенность современного процессора. Програмный патч в этом случае, как я понял, будет в какой-то мере ограничивать функциональность, так что нет, это не тот случай, о котором вы говорите. Тут одни умные парни укололи других умных парней, а заплатят все остальные.
Если проводить аналогии с болезнью, то да — это неизлечимая болезнь. Стоит ли её скрывать или всё таки надо признать и заняться лечением тем самым продлив пациенту жизнь?
Но аналогии фальшивы. А по факту уже написали — Security through obscurity не работает. Давно признанный в ИБ факт.
Есть ли тут какая-то доля тщеславия? Возможно. В конце концов «белые шляпы» очевидно зарабатывают меньше своих не столь отягощенных моралью коллег. Компенсируется это в том числе и так.
Но дело это не меняет всё равно — сокрытие ни к чему хорошему тоже не приводит.
Но аналогии фальшивы. А по факту уже написали — Security through obscurity не работает. Давно признанный в ИБ факт.
Есть ли тут какая-то доля тщеславия? Возможно. В конце концов «белые шляпы» очевидно зарабатывают меньше своих не столь отягощенных моралью коллег. Компенсируется это в том числе и так.
Но дело это не меняет всё равно — сокрытие ни к чему хорошему тоже не приводит.
Поэтому давайте вирусописатели будут знать (им кто-то обязательно продал бы, не сейчас, так через пару лет), а остальные пусть знать не будут, что б спокойнее спалось? Верно понимаю вашу логику?
Intel уведомили об ошибке в июне прошлого года. Было достаточно времени, чтобы предпринять хоть какие-то меры.
Хорошие люди ничем от плохих в плане интеллекта принципиально не отличаются. Если до чего-то смог додуматься хороший человек, то и плохой человек додуматься сможет (а, возможно, даже кто-то плохой до этой уязвимости додумался уже давно, просто никто не знает). А это значит, что в один прекрасный момент Х, эпидемия всё равно случится (потому что плохой человек додумается до уязвимости, а также будет иметь мотивацию её применить на практике). Только вот сейчас пострадают только те, кто поленился поставить апдейты, ибо у софтовых компаний время на закрытие дыры было. А так пострадают вообще все.
Запретить дыры?
Ладно пользовательский софт, а драйверы? По ним же должно ударить?
а может кто-то дать ссылку, на видео или статью где все вышеописанное на практике используют и тырят пароль или еще какой ключ в реале? Просто в статье упоминается перебор каких то там комбинаций и т.о. типа всю память физическую можно прочесть: ну ок, а за какое время?(может там уже мусор будет давно) и куда оно пишется после чтения? а сколько это займет времени и оперативки. чем/кем это все анализируется после считывания?
Например вот, та же техника — переброс видео через кэш процессора на двух виртуалках в Amazon ec2.
честно: не вижу более одной виртуалки/железной тачки) на видео. просто какое-то консольное нагромождение.
прошу простить, если с телефона не разглядел чего то.
Это иллюстрация другой методики, когда на двух разных виртуальных машинах работает специальный код, пересылающий данные между ними по скрытому каналу через кэш-память
Black Hat Asia 2017: Hello From the Other Side
https://www.youtube.com/watch?v=a9sGk7FtnYk SSH Over Robust Cache Covert Channels in the Cloud (от тех же Daniel Gruss и ко)
https://gruss.cc/files/hello.pdf
Especially cache covert channels allow the transmission of several hundred kilobits
per second between unprivileged user programs in separate virtual machines… Our errorcorrecting and error-handling high-throughput covert channel can sustain transmission rates of more than 45 KBps on Amazon EC2, which is 3 orders of magnitude higher than previous covert channels demonstrated on Amazon EC2. Our robust and errorfree channel even allows us to build an SSH connection between two virtual machines, where all existing covert channels fail.
… Covert channels are unauthorized communication channels between two parties, a sender and a receiver.… At a high level, the sender transmits bits by evicting cache lines from the receiver. The receiver constantly probes a set in his L1 cache. These cache lines are also present in the lastlevel cache due to the inclusive property. To transmit a ‘0’, the
sender does nothing. The lines thus stay in the L1 cache of the receiver, which thus observes a short timing to probe its lines. To transmit a ‘1’, the sender accesses cache lines that are mapped to the same set in the last-level cache as the receiver’s.
По Spectre для примера в статье заявлена скорость порядка килобайтов в сек https://spectreattack.com/spectre.pdf The unoptimized code in Appendix A reads approximately 10KB/second on an i7 Surface Pro 3.
Для meltdown быстрее — https://meltdownattack.com/meltdown.pdf we can dump kernel and physical memory with up to 503 KB/s… With exception handling, we achieved average reading speeds of 123 KB/s when leaking 12 MB of kernel memory
по первому видео: ну там адреса заранее известны. немного не жиза))
по второй ссылке: ну диспетчер паролей фф и какая то неведомая хня в hex. не ясно, какой вывод надо сделать то.
Да какая по большому счёту разница, известны они заранее или нет. Это только на время работы влияет.
На том же Heartbleed убедительно показывали, из какого сора растут цветы и добываются сертификаты.
На том же Heartbleed убедительно показывали, из какого сора растут цветы и добываются сертификаты.
разница есть. особенно в ентерпрайз, с сотнями гигов оперативы. так же можно сказать, что любой пароль можно подобрать, вопрос времени :-)
а хартблид чутка попроще и для понимания и для реализации имхо!
Какую рускоязычную статью не читаю, везде пишут мол на амд тоже есть и причем вполне уверенно. Это очень смешно, учитывая тот факт что на амд так не смогли ее провернуть и что представители амд предупредили что у них совсем другой подход к работе процессора. Банально — у них даже шины не имеют ничего общего между собой- у амд звезда, у интел кольцо. Spectre на амд вообще работает только на системах с включеным BPF(линуксы и bsd), который по дефолту отрублен. Что это за мания пытаться за компанию и амд затянуть в это болото? У амд была проблема с райзенами до 25 недели, приводящая к сегфолту, но она решается отключением опкеша и эти процы амд меняет бесплатно по RMA. Как думаете, сколько процессоров поменяет интел? Мой вариант — 0.
Spectre на амд вообще работает только на системах с включеным BPF(линуксы и bsd),
НЕТ.
Ёлки зелёные, из того, что гугль для простоты демонстрации дырки использовал eBPF, никак не следует, что без него эта дырка исчезает.
Какой патч, куда патч? AMD не подвержены Meltdown вообще.
я про spectre многие говорят, типо от нее вообще нельзя избавится у AMD судя по всем получилось. От Meltdown помогает программный патч. хоть и тормозной
У AMD по ссылке написано, дословно, «проблему решат обновления ПО, которые вам предоставят производители».
Ровно по причине таких прекрасных, подробных пресс-релизов я специально добавил в текст абзац про пресс-релизы.
Ровно по причине таких прекрасных, подробных пресс-релизов я специально добавил в текст абзац про пресс-релизы.
насколько я понял имеется в виду обновление микрокода, а не обновления ядер ОС
Строго говоря, по ссылке написано: "(Уже) решено путем обновления программного обеспечения / ОС, которое должно быть доступно поставщикам и производителям систем. Ожидается незначительное влияние на производительность."
Но Вы правы, что надо подождать реальной поставки и независимой проверки готовых патчей на системах AMD, чтобы делать окончательные выводы.
Но Вы правы, что надо подождать реальной поставки и независимой проверки готовых патчей на системах AMD, чтобы делать окончательные выводы.
Проблема сегфолтов отключением опкеша не решается, а на на некоторых замененных процах сегфолт остаётся.
Для информации: подсистему eBPF в Linux рекомедовали отключить (для пользователей) ещё 23.12.2017, и по другому поводу.
Нуб с мировым именем MODE ON.
Какой-то простой алгоритм. Я ни капли не программист, ну разве что самую малость, но это объяснение на пальцах мне показалось очень понятным, а сам алгоритм — лежащим на поверхности. Ну ладно, я всё таки Физтех закончил, благо, я могу попробовать объяснить это всё родственнику, который хоть и весьма толковый, но, как показала недавняя практика, даже не вполне умеет пользоваться гиперссылками на страницах в интернете. Так я даже ему смог это объяснить. Как тогда так получилось, что до этого додумались только сейчас?
Во-первых, думается мне, это просто когда тебе это на блюдечке преподнесли и рассказали как работает. А поди ты сам до такого хитроумного способа додумайся. Отличный пример высказывания «всё гениальное просто».
Во-вторых кто сказал, что додумались только сейчас? Это white hat додумались сейчас. А сколько до них додумались black hat? Сие не ведомо. Может и действительно никто.
Во-вторых кто сказал, что додумались только сейчас? Это white hat додумались сейчас. А сколько до них додумались black hat? Сие не ведомо. Может и действительно никто.
Хороший вопрос. Я вроде в предыдущих постах видел, что все бьют себя пяткой в грудь и заявляют, что подобных атак не наблюдали. Отсюда вопрос: как они могли знать были атаки или нет, если сама уязвимость не была известна?
«Если вы, откусив яблоко, обнаружили торчащую из него половину червяка, значит, вы только что съели червяка. Если же вы ничего не обнаружили, это ещё ничего не значит».
Лучше быть подготовленным.
В Amazon решили не доедать яблоко.
В Amazon решили не доедать яблоко.
We will be updating the certificate authority (CA) for the certificates used by Amazon CloudWatch Logs domain(s), between 8 January 2018 and 22 January 2018. After the updates complete, the SSL/TLS certificates used by Amazon CloudWatch Logs will be issued by Amazon Trust Services (ATS), the same certificate authority (CA) used by AWS Certificate Manager. The update means that customers accessing AWS webpages via HTTPS (for example, the Amazon CloudWatch Console, customer portal, or homepage) or accessing Amazon CloudWatch Logs API endpoints, whether through browsers or programmatically, will need to update the trusted CA list on their client machines if they do not already support any of the following CAs:
— «Amazon Root CA 1»
— «Starfield Services Root Certificate Authority — G2»
— «Starfield Class 2 Certification Authority»
Ну если black hat не додумались, то они, наверное, от обиды уже съели свои black hats
НЛО прилетело и опубликовало эту надпись здесь
Всегда знали об этой проблеме. Лет 5(а может и больше?) назад читал статью по поводу небезопасности реализации кеша в интеловских процессорах и там говорилось о теоретической возможности такой атаки, но тогда отмахнулись от этого как от назойливой мухи — это был довольно экзотический способ и его не воспринимали всерьёз.
Второй раз упоминание о возможной проблеме возникло когда ФСБ потребовало взлома айфона террориста у самой компании Эппл, но тогда эта уязвимость не помогла. Т.е. даже тогда было известно о такой проблеме и даже то что она касается не только интеловских процессоров.
Второй раз упоминание о возможной проблеме возникло когда ФСБ потребовало взлома айфона террориста у самой компании Эппл, но тогда эта уязвимость не помогла. Т.е. даже тогда было известно о такой проблеме и даже то что она касается не только интеловских процессоров.
Сейчас это выскочило на публику. А кто, когда додумался раньше, но не опубликовал — неизвестно.
Вообще-то материал уже четвёртый. Но написано очень доходчиво. Спасибо!
После чтения популярного изложения «на пальцах», у меня возник вопрос — как же до сих пор работала популярная в моем детстве программа ArtMoney, которая вполне себе работала с памятью других процессов?
Я понимаю, что в данном случае — вся беда в том, что доступ к чужим областям памяти может получить код запускаемый в средах, которые напрямую этого не позволяют, но все же — чем же занят MMU в случае с ArtMoney?
Я понимаю, что в данном случае — вся беда в том, что доступ к чужим областям памяти может получить код запускаемый в средах, которые напрямую этого не позволяют, но все же — чем же занят MMU в случае с ArtMoney?
MMU — не сферический конь в вакууме, он не работает «сам по себе», ему ОС указывает, какие куски памяти кому положены. В частности, разрешённые области памяти у разных процессов могут вообще пересекаться.
Разрешила ОС данному приложению лазить в чужую память — значит, хорошее приложение, годное, ему можно.
Антивирусу, например, вон тоже много чего можно.
Разрешила ОС данному приложению лазить в чужую память — значит, хорошее приложение, годное, ему можно.
Антивирусу, например, вон тоже много чего можно.
Чтение: msdn.microsoft.com/en-us/library/ms680553(VS.85).aspx
Запись: msdn.microsoft.com/en-us/library/ms681674(VS.85).aspx
Запись: msdn.microsoft.com/en-us/library/ms681674(VS.85).aspx
А вы запустите на современной ОС ArtMoney не от администратора, откажитесь от всяких вопросов «процесс хочет доступ» и попробуйте прочитать память. Скорее всего ничего не получится. А тут даже JS в браузере может вытащить что-нибудь из памяти без всяких разрешений и прочего.
Я вот подумал, а Noscript может как-нибудь помочь в противодействии данной бяке, потенциально пытающейся эксплойтить через JS в браузере? (Intel, ессно).
Я не в курсе, как работает noscript. Если он запрещает выполнение всего JS, то логично, что защитит. Но я вижу, что у меня на части сайтов не работает половина функционала, пока я в umatrix не разрешу загрузку пары скриптов с какого-нибудь CDN. Соотвественно, я от этой уязвимости не защищён — я рано или поздно запущу что-то ради функционала, либо скрипт будет лежать на доверенном домене.
А на практике, с JS скорее всего что-нибудь сделают производители браузеров — загрублением таймера или принудительным сбросом кеша, так что этого не очень стоит опасаться.
Pale Moon ещё в октябре 2016 «на всякий случай» решил огрубить таймер, как знали (ну, браузер для параноиков, решили упредить и не прогадали). Во всяком случае если верить записи разработчика на форуме.
Спасибо за статью, на удивление понятно и доходчиво! По итогам вдумчивого прочтения возникли два вопроса:
1. Если я правильно понимаю, реализация всего этого дела опирается на то, что MMU работает настолько медленно, что процессор успевает минимум два раза сходить в медленную RAM, прежде чем получит ответ, что так нельзя — это действительно так?
2. После получения первого значения процессор начинает его использовать, не дожидаясь ответа, можно ли было его вообще получать. Если я правильно понимаю, примерно из-за ожидания ответа в таком случае Meltdown не реализуется на AMD. Но в каком именно случае процессор таки будет дожидаться ответа от MMU, прежде чем сделать очередную операцию? Кажется, что помимо косвенной адресации погут быть и другие разрешенные операции, которые могут привести к схожим атакам.
1. Если я правильно понимаю, реализация всего этого дела опирается на то, что MMU работает настолько медленно, что процессор успевает минимум два раза сходить в медленную RAM, прежде чем получит ответ, что так нельзя — это действительно так?
2. После получения первого значения процессор начинает его использовать, не дожидаясь ответа, можно ли было его вообще получать. Если я правильно понимаю, примерно из-за ожидания ответа в таком случае Meltdown не реализуется на AMD. Но в каком именно случае процессор таки будет дожидаться ответа от MMU, прежде чем сделать очередную операцию? Кажется, что помимо косвенной адресации погут быть и другие разрешенные операции, которые могут привести к схожим атакам.
1. Тут можно разрисовывать варианты работы MMU и думать, почему так. Например, в TLB — кэше таблицы трансляции адресов — хранятся только собственно адреса, но не права доступа, поэтому ALU быстро достаёт оттуда нужный физический адрес, пока MMU медленно собирается идти в ОЗУ за таблицей прав доступа к нему. Далее представляется логичным дать приоритет ALU, чтобы оно первым достало из памяти данные и поехало работать дальше, а MMU подождёт. В результате, когда MMU наконец пустили до памяти, ALU улетело вперёд уже на десятки операций.
Это я чисто спекулятивно, искать, как оно реально устроено в Интелах, сейчас лень — да и не уверен, что это есть в открытом доступе. У AMD в такой схеме могут быть или другие приоритеты (другой баланс между потребностями ALU и MMU), или в TLB уже лежат и права доступа тоже, например.
2. Могут быть и другие, но косвенной адресации более чем достаточно для счастья. Нет даже повода искать что-то ещё.
Это я чисто спекулятивно, искать, как оно реально устроено в Интелах, сейчас лень — да и не уверен, что это есть в открытом доступе. У AMD в такой схеме могут быть или другие приоритеты (другой баланс между потребностями ALU и MMU), или в TLB уже лежат и права доступа тоже, например.
2. Могут быть и другие, но косвенной адресации более чем достаточно для счастья. Нет даже повода искать что-то ещё.
TLB — это часть MMU, см http://www.cs.vu.nl/~giuffrida/papers/anc-ndss-2017.pdf "Fig. 2. Memory organization in a recent Intel processor.… The MMU performs the translation from the virtual address to the physical address using the TLB before accessing the data or the instruction since the caches that store the data are tagged with physical addresses (i.e., physically-tagged caches).".
Права доступа негде хранить, кроме как в TLB (их оригинал хранится в PT data structure, в PTE, но до настоящей pte далеко). Так как права должны быть проверены к моменту retire каждой инструкции, работающей с памятью, они не могут читаться из памяти или из обычных кэшей (всё чтение в L1 включая попадание в TLB и проверку прав занимает 4 такта). При этом права из TLB могут быть выдаваться в какие-то другие направления…
https://xem.github.io/minix86/manual/intel-x86-and-64-manual-vol3/o_fe12b1e2a880e0ce-140.html
https://xem.github.io/minix86/manual/intel-x86-and-64-manual-vol3/o_fe12b1e2a880e0ce-141.html
Each entry in a TLB… contains the… The access rights from the paging-structure entries…
https://xem.github.io/minix86/manual/intel-x86-and-64-manual-vol3/o_fe12b1e2a880e0ce-133.html
https://googleprojectzero.blogspot.ru/2018/01/reading-privileged-memory-with-side.html
The underlying idea is that the permission check for accessing an address might not be on the critical path for reading data from memory to a register, where the permission check could have significant performance impact. Instead, the memory read could make the result of the read available to following instructions immediately and only perform the permission check asynchronously, setting a flag in the reorder buffer that causes an exception to be raised if the permission check fails.
Так как права должны быть проверены к моменту retire каждой инструкции, работающей с памятью, они не могут читаться из памяти
Это не так. Даже сам адрес в ходе трансляции может читаться из ОЗУ, т.к. TLB — это кэш, он по определению не покрывает всех возможных адресов трансляции, не говоря уж о том, что он тупо сбрасывается в ноль при переключении контекста на большинстве процессоров.
Each entry in a TLB… contains the… The access rights from the paging-structure entries
where the permission check could have significant performance impact
Если оба утверждения корректны, то механизм возникновения significant performance impact, если и физический адрес, и права доступа достаются одновременного и из одного и того же места, остаётся неясен.
TLB — это кэш, но все операции доступа к памяти (в нормальных режимах) проходят через него и не могут завершиться без выдачи физадреса из tlb. При промахе всех уровней tlb будет совершен (в MMU) pt walk, заполнение строки в tlb, трансляция физадреса + проверка прав. Т.е. инструкция работы с памятью не может завершиться, пока не ответил TLB.
Непонятно почему в TLB сохраняется только физический адрес, а не полностью аттрибуты доступа. TLB явно работает как CAM (content-addressable memory, идет сравнение тегов виртуального адреса с выставленным) поэтому странно. что физадрес из TLB извлечь успевают, а извлечь и проверить аттрибуты — нет. Я склоняюсь к тому что это именно архитектурный залет, технических же проблем реализовать проверку аттрибутов нет.
Я не утверждаю, что права не хранятся в TLB, более того, выше есть ссылки, утверждающие, что это не так — и они там хранятся.
Но тогда вдвойне непонятно, откуда возникает такой performance impact на проверку прав доступа, что проще эту проверку отложить на потом.
Но тогда вдвойне непонятно, откуда возникает такой performance impact на проверку прав доступа, что проще эту проверку отложить на потом.
Про performance impact — это только предположение исследователей уязвимости. Время извлечения аттрибутов из TLB точно такого же порядка как и время извлечения физадреса. Возможно там есть сложности собственно проверки аттрибутов (многие биты режима работы процессора тоже конвееризуются), но решаемые, имхо, если задасться целью. Вероятнее всего, блок проверки прав сделан в уязвимых процессорах отдельно и работает асинхронно в целях упрощения структуры.
В общем, там должна быть веская причина делать именно так — потому что логика откладывания проверки не выглядит самоочевидной, и не пережила бы двадцать лет и кучу поколений процессоров одного производителя, чтобы потом ещё и вылезти у другого.
Нам, впрочем, её всё равно вряд ли расскажут.
Упрощение структуры тут вряд ли является причиной — в современных процессорах наверчено уже столько, что на лишнюю сотню тысяч транзисторов в MMU посмотрят далеко не в первую очередь.
Нам, впрочем, её всё равно вряд ли расскажут.
Упрощение структуры тут вряд ли является причиной — в современных процессорах наверчено уже столько, что на лишнюю сотню тысяч транзисторов в MMU посмотрят далеко не в первую очередь.
>>логика откладывания проверки не выглядит самоочевидной
Пока оно выглядит так что аттрибуты доступа просто сохраняются рядом с полученными данными, и проверяются непосредственно в момент instruction retirement. Это позволяет иметь валидный контекст исключения на момент проверки. Гораздо сложнее «собрать» этот контекст при спекулятивном исполнении. В любом случае, нет оправдания почему не сделана хотя бы предварительная проверка прав в момент доступа к памяти и прекращение спекулятивного исполнения, если проверка не пройдена. Пенальти то тут никакого — ветка будет отброшена или из-за ложного предсказания исполнения, или таки из-за исключения.
>>что на лишнюю сотню тысяч транзисторов
Имелся ввиду не транзисторный бюджет, а именно сложность разработки архитектуры.
Пока оно выглядит так что аттрибуты доступа просто сохраняются рядом с полученными данными, и проверяются непосредственно в момент instruction retirement. Это позволяет иметь валидный контекст исключения на момент проверки. Гораздо сложнее «собрать» этот контекст при спекулятивном исполнении. В любом случае, нет оправдания почему не сделана хотя бы предварительная проверка прав в момент доступа к памяти и прекращение спекулятивного исполнения, если проверка не пройдена. Пенальти то тут никакого — ветка будет отброшена или из-за ложного предсказания исполнения, или таки из-за исключения.
>>что на лишнюю сотню тысяч транзисторов
Имелся ввиду не транзисторный бюджет, а именно сложность разработки архитектуры.
В любом случае, нет оправдания почему не сделана хотя бы предварительная проверка прав в момент доступа к памяти и прекращение спекулятивного исполнения, если проверка не пройдена.В некоторых случаях данные могут использоваться позже и есть смысл их загрузить заранее. Например запись в copy-on-write страницу вызовет исключение и последующее копирование в обработчике страничных ошибок. Я думаю, что Intel обнаружил небольшое увеличение производительности при таком спекулятивном кешировании.
Физадрес из tlb cam надо сразу выдавать в сторону кэш-памяти для параллельной сверки тэгов в VIPT L1 (приблизительно/условно так http://images.slideplayer.com/39/10978514/slides/slide_23.jpg http://images.slideplayer.com/23/6620421/slides/slide_16.jpg). Выдаются ли права доступа в сторону кэша — неясно (для них неважно, будет ли попадание в кэш), их надо проверить и выдать в какое-то устройство OOO-конвейера — ROB / MOB / retire...
Насколько я понял, перенос памяти ядра в другое адресное пространство — не единственный метод борьбы с этой уязвимостью. Можно, например, при попытке чтения памяти ядра сбрасывать весь кэш процессора. Возможно это в некоторых применениях будет эффективнее? Хотя, конечно если не изменить при этом алгоритмы таймменеджмента ОС — можно будет сильно затормозить систему используя этот механизм.
Вся соль в том, что в момент чтения процессор не знает относится ли читаемая память к ядру.
А, до меня дошло — исключение в этом случае не генерится, потому что результаты отбрасываются, так что да, не получится.
Оно внутри процессора генерируется, иначе бы он не знал, что результат надо отбросить. Но — в случае Intel и свежих ARM — только после того, как данные de facto прочитаны.
Я имел в виду, что исключение по обращению к памяти, которое запрещено по уровню привилегий приложения, не вызывает прерывание, которое ядро могло бы обработать, и сбросить кэш. В принципе, на уровне микрокода, наверное, такое прерывание можно было бы добавить, но это, вероятно, приведёт к большому числу случайных срабатываний так что такой метод ещё больше затормозит процессор. А вот с точки зрения обнаружения атаки через эту уязвимость — думаю, было бы полезно.
но это, вероятно, приведёт к большому числу случайных срабатываний так что такой метод ещё больше затормозит процессор
Вообще нет, при нормальной работе каких-то особо частых попаданий в чужую память быть не должно, если бы спекулятивное выполнение часто приводило к промахам — оно было бы тупо неэффективно, т.к. сброс конвейера дорого стоит.
Но это всё равно так себе решение, т.е. требует взаимодействия процессора и софта и при этом не даёт ничего, кроме зажигания лампочки «что-то тут не так».
Если сбросить весь кэш по попытке чтения памяти ядра — это полностью закроет уязвимость. Другое дело что это на порядки больший тормоз чем единичный кэш-промах, и неизвестно какая программа, написанная с точки зрения программной модели вполне корректно начнёт дико тормозить систему. Но если обрабатывать это прерывание антивирусом не всегда, а так, чтобы оно не тормозило систему, можно набрать статистику по подозрительным участкам кода, а потом посмотреть на них более детально и определить, пытается ли программа использовать уязвимость.
Простите за возможно очень нубский вопрос, но в вопросах архитектурного устройства CPU и RAM у меня познания весьма невелики. Как я понял, суть дырки в том, что вредоносный код лезет туда, куда низзя, его за это посылают, но код определяет содержимое по интонации (задержке) отказа. И в итоге процессор может спалиться, как в анекдоте:
— Дед, люди говорят, у вас винтовка есть?
— Врут.
— Дед, люди говорят, у вас пулемет есть.
— Врут.
— Дед, люди говорят, у вас пушка есть.
— Врут.
— Дед, люди говорят, у вас танк есть.
— Врут.
— Дед, люди говорят, у вас атомная бомба есть.
— А вот чего нет, того нет.
То есть, отличающийся от других ответ говорит, что значение ячейки памяти угадано, а дальше по цепочке как-то к другим ячейкам подбирает значения? Если нет, то где моя ошибка?
Ну и вопрос практического характера. Имею комп на i5-7600, включенный 24/7, с постоянно открытым браузером. ОС — Винда 7 (ну не люблю я десятку), с отключенными обновами. Никаких биткоин-кошельков на компе нет, к тому же счету вебмани или банк-клиенту авторизация все равно смартфоном прикрыта (двухфакторная авторизация), админок с правами, способными навредить какому-то ресурсу или стащить оттуда что-то ценное тоже нет. Я где попало не хожу обычно, и за всю жизнь ни одного серьезного виря не ловил (червячки максимум, лет 7 назад). Поэтому вопрос: мне бояться или выдыхать?
Насколько я понимаю, системам, у которых на процессоре работает один пользователь, бояться особо нечего, за исключением JavaScript-эксплойтов, которые должны более или менее прикрыть разработчики браузеров (если на винде работает какой-то левый код, то он может наворотить дел и без этой уязвимости). Большая проблема возникает, если на одном CPU выполняется код разных пользователей — тогда один из них получает доступ к памяти остальных.
То есть, отличающийся от других ответ говорит, что значение ячейки памяти угадано, а дальше по цепочке как-то к другим ячейкам подбирает значения?
А дальше адрес увеличивается на единицу и подбирается значение дальше. В итоге получаем кусок памяти, в котором возможно что-то интересное.
к тому же счету вебмани или банк-клиенту авторизация все равно смартфоном прикрыта (двухфакторная авторизация)
Всегда можно вытащить токен/кукис, который позволит зайти без авторизации. Если не от банк-клиента, так хоть от почты/соцсети/итд. А «где попало не хожу» — плохая защита, не гарантирует того, что хороший сайт не сломают и не добавят туда маленький скрипт. Но вопрос с эксплуатацией уязвимости через браузерный JS остается открытым.
Как я понял, суть дырки в том, что вредоносный код лезет туда, куда низзя, его за это посылают, но код определяет содержимое по интонации (задержке) отказа. И в итоге процессор может спалиться, как в анекдоте
Почти так. Если совсем строго — вредоносный код в явном виде даже никуда не лезет, он просто подстраивает ситуацию так, что процессор лезет туда сам, вперёд батьки в пекло. Поэтому формально код даже и не посылают.
Ну подумаешь, комп станет частью ботнета и примется рассылать спам и майнить крипту) можно дышать спокойно…
Ну подумаешь, комп станет частью ботнета и примется рассылать спам и майнить крипту)
Логика мне подсказывает, что если такое случится, то комп станет медленнее, что будет видно в диспетчере задач по уровню загрузки проца, горячее и шумнее. А уж шум кулера повышенный я сразу засеку, так как сейчас он на 300 об/мин постоянно лопатит, все тихо. И если я пойму, что это не термопаста, обнаружу какие-то мутные-непонятные процессы и т.д. — я в таких случаях просто нафиг переустановлю винду, на всяк пожарный проверю, все ли "лишние" порты залочены на роутере, плюс потом попрошу провайдера сменить мне айпишник.
Данная уязвимость не позволяет запускать код, она позволяет только извлечь данные: пароли, куки, сертификаты, интимные фотки…
olartamonov, подскажите, реально ли извлечь ключи кошельков криптовалют. Например, насколько опасны сервисы, не закрывшие софт-заплаткой свои мощности, но которые сдают мощности майнерам или частные фермы/кластеры.
Или 2. Можно ли как-нибудь с помощью этой «архитектурной особенности» противостоять шифровальщикам (дешифровать данные), etc.
Или 2. Можно ли как-нибудь с помощью этой «архитектурной особенности» противостоять шифровальщикам (дешифровать данные), etc.
Теоретически реально извлечь всё перечисленное, а также всё остальное, не перечисленное.
В системах без специальных аппаратных криптопроцессоров любые ключи и пароли в тот или иной момент оказываются в памяти в полностью открытом виде, независимо от того, как они зашифрованы или иным образом защищены при хранении, потому что другого способа работы с ними нет.
В системах без специальных аппаратных криптопроцессоров любые ключи и пароли в тот или иной момент оказываются в памяти в полностью открытом виде, независимо от того, как они зашифрованы или иным образом защищены при хранении, потому что другого способа работы с ними нет.
Но, кстати, конкретно шифровальщики используют несимметричное шифрование, поэтому ключа для дешифровки у вас на компьютере не будет ни в каком виде.
Если б там было симметричное, ключ можно было бы так или иначе достать из тушки шифровальщика и применить.
Если б там было симметричное, ключ можно было бы так или иначе достать из тушки шифровальщика и применить.
Скорее, это работает так:
— Дед, люди говорят, у вас винтовка есть?
— Есть.
— Дед, люди говорят, у вас пулемет есть.
— Есть.
— Дед, люди говорят, у вас пушка есть.
— Есть.
— Дед, люди говорят, у вас танк есть.
— Есть.
— Дед, люди говорят, у вас атомная бомба есть?
—… не дожидаясь ответа, потому что ответ будет «не положено тебе про атомные бомбы знать»… Дед, а красные атомные бомбы бывают?
—… задумался… Бывают.
— Дед, а зеленые атомные бомбы бывают?
—… задумался… Бывают.
— Дед, а синие атомные бомбы бывают?
—… мгновенно, потому что уже вспомнил бомбу в сарае… Бывают.
Я уже сгораю от нетерпения, жду статью про spectre. Правда по описанию, мне показалась что в этом статье именно это и было описано.
Спасибо за статью, на все понятно и доходчиво.
Ждем вторую часть.
Конечно то сколько лет назад была допущена данная аппаратная ошибка… крутовато.
Но обновами кое-как заткнут, подкрасят и OK.
Немного фантазии:
Виноваты Скайнет, Реплилоиды, путешественники во времени (Наиболее вероятны).
А так да заложенная в далёком прошлом архитектурная уязвимость.
Вот интересно вылезла только на современных CPU из-за их быстродействия?
На на каком нибудь 4 пне не будет столь эффективно работать?
Ждем вторую часть.
Конечно то сколько лет назад была допущена данная аппаратная ошибка… крутовато.
Но обновами кое-как заткнут, подкрасят и OK.
Немного фантазии:
Виноваты Скайнет, Реплилоиды, путешественники во времени (Наиболее вероятны).
А так да заложенная в далёком прошлом архитектурная уязвимость.
Вот интересно вылезла только на современных CPU из-за их быстродействия?
На на каком нибудь 4 пне не будет столь эффективно работать?
Будет интересно посмотреть на то как тру хацкеры крадут ключи шифрования из моей оперативной памяти и достают с моего компа котов.
НЛО прилетело и опубликовало эту надпись здесь
По статье следует, что уязвимость позволяет чтение памяти по виртуальным адресам, чтение которых не было разрешено коду. Не запись и не чтение по произвольным физическим адресам.
В былые времена я пробовал писать свою игрушечную ОС, поэтому я знаю, что все пользовательские приложения на Intel всегда работают в 3-ем кольце защиты, а ядро в нулевом (1-ое и 2-ое кольцо существуют, но обычно не используются). Сами же по себе приложения по кольцам защиты никак не разделены (банально потому что колец защиты не хватит на всех), но имеют разные виртуальные адресные пространства. Таким образом, уязвимость открывает только доступ к структурам ядра, но не структурам других приложений.
Да, это плохо. Ведь в структурах ядра тоже могут содержаться данные, которые не стоило бы раскрывать. Например, ключи шифрования файловой системы (ведь этим занимается дравйвер из нулевого кольца). Плюс всякие буферы ввода-вывода (одно приложение туда запишет данные, а другое через уязвимость прочитает, хотя эта информация предназначалась вообще драйверу или третьему приложению). Но это значит, что есть немало информации, раскрытие которой не является уязвимостью. Например, сам исполняемый код ядра и драйверов. Это и так практически открытая информация — ведь весь этот софт находится в свободном или почти свободном доступе (в смысле платном, но от конечного пользователя не убудет, если кто-то сможет таким образом «спиратить» коммерческий драйвер или ОС, которые он купил).
Отсюда следует, что для закрытия уязвимости достаточно не полностью изолировать пространство ядра, а лишь вынести из него информацию, которая не имеет отношения к текущему процессу (например, чужие буферы ввода-вывода, чужие файловые дескрипторы и т. д.). Конечно, это тоже ударит по производительности, но в меньшей степени, ибо большинство системных вызовов работают с объектам, которые принадлежат самому процессу. От того, что процесс через уязвимость сможет прочитать кеш записи файла, в который он только что сам же записал данные, ничего страшного не случится.
Где я не прав?
В былые времена я пробовал писать свою игрушечную ОС, поэтому я знаю, что все пользовательские приложения на Intel всегда работают в 3-ем кольце защиты, а ядро в нулевом (1-ое и 2-ое кольцо существуют, но обычно не используются). Сами же по себе приложения по кольцам защиты никак не разделены (банально потому что колец защиты не хватит на всех), но имеют разные виртуальные адресные пространства. Таким образом, уязвимость открывает только доступ к структурам ядра, но не структурам других приложений.
Да, это плохо. Ведь в структурах ядра тоже могут содержаться данные, которые не стоило бы раскрывать. Например, ключи шифрования файловой системы (ведь этим занимается дравйвер из нулевого кольца). Плюс всякие буферы ввода-вывода (одно приложение туда запишет данные, а другое через уязвимость прочитает, хотя эта информация предназначалась вообще драйверу или третьему приложению). Но это значит, что есть немало информации, раскрытие которой не является уязвимостью. Например, сам исполняемый код ядра и драйверов. Это и так практически открытая информация — ведь весь этот софт находится в свободном или почти свободном доступе (в смысле платном, но от конечного пользователя не убудет, если кто-то сможет таким образом «спиратить» коммерческий драйвер или ОС, которые он купил).
Отсюда следует, что для закрытия уязвимости достаточно не полностью изолировать пространство ядра, а лишь вынести из него информацию, которая не имеет отношения к текущему процессу (например, чужие буферы ввода-вывода, чужие файловые дескрипторы и т. д.). Конечно, это тоже ударит по производительности, но в меньшей степени, ибо большинство системных вызовов работают с объектам, которые принадлежат самому процессу. От того, что процесс через уязвимость сможет прочитать кеш записи файла, в который он только что сам же записал данные, ничего страшного не случится.
Где я не прав?
везде прав, только сложность реализации. Сейчас нужно «всего лишь» переключить адресное пространство во время системного вызова. А в вашем случае переписывать кэши и много чего еще.
Полное скрытие всего — да, хорошее временное решение (потому что сейчас надо решать проблему максимально быстро, пока не начались массовые атаки). Но в перспективе надеюсь будут разработаны и варианты скрытия только того, что действительно нужно скрывать. Ради производительности можно и помучаться, не?
Но это уже никак не «найденная уязвимость может быть решена ТОЛЬКО снижением производительности на 30%». Это «найденная уязвимость может быть БЫСТРО решена только снижением производительности на 30%, в будущем можно решить её снижением производительности на 1%».
(цифры условные)
Но это уже никак не «найденная уязвимость может быть решена ТОЛЬКО снижением производительности на 30%». Это «найденная уязвимость может быть БЫСТРО решена только снижением производительности на 30%, в будущем можно решить её снижением производительности на 1%».
(цифры условные)
Таким образом, уязвимость открывает только доступ к структурам ядра, но не структурам других приложений.
А вот для структур других приложений и предназначен Spectre.
Не-а, проще. Через память ядра обычно можно достать всю физическую память системы, то есть, если к ней есть доступ из пространства памяти приложения, то между ним и всем остальным на компьютере нет никаких барьеров, кроме прав доступа.
Насколько я понял, Meltdown позволяет обратится только к памяти ядра отображенной в пользовательский процесс, а не вообще к любой. А Spectre — к памяти любого пользовательского процесса, но не ядра. В Meltdown используется out-of-order исполнение и прерывание по доступу, а в Spectre — спекулятивное исполнение и переполнение буфера (или подобное). При этом в обоих случаях данные получаются через кэш, играя с процессором в «угадайку». Подобные техники называются side channel среди хакеров. Я назвал бы эту — «гадание по кэшу».
А нет какого-то отдельного кусочка памяти ядра, который был бы отображён в память процесса, а всё остальное ядро не было бы.
Оно целиком там. А в нём — целиком физическая память, гуляй не хочу.
До сего момента никто даже не видел смысла заморачиваться с тем, чтобы сделать как-то иначе.
Нет. В Meltdown не возникает прерывания, в Spectre — переполнения. Спекулятивное выполнение формально не порождает ни того, ни другого.
Оно целиком там. А в нём — целиком физическая память, гуляй не хочу.
До сего момента никто даже не видел смысла заморачиваться с тем, чтобы сделать как-то иначе.
В Meltdown используется out-of-order исполнение и прерывание по доступу, а в Spectre — спекулятивное исполнение и переполнение буфера (или подобное)
Нет. В Meltdown не возникает прерывания, в Spectre — переполнения. Спекулятивное выполнение формально не порождает ни того, ни другого.
Я читал доклад об этих уязвимостях, прерывание возникает когда выполняется попытка прочитать память ядра, но из-за out-of-order данные все же попадают в кэш. В Spectre, мы «заманиваем» предсказатель перехода в ветку с доступом за границы буфера в коде процесса-жертвы и таким образом также в кэш попадают данные недоступные иначе. Далее в обеих случаях происходит «угадывания» данных попавших в кэш. Как-то так, насколько я понял.
Нет, прерывания не возникает.
Оно не может и не должно там возникать, т.к. данные читаются в ходе спекулятивного выполнения инструкций, о котором программа не знает и знать не может — так что внезапно, посреди совершенно корректного кода прилетевшее прерывание GPF ей будет немного как гром среди ясного неба.
Оно не может и не должно там возникать, т.к. данные читаются в ходе спекулятивного выполнения инструкций, о котором программа не знает и знать не может — так что внезапно, посреди совершенно корректного кода прилетевшее прерывание GPF ей будет немного как гром среди ясного неба.
Ну, вообще говоря, в оригинальной meltdown.pdf рассматривается как раз случай с исключением. Другое дело, что если вместо него использовать branch prediction miss, то будет то же самое.
Давайте не путать. Исключение — возникает, руководствуясь им, процессор считает результат спекулятивного выполнения невалидным и сбрасывает весь конвейер. Исключение — это внутренняя ошибка процессора, она наружу не всегда передаётся.
К генерации прерывания это исключение не приводит, так как любые прерывания при спекулятивном выполнении генерируются тогда и только тогда, когда оно будет признано успешным.
Вот если бы это было не спекулятивное выполнение, тогда да, исключение приводило бы к прерыванию, а атакующая программа получала бы от ОС в лоб segmentation fault.
К генерации прерывания это исключение не приводит, так как любые прерывания при спекулятивном выполнении генерируются тогда и только тогда, когда оно будет признано успешным.
Вот если бы это было не спекулятивное выполнение, тогда да, исключение приводило бы к прерыванию, а атакующая программа получала бы от ОС в лоб segmentation fault.
Именно это описано в работе о spectre, однако в meltdown.pdf на сайте meltdownattack.com, которые я воспринимаю изначальным источником информации, рассматривается случай, когда мы напрямую читаем память ядра и напрямую получаем segmentation fault. Потом мы его обрабатываем с помощью хендлеров или подавляем с помощью TSX, но мы его получаем.
кстати согласен с вопросом. В оригинале там реально вроде ловили уже эксепшен.
У вас неправильная терминология. Исключение (exception) — это подвид прерывания (interrupt). Оба вполне реальны.
wiki.osdev.org/Exceptions
ЕМНИП, именно так обстоят дела в доках Интела.
В нашем случае это неслучившееся исключение, кандидат на исключение или ещё как-то так.
wiki.osdev.org/Exceptions
ЕМНИП, именно так обстоят дела в доках Интела.
В нашем случае это неслучившееся исключение, кандидат на исключение или ещё как-то так.
А, то есть, операция с доступом к защищенной памяти находится в заведомо недосягаемой ветви программы, но из-за out-of-order она все равно попадает на исполнение и потом отбрасывается, но данные в кэше остаются?
Это уже зависит от реализации ядра. Я не вижу веских причин маппить всю физическую память в пространство ядра.
Так просто до сих пор не было никаких причин делать иначе.
Отобрази всё, а там уже процессор разберётся, кто свой, а кто чужой.
Отобрази всё, а там уже процессор разберётся, кто свой, а кто чужой.
Я правильно понимаю, как происходит в современных ОС вызов функции из ядра (syscall)?
1. Весь код ядра отображается в виртуальное пространство каждого процесса. Но на эти страницы права для процесса выставлены так, что код самого процесса может по адресам страниц ядра только execute, но не read и не write.
Код процесса делает вызов по некоторому адресу относящемуся к ядру, когда процессор переходит к выполнению кода с этого адреса, то виртуальное адресное пространство не меняется т.е. весь фарш процесса остаётся по тем же адресам. Только меняется кольцо исполнения на ring 0 и код из ядра может делать всё, что хочет. Всё верно?
2. Не очень понятно, с адресом вызова. Ведь процесс мог бы сделать вызов не на адрес начала функции, а в её середину, поломав всё. Но так не происходит. Значит и execute можно делать не для всего отображённого ядра, а только для небольшой части, видимо, некоторой таблицы jump-ов на сами функции. Или как оно работает?
3. Ядро отображается целиком в виртуальное адресное пространство процесса, для экономии времени, чтобы не нужно было переписывать таблички сопоставления адресов?
4. Раньше вызов функций ядра делался через определённое прерывание, но от этого отказались, т.к. медленно?
Где про всё это прочитать? Желательно на русском. Уровень знаний: лопух, делал лабораторные работы на ассемблере в пределах ста строчек. =)
P.S.: Надеюсь, не сочтёте нубские вопросы бестактными. Вас и так, видимо, завалили комментариями к статьям.
1. Весь код ядра отображается в виртуальное пространство каждого процесса. Но на эти страницы права для процесса выставлены так, что код самого процесса может по адресам страниц ядра только execute, но не read и не write.
Код процесса делает вызов по некоторому адресу относящемуся к ядру, когда процессор переходит к выполнению кода с этого адреса, то виртуальное адресное пространство не меняется т.е. весь фарш процесса остаётся по тем же адресам. Только меняется кольцо исполнения на ring 0 и код из ядра может делать всё, что хочет. Всё верно?
2. Не очень понятно, с адресом вызова. Ведь процесс мог бы сделать вызов не на адрес начала функции, а в её середину, поломав всё. Но так не происходит. Значит и execute можно делать не для всего отображённого ядра, а только для небольшой части, видимо, некоторой таблицы jump-ов на сами функции. Или как оно работает?
3. Ядро отображается целиком в виртуальное адресное пространство процесса, для экономии времени, чтобы не нужно было переписывать таблички сопоставления адресов?
4. Раньше вызов функций ядра делался через определённое прерывание, но от этого отказались, т.к. медленно?
Где про всё это прочитать? Желательно на русском. Уровень знаний: лопух, делал лабораторные работы на ассемблере в пределах ста строчек. =)
P.S.: Надеюсь, не сочтёте нубские вопросы бестактными. Вас и так, видимо, завалили комментариями к статьям.
Почти так.
Передача управления от пользовательского кода к ядру происходит по прерыванию, в линуксе это 0x80, т.е. процессу не надо знать заранее адреса функций ядра и не надо иметь вообще никакого доступа к адресному пространству ядра.
Передача управления от пользовательского кода к ядру происходит по прерыванию, в линуксе это 0x80, т.е. процессу не надо знать заранее адреса функций ядра и не надо иметь вообще никакого доступа к адресному пространству ядра.
Эм… А я думал, что теперь используется инструкция syscall, вместо int.
blog.rchapman.org/posts/Linux_System_Call_Table_for_x86_64
""«Note: 64-bit x86 uses syscall instead of interrupt 0x80.»""
Только я сам перемудрил, как оно используется. Полагал, что syscall выполняется в виде «syscall адрес», а оно просто «syscall». При этом выбор происходит через регистр. Или я опять ничего не понял?
blog.rchapman.org/posts/Linux_System_Call_Table_for_x86_64
""«Note: 64-bit x86 uses syscall instead of interrupt 0x80.»""
Только я сам перемудрил, как оно используется. Полагал, что syscall выполняется в виде «syscall адрес», а оно просто «syscall». При этом выбор происходит через регистр. Или я опять ничего не понял?
Таким образом, уязвимость открывает только доступ к структурам ядра, но не структурам других приложений.
Не совсем так. Поскольку предполагалось, что хардварной проверки доступа достаточно для защиты, в целях производительности сисколлов и удобства в ядрах большинства систем, помимо собственно структур ядра, в адресное пространство ядра отображается также и физическая память целиком. В конце концов, на 64-битных системах виртуальное адресное пространство содержит 2^64 адресов, и пусть даже у компьютера десятки и сотни гигабайт оперативки, это все равно будет капля в море виртуальной памяти. Соответственно, возможность прочитать память ядра = возможности прочитать память любого процесса, работающего рядом. В этом суть фикса KAISER и его аналогов для других ОС — он убирает это отображение физической памяти и прочих структур ядра, кроме совершенно необходимых. Плата за это — необходимость восстанавливать маппинг памяти при системных вызовах, что приводит к просадке производительности.
> поэтому при условии отсутствия ошибок в ПО различные процессы не имеют доступа к данным друга друга, если такой доступ не был предоставлен в явном виде.
Вообще-то различные процессы не должны иметь доступа к данным друга друга, если такой доступ не был предоставлен в явном виде, даже
при условии ПРИСУТСТВИЯ ошибок в доступающемся процессе.
Т.е. процесс дающий доступ должен явно открыть разделяюмую область и назначить права доступа на нее. А процесс пытающийся получить доступ должен его получить только если у него есть права.
И уж тем более он не должен получить доступ к неразделяемой памяти другого процесса/ядра/гипервизора. И за это должен был отвечать ЦПУ, виртуализируя адресное пространство.
Вообще-то различные процессы не должны иметь доступа к данным друга друга, если такой доступ не был предоставлен в явном виде, даже
при условии ПРИСУТСТВИЯ ошибок в доступающемся процессе.
Т.е. процесс дающий доступ должен явно открыть разделяюмую область и назначить права доступа на нее. А процесс пытающийся получить доступ должен его получить только если у него есть права.
И уж тем более он не должен получить доступ к неразделяемой памяти другого процесса/ядра/гипервизора. И за это должен был отвечать ЦПУ, виртуализируя адресное пространство.
Если я правильно помню организацию памяти в x86 (в x86_64-процах, по-моему, не слишком сильно отличается), то:
Есть используемые системой области данных. Они доступны только из ring0 и описываются в GDT
Есть используемые программой области данных. Они доступны из ring3 и описываются в LDT
ОС делает области памяти, описываемые в GDT и используемые в ring0, недоступными для кода ring3, но в то же время они проецируются на адресное пространство любого процесса.
И вот этот эксплоит как раз позволяет считывать эти данные из системных областей памяти. И из того, что можно там найти — например, буфер клавиатуры, пароль root или ещё что-нибудь важное.
Я правильно понимаю суть уязвимости?
Есть используемые системой области данных. Они доступны только из ring0 и описываются в GDT
Есть используемые программой области данных. Они доступны из ring3 и описываются в LDT
ОС делает области памяти, описываемые в GDT и используемые в ring0, недоступными для кода ring3, но в то же время они проецируются на адресное пространство любого процесса.
И вот этот эксплоит как раз позволяет считывать эти данные из системных областей памяти. И из того, что можно там найти — например, буфер клавиатуры, пароль root или ещё что-нибудь важное.
Я правильно понимаю суть уязвимости?
Правильно.
В современных ОС за небольшим исключением сегментация для защиты памяти не используется. То есть тупо создаётся 4 сегмента с нулевой базой и максимальной длинной. ring0 код, ring0 данные, ring3 код, ring3 данные. А вся защита уже воротится на уровне таблиц страниц, которые задают преобразование виртуальных адресов на физические. При этом у каждой страницы есть флаг «доступно из ring3». Для кода из ring0 (в CS в настоящий момент находится селектор сегмента ring0 кода) этот бит игнорируется, для кода из ring3 при отсутствии этого бита происходит прерывание и ядро решает, что делать с провинившимся процессом.
Спасибо!
А как работает контроль доступа по адресам, на который возлагается надежда в патче?
Нужные страницы будут проецировать на виртуальное адресное пространство только внутри системных вызовов, а перед выходом — убирать проекцию?
А как работает контроль доступа по адресам, на который возлагается надежда в патче?
Нужные страницы будут проецировать на виртуальное адресное пространство только внутри системных вызовов, а перед выходом — убирать проекцию?
Что-то вроде этого, да. Почти все структуры ядра, кроме тех, которые необходимо маппить из-за архитектуры процессора, перестанут маппиться "по умолчанию", Цитата из статьи о Meltdown:
The KAISER patch by Gruss et al. [8] implements
a stronger isolation between kernel and user space.
KAISER does not map any kernel memory in the user
space, except for some parts required by the x86 archi-
tecture (e.g., interrupt handlers). Thus, there is no valid
mapping to either kernel memory or physical memory
(via the direct-physical map) in the user space, and such
addresses can therefore not be resolved. Consequently,
Meltdown cannot leak any kernel or physical memory
except for the few memory locations which have to be
mapped in user space.
We verified that KAISER indeed prevents Meltdown,
and there is no leakage of any kernel or physical memory.
Furthermore, if KASLR is active, and the few re-
maining memory locations are randomized, finding these
memory locations is not trivial due to their small size of
several kilobytes. Section 7.2 discusses the implications
of these mapped memory locations from a security per-
spective.
Вот до чего доводят разного рода «спекуляции»
Кроме того, участки памяти могут иметь разные уровни доступа, контроль за которыми также осуществляет MMU — в результате пользовательское приложение не сможет получить доступ к памяти, занимаемой ядром системы или драйверами, даже если соответствующие адреса формально ему доступны.Вот тут я немного не понял: зачем надо делать какие-то куски памяти формально доступными процессу и при этом запрещать ему доступ через уровень доступа.
у современных процессоров есть процедуры косвенной адресации, указывающие, что процессор должен прочитать значение X, лежащее по адресу Y, а потом — значение Z, лежащее по только что прочитанному XХотелось бы примеры таких инструкций. Насколько я помню, это требует двух инструкций процессора; впрочем, при достаточно длинном конвейере это не помешает.
Представьте, что у нас есть доступная приложению область памяти, поделённая на два куска с разными приоритетами — у одного приоритет собственно приложения, у другого приоритет ядра {...} — дёрнуть что-то из того же куска виртуальной памяти намного быстрее, чем ходить каждый раз в другой кусок, а приоритеты решают проблему запрета приложению на прямой доступ к этому куску.Ну, хорошо. А что лежит во втором куске памяти? Я надеюсь, там нет ничего такого, что не имеет отношения к этому приложению (например, список страниц памяти данного приложения или список открутых им файлов).
На адресе 98 время доступа вдруг оказывается в несколько раз ниже, чем на других адресахВообще-то, кэш загружает в себя данные большими кусками. Т.е. на процессора 386 и 486 с размером строки кэша в 16 байт быстрый доступ будет к адресам от 96 до 111; а на современных — даже трудно представить себе, сколько именно.
Наверно, надо как-то так: «Процессор в спекулятивном режиме читает значение по адресу 15000. Пусть там будет лежать, например, 98. Это число умножается на размер строки кэша (ну, там не умножение, а сдвиг) — и тогда уже делается следующее чтение.
Наше приложение начинает читать адреса от 0 и выше в собственном адресном пространстве (имеет полное право), замеряя время, требующееся на чтение каждого адресаПростите, а каким таймером можно замерить это время? Ведь тут даже нельзя накапливать статистику, многократно читая одно и то же место памяти — ибо разница будет только на первом обращении, а потом содержимое памяти уже в кэше.
Таким образом мы можем прочитать всю память ядра системы, на которую, в свою очередь, в современных ОС отображается вообще вся физическая память компьютера.Ну и какой неумный человек додумался отображать в память ядра „всю физическую память компьютера“???
И вообще, глупость какая-то получается:
Сначала нам говорят, что в адресном пространстве процесса/приложения есть его собственная память; а есть память ядра, защищённая от доступа уровнем доступа.
А потом оказывается, что в этом адресном пространстве (в области, защищённой уровнем доступа) есть вообще вся память компьютера. Что эта „вся память компьютера“ там делает, зачем она там нужна?
При этом не надо забывать, что Javascript в браузере — это тоже локально выполняющийся код.Вообще-то, Javascript в браузере — это интерпретируемый код, а не код процессора. К тому же он не умеет обращаться напрямую к адресам. Или я отстал от жизни?
глупо предполагать, что Intel запланировала это за двадцать лет до реального использования и в надежде, что никто раньше не обнаружит случайно.Сделали уязвимость — и спокойно ждали, что кто-то обнаружит уязвимость. Неважно, когда.
Вот тут я немного не понял: зачем надо делать какие-то куски памяти формально доступными процессу и при этом запрещать ему доступ через уровень доступа.
Потому что процесс иногда обращается к функциям ядра, а обращаться к тому же куску виртуальной памяти — сильно быстрее, чем к другому. При этом процесс не должен быть способным напрямую читать эту память.
А что лежит во втором куске памяти? Я надеюсь, там нет ничего такого, что не имеет отношения к этому приложению
Туда ядро отражено. Там лежат тонны всего, что не имеет никакого отношения к этому приложению.
Это число умножается на размер строки кэша
Излишнее усложнение объяснения, требующее уйти в рассуждения об организации кэша. Но да, на практике, при реальной атаке — умножается.
Простите, а каким таймером можно замерить это время?
Микросекундного на практике более чем достаточно.
А потом оказывается, что в этом адресном пространстве (в области, защищённой уровнем доступа) есть вообще вся память компьютера
Вы концепцию виртуальной памяти себе представляете? У процесса потенциально есть 64 бита адресного пространства, туда не то что всю память компьютера отобразить можно, а добрую половину галактики, и не заморачиваться по этому поводу.
Вообще-то, Javascript в браузере — это интерпретируемый код, а не код процессора
Интерпретируемый код в конечном итоге выполняется тем же процессором, а отнюдь не святым духом.
Неважно, когда
Также, видимо, неважно, кто из конкурентов на этом себе продажи поднимет.
Потому что процесс иногда обращается к функциям ядра, а обращаться к тому же куску виртуальной памяти — сильно быстрее, чем к другому.Впервые слышу, что вирт.память делится на куски. Про страницы — знаю. Про сегменты (а также ппро проблемы от их использования) — знаю. А вот слово «кусок» в данном применении вижу впервые. Как оно в оригинало хоть звучит?
Туда ядро отражено. Там лежат тонны всего, что не имеет никакого отношения к этому приложению.Я бы понял, если бы в адресное пространство процесса отображались только данные тех функций, которые этот процесс может вызвать. Но зачем передавать туда вообще всё, что имеется в распоряжении ядра?
Я вижу только одну причину: архитекторам системы было лень осуществлять изоляцию разных сущностей (тут часто говорят «уровней абстракции»; но термин неадекватен, ибо это не стек, не иерархия) друг-от-друга.
Кажется, старик Танненбаум с его идеей микроядра был прав: с микроядром такие фокусы не прокатили бы.
И кстати, интересно — способна ли подобная атака выйти за пределы вирт.машины.
Излишнее усложнение объяснения, требующее уйти в рассуждения об организации кэша.А без этого объяснения — совершенно неясно, каким образом это работает. Да собственно, описанный алгоритм и не работает.
Микросекундного {таймера} на практике более чем достаточно.Хм, а как его опрашивают? Не будет ли опрос таймера сбивать содержимое кэша?
Кстати, опрос таймера с высокой частотой — это характерный признак подобной атаки. Особенно вкупе с действиями по опустошению кэша.
У процесса потенциально есть 64 бита адресного пространства, туда не то что всю память компьютера отобразить можно, а добрую половину галактики, и не заморачиваться по этому поводу.Мне кажется, Вы путаете «можно» и «нужно».
Интерпретируемый код в конечном итоге выполняется тем же процессором, а отнюдь не святым духом.Я в курсе. Однако, интерпретатор может не содержать кода, который внутри условного оператора обращается к недоступной ему памяти!
Также, видимо, неважно, кто из конкурентов на этом себе продажи поднимет.У Intel разве есть конкуренты? ;)
А вот слово «кусок» в данном применении вижу впервые. Как оно в оригинало хоть звучит?
«Блоки адресного пространства с различными уровнями доступа» вас устроит? Ну если да, то так дальше и пишите.
Но зачем передавать туда вообще всё, что имеется в распоряжении ядра?
Затем, что иначе вам надо целенаправленно писать процедуры, которые смогут разделить то, что нужно передавать, и то, что ненужно. Если вы на минуту задумаетесь об этом вопросе — вам станет понятно, почему ни один человек в здравом уме этого делать не будет.
То есть, например, с вашей точки зрения, как будет выглядеть механизм, определяющий, что именно в линуксовом ядре надо показать процессу для выполнения им конкретного сисколла?
Хм, а как его опрашивают? Не будет ли опрос таймера сбивать содержимое кэша?
Вы себе представляете кэширование значения, запрошенного у таймера?.. Во-первых, с какой целью вы себе это представляете, во-вторых, на x86 самый точный из таймеров — это одна команда, RDTSC, отдаёт 64-битный счётчик циклов процессора.
У Intel разве есть конкуренты? ;)
Ах, ну да, ещё Мур в семьдесят третьем писал, что нет и он может на пятьдесят лет гарантировать, что не будет.
Т.е. сторонники микроядерной архитектуры — ненормальные? А мне после прочтения этой статьи показалось, что именно они оказались правы — хотя аргумент в их защиты приплыл с совершенно неожиданной стороны.Но зачем передавать туда вообще всё, что имеется в распоряжении ядра?Затем, что иначе вам надо целенаправленно писать процедуры, которые смогут разделить то, что нужно передавать, и то, что ненужно. Если вы на минуту задумаетесь об этом вопросе — вам станет понятно, почему ни один человек в здравом уме этого делать не будет.
Впрочем, я сейчас размышляю над куда более интересной идеей — «надо отказаться от UMA и перейти к полностью раздельной памяти». В такой системе ядро операционки будет частично выполняться на пользовательских процессорах (их много), а частично будет вынесено на собственные процессоры (их тоже много). И у каждого процессора будет своя собственная память.
При такой схеме ситуация «в адресном пространстве ядра в числе прочего есть вся физическая память компьютера» становится физически невозможна.
То есть, например, с вашей точки зрения, как будет выглядеть механизм, определяющий, что именно в линуксовом ядре надо показать процессу для выполнения им конкретного сисколла?Очевидно — данные, затрагиваемые этим сисколлом.
Вы себе представляете кэширование значения, запрошенного у таймера?А кроме этого значения ничего более не используется?
Впрочем, ответ «RDTSC» снимает все вопросы — это действительно не сбивает кэш.
Присоединяюсь к вопросу:
Предположим, что размер строки кэша = 16. Как мы узнаём, что по адресу 15000 лежало именно 98, ведь в кэш попадут как 98, так и ещё 15 значений вокруг него?
В кеш не попадёт число 98, а ЧТО-ТО по адресу 98. Верней даже не так, для уверенности туда будет попадать содержимое памяти по адресу 98*4096, где число 98 — это индекс взятый по адресу 15000, и потом проверяя время доступа к ячейкам НАШЕГО массива даже если в тот массив ничего не было положено(из-за ограничений доступа) можно определить в какую область памяти было обращение и выяснить какое значение индекса было использовано процессором для реальной команды при спекулятивном выполнении. Можно конечно проверять КАЖДУЮ ячейку массива, но достаточно любую ячейку которая попала в диапазон кеш-линии, то есть достаточно проверить каждую 4096-ю ячейку а их у нас ровно 256 и элемент к которому будет минимальное время доступа — будет искомым индексом и стало быть значением ячейки памяти по адресу 15000.
по поводу javascript, я думаю это кто-то ляпнул в одной из первых статей про уязвимость, а дальше начали копипастить
Достаточно призрачной теоретической возможности, чтобы опасаться — с учетом того, что какой JS выполняется на компах, никто и никогда не контролирует, полагаясь на изоляцию от других сайтов и от других процессов.
Ляпнули там примерно так, цитирую:
«Attacks using JavaScript. In addition to violating process isolation boundaries using native code, Spectre attacks can also be used to violate browser sandboxing, by mounting them via portable JavaScript code. We wrote a JavaScript program that successfully reads data from the address space of the browser process running it»
«Attacks using JavaScript. In addition to violating process isolation boundaries using native code, Spectre attacks can also be used to violate browser sandboxing, by mounting them via portable JavaScript code. We wrote a JavaScript program that successfully reads data from the address space of the browser process running it»
Вообще-то, Javascript в браузере — это интерпретируемый код, а не код процессора. К тому же он не умеет обращаться напрямую к адресам. Или я отстал от жизни?
Гугловский V8, например, использует JIT-компиляцию. А напрямую обращаться к адресам не обязательно, можно сделать это косвено, например, запросив элемент массива с индексом, выходящим за его границы.
Для этого надо, чтобы JIT-компилятор сгенерил код, реализующий соответствующую атаку. Ну, допустим, мы можем долго экспериментировать с JS-программой, анализируя, какой код получается.
Но дальше нам надо знать, какие адреса у нас свободны, а какие заняты. Как нам это сделать?
Ну и наконец, командой "RDTSC" (см.выше) воспользоваться явно не получится.
Я правильно понял, что вычитать данные, лежащие в 15000, если там было записано 98, мы сможем, увидев изменение скорости на чтении по адресу 98? А если бы там лежало нечто такое, на что нам адресов не хватило бы?
2. Процессор читает значение, лежащее по адресу 98.
А что если этот адрес тоже не доступен? Может такое быть?
Самая лучшая и понятная статья на данный момент. Спасибо.
Статья об атаке на кэш из браузера за 2015 год (!!!)
arxiv.org/pdf/1502.07373.pdf
arxiv.org/pdf/1502.07373.pdf
На самом деле, вопрос о реализации кеша именно в интеловских процессорах и возможность ПОДОБНОЙ уязвимости была озвучена как минимум лет 5 назад… просто тогда это было не так актуально и не резонансно, о Heartbleed ещё никто даже не подозревал… ну а сейчас просто выстрелило.
А что с виртуальными площадками (AWS, Azure, ...)?
Предположим, крутится у меня линух на одной из них. Поставил я на него заплатку. А злоумышленник запустил свою виртуалку, и, естественно без патча. В итоге делим мы с ним один проц, кэш общий, и он может из свой ОС читать все, что внутри моей, и даже патчи не помогут?
Нет, не сможет.
Окей.
Значит уязвимость даже в случае виртуальных площадок сугубо локальная, и если не запускать на сервере стороннего кода (и уж тем более страниц c JS через командную строку), то, формально, можно не беспокоиться?
И если все действительно так, то в данном случае большему риску подвергнуты скорее пользовательские машины, чем сервера (на которых локально установлен только необходимый софт)?
Немного упустил из вида про патч в своем вопросе, поэтому уточню.
Информацию из соседней виртуалки не получится выкрасть в случае установленного патча или не получится даже и без патча, если, именно, локально не запустить?
Виртуалка через meltdown не может прочитать ничего из других виртуалок на том же хосте, и не важно стоят ли какие-то патчи на любых ОС или не стоят. Это, естественно, не означает, что не может найтись какой-нить другой способ (особенно если гипервизор плохо сделан, но я не в курсе что там у них с качеством).
Есть вопрос к компетентным товарищам: зашёл я на интеловский сайт с описанием действий при обсуждаемой проблеме — Intel Management Engine Critical Firmware Update (Intel-SA-00086) и забрал оттуда утилиту Intel-SA-00086 Detection Tool. Процессор у меня на основной рабочей станции Intel Core i5-3450, чипсет — H61, версия Intel ME — 11.0.0.1156. И утилита мне выдала занятное — «Эта система не является уязвимой.»
Значит ли это, что мне чудовищно повезло и мало того, что ME обновлять не надо, так еще и обновление KB4056892 на Windows 10 мне не нужно?
Значит ли это, что мне чудовищно повезло и мало того, что ME обновлять не надо, так еще и обновление KB4056892 на Windows 10 мне не нужно?
Для винды уже появилась тестовая тулза, которая считывает байтики из ядра:
github.com/stormctf/Meltdown-PoC-Windows/tree/master/Meltdown/x64/Debug
Эти байтики находятся в самом начале образа ntoskrnl.exe (см. на картинке ряд real).
github.com/stormctf/Meltdown-PoC-Windows/tree/master/Meltdown/x64/Debug
Эти байтики находятся в самом начале образа ntoskrnl.exe (см. на картинке ряд real).
Выглядит как-то так себе. Что, на мой взгляд, ожидаемо — современные ОС многозадачные и кеш забивают многие другие процессы.
Тут нигде не совпало, т.е. не работает?
проверил на нескольких компах — ни байта не сходится
кстати екзешник там странный 212480 байтов
многовато
я перекомпилил сорцы получил 8704 :)
кстати екзешник там странный 212480 байтов
многовато
я перекомпилил сорцы получил 8704 :)
> Кто бы это мог быть? Ах, да, это наш дорогой процессор. По адресу 15000, соответственно, лежит значение 98.
Из описания проблемы совершенно непонятно, откуда код приложения берет цифирь 15000, которое является адресом в пространстве ядра.
Из описания проблемы совершенно непонятно, откуда код приложения берет цифирь 15000, которое является адресом в пространстве ядра.
Насколько теперь реально сбагрить интеловские процы по гарантии, и получить деньги по чеку?
Сразу предупреждаю: вопрос не ради спора, а исключительно токмо ради пославшей мя жены ради интереса. Насколько вообще реальна атака с применением Metldown in-the-wild? Ведь, в отличие от PoC, вредоносному коду/атакующему не известны базовые адреса загрузки прикладных программ в произвольно взятой системе, а, значит, например, добраться до памяти браузера и хешей/паролей будет довольно нетривиально (не перебирать же и тем более не дампить всю доступную память?). Ведь, насколько я помню, например, Windows гарантирует загрузку только компонентов ядра по определенным адресам, даже системные DLL грузятся динамически (могу ошибаться, интересовался этим очень давно).
VPS сервис. к примеру. Если на хосте чувствительные данные есть в переменных окружения, то их можно будет получить сдампив кусок памяти.
Так ядро знает, какой процесс у него где живёт, и если мы имеем доступ к памяти ядра, мы тоже можем это узнать.
А что мешает сдампить всю, а потом регулярками номера кредиток найти? Уязвимости обычно всегда используются в паре или трио. Сам факт, что подобное возможно ставит безопасность компьютерных систем под большой вопрос.
Как вы себе это представляете? Незаметно сдампить, скажем, 16 ГБ памяти (при том, что чтение через Meltdown весьма небыстрая операция) и потом ее передать куда-то? Это, во-первых, слишком заметно и, во-вторых, абсолютно нецелесообразно. Эти же дампы потом еще надо будет где-то хранить и как-то обрабатывать.
Ну что Вы в самом деле.
Петя вон сидел в системе и не шевелился до своего звёздного часа.
Что мешает в дуэте с другой уязвимостью дождаться пока юзер пойдет спать, а потом начать читать всё подряд или тыкать палочкой в процессы которые хранят ключи и кредитные карты, или банально делать те же дампы при живом юзере, только не загружая процессор так, что юзер заметит. Часто обычный пользователь наблюдает за тем, какой процесс сколько ресурсов использует? Да 99% пользователей даже не знает где это посмотреть.
Петя вон сидел в системе и не шевелился до своего звёздного часа.
Что мешает в дуэте с другой уязвимостью дождаться пока юзер пойдет спать, а потом начать читать всё подряд или тыкать палочкой в процессы которые хранят ключи и кредитные карты, или банально делать те же дампы при живом юзере, только не загружая процессор так, что юзер заметит. Часто обычный пользователь наблюдает за тем, какой процесс сколько ресурсов использует? Да 99% пользователей даже не знает где это посмотреть.
НЛО прилетело и опубликовало эту надпись здесь
Насколько же человечество себя плохо вело в 2017м, раз такой подарочек от Санты?
Правильно ли я понимаю, что в будущем появится два типа процессоров: «защищённые и быстрые» и «не защищённые и очень быстрые»? Скажем для кодирования видео не важно защищенный процессор или нет.
Нет.
Во-первых, дыры такие, что для всех важно, защищённый это процессор или нет — кроме случая работы в строго контролируемом окружении, что для x86 некоторая редкость (поэтому, например, для Cortex-R наличие дырок не слишком принципиально, это процессоры для задач жёсткого реального времени, они в системах, где пользователь может какой-то код загрузить и исполнить, встречаются примерно никогда).
Во-вторых, Meltdown аппаратно можно закрыть без существенной потери производительности. Со Spectre сложнее, но вариант 2 тажке можно закрыть аппаратно без существенных потерь.
NB: существенными я считаю потери больше 2-3 %.
Во-первых, дыры такие, что для всех важно, защищённый это процессор или нет — кроме случая работы в строго контролируемом окружении, что для x86 некоторая редкость (поэтому, например, для Cortex-R наличие дырок не слишком принципиально, это процессоры для задач жёсткого реального времени, они в системах, где пользователь может какой-то код загрузить и исполнить, встречаются примерно никогда).
Во-вторых, Meltdown аппаратно можно закрыть без существенной потери производительности. Со Spectre сложнее, но вариант 2 тажке можно закрыть аппаратно без существенных потерь.
NB: существенными я считаю потери больше 2-3 %.
По сути Intel обманул и сам себя и весь мир: я бы назвал это «незаконная производительность». Это как бизнес построенный только на «чёрные деньги». Невозможен в принципе если играть по правилам.
НЛО прилетело и опубликовало эту надпись здесь
Весело.
Я что-то не понял: «адреса от 0 и выше в собственном адресном пространстве».
Так, что ли? Если так, то это, очевидно, работать не будет. :)
BYTE* p = 0; BYTE dest = *p;Так, что ли? Если так, то это, очевидно, работать не будет. :)
Не будет работать где?
Везде? Не существует ОС, в которой NULL — валидный адрес. Как и все в интервале 1-0xFF.
А что, у нас NULL обязательно имеет значение 0? Во всех языках программирования?
Я даже не говорю о том, что вы придираетесь к числам, про которые прямо сказано, что они написаны для примера. Вам в этом примере сколько ещё упрощений показать, которые вы не заметили?
Я даже не говорю о том, что вы придираетесь к числам, про которые прямо сказано, что они написаны для примера. Вам в этом примере сколько ещё упрощений показать, которые вы не заметили?
CP/M.
С третьей стороны, так как до недавних пор память считалась сравнительно безопасным местом временного хранения данных, то все ваши пароли и сертификаты лежат в ней в открытом виде.А как же «простукивание» DDR?
Я вот думаю — а нельзя ли частично отравлять кеш, иногда читая рандомные данные, чтобы внести некоторый процент шума в замеры времени доступа? Не будет ли вреда меньше?
Да и «простукивание кэша» уже демонстрировали.
Но это всё атаки, которые выполнялись либо в сугубо лабораторных условиях, либо демонстрировали передачу данных между двумя заранее подготовленными программами (например, через кэш процессора между двумя VM, не имеющими прямой связи друг с другом), либо демонстрировали лишь некие общие паттеры проходящей на компьютере активности.
Здесь же — в живой природе, без дополнительных условий, чтение чистых данных из ОЗУ.
Отравлять кэш довольно бессмысленно, его очень много у современных процессоров.
Но это всё атаки, которые выполнялись либо в сугубо лабораторных условиях, либо демонстрировали передачу данных между двумя заранее подготовленными программами (например, через кэш процессора между двумя VM, не имеющими прямой связи друг с другом), либо демонстрировали лишь некие общие паттеры проходящей на компьютере активности.
Здесь же — в живой природе, без дополнительных условий, чтение чистых данных из ОЗУ.
Отравлять кэш довольно бессмысленно, его очень много у современных процессоров.
>По адресу 15000, соответственно, лежит значение 98.
Мне вот что непонятно: а что, если в участке памяти, который доступен приложению, нет значения 98?
Мне вот что непонятно: а что, если в участке памяти, который доступен приложению, нет значения 98?
Не играет вообще никакой роли, какое значение есть в участке памяти, легально доступном приложению.
Извините, если совсем нубский вопрос, но мне тоже непонятно.
То есть, прочитать содержимое защищённого адреса в памяти можно только в том случае, если это содержимое, в свою очередь, указывает на участок в памяти, доступный приложению? А если нет? Если по адресу 15000 находится не 98, а 16000? Или вообще не указатель, а что-то ещё?
Получается, читать можно не всю защищённую память, а только те фрагменты, которые содержат указатели на и так доступные приложению адреса?
Если по адресу 15000 находится не 98, а 16000?
Замените в атаке array1[array2[x]] на array1[array2[x — 10000]]. На спекулятивное выполнение это никак не повлияет, с его точки зрения дополнительная арифметическая операция не стоит практически ничего.
NB: в настоящей атаке в индексах арифметика используется по-любому, чтобы обойти такие свойства процессора, как загрузка в кэш целыми блоками и опережающее чтение памяти.
Или вообще не указатель, а что-то ещё?
Указателей вообще не существует. Как той ложки. Это просто договорённость между программистами, что вот тут мы число считаем числом, а тут — указателем.
Кажется, что проблема раздута.
Программа запускается, ей выделяется виртуальное адресное пространство. Там есть область с куском памяти, доступной только ядру, или отображается часть рабочей памяти ядра?
Программа сможет прочитать эту область, и что там найдет?
К чему тут пароли и т.п. от других запущенных програм, они в другом адресном пространстве?
Выход простой — если программа вызвала ошибку-исключение доступа к памяти, то ОС убивает данную программу.
Всё сошлось,
мир с его квантовыми приколами работает на процессорах с предсказанием.
Когда электрон летит через две щели, процессор просчитывает оба варианта, а когда мы его ловим — иные варианты отбрасываются…
мир с его квантовыми приколами работает на процессорах с предсказанием.
Когда электрон летит через две щели, процессор просчитывает оба варианта, а когда мы его ловим — иные варианты отбрасываются…
С целью ускорения при операции чтения проверка прав доступа и само чтение выполняются одновременно. Так что практически все процессоры должны быть уязвимы. Вряд ли до сего момента кто-то заботился очистить значение в кэш при нарушении прав. У AMD это тоже, как пишут, работает, только затирается чаще. Для записи такая оптимизация не возможна.
а нельзя добавить в процессор процедуру принудительного обнуления в кэше данных, «запрещённых» MMU, желательно, сразу после «запрещения»?
Так понимаю, что владельцам яблочной техники, в отличие от андроидов, нечего бояться. Пусть пооцессоры в теории и имеют уязвимость, но политика эйпл в плане проверок приложений перед отправкой в стор сводит возможность её использования на нет. Остаётся джэйл и левые приложения. Но для последних операционок джэйла нет.
Итого, добрый день.
Верно ли я понимаю что проблема именно в этом
И процессору достаточно просто после выполнения пункта
Верно ли я понимаю что проблема именно в этом
То в кэше спокойно останется лежать значение, хранящее по адресу N.
И процессору достаточно просто после выполнения пункта
Результаты чтения адреса сброшены из регистров процессораеще и сделать очистку кеша в результате чего проблема невелируется?
Извините чайника за дурацкий вопрос, но нет ли ресурса со списком процессоров Intel, уже точно подверженных этим двум новым уязвимостям (пардон, что мешаю их тут вместе, но для не сведующего в деталях нет никакой разницы между ними по сути,- ибо суть одна- могут быть подвержены твои конф.данные утечке с компа или нет), чтобы тупо проверить свой проц компа Intel Core i5-3570K по списку?
Мне уже стало реально интересно, когда посреди этой истерии кто-нибудь, наконец, родит работоспособный пример. Пока все лишь бурно обсасывают подробности.
Да всё уже давно работает как 20 лет, все эти дыры давно эксплуатируются тем кому нужно, а сколько ещё дыр народу пока неизвестно… ооо…
Вот я и хочу лично наблюдать работоспособный пример — только не тот, который сам у себя что-то якобы крадет в стерильных условиях, а который реально читает из ядра или чужого процесса. Как это можно сделать?
У меня не получилось что либо прочитать из ядра ни на amd ни на intel проце. Из легально доступной памяти — с разной достоверностью (но везде достаточной для полного чтения) получается везде.
Вот тут twitter.com/brainsmoke/status/948561799875502080 кто-то показывает скриншот как он скомпилит эксплоит для meltdown и успешно применил его, можете у него спросить исходник (сам не пробовал, в твиттере не зареген и не уверен что он даст).
Вот тут twitter.com/brainsmoke/status/948561799875502080 кто-то показывает скриншот как он скомпилит эксплоит для meltdown и успешно применил его, можете у него спросить исходник (сам не пробовал, в твиттере не зареген и не уверен что он даст).
Процессор в спекулятивном режиме читает значение по адресу 15000. Пусть там будет лежать, например, 98.
Процессор читает значение, лежащее по адресу 98.
я правильно понимаю, что по адресу 1500 читается 1 байт, собственно потом надо проверить только адреса 0-255? Если так, то не проще виртуальную память сдвинуть немного, чтобы 0-255 не были доступны?
На адресе 98 время доступа вдруг оказывается в несколько раз ниже, чем на других адресах
А где гарантия, что другая ячейка не будет в кеше по другой причине, эта же память нашего приложения? код какойнить дергался или данные?
и читая их не по порядку, чтобы не натренировать тот же спекулятивный доступ
опять же, мы можем выполнять код таким образом, чтобы 100% не было спекулятивного выполнения? или можем только выполнять рекомендации и надеяться?
Отличная статья! Спасибо!
А как патч для ядра у cloud-провайдеров просадит производительность? Будет это 2 раза? 1й раз со стороны host-OS и второй уже в гостевой виртуалке после обновления?
А как патч для ядра у cloud-провайдеров просадит производительность? Будет это 2 раза? 1й раз со стороны host-OS и второй уже в гостевой виртуалке после обновления?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Новогодние подарки, часть первая: Meltdown