Для устранения Spectre и Meltdown, возможно, придётся создать процессор совершенно нового типа

https://www.pcworld.com/article/3299477/components-processors/solving-spectre-and-meltdown-may-ultimately-require-an-entirely-new-type-of-processor.html
  • Перевод

Правда ли, что Meltdown и Spectre слишком фундаментальны для того, чтобы выпустить для них патч? Один эксперт считает именно так.




Как определить и исправить такие ошибки, как Spectre и Meltdown? Этот вопрос был самой горячей темой среди энтузиастов микропроцессоров в этом году. На одном из главных академических событий индустрии, конференции Hot Chips, эксперты согласились, что окончательное решение проблемы может потребовать – да, ещё больше разговоров.

На встрече в Купертино профессора Марка Хилла из Висконсинского университета попросили порассуждать о последствиях атак по сторонним каналам или атак на спекулятивное выполнение команд у современных процессоров, которые изготавливают компании ARM, Intel, и другие. Он перечислил такие решения, как специализированные ядра, сброс кэша при смене контекста и бизнес-идеи вроде увеличения платы за эксклюзивные виртуальные машины.

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

Как целая индустрия чипов получила удар исподтишка


Информацию о Meltdown и Spectre неожиданно раскрыли в конце 2017 года, незадолго до того, как эти уязвимости должны были формально, по-тихому раскрыть на CES в январе 2018 года. Их обнаружила команда поиска уязвимостей нулевого дня из Google, Google Project Zero. Атаки пользуются такой возможностью современных микропроцессоров, как спекулятивное выполнение команд, когда процессор, по сути, «угадывает», какую ветвь инструкций нужно выполнять. Пол Тёрнер, инженер и руководитель основного костяка разработчиков Google, присутствовавший на конференции, рассказал, что никто из членов Project Zero не предупредил об открытии своих коллег; они узнали об этом вместе со всеми.

В течение 20 лет разработчики микропроцессоров считали, что неверная «догадка» просто отбрасывает данные, не создавая рисков для безопасности. Они ошибались, что и доказали атаки по сторонним каналам.

С практической точки зрения это означает, что одна вкладка браузера может просматривать содержимое другой, или одна виртуальная машина может заглядывать в другую. Это побудило производителей процессоров, в частности, Intel, совместно с Microsoft, выпустить исправляющие положение программы, или заплатки. Это наиболее эффективный способ защиты вашего ПК от Spectre, Meltdown, или любых других последующих атак, например, Foreshadow.

К счастью, проверка такой информации требует времени — в некоторых случаях, довольно много. NetSpectre, способный удалённо воспользоваться уязвимостью Spectre, можно использовать для взлома облачного сервиса или удалённой машины. С одной стороны, данные могут утекать не быстрее 1 бита в минуту, как говорит Джон Хеннесси, знаменитый разработчик микропроцессоров, член совета директоров Alphabet. С другой стороны, среднее время между взломом сервера и обнаружением этого факта составляет 100 дней, добавил он – что может дать уязвимости время поработать.

Процессоры Intel следующего поколения, вероятно, не смогут полностью исправить первый вариант Spectre, как сказал Хеннесси, несмотря на то, что разработка мер по устранению этого недостатка начнётся этой осенью, в проекте нового процессора Xeon, Cascade Lake.



Патчить или переделывать?


ARM, Intel, AMD и другие гиганты индустрии могут исправить проблему, приняв необходимые меры довольно быстро, добавил Хилл. Но для полного устранения проблемы могут потребоваться более фундаментальные изменения, сказал он.

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

Спекулятивное выполнение команд – одна из причин, по которым микропроцессор, а следовательно, и ПК, достигли рекордных продаж, отметил участник конференции Джон Мастерс, архитектор компьютерных систем из Red Hat. Но такое выполнение расценивали как «волшебный чёрный ящик», сказал он, без соответствующих вопросов со стороны пользователей или клиентов. Этот джинн уже тоже выпущен из бутылки. Устраните спекулятивное выполнение – и это замедлит работу процессора в двадцать раз, сказал Хилл.

Среди предложенных Хиллом решений – изолирование элемента предсказания ветвления, добавление рандомизации, реализация улучшенной защиты оборудования. Одним решением может быть добавление более медленных и безопасных режимов исполнения; другим – разделение механизма исполнения команд между «быстрыми ядрами» и «безопасными ядрами». Он также предложил бизнес-решения, среди которых увеличение стоимости виртуальных машин – вместо разделения ресурсов оборудования между несколькими виртуалками, облачный провайдер мог бы обеспечивать эксклюзивный доступ. Наконец, Хилл отметил, что атаки вроде Spectre могут также привести к возрождению ускорителей: логики фиксированного назначения, оптимизированной для одной задачи, и не полагающейся на спекуляции.

Но фундаментальным решением этой проблемы была бы полная переработка архитектуры, сказал Хилл. Архитектура компьютера определяет, как процессор выполняет набор инструкций программы при помощи арифметических устройств, устройств для работы с плавающей запятой, и прочих. Сегодняшние чипы были разработаны для удовлетворения требований оригинальной модели. Но если базовая архитектурная модель имеет фундаментальный недостаток, сказал он, возможно, пришло время для новой модели. Иначе говоря, Spectre и Meltdown – это не баги, а недостатки в дизайне современных чипов, из-за чего может потребоваться новая модель.

