Новогодние подарки, часть первая: Meltdown

    Да, я знаю, что это уже третий материал на GT/HH по данной проблеме.

    Однако, к сожалению, до сих пор я не встречал хорошего русскоязычного материала — да в общем и с англоязычными, чего уж тут греха таить, та же проблема, там тоже многих журналистов изнасиловали учёные — в котором внятно раскладывалось бы по полочкам, что именно произошло 3 января 2018 года, и как мы будем с этим жить дальше.

    Попробую восполнить пробел, при этом и не слишком влезая в глубины работы процессоров (ассемблера не будет, тонких подробностей постараюсь избегать там, где они не нужны для понимания), и описывая проблему максимально полно.

    Тезисно: в прошлом году нашли, а в этом опубликовали информацию о самой серьёзной ошибке в процессорах за все десятилетия их существования. В той или иной степени ей подвержены все процессоры, используемые в настоящее время в настольных компьютерах, серверах, планшетах, смартфонах, автомобилях, самолётах, поездах, почте, телефоне и телеграфе. То есть — вообще все процессоры, кроме микроконтроллеров.

    К счастью, подвержены они ей в разной степени. К несчастью, самый серьёзный удар пришёлся на самые распространённые процессоры — Intel, причём затронул он абсолютно все выпускающиеся и практически все эксплуатируемые (единственным исключением являются старые Atom, выпущенные до 2013 года) процессоры этой компании.

    До сих пор вся система обеспечения информационной безопасности на локальном компьютере в основе своей полагалась на одну предпосылку: центральный процессор способен гарантированно обеспечить полную изоляцию выполняющихся на нём программ друг от друга, поэтому при условии отсутствия ошибок в ПО различные процессы не имеют доступа к данным друга друга, если такой доступ не был предоставлен в явном виде.

    Уберите эту предпосылку — и всё остальное рушится, как карточный домик.

    Конкретно в архитектуре x86 защищённый режим был представлен в процессорах 80286 и доведён до ума в 80386. При работе в нём приложения вместо прямого доступа к физической памяти получают виртуальные адресные пространства, отображаемые на физическую память так, что пространства разных приложений не пересекаются. Контроль за адресными пространствами реализован аппаратно — блоком MMU, Memory Management Unit — поэтому, если при запуске нового процесса ОС корректно выделила ему память, попытка вылезти за пределы этой памяти будет немедленно пресечена процессором. Кроме того, участки памяти могут иметь разные уровни доступа, контроль за которыми также осуществляет MMU — в результате пользовательское приложение не сможет получить доступ к памяти, занимаемой ядром системы или драйверами, даже если соответствующие адреса формально ему доступны.

    Всё было хорошо, пока не выяснилось, что сам процессор в ходе отработки своих внутренних алгоритмов может целенаправленно игнорировать MMU, а результаты работы этих алгоритмов могут быть косвенными путями получены программно.

    Все современные процессоры — если мы говорим конкретно про Intel x86, то это модели начиная с Atom 2013-го года, Pentium Pro и Pentium II — имеют функции спекулятивного выполнения инструкций и предсказания ветвлений, а также кэши инструкций и данных.

    Эти алгоритмы необходимы для обеспечения высокой производительности всей системы при условии, что все имеющиеся периферийные устройства, включая оперативную память, значительно медленнее центрального процессора. В случае, когда очередная выполняемая инструкция приводит к необходимости ожидания поступления данных снаружи, в течение периода ожидания процессор вместо простаивания начинает выполнять следующий за данной инструкцией код, исходя из ожиданий о том, какие именно данные с наибольшей вероятностью поступят.

    Например:

    if (x < array1_size)
    {
        y = array1[x]
    }

    При последовательном выполнении этого кода процессор сначала проверяет, что переменная x находится в пределах массива array1, а потом выполняет вторую строку. При спекулятивном выполнении после какого-то количества if'ов, в которых действительно x < array1_size, процессор начинает считать, что данное условие с высокой вероятностью выполняется. поэтому начинает выполнение второй строки, не дожидаясь вычисления условия.

    Что случается, если результат вычисления условия вдруг оказывается негативным? Процессор просто отбрасывает все предварительно вычисленные результаты и проводит вычисления заново, на этот раз уже последовательно. Одновременно модуль предсказания ветвлений снижает оценку вероятности того, что данное условие будет выполняться.

    Что случается, если переменная x оказывается расположенной не просто за пределами конкретного массива, а вообще за пределами доступной данному процессу памяти? Процессор всё равно выполняет вторую строку кода. Дело в том, что на работу модуля MMU, в задачу которого входит определение, разрешено ли вообще данному процессу что-то читать по адресу x, также нужно время, поэтому механизм спекулятивного выполнения относится к MMU ровно тем же образом, как и к внешним шинам — он начинает выполнение до того, как из MMU поступит ответ о корректности этого кода.

    Если MMU сообщает, что код некорректен, в эту память нельзя — процессор просто сбрасывает всё насчитанное.

    Длина «забегания вперёд» у современных процессоров легко может составлять десятки инструкций.

    На этой стадии всё пока ещё хорошо. Программа не знает о том, что происходит внутри процессора, если спекулятивное выполнение было самим процессором признано неудачным — его результаты ни одним из формальных путей в приложение не попадают (они не сохраняются ни в ОЗУ, ни в регистрах процессора). Всё, что можно зафиксировать снаружи — небольшую просадку темпа выполнения инструкций в момент, когда процессор понял, что кусок кода надо выполнить заново, и сбросил уже посчитанный результат и загруженные на конвейер команды (кто помнит дискуссии вокруг производительности Pentium 4, земля ему пухом, — там как раз был очень длинный конвейер, сброс которого обходился, соответственно, довольно дорого).

    Но у процессора есть ещё один блок, и этот блок работает полностью самостоятельно — это кэш. В кэш ложатся все данные, прошедшие через процессор. Кэш, повторюсь, совершенно автономен — он не знает и не хочет знать, почему и как эти данные в него свалились, были ли они загружены в результате спекулятивного или последовательного выполнения, было ли спекулятивное выполнение признано корректным или нет. Данные пришли — данные легли в кэш.

    То есть, если в рамках спекулятивного выполнения команд случится следующая последовательность:

    1. Прочитано значение по адресу в памяти N
    2. Получен ответ от MMU о невалидности данного адреса в контексте данного процесса
    3. Результаты чтения адреса сброшены из регистров процессора

    То в кэше спокойно останется лежать значение, хранящее по адресу N.

    Но и этого ещё мало, так как кэш — это внутреняя сущность процессора, ПО не может напрямую его читать. Однако, если ПО снова обратится по адресу N, то по скорости ответа процессора оно сможет определить, хранится ли соответствующее значение в кэше (быстрый ответ) или нет (медленный ответ).

    И вот тут мы подбираемся к интересной части: ПО всё ещё не может напрямую прочитать некий адрес N, находящийся за пределами его доступа, но уже может определить, читался ли этот адрес кем-либо ранее.

    Но ведь наше ПО по-прежнему не может в открытую читать адрес N, не так ли? Так. Но тут всё уже совсем просто: у современных процессоров есть процедуры косвенной адресации, указывающие, что процессор должен прочитать значение X, лежащее по адресу Y, а потом — значение Z, лежащее по только что прочитанному X. Ну да, работа с указателями.

    Представьте, что у нас есть доступная приложению область памяти, поделённая на два куска с разными приоритетами — у одного приоритет собственно приложения, у другого приоритет ядра. Так делают до позавчерашнего дня делали по умолчанию, чтобы приложению не приходилось далеко ходить за системными вызовами, уходящими в ядро — дёрнуть что-то из того же куска виртуальной памяти намного быстрее, чем ходить каждый раз в другой кусок, а приоритеты решают проблему запрета приложению на прямой доступ к этому куску.

    И, допустим, приложению в этом куске доступны адреса 0...9999, а ядру — 10000...20000, цифры тут неважны. И мы делаем конструкцию, расположенную в коде так, что процессор заведомо выполнит её в спекулятивном режиме (например, на тысячном повторении одного и того же цикла, 999 предыдущих повторений которого выполнялись корректно), и которая будет представлять собой косвенную адресацию по значению, лежащему по адресу 15000.

    1. Процессор в спекулятивном режиме читает значение по адресу 15000. Пусть там будет лежать, например, 98.
    2. Процессор читает значение, лежащее по адресу 98.
    3. От MMU приходит ответ о невалидности адреса 15000.
    4. Процессор сбрасывает конвейер и вместо значения, лежащего по адресу 98, выдаёт нам ошибку.
    5. Наше приложение начинает читать адреса от 0 и выше в собственном адресном пространстве (имеет полное право), замеряя время, требующееся на чтение каждого адреса, и читая их не по порядку, чтобы не натренировать тот же спекулятивный доступ
    6. На адресе 98 время доступа вдруг оказывается в несколько раз ниже, чем на других адресах

    Таким образом мы понимаем, что кто-то уже недавно читал что-то по этому адресу, в результате чего он попал в кэш. Кто бы это мог быть? Ах, да, это наш дорогой процессор. По адресу 15000, соответственно, лежит значение 98.

    Таким образом мы можем прочитать всю память ядра системы, на которую, в свою очередь, в современных ОС отображается вообще вся физическая память компьютера.

    Это называется Meltdown (CVE-2017-5754), и эта уязвимость полностью перечёркивает все имеющиеся в процессоре защитные механизмы.

    Кто подвержен Meltdown?


    Как минимум все процессоры Intel линейки Core, все процессоры Intel линейки Xeon, все процессоры Intel линеек Celeron и Pentium на ядрах семейства Core.

    Также подвержены уязвимости процессоры на ядрах ARM Cortex-A75, на которых, однако, пока что не выпущено каких-либо конечных устройств, а первый процессор — Qualcomm Snapdragon 845 на ядре Kryo 385, основанном на Cortex-A75 и Cortex-A53 — объявлен только месяц назад. Скорее всего, Kryo 385 также будет уязвим к Meltdown.

    Согласно заявлению Apple, «все iOS-устройства» подвержены Meltdown. Это, очевидно, не может относиться к вообще всем когда-либо использовавшимся в iPhone/iPad процессорам (в конце концов, какой-нибудь iPhone 4 использует стандартное ядро Cortex-A8), но ARM-процессоры в современных моделях iPhone и iPad можно считать уязвимыми.

    Кто не подвержен Meltdown?


    Здесь чуть вопрос сложнее, поэтому сначала переформулируем его так: на данный момент не удалось — и, возможно, не удастся никогда — показать уязвимость Meltdown на процессорах AMD и ARM Cortex, отличных от перечисленных выше.

    В оригинальной работе, публично открывающей подробности Meltdown, указывается, что на этих процессорах также были замечены изменения состояния кэша в результате спекулятивного выполнения инструкций, однако полезные данные получить не удалось.

    Возможно, логика работы данных процессоров такова, что практическая реализация уязвимости на них невозможна вообще — например, MMU успевает прервать спекулятивное выполнение до того, как процессор прочитает вторую ячейку памяти; в этом случае в кэше окажется значение первой ячейки (лежащей в недоступной нам области), что не позволит эксплуатировать уязвимость.

    Кроме того, ARM заявляет об уязвимости ядер Cortex-A15, Cortex-A57 и Cortex-A72 — формально компания относит эту уязвимости к Meltdown, называя оригинальный Meltdown «Variant 3», а обнаруженный в данных ядрах — «Variant 3a»

    На этих ядрах сделано довольно много процессоров, например, Samsung Exynos 5 и Exynos 7 (смартфоны Galaxy S5, Galaxy S6, Galaxy Note с 3 по 7), Qualcomm Snapdragon 650, 652, 653, 808 и 810, Mediatek Helio X20.

    К счастью, «Variant 3a», хотя и аналогичен «взрослому» Meltdown по причинам, сильно слабее по эффекту — он позволяет атакующему украсть содержимое не произвольных областей памяти, а лишь отдельных системных регистров процессора, пусть формально и недоступных на том уровне привилегий, который есть у атакующего.

    Это позволяет облегчённо выдохнуть и считать данные три ядра и все сделанные на них смартфоны фактически атаке не подверженными.

    Про кого мы не знаем, подвержен ли он Meltdown?


    Есть масса процессоров, которые ещё толком никто не проверял — как минимум потому, что «оглушающий успех» Intel затмил всех остальных. С хорошей вероятностью не подвержен MIPS. Про более маргинальные архитектуры сказать ничего нельзя, и, вероятно, до них ещё долго никто не доберётся.

    Если вас интересуют отечественные процессоры, то у Эльбруса своя архитектура, Байкал-Т1 построен на ядре MIPS P5600, Элвис — тоже на MIPS. С большой вероятностью они не подвержены Meltdown, хотя пока что в открытом виде информации об этом нет. Байкал-М построен на ядре Cortex-A57 и, соответственно, подвержен Meltdown.

    Наконец, неизвестен статус кастомизированных ARM-ядер — это, например, Samsung Mongoose (серия процессоров Exynos 8, смартфоны Galaxy S7, Galaxy S8, Galaxy Note 8), Qualcomm Krait и Kryo 2xx, HiSilicon Kirin и прочих — но с большой вероятностью они в значительной степени похожи на своих ровесников из стандартной линейки.

    Можно ли защититься от Meltdown программно?


    Да. Meltdown эксплуатирует игнорирование процессором уровней доступа к памяти, но не позволяет читать память, находящуюся за пределами выделенного приложению виртуального блока.

    Для всех распространённых ОС уже вышли или готовятся выйти патчи, переносящие область памяти ядра в другую облась, т.е. обеспечивающие защиту не только выставлением привилегий, но и контролем доступа по адресам — второе Meltdown обойти не может.

    Проблема в том, что при такой архитектуре системные вызовы (syscalls) становятся крайне накладными — они замедляются в несколько раз. Соответственно, реальные приложения также теряют в производительности, в зависимости от доли системных вызовов в конкретном приложении падение может составить от 1-2 до нескольких десятков процентов. Например, на PostgreSQL продемонстрировано падение более 20 %, в то время как в игрушках разницы практически нет.

    Кроме того, при подобном переключении страниц памяти принудительно сбрасывается TLB, Translation Lookaside Buffer — это кэш трансляций между виртуальной памятью и физической, когда меняется блок виртуальной памяти, он с очевидностью становится невалидным. В свежих процессорах Intel есть так называемый PCID, идентификатор процесса, который позволяет не сбрасывать весь TLB разом, а определить, к какому процессу какая запись имеет отношение. Использование PCID (он должен поддерживаться и ОС, и процессором) снижает потери на переключение между двумя кусками памяти, но не устраняет их полностью.

    Меньше всего угроза для игр и иных пользовательских десктопных приложений, так как они мало используют системные вызовы — в абсолютном большинстве из них падение производительности не превысит 3 %, что можно считать погрешностью измерений. Впрочем, всегда могут быть исключения в лице отдельных приложений.

    По этой причине данное поведение в ОС, скорее всего, будут включать только на процессорах, про которые известно, что они подвержены уязвимости. Тут тоже могут быть нюансы: например, в свежих патчах для ядра Linux есть не чёрный список уязвимых, а белый список неуязвимых, и в него пока входят только AMD.

    Когда не нужно защищаться от Meltdown?


    Meltdown относится к сугубо локальным атакам и подразумевает выполнение кода на вашем компьютере. Если никакой посторонний код, включая высокоуровневые языки, проникнуть на конкретный компьютер не может, Meltdown не опасен.

    При этом не надо забывать, что Javascript в браузере — это тоже локально выполняющийся код. Разработчики браузеров сейчас предпринимают усилия (по состоянию на 4 января Firefox 57.0.4 уже вышел, соответствующая версия Chrome ожидается до конца месяца) по снижению эффективности использования JS для подобных атак, например, сознательно загрубляют доступные таймеры так, чтобы JS-код не смог достоверно измерить время доступа к памяти, но эти меры лишь снизят эффективность атак, но не исключат их полностью.

    Если у вас стоит домашний сервер, который доступен только по сети, а софт на него вы устанавливаете исключительно из репозитария вашего любимого дистрибутива, то опасность для него будет заключаться только в сочетании Meltdown с каким-либо классическим эксплоитом, позволяющим подсадить вам «жучка» удалённо. Для атакующего удобство Meltdown будет заключаться в том, что с ним «жучку» не обязательно иметь какие-либо конкретные привилегии на атакуемой системе, достаточно запуститься на ней любым образом. С другой стороны, Meltdown позволяет только читать память, но не изменять её или выполнять какой-либо код. С третьей стороны, так как до недавних пор память считалась сравнительно безопасным местом временного хранения данных, то все ваши пароли и сертификаты лежат в ней в открытом виде.

    Поэтому лучше поставьте патч сразу, как только он будет доступен для вашей ОС.

    Несколько печальна может оказаться ситуация со смартфонами на Android, половина производителей которых известно в какого цвета тапочках видела все эти обновления — но, с другой стороны, у ARM подвержены Meltdown только новые старшие ядра, в то время как большинство неподдерживаемого ширпотреба сделано на старых и/или упрощённых ядрах.

    Покажите мне, как вы с этим рутовый доступ получите!


    Самое бессмысленное требование в дискуссиях о Meltdown. Уязвимости процессора не требуют обращения к верхнеуровневым абстракциям операционной системы — они даже не обходят их, они их просто не замечают.

    В этом и есть самая большая опасность эксплоита Meltdown — он никак не взаимодействует с операционной системой, а значит, не только практически не зависит от неё, но и не оставляет в ней никаких следов.

    Смогут ли антивирусы определять эксплуатирующее Meltdown ПО?



    В общем случае — нет. В частном — они смогут определять ПО, про которое иными путями стало известно об эксплуатации им уязвимости, но в самом коде ничего однозначно нелегитимного нет, так что попытка эвристического определения может привести к большому количеству ложноположительных срабатываний.

    Придумало ли Meltdown ЦРУ или KGB?


    Нет, им не надо. Если они очень захотят заложить в ваш процессор закладку — они вежливо попросят производителя добавить какой-нибудь специализированный модуль, по типу JTAG, который спокойно позволит кому положено читать что ему надо напрямую. Сложность современных ядер такова, что этот модуль никто вообще никогда не заметит, а если и заметит, то у него прошивка всё едино будет в зашифрованном виде «для обеспечения безопасности наших пользователей».

    Сделала ли Intel это специально, чтобы мы купили новые процессоры?


    Разумеется, нет. Во-первых, глупо предполагать, что Intel запланировала это за двадцать лет до реального использования и в надежде, что никто раньше не обнаружит случайно. Во-вторых, цикл проектирования и выпуска нового процессора — не меньше пары лет (что неплохо видно по выпуску железа на лицензируемых ядрах, будь то ARM или MIPS; в случае AMD или Intel мы не знаем, когда реально было закончено проектирование ядра, а видим только работу маркетингового отдела, по которой создаётся впечатление, что там всех дел на полгодика — тут, как говорится, «хорошо вам, товарищ политрук, рот закрыл — рабочее место убрано»). В-третьих, кстати, про ARM, на примере которого видно, что уязвимость может появиться в ядрах процессоров в любой момент, в том числе в новейших топовых моделях — говоря проще, до сих пор никто не задумывался о функционировании связки из MMU, кэша и предсказания ветвлений как о потенциально уязвимой области, а выбирал их алгоритмы, исходя из иных предпосылок. В-четвёртых, трудно представить удара по Intel больнее, чем быстрый выпуск линейки исправленных процессоров: влияние этого на продажи моделей, которыми уже завалены склады, представляете?

    Так что готовьтесь к тому, что 9-е поколение Intel Core будет иметь ту же уязвимость в полном объёме и полном составе.

    Хотя многие действительно рано или поздно задумаются о новом процессоре. Подозреваю, в AMD сейчас по этому поводу второй раз за неделю фейерверки и шампанское.

    Компания <Intel | AMD | ARM | Microsoft | Google | Amazon | etc.> заявила, что к обеду выпустит патч, который всё исправит


    Коротко: вот когда выпустит — тогда и посмотрим.

    В данный момент во всех компаниях, хоть как-то причастных к теме, из окон PR-отделов валит дым, а заявивших что-то кроме «к обеду мы всё исправим» просто молча выводят в коридор и расстреливают за углом. Последнее, что нужно всей индустрии, от производителей процессоров до владельцев датацентров — это паника среди их клиентов.

    В результате абсолютное большинство заявлений всех компаний, последовавших после раскрытия подробностей Meltdown, отличаются предельной неконкретностью и отсутствием хотя бы минимальных деталей о том, что именно и как именно будет ими исправлено к обеду.

    Смысла читать эти заявления, а тем более, фразы в стиле «это проблема легко исправляется внесением небольших программных изменений» в данный момент нет никакого, если в них далее не идёт перечень изменений с указанием, куда именно они вносятся. Просто вспоминайте старую истину про то, что хороший пиарщик никогда не врёт — он просто не говорит всей правды, а закавыченную фразу легко продолжить тезисом «… во все используемые на ваших компьютерах программы, драйверы и ОС», что несколько изменит её смысл.

    TL:DR


    Полная жопа, самая эпическая дыра за последние двадцать лет, но заплатка на ОС проблему устраняет полностью, пусть и ценой некоторой потери производительности. Владельцы AMD могут пока не волноваться.

    А что там со Spectre?


    Сейчас напишу отдельным текстом, ибо тема Spectre ещё обширнее.

    Часть вторая: Spectre
    Часть третья: хорошо ли мы себя вели
    Поделиться публикацией
    Ой, у вас баннер убежал!

    Ну. И что?
    Реклама
    Комментарии 265
    • +1
      Звучит так, как будто процессоры AMD не подвержены уязвимости из-за того, что они просто медленнее и успевают дождаться ответа mmu о некорректности вызова адреса памяти. Но вот сейчас замедлят Intel до их уровня — и будет ок.
      Не холивара ради :)
      • +12
        Или что MMU у них работает по другой логике и поэтому отрабатывает быстрее. Или что-то ещё, кто ж нам расскажет-то (нет, ну я знаю пару-тройку людей, которые наверное могли бы, но они ж мне расскажут только если я сначала в письменной форме пообещаю вам не рассказывать).

        Причём на самом деле возможна и ситуация, что уязвимость у них столь же реальна, просто эксплоиту её надо отрабатывать быстрее или чуть иначе — но я в целом к этому отношусь как к маловероятному варианту.
        • 0
          Причём на самом деле возможна и ситуация, что уязвимость у них столь же реальна, просто эксплоиту её надо отрабатывать быстрее или чуть иначе — но я в целом к этому отношусь как к маловероятному варианту.

          Вот это, кстати, самое интересное. Потому что не очень верится в столь большие различия в архитектуре процессоров у самых заклятых друзей.
          они ж мне расскажут только если я сначала в письменной форме пообещаю вам не рассказывать

          Жаль, очень жаль.
          • +6
            Вот это, кстати, самое интересное. Потому что не очень верится в столь большие различия в архитектуре процессоров у самых заклятых друзей.


            Ну почему, вот я вижу гипотетический сценарий, в котором процессор успевает прочитать первый адрес, но пока он читает второй (там же оба процесса медленные, он же их по первому разу читает из ОЗУ) — к нему прибегает MMU с воплями, и проц прерывает выполнение, в итоге не донося результат до кэша.

            Это не какое-то грандиозное архитектурное отличие, это в общем-то нюансы реализации, на которые до сих пор никто мог даже не обращать особого внимания, а выбирать их исходя из длины конвейера, архитектуры MMU, архитектуры контроллера памяти и архитектуры чёрта в ступе.
            • 0
              Короч, либо архитекторам AMD несказанно повезло, или они что-то предполагали с самого начала, лет надцать назад.
              Ждём про Spectre, там всё чудесатее, и непонятно вообще можно ли его эксплуатировать на реальных системах.
              • 0
                можно, но сложней. Для амд есть патч который убирает эту брешу, падение производительности на уровне погрешности.
                • 0
                  Да хватит бредить, нет этого патча.

                  См. вторую часть.
                  • 0
                    я конечно гляну, но получает амд врет?
                    • +1
                      AMD нигде не говорит, что этот патч есть у AMD или у кого-либо ещё.

                      AMD говорит, что однажды нам его кто-нибудь сделает.
              • 0
                Что случается, если переменная x оказывается расположенной не просто за пределами конкретного массива, а вообще за пределами доступной данному процессу памяти? Процессор всё равно выполняет вторую строку кода.

                Ну AMD сообщает, что их процессоры как раз корректно отрабатывают это исключение поэтому и не подвержены meltdown. Т.е. атака по таймингу есть, а вот вылазки за адресное пространство — нет. В связи с этим вам, возможно, правильнее использовать "процессоры Intel" вместо "процессоры" — в статье и комментариях.

                • +2
                  Да там уже не только Intel, ARM тоже отметился.
                  • 0

                    Ну я просто за справедливость: если разность в производительности/энергоэффективности Intel vs AMD последние 15 лет была обусловлена тем, что Intel забивала на bounds check до последнего момента, то сейчас справедливо было бы уточнять, что не все процессоры выполняют вторую строку кода (а скоро никто не будет).

                • 0
                  Я когда-то читал статью по устройству кешей в процессорах, из неё я точно помню что у INTEL и AMD работа кеша отличается довольно принципиально. Причем там же было предположение о возможности нынешней уязвимости на интеловских процессорах. Как-то они лихо срезали углы в ущерб безопасности но повысили быстродействие. Но это было достаточно давно, саму статью естественно не помню, читал её почти по диагонали — тогда это было просто интересно. Видимо тогда резонанс просто не получился ибо предполагали что уязвимость слишком сложная для реализации.
              • –1
                Если успели сходить только по первому (невалидному) адресу, то всё равно можно оценить, например — по изменению объёма наших закешированных данных.
                насколько понял из пейпера, это и пытались сделать — просто вероятность паршивая
                • 0
                  Так а кто ж даст кэш взвесить?
                  • +1
                    Это отдельная задача. Оценка какая линейка сейчас в кеш упала тоже сложная штука, но решилась же.
                  • 0
                    Если я все правильно понял, то за один раз возможно проверить байт по интересующему адресу на совпадение с одним значением (на 0 для простоты). Значит, реализуя тот же трюк второй раз, проверяем на 1. Итого, не более чем за 256 проверок будет получен результат. Где я налажал с рассуждениями?
                  • +2

                    В 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.
                    • +3
                      Да, вполне может быть и так. Тогда на AMD даже теоретической возможности эксплоита нет (а «игрушечный пример» в оригинальной работе по Meltdown, строго говоря, не демонстрирует доступ спекулятивного выполнения именно к закрытой от процесса памяти).
                • 0
                  Кто-нибудь знает, как закрытие уязвимости повлияет на тот или иной конкретный софт?

                  Лично меня интересуют:

                  Браузеры (конкретно — Опера)
                  2д редакторы графики: Illustrator, InDesign, Photoshop
                  WinRAR

                  • +2
                    На пользовательский десктопный софт в среднем по больнице повлияет мало, т.к. он в основном занимается своими делами, а ядро системы дёргает мало, ибо зачем оно ему.

                    Но, конечно, возможны исключения.
                    • 0
                      Но, конечно, возможны исключения.


                      Есть ли сайт, освещающий такие исключения? Или, быть может, стоит подписаться на вас — будете освещать? :)
                      • 0
                        Сайта пока точно нет, я точно не буду, мне эти все бенчармки уже много лет как малоинтересны.

                        На реддите где-нибудь будут коллекционировать результаты.
                    • 0
                      Исключения — работа с гигабитной сетью или nvme ssd
                      • 0
                        nvme ssd

                        Ну-ка, ну-ка? Я как раз присматриваюсь к nvme ssd, хочу улучшить рабочую станцию. Есть подробности?
                        • +1
                          От патча для meltdown для интела страдают все системные вызовы без исключения. Обычно это не является большой проблемой, но к системным вызовам также относятся работа с дисками и с сетью.
                          Пострадали все без исключения приложения, работающие с дисками, но обычно это выражается просто в увеличении загрузки процессора. В случае с nvme ssd проц и так в некоторых ситуациях был бутылочным горлышком при работе с диском, поэтому у них просела производительность. Я встречал отзывы, что скорость линейных чтения/записи упала до двух раз в бенчмарках. Про случайных доступ не знаю, но думаю, что он (т.к. ограничителем все же до сих пор выступает диск) просел не настолько много.
                          • 0
                            Ну, в случае уже моего уже относительно старенького samsung 950 pro (2500/1500) бенчмарк показал данные, весьма близкие к заявленным (2447/1498). Насколько помню, когда замерял сразу после покупки (год назад), цифры были похожими.
                          • 0
                            Для большинства рабочих задач просто любой ссд — уже сильно улучшение. Просто данный патч отьедает кусочек от каждого запроса к диску. А когда у вас ssd, он их может ОЧЕНЬ много переварить. В результате у вас загружен проц там, где раньше не был.
                        • 0
                          Sprint Layout — до патча МС 0:58, после патча МС-время запуска 1:11,7. Это с библиотекой макросов, замеры на i5-4210
                          Я патч убрал в конце концов.
                        • 0
                          Такой новогодний подарок принесли… что все ресурсы гудят уже как ульи с пчёлами обсуждая эту тему. Потому что такое не каждый день прилетает.
                          Ждём про Spectre, спасибо :)
                          • +3
                            Большинство ресурсов, кстати, те ещё мудаки. Все эти желтушные новости про потерю производительности в два раза после обновления приводят к тому, что люди отключают обновления, а потом происходит WannaCry и все ноют какой Windows плохой и дырявый.
                            • +3
                              Сам гугл так же выпустил статью про то, что много спекулятивных статей и на их серверах «незначительное» изменение производительности.
                              security.googleblog.com/2018/01/more-details-about-mitigations-for-cpu_4.html
                              image
                              • +1
                                Большинство ресурсов написали статьи без разъяснения и с посылом «шеф, всё пропало!». А всё потому что там основном писатели, а не люди которые понимают что происходит. И это печально.
                                Сейчас пошли статьи о том, что топ-менеджмент знал и сливали акции. Опять эти все вбросы и желтизна. Толкового материала как здесь, просто единицы.
                                • +1
                                  На данном этапе я бы просто игнорировал все заявления причастных компаний, которые не сопровождаются конкретными цифрами.

                                  Intel там вообще уже пообещал чуть ли не к обеду микрокод выпустить, который придёт и молча исправит всё. Неизвестно что конкретно, неизвестно как конкретно, но точно-точно всё исправит.
                                  • 0
                                    Вроде как они написали, что еще выпьют валерьянки на выходных и начнут поставку микрокода на следующей неделе и он будет полноценно работать на системах выпущенных за последние 5 лет (PCID?).
                                    • 0
                                      Вот как начнут — так и посмотрим, что он там делать будет.

                                      Из описания уязвимостей никаким очевидным образом не следует, как это можно закрыть микрокодом без падения производительности, а заявление Интела — это просто образчик политкорректности и обтекаемости, PR-отдел такое должен в рамочку на стенку вешать и учиться.

                                      Особенно если вспомнить их предыдущее заявление, выполненное в стиле «а чо сразу мы-то?».
                                      • 0
                                        Да это все бизнес. Те, у кого есть голова на плечах, умеют читать между строк и играть между струн.
                                        Мне без разницы как закроют. Нужно будет сегодня покопаться в коде примера спектра и пробовать заменить victim_function на что-то что сможет читать определенную область памяти. Сомневаюсь, что у меня получится, но попытка не пытка.
                                        • 0
                                          PoC, лежащему на гистк можно скормить адрес и количетсво данных для чтения в аргументах. Так что жаэе не придется ничего менять
                                          • 0
                                            Я это и так понял, хоть моих знаний в С не так много, и хотелось бы получить что-то более пристойное для эксплуатации, ну к примеру самый простой пример прочитать, что сейчас загружено процессом, ну и память же будет выделена кусками для процесса.
                                  • 0
                                    Архитектура систем подразумевает, что вы разносите процессы по серверам в соответствии с требуемыми ресурсами.
                                    На синтетических тестах у вас действительно могут быть просадки на 30%, но на реальной системе, даже на той, которая активно использует системные вызовы, у вас будет просадка меньше, есть еще сеть, память, и все это будет влиять. В масштабах датацентров класса GCP, AWS, FB доля таких сервером далеко не подавляющая, что и приводит к общей потери производительности измеряемой числами порядка единиц процентов. Под удар попадут клиенты, у которых основная масса серверов оказалась подвержена деградации производительности, но думаю, что таких довольно мало.
                                    • +2
                                      Сеть и доступ к ссд как раз наибольшее падение и показывает.
                                      Вы плохо понимаете, что происходит. ВСЕ нагруженные системы mysql, oracle, postgress паказывают 15% падение, а для многих 10% разницы это разница между живой и мертвой системой.

                                      Просто никому не нужна паника.
                                      • 0
                                        Вы можете показать это на падение на уровне всей инфраструктуры компании/проекта? Я еще понимаю, когда вся система закручена на ERP на SAP или Oracle и есть только пользовательские клиенты, но зачастую, сервера БД, хоть и критичны, но составляют далеко не большинство, даже внутри огромных компаний.
                                        И я на это смотрю с опыта работы в очень большой компании.
                                        • 0
                                          Я лично видел, как система падала от того, что ее поставили на процессор на 200мгц и 2мб кеша меньше, чем стояла до этого(и не падала).
                                          В базах данных расстояние от «успевает нормально» до «пошла увеличиватся очередь» буквально проценты.
                                          • 0
                                            Это как-то отменяет то, что написал я? Вы приводите крайний случай, в реальности же не доверять данным гугла об изменении общей нагрузки предпосылок нет.
                                            Все это уже давно описано и собрано в методологии. Есть понятия планирования ресурсов, которые учитывают управление рисками. И в данном случае мы имеем рисковый случай, все остальное зависит от качества управления компанией. А крайние случаи будут всегда, и тут еще вилами по воде писано, что дешевле и проще: накатить патч, протестировать нагрузку и заказать один-два сервера или потратить несколько сотен человеко часов на разруливание проблемы в корявом софте.
                              • 0
                                Процессор сбрасывает конвейер и вместо значения, лежащего по адресу 98, выдаёт нам ошибку.

                                По моему процессор в этом случае не выдает ошибку, а процесс получает сигнал segmentation fault и аварийно завершается. Разве не так ?

                                • +3
                                  Ну, процесс же откуда-то получает этот Segmentation Fault?

                                  У любого процессора есть набор прерываний, которыми он реагирует на подобные действия, ОС их обрабатывает и выдаёт по носу приложению (ну или предпринимает иные действия).

                                  На примере Cortex-M в силу их простоты сравнительной хорошо видно, как это работает. Там у младших (M0) на все случаи жизни единственное прерывание — Hard Fault, у которого наивысший приоритет и которое нельзя замаскировать, а в M3 уже начинается разделение на BusFault (лезем по несуществующему адресу), MemFault (лезем по неразрешённом нам адресу, там зачатки управления памятью уже есть), UsageFault (пытаемся выполнить мусор вместо инструкции), которые ПО может отрабатывать по отдельности, решая, что ему с этим делать.

                                  Собственно, даже пример вспомнил, как приложение лезет не в свою область памяти, но при этом корректно всё разруливает. Мы это используем, например, на Cortex-M3 для определения объёмов памяти, наличия всякой периферии и т.п. — просто маскируем прерывание BusFault, лезем по нужному адресу, если флажок BusFault встал, то там ничего нет, ставим отметку, что сюда не ходи, работаем дальше.
                                  • 0

                                    А разве в intel процессорах segmentation fault можно перехватить ?

                                    • +3
                                      Segfault — это же на уровне системы почти обычное прерывание, 13-й номер, кто-то же его должен обработать? Может или нет пользовательский код отнять его обработку у ОС — это вопрос к ОС, не к процессору. Вот пишут, что и под линуксом с виндой вполне можно.
                                      • +1
                                        По ссылке что-то слишком длинно расписано.
                                        «Перехват» segfault делается через конструкцию __try __except (называется structured exception handler, SEH) в msvc и через sigaction(SIGSEGV) (посмотрите man sigaction) в unix-подобных системах. Из обработчика SIGSEGV, если не хотите завершать процесс, можно выпрыгнуть назад в основной код с помощью longjmp().
                                      • +1
                                        Когда вы видите окошко типа «программа упала, не хотите ли отправить отчет такой-то матери», это с большой вероятностью выполняется обработчик SIGSEGV.

                                        Процесс прибивается принудительно, если он не выставил собственный обработчик.
                                    • 0

                                      Достаточно обернуть всю работу с этим значением в, условно,


                                      if (likely(false)) {
                                      
                                      }

                                      Процессор послушно прогреет кэш если спровоцировать branch misprediction, даже если этот код никогда не выполнится.

                                    • +1
                                      >>> кроме микроконтроллеров
                                      Ура! Мой Arduino UNO неуязвим!
                                      • –14
                                        Я не понимаю мотивации людей, которые обнародовали эту дыру. На мой взгляд это их действия превратили поведение алгоритма в опасную уязвимость. Ну нашли вы уязвимость, быстро стало ясно что затрагивает она все современные процессоры и ее нельзя устранить, так зачем об этом кричать? Без этой огласки знали бы о ней единицы специально обученных людей и и уязвимость коснулась бы единиц. Теперь же в ближайшее время в открытом доступе появятся уже готовые жаваскрипты крадущие логины, пароли и бог знает что. Мотивация детей, «смотрите какие мы умные, мы такую дыру нашли». Здесь действия этих людей принесут принесут вред, а не сама эта уязвимость.
                                        • +5
                                          уязвимость коснулась бы единиц


                                          Или миллионов, если бы кто-то из специально обученных людей решил бы выпустить свежего симпатичного червячка. И на заделывание этой дыры тогда ушли бы не сутки, как в случае с типичными софтовыми дырками, а месяцы.
                                          • +10
                                            Security through obscurity не работает. Не сегодня — завтра кто-нибудь докопался бы. Вон покойный Касперски ещё в 2008 писал (PDF).
                                            • +3
                                              Думать так — очень большая ошибка. Всё равно что скрывать симптомы и делать вид, что всё нормально. Вместо того что бы признать болезнь и заняться лечением.
                                              Вообще это обычная практика у white hat. Нашли уязвимость -> уведомили ответственных -> подождали патча (или какое-то время)-> обнародовали. Если не обнародовать, то у ответственных пропадает стимул что-то исправлять.
                                              И кстати есть инфа (достоверность правда не известна), что производители процессоров были уведомлены еще в июне.
                                              • 0

                                                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."
                                                • +1
                                                  Отличительная и ключевая особенность этой уязвимости — невозможность устранения, по-сути это не болезнь, ошибка или недоделка, это архитектурная особенность современного процессора. Програмный патч в этом случае, как я понял, будет в какой-то мере ограничивать функциональность, так что нет, это не тот случай, о котором вы говорите. Тут одни умные парни укололи других умных парней, а заплатят все остальные.
                                                  • +2
                                                    Если проводить аналогии с болезнью, то да — это неизлечимая болезнь. Стоит ли её скрывать или всё таки надо признать и заняться лечением тем самым продлив пациенту жизнь?
                                                    Но аналогии фальшивы. А по факту уже написали — Security through obscurity не работает. Давно признанный в ИБ факт.
                                                    Есть ли тут какая-то доля тщеславия? Возможно. В конце концов «белые шляпы» очевидно зарабатывают меньше своих не столь отягощенных моралью коллег. Компенсируется это в том числе и так.
                                                    Но дело это не меняет всё равно — сокрытие ни к чему хорошему тоже не приводит.
                                                    • +1

                                                      Поэтому давайте вирусописатели будут знать (им кто-то обязательно продал бы, не сейчас, так через пару лет), а остальные пусть знать не будут, что б спокойнее спалось? Верно понимаю вашу логику?

                                                  • +2
                                                    Intel уведомили об ошибке в июне прошлого года. Было достаточно времени, чтобы предпринять хоть какие-то меры.
                                                    • 0
                                                      Хорошие люди ничем от плохих в плане интеллекта принципиально не отличаются. Если до чего-то смог додуматься хороший человек, то и плохой человек додуматься сможет (а, возможно, даже кто-то плохой до этой уязвимости додумался уже давно, просто никто не знает). А это значит, что в один прекрасный момент Х, эпидемия всё равно случится (потому что плохой человек додумается до уязвимости, а также будет иметь мотивацию её применить на практике). Только вот сейчас пострадают только те, кто поленился поставить апдейты, ибо у софтовых компаний время на закрытие дыры было. А так пострадают вообще все.
                                                      • +2
                                                        Запретить дыры?
                                                      • 0
                                                        Ладно пользовательский софт, а драйверы? По ним же должно ударить?
                                                        • +1
                                                          Нет, у драйверов изначально уровень привилегий другой.
                                                        • +2

                                                          а может кто-то дать ссылку, на видео или статью где все вышеописанное на практике используют и тырят пароль или еще какой ключ в реале? Просто в статье упоминается перебор каких то там комбинаций и т.о. типа всю память физическую можно прочесть: ну ок, а за какое время?(может там уже мусор будет давно) и куда оно пишется после чтения? а сколько это займет времени и оперативки. чем/кем это все анализируется после считывания?

                                                          • –2
                                                            Например вот, та же техника — переброс видео через кэш процессора на двух виртуалках в Amazon ec2.
                                                            • честно: не вижу более одной виртуалки/железной тачки) на видео. просто какое-то консольное нагромождение.
                                                              прошу простить, если с телефона не разглядел чего то.

                                                              • +1

                                                                Это иллюстрация другой методики, когда на двух разных виртуальных машинах работает специальный код, пересылающий данные между ними по скрытому каналу через кэш-память
                                                                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

                                                              • –1

                                                                по первому видео: ну там адреса заранее известны. немного не жиза))
                                                                по второй ссылке: ну диспетчер паролей фф и какая то неведомая хня в hex. не ясно, какой вывод надо сделать то.

                                                                • +2
                                                                  Да какая по большому счёту разница, известны они заранее или нет. Это только на время работы влияет.

                                                                  На том же Heartbleed убедительно показывали, из какого сора растут цветы и добываются сертификаты.
                                                                  • разница есть. особенно в ентерпрайз, с сотнями гигов оперативы. так же можно сказать, что любой пароль можно подобрать, вопрос времени :-)
                                                                    а хартблид чутка попроще и для понимания и для реализации имхо!

                                                                    • 0
                                                                      Энтерпрайзу будет легче, если с его сервера утекут не пароли пользователей, а in-memory база данных, или открытые в терминалах офисные документы, или списки клиентов с контактными данными и номерами кредиток?
                                                                      • вы читали мои изначальные вопросы(пост 05.01.18 в 16:24)?
                                                                        Они по идее, должны бы увести беседу немного в другое русло (перейти от общего к частному, пруфам и т.п.). Понятно что дело серьезное, теперь осталось выяснить насколько срочно надо рвать волосы на *опе.
                                                            • 0

                                                              Какую рускоязычную статью не читаю, везде пишут мол на амд тоже есть и причем вполне уверенно. Это очень смешно, учитывая тот факт что на амд так не смогли ее провернуть и что представители амд предупредили что у них совсем другой подход к работе процессора. Банально — у них даже шины не имеют ничего общего между собой- у амд звезда, у интел кольцо. Spectre на амд вообще работает только на системах с включеным BPF(линуксы и bsd), который по дефолту отрублен. Что это за мания пытаться за компанию и амд затянуть в это болото? У амд была проблема с райзенами до 25 недели, приводящая к сегфолту, но она решается отключением опкеша и эти процы амд меняет бесплатно по RMA. Как думаете, сколько процессоров поменяет интел? Мой вариант — 0.

                                                              • +4
                                                                Spectre на амд вообще работает только на системах с включеным BPF(линуксы и bsd),


                                                                НЕТ.

                                                                Ёлки зелёные, из того, что гугль для простоты демонстрации дырки использовал eBPF, никак не следует, что без него эта дырка исчезает.
                                                                • –2
                                                                  www.amd.com/en/corporate/speculative-execution

                                                                  Амд сделали патч, без падения производительности.
                                                                  • +3
                                                                    Какой патч, куда патч? AMD не подвержены Meltdown вообще.
                                                                    • –2
                                                                      я про spectre многие говорят, типо от нее вообще нельзя избавится у AMD судя по всем получилось. От Meltdown помогает программный патч. хоть и тормозной
                                                                      • +2
                                                                        У AMD по ссылке написано, дословно, «проблему решат обновления ПО, которые вам предоставят производители».

                                                                        Ровно по причине таких прекрасных, подробных пресс-релизов я специально добавил в текст абзац про пресс-релизы.
                                                                        • 0
                                                                          насколько я понял имеется в виду обновление микрокода, а не обновления ядер ОС
                                                                          • 0
                                                                            Строго говоря, по ссылке написано: "(Уже) решено путем обновления программного обеспечения / ОС, которое должно быть доступно поставщикам и производителям систем. Ожидается незначительное влияние на производительность."

                                                                            Но Вы правы, что надо подождать реальной поставки и независимой проверки готовых патчей на системах AMD, чтобы делать окончательные выводы.
                                                                            • 0
                                                                              (Уже) решено

                                                                              Нет, это фигура речи.
                                                                              Resolved by software / OS updates to be made available by system vendors and manufacturers.

                                                                              Можно перевести как «решается апдейтами софта/ОС, которые будут предоставлены производителями софта/ОС».

                                                                  • 0

                                                                    Проблема сегфолтов отключением опкеша не решается, а на на некоторых замененных процах сегфолт остаётся.

                                                                  • +1
                                                                    Для информации: подсистему eBPF в Linux рекомедовали отключить (для пользователей) ещё 23.12.2017, и по другому поводу.
                                                                  • +2

                                                                    Нуб с мировым именем MODE ON.
                                                                    Какой-то простой алгоритм. Я ни капли не программист, ну разве что самую малость, но это объяснение на пальцах мне показалось очень понятным, а сам алгоритм — лежащим на поверхности. Ну ладно, я всё таки Физтех закончил, благо, я могу попробовать объяснить это всё родственнику, который хоть и весьма толковый, но, как показала недавняя практика, даже не вполне умеет пользоваться гиперссылками на страницах в интернете. Так я даже ему смог это объяснить. Как тогда так получилось, что до этого додумались только сейчас?

                                                                    • +9
                                                                      Во-первых, думается мне, это просто когда тебе это на блюдечке преподнесли и рассказали как работает. А поди ты сам до такого хитроумного способа додумайся. Отличный пример высказывания «всё гениальное просто».
                                                                      Во-вторых кто сказал, что додумались только сейчас? Это white hat додумались сейчас. А сколько до них додумались black hat? Сие не ведомо. Может и действительно никто.
                                                                      • 0

                                                                        Хороший вопрос. Я вроде в предыдущих постах видел, что все бьют себя пяткой в грудь и заявляют, что подобных атак не наблюдали. Отсюда вопрос: как они могли знать были атаки или нет, если сама уязвимость не была известна?

                                                                        • +7
                                                                          «Если вы, откусив яблоко, обнаружили торчащую из него половину червяка, значит, вы только что съели червяка. Если же вы ничего не обнаружили, это ещё ничего не значит».
                                                                          • 0
                                                                            Лучше быть подготовленным.
                                                                            В 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»
                                                                        • 0
                                                                          Ну если black hat не додумались, то они, наверное, от обиды уже съели свои black hats
                                                                          • 0
                                                                            При всём уважении, хитроумный способ — это вот это. Meltdown, на мой взгляд, по сравнению с ним — образец очевидности.
                                                                            • 0
                                                                              Всегда знали об этой проблеме. Лет 5(а может и больше?) назад читал статью по поводу небезопасности реализации кеша в интеловских процессорах и там говорилось о теоретической возможности такой атаки, но тогда отмахнулись от этого как от назойливой мухи — это был довольно экзотический способ и его не воспринимали всерьёз.
                                                                              Второй раз упоминание о возможной проблеме возникло когда ФСБ потребовало взлома айфона террориста у самой компании Эппл, но тогда эта уязвимость не помогла. Т.е. даже тогда было известно о такой проблеме и даже то что она касается не только интеловских процессоров.
                                                                            • 0
                                                                              Сейчас это выскочило на публику. А кто, когда додумался раньше, но не опубликовал — неизвестно.
                                                                            • +1
                                                                              Вообще-то материал уже четвёртый. Но написано очень доходчиво. Спасибо!
                                                                              • +1
                                                                                После чтения популярного изложения «на пальцах», у меня возник вопрос — как же до сих пор работала популярная в моем детстве программа ArtMoney, которая вполне себе работала с памятью других процессов?
                                                                                Я понимаю, что в данном случае — вся беда в том, что доступ к чужим областям памяти может получить код запускаемый в средах, которые напрямую этого не позволяют, но все же — чем же занят MMU в случае с ArtMoney?
                                                                                • +3
                                                                                  MMU — не сферический конь в вакууме, он не работает «сам по себе», ему ОС указывает, какие куски памяти кому положены. В частности, разрешённые области памяти у разных процессов могут вообще пересекаться.

                                                                                  Разрешила ОС данному приложению лазить в чужую память — значит, хорошее приложение, годное, ему можно.

                                                                                  Антивирусу, например, вон тоже много чего можно.
                                                                                  • +1
                                                                                    • +2
                                                                                      А вы запустите на современной ОС ArtMoney не от администратора, откажитесь от всяких вопросов «процесс хочет доступ» и попробуйте прочитать память. Скорее всего ничего не получится. А тут даже JS в браузере может вытащить что-нибудь из памяти без всяких разрешений и прочего.
                                                                                      • +1
                                                                                        Я вот подумал, а Noscript может как-нибудь помочь в противодействии данной бяке, потенциально пытающейся эксплойтить через JS в браузере? (Intel, ессно).
                                                                                        • +1

                                                                                          Я не в курсе, как работает noscript. Если он запрещает выполнение всего JS, то логично, что защитит. Но я вижу, что у меня на части сайтов не работает половина функционала, пока я в umatrix не разрешу загрузку пары скриптов с какого-нибудь CDN. Соотвественно, я от этой уязвимости не защищён — я рано или поздно запущу что-то ради функционала, либо скрипт будет лежать на доверенном домене.
                                                                                          А на практике, с JS скорее всего что-нибудь сделают производители браузеров — загрублением таймера или принудительным сбросом кеша, так что этого не очень стоит опасаться.

                                                                                          • +2
                                                                                            Pale Moon ещё в октябре 2016 «на всякий случай» решил огрубить таймер, как знали (ну, браузер для параноиков, решили упредить и не прогадали). Во всяком случае если верить записи разработчика на форуме.
                                                                                    • 0
                                                                                      Спасибо за статью, на удивление понятно и доходчиво! По итогам вдумчивого прочтения возникли два вопроса:
                                                                                      1. Если я правильно понимаю, реализация всего этого дела опирается на то, что MMU работает настолько медленно, что процессор успевает минимум два раза сходить в медленную RAM, прежде чем получит ответ, что так нельзя — это действительно так?
                                                                                      2. После получения первого значения процессор начинает его использовать, не дожидаясь ответа, можно ли было его вообще получать. Если я правильно понимаю, примерно из-за ожидания ответа в таком случае Meltdown не реализуется на AMD. Но в каком именно случае процессор таки будет дожидаться ответа от MMU, прежде чем сделать очередную операцию? Кажется, что помимо косвенной адресации погут быть и другие разрешенные операции, которые могут привести к схожим атакам.
                                                                                      • 0
                                                                                        1. Тут можно разрисовывать варианты работы MMU и думать, почему так. Например, в TLB — кэше таблицы трансляции адресов — хранятся только собственно адреса, но не права доступа, поэтому ALU быстро достаёт оттуда нужный физический адрес, пока MMU медленно собирается идти в ОЗУ за таблицей прав доступа к нему. Далее представляется логичным дать приоритет ALU, чтобы оно первым достало из памяти данные и поехало работать дальше, а MMU подождёт. В результате, когда MMU наконец пустили до памяти, ALU улетело вперёд уже на десятки операций.

                                                                                        Это я чисто спекулятивно, искать, как оно реально устроено в Интелах, сейчас лень — да и не уверен, что это есть в открытом доступе. У AMD в такой схеме могут быть или другие приоритеты (другой баланс между потребностями ALU и MMU), или в TLB уже лежат и права доступа тоже, например.

                                                                                        2. Могут быть и другие, но косвенной адресации более чем достаточно для счастья. Нет даже повода искать что-то ещё.
                                                                                        • 0

                                                                                          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.

                                                                                          • 0
                                                                                            Так как права должны быть проверены к моменту 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, если и физический адрес, и права доступа достаются одновременного и из одного и того же места, остаётся неясен.
                                                                                            • 0

                                                                                              TLB — это кэш, но все операции доступа к памяти (в нормальных режимах) проходят через него и не могут завершиться без выдачи физадреса из tlb. При промахе всех уровней tlb будет совершен (в MMU) pt walk, заполнение строки в tlb, трансляция физадреса + проверка прав. Т.е. инструкция работы с памятью не может завершиться, пока не ответил TLB.

                                                                                          • +1
                                                                                            Непонятно почему в TLB сохраняется только физический адрес, а не полностью аттрибуты доступа. TLB явно работает как CAM (content-addressable memory, идет сравнение тегов виртуального адреса с выставленным) поэтому странно. что физадрес из TLB извлечь успевают, а извлечь и проверить аттрибуты — нет. Я склоняюсь к тому что это именно архитектурный залет, технических же проблем реализовать проверку аттрибутов нет.
                                                                                            • 0
                                                                                              Я не утверждаю, что права не хранятся в TLB, более того, выше есть ссылки, утверждающие, что это не так — и они там хранятся.

                                                                                              Но тогда вдвойне непонятно, откуда возникает такой performance impact на проверку прав доступа, что проще эту проверку отложить на потом.
                                                                                              • +1
                                                                                                Про performance impact — это только предположение исследователей уязвимости. Время извлечения аттрибутов из TLB точно такого же порядка как и время извлечения физадреса. Возможно там есть сложности собственно проверки аттрибутов (многие биты режима работы процессора тоже конвееризуются), но решаемые, имхо, если задасться целью. Вероятнее всего, блок проверки прав сделан в уязвимых процессорах отдельно и работает асинхронно в целях упрощения структуры.
                                                                                                • 0
                                                                                                  В общем, там должна быть веская причина делать именно так — потому что логика откладывания проверки не выглядит самоочевидной, и не пережила бы двадцать лет и кучу поколений процессоров одного производителя, чтобы потом ещё и вылезти у другого.

                                                                                                  Нам, впрочем, её всё равно вряд ли расскажут.

                                                                                                  Упрощение структуры тут вряд ли является причиной — в современных процессорах наверчено уже столько, что на лишнюю сотню тысяч транзисторов в MMU посмотрят далеко не в первую очередь.
                                                                                                  • +1
                                                                                                    >>логика откладывания проверки не выглядит самоочевидной
                                                                                                    Пока оно выглядит так что аттрибуты доступа просто сохраняются рядом с полученными данными, и проверяются непосредственно в момент instruction retirement. Это позволяет иметь валидный контекст исключения на момент проверки. Гораздо сложнее «собрать» этот контекст при спекулятивном исполнении. В любом случае, нет оправдания почему не сделана хотя бы предварительная проверка прав в момент доступа к памяти и прекращение спекулятивного исполнения, если проверка не пройдена. Пенальти то тут никакого — ветка будет отброшена или из-за ложного предсказания исполнения, или таки из-за исключения.
                                                                                                    >>что на лишнюю сотню тысяч транзисторов
                                                                                                    Имелся ввиду не транзисторный бюджет, а именно сложность разработки архитектуры.
                                                                                                    • 0
                                                                                                      В любом случае, нет оправдания почему не сделана хотя бы предварительная проверка прав в момент доступа к памяти и прекращение спекулятивного исполнения, если проверка не пройдена.
                                                                                                      В некоторых случаях данные могут использоваться позже и есть смысл их загрузить заранее. Например запись в copy-on-write страницу вызовет исключение и последующее копирование в обработчике страничных ошибок. Я думаю, что Intel обнаружил небольшое увеличение производительности при таком спекулятивном кешировании.
                                                                                              • 0

                                                                                                Физадрес из 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...

                                                                                                • +1
                                                                                                  Права доступа в сторону физкеша выдавать бессмысленно, кеш про них понятия не имеет. Наоборот, надо права проверить и результат проверки слать на блоки исполнения — пометить неправомерный доступ как токсичный и вызывающий исключение, на этом спекулятивное исполнение ветки прекратить.
                                                                                                  • 0
                                                                                                    на этом спекулятивное исполнение ветки прекратить


                                                                                                    Что характерно, вот это должно дать положительный импакт по сравнению с тем, что сейчас творится у интела и арма.
                                                                                          • 0
                                                                                            Насколько я понял, перенос памяти ядра в другое адресное пространство — не единственный метод борьбы с этой уязвимостью. Можно, например, при попытке чтения памяти ядра сбрасывать весь кэш процессора. Возможно это в некоторых применениях будет эффективнее? Хотя, конечно если не изменить при этом алгоритмы таймменеджмента ОС — можно будет сильно затормозить систему используя этот механизм.
                                                                                            • +1
                                                                                              Вся соль в том, что в момент чтения процессор не знает относится ли читаемая память к ядру.
                                                                                              • 0
                                                                                                А, до меня дошло — исключение в этом случае не генерится, потому что результаты отбрасываются, так что да, не получится.
                                                                                                • +1
                                                                                                  Оно внутри процессора генерируется, иначе бы он не знал, что результат надо отбросить. Но — в случае Intel и свежих ARM — только после того, как данные de facto прочитаны.
                                                                                                  • 0
                                                                                                    Я имел в виду, что исключение по обращению к памяти, которое запрещено по уровню привилегий приложения, не вызывает прерывание, которое ядро могло бы обработать, и сбросить кэш. В принципе, на уровне микрокода, наверное, такое прерывание можно было бы добавить, но это, вероятно, приведёт к большому числу случайных срабатываний так что такой метод ещё больше затормозит процессор. А вот с точки зрения обнаружения атаки через эту уязвимость — думаю, было бы полезно.
                                                                                                    • 0
                                                                                                      но это, вероятно, приведёт к большому числу случайных срабатываний так что такой метод ещё больше затормозит процессор


                                                                                                      Вообще нет, при нормальной работе каких-то особо частых попаданий в чужую память быть не должно, если бы спекулятивное выполнение часто приводило к промахам — оно было бы тупо неэффективно, т.к. сброс конвейера дорого стоит.

                                                                                                      Но это всё равно так себе решение, т.е. требует взаимодействия процессора и софта и при этом не даёт ничего, кроме зажигания лампочки «что-то тут не так».
                                                                                                      • +1
                                                                                                        Если сбросить весь кэш по попытке чтения памяти ядра — это полностью закроет уязвимость. Другое дело что это на порядки больший тормоз чем единичный кэш-промах, и неизвестно какая программа, написанная с точки зрения программной модели вполне корректно начнёт дико тормозить систему. Но если обрабатывать это прерывание антивирусом не всегда, а так, чтобы оно не тормозило систему, можно набрать статистику по подозрительным участкам кода, а потом посмотреть на них более детально и определить, пытается ли программа использовать уязвимость.
                                                                                            • 0

                                                                                              Простите за возможно очень нубский вопрос, но в вопросах архитектурного устройства CPU и RAM у меня познания весьма невелики. Как я понял, суть дырки в том, что вредоносный код лезет туда, куда низзя, его за это посылают, но код определяет содержимое по интонации (задержке) отказа. И в итоге процессор может спалиться, как в анекдоте:


                                                                                              — Дед, люди говорят, у вас винтовка есть?
                                                                                              — Врут.
                                                                                              — Дед, люди говорят, у вас пулемет есть.
                                                                                              — Врут.
                                                                                              — Дед, люди говорят, у вас пушка есть.
                                                                                              — Врут.
                                                                                              — Дед, люди говорят, у вас танк есть.
                                                                                              — Врут.
                                                                                              — Дед, люди говорят, у вас атомная бомба есть.
                                                                                              — А вот чего нет, того нет.

                                                                                              То есть, отличающийся от других ответ говорит, что значение ячейки памяти угадано, а дальше по цепочке как-то к другим ячейкам подбирает значения? Если нет, то где моя ошибка?
                                                                                              Ну и вопрос практического характера. Имею комп на i5-7600, включенный 24/7, с постоянно открытым браузером. ОС — Винда 7 (ну не люблю я десятку), с отключенными обновами. Никаких биткоин-кошельков на компе нет, к тому же счету вебмани или банк-клиенту авторизация все равно смартфоном прикрыта (двухфакторная авторизация), админок с правами, способными навредить какому-то ресурсу или стащить оттуда что-то ценное тоже нет. Я где попало не хожу обычно, и за всю жизнь ни одного серьезного виря не ловил (червячки максимум, лет 7 назад). Поэтому вопрос: мне бояться или выдыхать?

                                                                                              • 0
                                                                                                Насколько я понимаю, системам, у которых на процессоре работает один пользователь, бояться особо нечего, за исключением JavaScript-эксплойтов, которые должны более или менее прикрыть разработчики браузеров (если на винде работает какой-то левый код, то он может наворотить дел и без этой уязвимости). Большая проблема возникает, если на одном CPU выполняется код разных пользователей — тогда один из них получает доступ к памяти остальных.
                                                                                                • 0
                                                                                                  То есть, отличающийся от других ответ говорит, что значение ячейки памяти угадано, а дальше по цепочке как-то к другим ячейкам подбирает значения?

                                                                                                  А дальше адрес увеличивается на единицу и подбирается значение дальше. В итоге получаем кусок памяти, в котором возможно что-то интересное.
                                                                                                  к тому же счету вебмани или банк-клиенту авторизация все равно смартфоном прикрыта (двухфакторная авторизация)

                                                                                                  Всегда можно вытащить токен/кукис, который позволит зайти без авторизации. Если не от банк-клиента, так хоть от почты/соцсети/итд. А «где попало не хожу» — плохая защита, не гарантирует того, что хороший сайт не сломают и не добавят туда маленький скрипт. Но вопрос с эксплуатацией уязвимости через браузерный JS остается открытым.
                                                                                                  • 0
                                                                                                    Как я понял, суть дырки в том, что вредоносный код лезет туда, куда низзя, его за это посылают, но код определяет содержимое по интонации (задержке) отказа. И в итоге процессор может спалиться, как в анекдоте


                                                                                                    Почти так. Если совсем строго — вредоносный код в явном виде даже никуда не лезет, он просто подстраивает ситуацию так, что процессор лезет туда сам, вперёд батьки в пекло. Поэтому формально код даже и не посылают.
                                                                                                    • –1
                                                                                                      Ну подумаешь, комп станет частью ботнета и примется рассылать спам и майнить крипту) можно дышать спокойно…
                                                                                                      • 0
                                                                                                        Ну подумаешь, комп станет частью ботнета и примется рассылать спам и майнить крипту)

                                                                                                        Логика мне подсказывает, что если такое случится, то комп станет медленнее, что будет видно в диспетчере задач по уровню загрузки проца, горячее и шумнее. А уж шум кулера повышенный я сразу засеку, так как сейчас он на 300 об/мин постоянно лопатит, все тихо. И если я пойму, что это не термопаста, обнаружу какие-то мутные-непонятные процессы и т.д. — я в таких случаях просто нафиг переустановлю винду, на всяк пожарный проверю, все ли "лишние" порты залочены на роутере, плюс потом попрошу провайдера сменить мне айпишник.

                                                                                                        • +1
                                                                                                          Данная уязвимость не позволяет запускать код, она позволяет только извлечь данные: пароли, куки, сертификаты, интимные фотки…
                                                                                                          • 0
                                                                                                            olartamonov, подскажите, реально ли извлечь ключи кошельков криптовалют. Например, насколько опасны сервисы, не закрывшие софт-заплаткой свои мощности, но которые сдают мощности майнерам или частные фермы/кластеры.
                                                                                                            Или 2. Можно ли как-нибудь с помощью этой «архитектурной особенности» противостоять шифровальщикам (дешифровать данные), etc.
                                                                                                            • +1
                                                                                                              Теоретически реально извлечь всё перечисленное, а также всё остальное, не перечисленное.

                                                                                                              В системах без специальных аппаратных криптопроцессоров любые ключи и пароли в тот или иной момент оказываются в памяти в полностью открытом виде, независимо от того, как они зашифрованы или иным образом защищены при хранении, потому что другого способа работы с ними нет.
                                                                                                              • +1
                                                                                                                Но, кстати, конкретно шифровальщики используют несимметричное шифрование, поэтому ключа для дешифровки у вас на компьютере не будет ни в каком виде.

                                                                                                                Если б там было симметричное, ключ можно было бы так или иначе достать из тушки шифровальщика и применить.