https://www.opennet.me/openforum/vsluhforumID3/113350.html Компания Red Hat отозвала (https://access.redhat.com/solutions/3315431) обновление (https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2017-5715) пакетов с микрокодом (microcode_ctl и linux-firmware), выпущенное 16 января для устранения второго варианта уязвимости Spectre (CVE-2017-5715 (https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2017-5715)). В качестве причины отмены обновления называются проблемы со стабильностью, которые были выявлены в результате дополнительного тестирования и жалоб клиентов. На некоторых системах обновление микрокода приводило к невозможности загрузки. <br><br><br>Для блокирования CVE-2017-5715 пользователям рекомендуется использовать обновление прошивок, предоставленных для конкретных систем производителями CPU и оборудования. Напомним, что уязвимость Meltdown (CVE-2017-5754) и второй вариант уязвимости Spectre (CVE-2017-5715) могут быть целиком закрыты на уровне операционной системы (патчи KPTI и retpoline). Второй вариант Spectre также устраним на уровне обновления микрокода. Для полн https://www.opennet.me/openforum/vsluhforumID3/113350.html#44 Thu, 25 Jan 2018 16:21:00 GMT Z80 наше всё. :-)<br> https://www.opennet.me/openforum/vsluhforumID3/113350.html#43 Wed, 24 Jan 2018 16:49:18 GMT После всех этих историй с, назывём вещи своими именами, жульничеством ради повышения валовой производительности, становится не такой уж &#171;очевидной&#187; практическая неправота ребят, придумавших VLIW.<br> https://www.opennet.me/openforum/vsluhforumID3/113350.html#42 Wed, 24 Jan 2018 13:17:25 GMT &gt;[оверквотинг удален]<br>&gt; Проблема в том, что для того, чтобы это все понять, процессору надо <br>&gt; загрузить операцию со всеми операндами.<br>&gt; А как только операнды загружены, то можно попытаться их угадать, зная что <br>&gt; кеш быстрее памяти.<br>&gt; Делать же кеш только для одного потока - деньги на ветер. Да <br>&gt; и так на полный разбор адреса не хотят тратится, мол <br>&gt; накладно. А тут еще на каждую операцию храни и проверяй <br>&gt; всю подноготную.<br>&gt; Ну максимум как у красных - пару бит, чтоб проверить какое кольцо <br>&gt; грузило.<br><br>спасибо, теперь стало понятно в чём конкретно ошибка<br>тоесть надо бы перед "предпрогрузкой" операции проверять права доступа к операндам и если нельзя - не предгружать и не пытаться угадать что там с ветками?<br> https://www.opennet.me/openforum/vsluhforumID3/113350.html#41 Mon, 22 Jan 2018 10:48:22 GMT Нет, без изменения архитектуры CPU (отказа от спекулятивного исполнения) закрыть уязвимости типа Spectre невозможно.<br>Однако, можно сделать эксплуатацию этого класса уязвимостей весьма затруднительной в том или ином частном случае. Например, AMD сделал практически невозможной эксплуатацию этого класса уязвимостей в направлении RingN -&gt; RingN-1, но это никак не затрудняет атаку получения лежащего в ОЗУ закрытого ключа из "соседнего" процесса (RingN -&gt; RingN).<br><br> https://www.opennet.me/openforum/vsluhforumID3/113350.html#39 Mon, 22 Jan 2018 09:17:38 GMT &gt; в браузерах прибили -- ну молодцы, right..<br><br>и то слегка криво: https://support.mozilla.org/en-US/questions/1198266<br> https://www.opennet.me/openforum/vsluhforumID3/113350.html#38 Mon, 22 Jan 2018 07:48:37 GMT &gt;И Meltdown и Spectre трудно заткнуть без полноценного механизма проверки прав при спекулятивном выполнении.<br><br>В этом нет никакой проблемы. Это проверяется и код не выполняется - два раза. Один раз потому, что нельзя, а другой раз потому, что и не надо. :)<br>Проблема в том, что для того, чтобы это все понять, процессору надо загрузить операцию со всеми операндами.<br>А как только операнды загружены, то можно попытаться их угадать, зная что кеш быстрее памяти.<br>Делать же кеш только для одного потока - деньги на ветер. Да и так на полный разбор адреса не хотят тратится, мол накладно. А тут еще на каждую операцию храни и проверяй всю подноготную.<br>Ну максимум как у красных - пару бит, чтоб проверить какое кольцо грузило.<br> https://www.opennet.me/openforum/vsluhforumID3/113350.html#37 Sun, 21 Jan 2018 03:01:08 GMT &gt; Текущие исправления софта и микрокода лишь немного затыкают опубликованные CVE, не решая всей проблемы.<br><br>Спорные заявления.<br><br>И Meltdown и Spectre трудно заткнуть без полноценного механизма проверки прав при спекулятивном выполнении. Трудно, но возможно &#8212; достаточно или отключить спекулятивное выполнение, или регулярно очищать внутренние структуры CPU, через которые происходят утечки. Просто если выполнять такую очистку программно, она приведёт к массивному падению производительности (что и наблюдаем в случае процессоров Intel).<br><br>Если верить заявлениям AMD, у них используется какая-то аппаратная поддержка таких проверок прав. Но она занимается не очисткой кешей, а изоляцией разных уровней защиты: Ring-0/Ring-1 и т.д. Т.е. ядро и программы изолированы друг от друга, а Javascript и браузер, который его выполняет, &#8212; нет. Логично, &#8212; кто в здравом уме будет выполнять в своём процессе недоверенный код?! Так что правильнее сказать, что в современных CPU просто нет полноценной поддержки выполн https://www.opennet.me/openforum/vsluhforumID3/113350.html#35 Sun, 21 Jan 2018 00:19:57 GMT &gt; Т.е. процессоры выпускались со спекулятивным выполнением, чтобы конвейеры не простаивали <br>&gt; и считали несколько веток,<br><br>Не совсем, обе ветки сразу считать &#8212; это предикатное выполнение. На интелах (кроме Itanium) предикатного выполнения нет. Спекулятивное &#8212; это когда на основе ранее собраных процессором данных делается предсказание более вероятной ветки и она считается, и всё, что за ней следует. Это и позволяет заполнить конвеер.<br><br>&gt; а сейчас софт переписывают под особенности процессоров, <br>&gt; чтобы последние "промаргивали" возможное выполнение веток, отличных от текущей?<br><br>Да, именно так. Притом потери быстродействия сильные и компилятор пытается угадать, где нужно дурить предсказатель ветвей, а где нет. Результаты ошибок при попытках угадать мы уже видели, дежавю. Так что уязвимости класса Spectre в том или ином виде будут ещё долго встречаться.<br><br>&gt; Ну отличненько, <br>&gt; чё. Делайте аппаратный флаг, разрешающий/запрещающий это самое спекулятивное выполнение. <br><br>Ну так это нужно все процессоры https://www.opennet.me/openforum/vsluhforumID3/113350.html#34 Sun, 21 Jan 2018 00:12:55 GMT &gt; ну обновление микрокода делает процессор более тупым..<br>&gt; в частности говоря про "load fence"<br><br>Безусловно. Но load fence лишь усложняет подобные атаки, но не делает их невозможными.<br>