В итоге участники конференции сошлись на простых истинах, вроде той, что оборудование необходимо разрабатывать, помня о программном обеспечении, и наоборот – и обе стороны должны усиливать безопасность. «Часто бывает так, что разработчики оборудования создают какую-то прекрасную машину, и мы прекращаем говорить о ней, или разработчики ПО говорят – ну, это же железо, мне-то что до него. Пора это прекращать», — сказал Мастерс.
Поделиться публикацией
Комментарии 105
    0
    Полной защитой от такого класса атак, наверное, может быть только аппаратная реализация гомоморфного шифрования. Тогда процессор не сможет знать о том, что он вычисляет. (Но будет это делать ооооочень медленно и горячо :).)
      +6
      Всегда так кажется что проще взять и сделать всё по новому, только стоить это будет немерено.
        +7
        И скорее всего, там тоже будут security-дыры подобного масштаба.
          –3
          Так спецслужбы США проинвестируют разработку, с внедрением на сей раз более хитроумных дыр. С другой стороны закрадывается мысль что уязвимости были оставлены специально, возможно в то время развития процессоров выполнять дополнительные проверки в спекулятивном выполнении сводило на нет все полученное ускорение.
          +2
          Прошу прощения за нубский вопрос, но есть ли хоть какая-то реальная выгода в закрытии уязвимостей (и принятия пониженной производительности) для владельцев ПК и железных серверов, или практическую ценность уязвимости имеют только в случае виртуализации и размещения машин разных владельцев на одном хосте?
            0
            Если на компе выполняется браузер, то есть «выгода» (точнее, отсутствие убытков из-за возможных взломов), так как без javascript/html5 сейчас — никуда не сходишь, практически.
              0
              Можно белый список для выполнения JS (правда, остаётся проблема в случае взлома этих сайтов)…
                +2
                При скорости 1 бит в минуту сложно представить, как можно нанести ущерб. Интересно, если, к примеру, человек выключает компьютер каждую ночь, и всегда держит открытой вкладку браузера со зловредом, то можно возобновлять начатую вчера атаку, или, надо провести полную атаку за одну сессию? Если второй вариант, то как-то это сложно выходит что-то существенное сделать.

                PS: Пока у меня складывается впечатление, что все будут страдать ради решения проблемы всяких азуров и авээсов (причем, исключительно их проблемы).
                  0

                  Интересно, а данные в оперативной памяти всегда хранятся в одних и тех же адресах? Есть ли фрагментация? Может просто достаточно время от времени сдвигать все данные не случайное растоение, тогда и проблем не будет.

                    0
                    Только сразу перестанет работать кеширование, придется пересчитывать таблицы трансляции адресов, пересчитать виртуальную память и указатели…
                    Попутно придется найти того, кто будет память «тусовать» и учесть, что все это будет занимать шины памяти перегонкой десятков гигабайт в секунду, выжирая электричество и выделяя дофига тепла…
                      0

                      Ок, этим можно заниматься раз в сутки специально для серверов, в ночное время. На более коротком промежутке времени уязвимость не актуальна, тк не известен сам адрес пароля, или на что идет атака.

                    0
                    1 бит в минуту это для netspectre, класс атак по сети!
                    В локальном варианте все намного хуже. Так плохо, что специалисты не знают о том, как защититься.
                    0
                    Это вполне может решаться на уровне браузера огрублением таймеров и прочими рандомизациями из этой серии.
                      0
                      И получится то же самое замедление производительности, что и при решении на уровне патча микрокода (а так же всё равно решение в браузере не будет полным, «временнОй шум» аппаратуры всё равно будет «протекать» в последовательность выполнения фрагментов приложения). Ведь рандомизировать и замедлить придётся не просто таймеры, а абсолютно ВСЁ, ведь сравнивать скорости различных вычислительных процессов можно и вовсе без таймера (скажем, сравнить, сколько выполнится CSS-анимаций за время отрисовки какого-нибудь хитрого дива, или ещё что-то такое же косвенное).
                        0
                        Только в этом случае оно получится только в рамках браузера, а не ещё и компилятора, IDE и числодробилки вдовесок.
                          0
                          Для разработчика не проблема поработать и на уязвимой машине с нормальной скоростью (и с соблюдением гигиены), а у конечного пользователя кроме браузера уже и не осталось ничего :).
                      0
                      нужно просто закрывать браузер, когда пользуешься электронными кошельками или конфиденциальной инфой
                        0
                        Ага, особенно когда кошельки реализованы в этом самом браузере.
                      +1
                      Для домашних ПК — нет. Через браузер работает слишком медленно, а если вы все подряд на ПК ставите, то есть десятки более простых способов украсть с вашего ПК информацию.
                      –11
                      Такое впечатление, что это не «недостаток дизайна», а «фича дизайна». Сложно поверить, что куча людей в разных конторах и с опытом проектирования процессоров, кучей эмуляторов в железе просто «не увидела» такой побочный эффект. Да и АМД своевременно подсуетились с шифрацией памяти, Китай со своими процессорами и своей архитектурой — это тоже понятно.
                      Когда читал мануалы про 486 процессор в голове был вопрос «спекулятивное исполнение — понятно. Результаты отбрасываются — понятно. Но как они отбрасываются? Не проходит же микрокод и не обнуляет кеши и результаты исполнений...»
                      Такое впечатление, что каких-то ребят поймали «на горячем», и что бы такой «баг проектирования» не похоронили в каких гостайнах — плеснули в вентилятор, все что можно.
                      Можно сколько угодно зубоскалить про ФСБ-ФАПСИ & Co с их компьютерами «на лампах», процессорами Байкалам — но какие-то параноики из этих контор все таки оказались правы. Не сильно будет удивительно, если они «были в доле» — знать и молчать, делая вид что не знают…
                      По факту такой «баг дизайна» означает, что весомая часть безопастности в ИТ — одна большая подстава в планетарном масштабе, в пользу ребят «из АНБ». Прецеденты таких масштабов были и уже не один раз — ослабление криптомеханизмов GSM, слабые генераторы случайных чисел,Windows Bitlocker & EFS и т.д.
                      Нормальная стратегия: если не можем победить крипто — давайте сделаем так, что бы тупо читать ключи из памяти, а эти лохи путь думают что «дыра в безопастности» прикрыта.
                        +9
                        Конспирология на марше, как и всегда в последнее время. Есть замечательная поговорка — «что знают двое, знает и свинья». Невозможно объединить в заговоре молчания тысячи разработчиков и службистов, тем более — не только в одной стране, но и одновременно многих из геополитически враждебных стран так, чтобы они "были в доле". Не-воз-мож-но.
                          –3
                          Есть замечательная поговорка — «что знают двое, знает и свинья». Невозможно объединить в заговоре молчания тысячи разработчиков и службистов,

                          Есть прецеденты, когда знают «много поросят» — Энигма во вторую мировую,
                          GSM
                          Безопасность GSM сетей изначально основывалась на принципе «безопасность за счёт неизвестности». И когда в 1998 году алгоритм был вскрыт группой исследователей состоящих из Marc Briceno, Ian Goldberg и David Wagner обранужилась одна занятная особенность: последние 10 бит секретного ключа Ki всегда равнялись нулю. Используя это любопытное свойство, а так же уязвимость COMP128 к «атаке дней рождений» Marc Briceno, Ian Goldberg и David Wagner смогли извлечь секретный ключ Ki из SIM-карты.
                          Результатом этого исследования стал повсеместный отказ от алгоритма COMP128 и его замена на более надежные модификации COMP128-2 и COMP128-3, технические детали которых держатся в тайне. Хм… вам это ничего не напоминает?
                          ,
                          Ericsson подслушивание
                          В феврале 2006 года правительство Греции официально сообщило о факте прослушивания, которое осуществлялось с июня 2004 года по март 2005 года. Все пострадавшие пользовались услугами сотового оператора Vodafone, который использовал оборудование компании Ericsson.

                          Всего прослушке подверглись около сотни мобильных телефонов, среди обладателей которых были также активисты левых организаций и выходцы из арабских стран. Специальный комитет греческого парламента, занимавший расследованием этого дела, отметил причастность к этому скандалу трех сотрудников Vodafone и Ericsson. Их полные имена не были названы.

                          В отчете парламентского комитета указывалось, что подслушивание было бы невозможным без знания технологий компании Ericsson и без вмешательства внутри сети Vodafone. Однако впоследствии комитет прекратил расследование, сочтя дело слишком технически сложным.
                          ,
                          RSA Security заявила о наличии АНБ-бэкдора в своих продуктах
                          Итак, в их продуктах RSA Data Protection и RSA Bsafe во всю использовался алгоритм Dual EC_DRBG (Dual Elliptic Curve Deterministic Random Bit Generation), сертифицированный NIST (описание). И сертифицированный, как выяснилось, с сюрпризом от агенства национальной безопасности США. То есть, это никакой не random, если вы знаете в чём суть закладки.
                          Ну и о том, что этот алгоритм может содержать бэкдор, исследователи говорили еще в 2007м году. Что не помешало NIST его сертифицировать. А кипиш начался после опубликованных Сноуденом документов, где явно говорилось о неком стандарте 2006 года.

                          Dual_EC_DRBG, между прочим, является довольно популярной штуковиной.
                          Реализован в Windows, начиная с Vista SP1, что делает его самым популярным в мире. Так же, реализация есть в OpenSSL и вообще он похоже пролоббирован в куче продуктов (McAfee, например, но те использовали его только для программ гос сектора). Так что, вычищать от него код придется еще долгое время.

                          Почему «много поросят» молчат? патриотизм, деньги, принуждение и т.д.
                          «Сговорились» — на каждую хитрую #@&* найдется свой болт с левой резьбой. Если ребята покупают в свой Госдеп компы с «дырой в безопастности» — глупо орать об этом на весь мир, если ты можешь через эту «дыру в безопастности» шарится по сети потенциального противника/соперника как по свой собственной…
                            +3
                            Чаще всего много поросят молчат, потому что если расскажешь обывателю — никто не поверит, расскажешь знающим — заткнут (либо и так всем известно, либо молчи, не то прибьют).

                            Так и было до Сноудена, пока не было конфликта, никто не верил. Даже был фильм по мотивам в 1998 (Враг государства).
                              +1
                              Угу, упоминания шапочки из фольги после Сноудена — резко уменьшилось.
                              –1
                              «Масонская ложа» != «явная лажа»
                              0

                              Я просто напомню кусочек статьи:
                              Пол Тёрнер, инженер и руководитель основного костяка разработчиков Google, присутствовавший на конференции, рассказал, что никто из членов Project Zero не предупредил об открытии своих коллег; они узнали об этом вместе со всеми.

                              –1
                              По факту такой «баг дизайна» означает, что весомая часть безопастности в ИТ — одна большая подстава в планетарном масштабе, в пользу ребят «из АНБ».

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

                                0
                                  0

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

                                    +1
                                    Больше всего в опасности провайдеры облаков. Ибо запущенный ВПС может воровать данные со скоростью 1 байт в минуту (на данный момент, т.к. дыра кардинальная в архитектуре, возможно в будущем и более быстрый взлом). Что равно примерно 500 килобайт в год. Однако если знать откуда тырить, можно взять доступ рута хоста или чего похлеще.
                                      0
                                      Что равно примерно 500 килобайт в год. Однако если знать откуда тырить, можно взять доступ рута хоста или чего похлеще.

                                      А разве можно указать откуда тырить? Насколько я понимаю, это неконтролируемый процесс. То есть вы получите свои 500кб данных в год, но даже если все это время память была статична, то вероятность того, что это будут какие-то полезные данные… ну крайне мала. Если же учесть, что данные в памяти все таки регулярно обновляются, то вы скорее всего получите куски непонять из чего и как собранные.
                                      Разве не так?

                                        +1
                                        пароли в кэше процессора хранятся уже декодированными, таким образом, если вы знаете хотя бы немного структуру того против чего проводите атаку, то можете довольно точно получить доступ к декодированному паролю и всё сложное шифрование и криптоустойчивость идёт лесом…
                                          –1
                                          таким образом, если вы знаете хотя бы немного структуру того против чего проводите атаку, то можете довольно точно получить доступ к декодированному паролю

                                          Каким образом-то? Вы же просто случайные байты памяти читаете, которые еще и меняются.

                                          +1
                                          Spectre

                                          Согласно этому, большинство Спектральных атак еще вообще не залатаны.
                                          500байт данных только через один метод атак = Netspectre, которому не нужен доступ к запуску на пк.
                                          Для других систем скорость в принципе CPU Speed / byte, что достаточно для быстрого взлома (читай моментального).
                                      0
                                      Проверил.

                                      Пишет:
                                      $ Your browser is VULNERABLE to Spectre
                                      $ Please update your browser immediately

                                      Последняя версия Хрома.
                                        +1
                                        У меня наоборот, не подвержен уязвимости, FF на ОС, у которой отключены все эти патчи. В общем фигня всё это, что через яваскрипт.
                                          0
                                          Vivaldi последней версии, написал что неподвержен. Хром последней версии, написал что подвержен.
                                            0
                                            Забавно что старый хром, наоборот пишет НЕ подвержен. И старый (ESR) Лис тоже.

                                            Или это из-за того, что процессор AMD? Хотя Spectre вроде и на AMD можно реализовать в отличии от Meltdown.
                                  0

                                  Любопытно, а процессоры с архитектурой отличной от Интел — MILV Эльбрус-8C, например,
                                  и ARM, подвержены Meltdown и Spectre? И если подвержены то насколько патчи замедляют их? Интеловские процессоры патчи замедляют насколько я понял на ~ 5%, а AMD в среднем на 0.5%-1%.

                                    +1
                                    В Эльбрусе поддерживаются спекулятивные вычисления, так что Meltdown там вполне возможен, а вариации Spectre зависят от реализации защиты кешей/памяти.
                                      0
                                      в эльбрусе вроде был некий защищенный режим, когда вместе с кодом некий таг процесса передавался. вполне возможно таг спасет…
                                    +1
                                    Устраните спекулятивное выполнение – и это замедлит работу процессора в двадцать раз, сказал Хилл.
                                    Но ведь относительно свежие Intel Atom не подвержены этой атаке и при этом не работают в 20 раз медленнее аналогичных процессоров.
                                      +1
                                      Потому что уязвимость не в самом спекулятивном выполнении, а том, что это выполнение оставляет следы. На свежих атомах этих следов меньше либо их ещё не нашли.
                                        0
                                        Основной след это ведь попадание в кэш? То есть достаточно либо не писать в кэш пока инструкция реально не выполнится, либо откатывать попадание в кэш, если произошел переход и сброс конвейера. Или нет? Ну то есть это конечно изменение архитектуры, но вряд ли кардинальное.
                                          0
                                          И как Вы это представляете? stackoverflow.com/questions/4087280/approximate-cost-to-access-various-caches-and-main-memory

                                          DRAM намного медленнее даже L3 кеша, не касаясь его скорости.

                                          По сути надо избавляться от кешей вообще.
                                            0
                                            Зачем? Если инструкция реально выполнилась, то кэширование срабатывает и используется при выполнении следующих инструкций.
                                              0
                                              А если следующая инструкция? А следующая? И т.д. и т.п.

                                              Данные в кеше — надо очищать каждый раз после каждой операции — значит доступ к памяти нужен постоянно. Тут еще надо будет защитить этот самый доступ от похожих атак. А то можно таймить доступ и выяснять информацию.
                                                +1
                                                Данные в кеше — надо очищать каждый раз после каждой операции — значит доступ к памяти нужен постоянно.

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


                                                т.о. данные могут попасть в кеш в том и только том случае, если они и должны были туда попасть

                                                  0
                                                  Тут проблема в том, что спекулятивно требуется операция чтения.

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

                                                  Однако проблема в том, что проверка кеша для этого необходима. От скорости ответа и зависит тот байт или не тот.

                                                  То есть атака не на запись, а на чтение. Таким образом получается не только кеш, но и всю память прочесть (т.к. процессор спекулятивно-таки получает данные из памяти, до проверки стоит ли или нет)…

                                                  Сам факт проверки или какого-либо замедления этого процесса сразу привидет к замедлению быстродействия всей системы.

                                                  Иного выхода быть и не может.

                                                  Такого типа атаки применялись и ранее, чаще всего они есть в криптографии (тайминг и сайдченел).

                                                  Все ускорение процессоров за последнее время (от Intel по-крайней мере) висит на спекулятивном выполнении. Убрать это и мы вернемся во времена Pentium 2-3.
                                                    0
                                                    Как я понял из описания атак, проблема в том, что в кэш попадают элементы из памяти атакующего, которые зависят от значения по защищенному адресу. Атакующий потом их все читает и измеряет время доступа. Сами инструкции на чтение, но помещение в кэш это запись. То есть если не записывать в кэш прочитанные значения пока не произойдет реальное выполнение, то атакующий получит одно и то же время доступа для всех элементов, они попадут в кэш только во время этой проверки.
                                                      +2
                                                      Не, не PIII и уж тем более не PII. Кто-то похоже забыл, насколько это давно и медленно. И на самом деле, даже сказать, что на 10 лет назад — слукавить. Если убрать кэши разрушится почти-мгновенный доступ к памяти, но DDR-4 сегодня работает на четырёх гигагерцах с латентностью в сотню наносекунд. Это очень быстро по сравнению с PIII, у которых L3-кеш был примерно такого уровня. К тому же это освободит кристал от «лишней» сущности, что позволит развести дополнительные линии шины, хотя это и потребует значительной переделки. Всё это крайне сильно замедлит существенное число соверменного софта, особенно браузеры с вордами из-за активного использования разного рода виртуальных машин, которые без cpu-speed кэша не очень поворотливые, но тем не менее… Память в те времена была о-очень медленная, сейчас SSD накопители быстрее оперативной памяти того времени, так что дизайн кеша действительно может изменится, но прямо сейчас. Атака сейчас сложная к применению и только в лабораторных условиях, но со временем тулзы подрастут, а скрипты поумнеют, так что вполне возможно ожидать довольно скоро такой способ атаки от любого скрипт-кидди, а это уже проблема, и даже не только для AWS, но вообще для любого. И всё это может привести к полному пересмотру дизайна кэша.

                                                      Что до пересмотра спекулятивной логики, так это в том, что нет причин её изгонять. Дело не столько в том, что это дьявол, скрывающийся в деталях, сколько в том, что это скорее его адвокат, прикрывающий принципиальную тупость 95% населения: никто не есть фон Нейман в программировании, кроме пары нёрдов в свитерах с оленями, так что будет очень тяжело объяснить, что теперь надо программировать многопоточно, а потому 99% из вас будут расстреляны за ненадобностью, а остальные 1% клонированы, иначе нас ждёт финансовый коллапс.
                                                        0
                                                        То есть атака не на запись, а на чтение.

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


                                                        Все ускорение процессоров за последнее время (от Intel по-крайней мере) висит на спекулятивном выполнении. Убрать это и мы вернемся во времена Pentium 2-3.

                                                        Так и не надо убирать спекулятивное выполнение, надо убрать спекулятивное кеширование.
                                                        Естественно, какое-то замедление будет — но только в том случае, когда у вас вычисление условия для ветвления длиннее чтения из памяти.

                                                          0
                                                          А буффер в данном случае как защищен? Буфер жеж будет либо L1 либо L2
                                                            0
                                                            А буффер в данном случае как защищен? Буфер жеж будет либо L1 либо L2

                                                            Буфер — тут это не кеш, а специальная подсистема, в которой хранится ровно один кеш лайн перед сбросом в кеш в случае спекулятивного исполнения.
                                                            Если происходит чтение из памяти, не находящейся в кеше, вне спекулятивного исполнения — кешлайн читается в кеш (то есть ничего не меняется), если во время спекулятивного исполнения — кешлайн читается в буфер и сбрасывается из буфера в кеш после того, как операция, из-за которой он туда прилетел, стала неспекулятивной.
                                                            Читать из буфера нельзя, в принципе.

                                                              0
                                                              Амд быстрее/безопасней?
                                                              Авиры смогут как-то бороться с пооблемой?
                                                                0
                                                                АМД безопасней в некотором плане. Но спектру все подвержены в том или ином виде процы связанные со спекулянтством.

                                                                Антивири к этому не имеют отношения. Фактически это прямой доступ к ring0 из browser javascript. Решается латанием дыр (по сути запретом выполнения определенных вещей, например в firefox уменьшили разрешение gettime() колов) в компиляторах и интерпретаторах, оси и др.
                                                                0
                                                                Там не в прямом чтении дело. А в том что в процессе подбора байт проверка происходит либо быстро либо медленно, в зависимости от того, какой байт подошел. Если тот же байт то отказ приходит быстрее нежели не тот.
                                                    0
                                                    У меня на Phnom II X4 не такая уж и большая разница в прокачке DDR2 и L3, даже сам латенси больше выглядит.
                                                    0
                                                    Да фиг с ним — пусть попадает, если после этого не доступно «третьей стороне».
                                                    Процесс-владелец данных <-> Процессор.
                                                      0
                                                      Кстати да, хотя бы для системных процессов отдельное ядро со своим L2, а до L3 сложнее добраться.
                                                0
                                                Правильно ли понимаю — спекулятивные вычисления нужны, чтобы исправить косяки неэволюционирующих языков программирования, не расчитанных на параллельные вычисления? Иными словами — железные хаки?
                                                  +9
                                                  Нет. Логика проще — если есть 3 варианта ветвления кода, исполнить сразу 3, не дожидаясь решения. Когда решение будет принято — уже все 3 ветки будут исполнены, остается выбрать только одну из веток, согласно принятому решения.
                                                  Например: вы еще не пришли домой и не решили, что хотите на ужин, а подруга уже и пиво в холодильник поставила, и борщ сварила, и оладок с вареньем напекла, и горничной нарядилась — вам осталось только выбрать «чего изволите» :)
                                                    0
                                                    И уволить горничную с борщом
                                                      0
                                                      А можете продолжить пример, объяснив в таком виде суть этих атак?
                                                        +1
                                                        … «горничной» сказали, что закрыв дверь — все в безопастности и никто не зайдет. А «тот парень» открыл дверь, зашел и сожрал борщ, выпил пиво и что-то непотребное сделал с «горничной». В лучшем случае — останетесь голодным.
                                                          +3
                                                          «тот парень» подсмотрев, что ваша девушка пошла в магазин и взяла пиво «гинесс», прикупила одежку горничной, купила свеклу, варенье и муку… сделал соответствующие выводы… что вам это нравиться
                                                          и в следующий раз выгнав девушку, сам переоделся горничной, сварил борщ, пожарил оладьи и на видное место поставил пиво, что бы когда вы пришли домой, обрадовавшись пивку не сразу сообразили, что горничная-то не та…
                                                          короче по поведению вашей девушки, кто-то может подобрать ключ к вам -)
                                                            +1

                                                            Наконец-то что-то проясняется !

                                                              +4
                                                              Так вот он, концепт атаки Meltdown!
                                                              image
                                                              +1

                                                              Ну а дальше, узнав что вы сегодня будете борщ, девушка выбрасывает оладушки в мусор. И там их находит (и ворует) злобный хакер.

                                                            0
                                                            понимаете вы, разумеется, неправильно. И проблема (неэффективное использование кеша инструкций при ветвлениях), и её решение (спекулятивное выполнение) — на уровне железа, двумя уровнями ниже любых яп. Параллельно или нет, но совсем без ветвлений ни одну практическую задачу не решить.
                                                              0
                                                              Ну, всё равно спекулятивное выполнение похоже на грязный хак, а не на решение. Выполнять кучу инструкций, чтобы их выбрасывать? Неужели нельзя иначе?
                                                                –1
                                                                Можно выпилить из ЯП позднее связывание и заменить все интерфейсы на switch-case. Тогда VLIW-процессоры перестанут быть бесполезным мусором, а проблема скорости исполнения программ перестанет быть проблемой по сравнению со скоростью написания.
                                                                  0
                                                                  во-первых, switch почти во всех случаях реализуется через условные переходы. Во-вторых, VLIW процессоры не застрахованы от алгоритмов с условными переходами в рантайме.
                                                                    +1
                                                                    по сравнению со скоростью написания

                                                                    Вы забыли добавить слово «компиляторов». Java/.Net/JS программы ведь не надо переписывать.

                                                                  –1
                                                                  Ну, всё равно не ясно — чем ужасны условия? Неужели на вычисление условия нужно больше времени, чем на выполнение целой кучи инструкций?

                                                                  if(x) { 
                                                                      get_file(a, b, c);
                                                                      big_func(a, b, c); // Processing one hour 
                                                                  else { 
                                                                      get_file(e, f, g); 
                                                                      another_big_func(e, f, g); // Processing one hour 
                                                                  }  
                                                                  // x, a, b, c, e, f, g -- are known in runtime 
                                                                  

                                                                  Разъясние плиз на указанном примере принцип. Как правило условия нужны, ежели решение принимаеся во время выполнения, а знач и функции мы заранее не вычислим, ибо нужная инфа ещё не загружена.
                                                                    +2
                                                                    Проблема в наличие конвейера в современных процессорах. Обработка команд, если так можно выразиться, начинается сильно заранее их непосредственного «выполнения». Поэтому пока не получен результат if-а (пусть даже самого простого вычислительно), конвейеру пришлось бы простаивать без дела. А потом, когда исход условия прояснился бы, пришлось «раскочегаривать» конвейер заново, и ждать, пока нужная ветвь пройдёт все его стадии. Как я понимаю, в нынешних процессорах длина конвейера захватывает десятки команд.

                                                                    А так процессор может спекулятивно предположить результат if-а и заняться подготовкой на конвейере какой-либо ветви впрок. Поэтому к моменту разрешения условия всё уже готово без простоя.

                                                                    И ещё замечу, что дело не сложности или простоте условия, а в том, что его значение не может быть вычислено ранее определённого момента.
                                                                      0
                                                                      Как бы без реальных вычислений? Ну, например, конвертация машинных инструкций в низкоуровневые инструкции микропроцессора и прочее? Ибо чтобы реально выполнить функции из примера нам нужна инфа, получаемая лишь после проверки условия! А раз нету реальной инфы — знач нету и угрозы?

                                                                      И ещё, не является ли неравномерная нагрузка процессора — проблемой «линейных» языков программирования? И как её решить без спекуляции?

                                                                      Решение ну явно некрасивое ;-)
                                                                        0
                                                                        Ибо чтобы реально выполнить функции из примера нам нужна инфа, получаемая лишь после проверки условия! А раз нету реальной инфы — знач нету и угрозы?

                                                                        А на это есть алгоритмы пресказания ветвления — один из самых охраняемых «секретов фирмы». В последних процессорах пытаются приделать для этого нейронные сети, как раз потому что разное ПО с разным поведением сильно влияет на «утилизацию вычислительных ресурсов» и штрафы за ошибки предсказания.
                                                                        Дабы уменьшить штрафы — и загружают все что может пригодится «на всякий случай»
                                                                      +1
                                                                      рассмотрим простые инструкции на современных процах, например умножение вещ. чисел одинарной точности, для skylake: latency = 4, CPI = 0.5. Это значит, что за один такт процессор может засунуть в конвеер две инструкции умножения, но результат выполнения каждой из них будет доступен только через четыре такта. Теперь предположим, что мы между этими двумя операциями вставим условный переход, что-то типа:
                                                                      float a = b * c;
                                                                      if (a > d) // допустим, это холодная ветка
                                                                          return 0;
                                                                      float x = y * z;
                                                                      // Считаем дальше...
                                                                      

                                                                      В общем случае нам понадобится дождаться вычисления результата a (4 такта), посчитать условие (1-2 такта), и если мы не уходим в холодную ветку можно просто считать дальше, но с проверкой 7 тактов вместо 1.

                                                                      А если выполнять спекулятивно — одновременно считается x и перепроверяется, что холодную ветку выполнять на самом деле не надо. И там либо всё ок и к моменту перепроверки уже несколько тактов насчитано (а сама проверка словно ничего и не стоила), либо насчитано несколько тактов вхолостую и надо прыгать в холодную ветку. Уязвимости как раз и используют результат этих холостых вычислений

                                                                      п.с. на истину в последней инстанции не претендую, если где не прав — поправляйте
                                                                        0
                                                                        Спасибо! Но вы привели как раз параллелизуемый пример — a и x можно считать независимо. В моём примере, вычисления не прараллелизуемы — файлы загружены после проверки — ну, например, x нужно чтобы решиь, какие файлы загружать. И функции можно вызвать лишь после проверки. Но и если бы вся инфа была загружена заранее — выполнение функции (по условию) — час, выполняя лишнюю функцию, проц бы выполнил безумно много лишней работы ;-)

                                                                        В общем на низком уровне — умножение и прочее — всё хорошо, а на высоком уровне? Ежели у вас b, с, y и z — матрицы 1000 x 1000, или вызовы функции, выполняющейся часы?

                                                                        Хм, а раньше early exit как раз и был призван избавить мир лишних вычислений! А щаз, получается, все компилеры наплевали на порядок инструкций.
                                                                          0
                                                                          На лицо несоответствие модели ЯП — железу. Хорошо, ежели программа выполняется именно так, как она написана. Не правильнее было бы явно указывать, какие куски программы можно выполнять параллельно, а какие нельзя?
                                                                            0
                                                                            Есть и для этого инструментарий давно как и на уровне оптимизации в компиляторе, так и на уровне языков/библиотек.
                                                                            Но и если бы вся инфа была загружена заранее — выполнение функции (по условию) — час, выполняя лишнюю функцию, проц бы выполнил безумно много лишней работы ;-)

                                                                            Так процессору все равно заняться нечем — данных нет, кода нет. блоки вычисления и конвейры стоят пустые. Почему бы их не занять чем-то, что в будущем может окупиться? Так сказать «инвестиции свободных ресурсов в возможное светлое будущее»
                                                                              0

                                                                              Те куски, о которых тут речь, куда мельче отдельных строк и даже инструкций программы (см. μops, конвертация во внутреннее RISC-представление, вот это всё).


                                                                              Там, кстати, свои забавные баги бывают. ЕМНИП одно время одно из относительно недавних поколений процов считали, что, условно, xor eax, eax имеет зависимость по данным от eax, хотя где-то со второго пня процессоры умеют распознавать этот паттерн как зануление регистра и тупо мапят eax на нулевой/обнулённый регистр.

                                                                            +1

                                                                            На указанном примере это смысла действительно не имеет. Спекулятивное исполнение куда важнее для того, что называется tight loops.


                                                                            Например, для большого ArrSize,


                                                                            for (int i = 0; i < ArrSize; ++i)
                                                                            {
                                                                                // handle i
                                                                                if (!(i % 10))
                                                                                    // special handling for i = 10k
                                                                            }

                                                                            Более того, вам даже внутри цикла условий не нужно, чтобы ощутить профит от спекулятивного исполнения: сам цикл — тоже условие, в конце концов (if predicate goto loop). И вам не нужно дожидаться окончания текущей итерации цикла, если следующая итерация от текущей не зависит (умножение матриц там, всё такое, ага).


                                                                            А для выбора того, какой файл читать, это всё нафиг не нужно, да.

                                                                        0
                                                                        По виртуальным машинам непонятно. Если XEN выделяет целое ядро ВМ и только ей, то у нее нет возможности пробраться в другие ВМ или в корневую ОС.
                                                                          0
                                                                          Упсъ… а вот тут и проблема. У машины как таковой нет, а у процессора есть. Процессор просто помещает кусок памяти из процесса одной ВМ в кеш который общий то для всех, а в процесс другой ВМ эток кусок памяти отбражается.
                                                                            0
                                                                            Что-то я даже и не догадался, что у ядер общий кеш.
                                                                              0
                                                                              Да, свой «собственный» кэш у ядра только 1го уровня (L1).
                                                                              L2 в большинстве случаев, а L3 вообще всегда делятся с другими ядрами процессора и изоляции данных обеспечить не могут.
                                                                                0
                                                                                У меня Athlon ii X3 вообще без L3 кэша. Я застрахован от этих атак?
                                                                                  0
                                                                                  От Meltdown — точно. От Spectre — c высокой вероятностью.
                                                                                  Правда кэш тут не причем. Просто Meltdown уязвимости вообще в процессорах AMD нет за счет отличающейся архитектуры. А Spectre сложнее реализовать.

                                                                                  Структура кэш же важна при делении процессора «с соседями» — если к началу ветки вернуться, обсуждали работу на серверах и облачных вычислениях. Когда один физический процессор делится между несколькими разными клиентам разными системами виртуализации и один из клиентов может с помощью этих уязвимостей пытаться «выуживать» информацию из работающего софта у «соседей».
                                                                          –4
                                                                          Не нужно никакого нового процессора.
                                                                          Достаточно простой, очевидный и безусловно надежный способ уже описан в патентной заявке.
                                                                          Пока сложно сказать у кого будет патентный приоритет, но разработчики Эльбруса в курсе.
                                                                          Поэтому надеюсь что приоритет будет за ними.
                                                                            –1
                                                                            Можно отказаться от out-of-order, и вообще от суперскаларности, а для закрузки конвеера использовать гипертрединг с большим количество нитей.
                                                                            Еще можно хостить не нативные приложения, а байткод, котовый верифицировать на экслуотацию известных уязвимостей.
                                                                              +1
                                                                              Еще можно хостить не нативные приложения, а байткод, котовый верифицировать на экслуотацию известных уязвимостей.

                                                                              Это скрестить сигнатурный анализатор с JIT-компилятором? Так МС вас опередила — на уровне компилятора с 2003 года нельзя дергать системные функции без критериев безопастности (явного размера данных), в .Net встроены декларативные механизмы безопастности, в для нативных приложений используются манифесты. Это решило часть проблем. Что делать с остальным — пока не очень понятно.
                                                                                0
                                                                                Еще можно хостить не нативные приложения, а байткод, котовый верифицировать на экслуотацию известных уязвимостей.

                                                                                Ща, пять сек, только задачу останова дорешаю.

                                                                                  0

                                                                                  Причем тут задача останова к сигнатурному поиску это же не проактивка какая

                                                                                +2
                                                                                Мне кажется, что x86 это навсегда! Уж насколько Itanium был лучше, и то умер.
                                                                                  0
                                                                                  Уязвимость только х64 задела?
                                                                                  0
                                                                                  Насколько я понимаю, многозадачность современных системах реализована на уровне процессора. Т.е. в процессор уже заложено разграничение между процессами на доступ к ресурсам и т.д. В чём проблема подписывать данные в кэше идентификатором процесса? Процесс что-то вычислял, получал данные из своей области памяти и часть данных отпечаталась в кэш. Потом пришёл другой процесс со своей памятью и своими данными — зачем вообще процессор тратит время на поиск в области кеша, в которую этот новый процесс ничего не писал? «Ну а что, а вдруг?» Что стоит изолировать данные в кеше между процессами? Так и кеш будет работать быстрее — не потратит время на поиск данных там, где их нет и быть не может, и безопасность будет выше.
                                                                                    +1
                                                                                    В чём проблема подписывать данные в кэше идентификатором процесса?

                                                                                    Уже, гуглить PCID.
                                                                                    «Ну а что, а вдруг?»

                                                                                    Так и есть. Есть общесистемные библиотеки, разделяемые данные.
                                                                                    Так и кеш будет работать быстрее — не потратит время на поиск данных там, где их нет и быть не может, и безопасность будет выше.

                                                                                    Медленнее, потому что придётся учитывать ещё один параметр. Кеш реализован в железе, и тут дополнительыне параметры только портатят транзисторный бюджет.
                                                                                      0
                                                                                      Сейчас программно так и реализовали (KPTI), по сути ОС загружает и выгружает данные из кеша, когда они больше не нужны.

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

                                                                                      Да, производительность немного упадёт, но не нужно будет изобретать «процессор совершенно нового типа».

                                                                                      Или у меня искажённые представления, и программы постоянно лезут в недоступные области памяти, «разгоняя» друг друга за счёт кэширования?
                                                                                        0
                                                                                        Я слабо представляю, как работают современные процессоры, но неужели нельзя вместо «не читать лишние данные» и «очищать кэш после каждой операции» пойти немного другим путём — «очищать в кэше только те данные, которые не должны были туда попасть»?

                                                                                        Нюанс в том, как именно организована память и ее адресация. Физическая адресация. Кеш вычитывает данные не побайтово, а целыми кусками/страницами.
                                                                                        Такая логика имеет смысл по нескольким причинам причинам:
                                                                                        • исполнимый код расположен одним непрерывным куском в памяти,
                                                                                        • обрабатываемые данные с большой степенью вероятности расположены последовательно
                                                                                        • сменить физическую адресацию памяти занятие не дешевое само по себе (на планках памяти DDR4 CAS Latencies 14- 20 t, DDR3 CL9-CL11 t )

                                                                                        Если тонким слоем «размазать» данные по памяти — производительность сильно упадет.
                                                                                        «очищать в кэше только те данные, которые не должны были туда попасть»

                                                                                        По дизайну именно так и задумано «не должно попасть» — все нарезано на странички, каждая со своими пометками, все помещено в какой-то контекст, свои таблицы трансляции и т.д.
                                                                                        А по факту — весьма странный «баг дизайна»
                                                                                        0
                                                                                        То есть архитектура процессора не подверженного Spectre и Meltdown ещё не разработана? А как же тогда заявление про Ice Lake на Wiki?
                                                                                        It is expected that Ice Lake will have in-silicon mitigations for the Meltdown and Spectre hardware vulnerabilities
                                                                                          0
                                                                                          мне одному кажется, что эти уязвимости всплыли как бы случайно, но на самом деле это очень выгодно производителям процов — когда не смогли выжать нормальную мощность, то пошли лепить 100500 ядер, потом более «экологичные» процы со снижением энергопотребления, а теперь все процы оказывается суперуязвимые — снова тратить деньги

                                                                                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                                          Самое читаемое