Пришло время для открытых и свободных процессоров?

Автор оригинала: Jonathan Corbet
  • Перевод
Раскрытие уязвимостей Meltdown и Spectre снова привлекло внимание к багам на аппаратном уровне. Многое сделано для улучшения (всё ещё слабой) безопасности нашего программного обеспечения, но всё напрасно, если оборудование даёт сбой. Процессоры в наших системах по-прежнему, в основном, проприетарные и уже преподнесли ряд неприятных сюрпризов (например, в движке Intel Management Engine). Поэтому встаёт естественный вопрос о переходе на железо open-source, как мы сделали с нашим программным обеспечением. Такой переход вполне возможен и даёт ряд преимуществ, хотя и не является панацеей.

Учитывая сложность современных процессоров и свирепый рынок, где они продаются, их разработка по принципам open-source может показаться необычной идеей. Но в этой области уже есть серьёзные инициативы; так что идея свободного дизайна CPU — не просто фантазия. Небольшое исследование темы выявляет несколько проектов; хотя дальнейший список явно не полон.

Из чего выбирать


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

Затем, есть OpenSPARC, где Sun Microsystems полностью открыла архитектуры процессоров SPARC T1 и T2. Несколько проектов пытались использовать эти архитектуры, но пока неясно, удалось ли кому-нибудь добиться успеха. На данный момент открытой архитектуре SPARC уже десять лет, а будущее SPARC в целом под сомнением. Что-нибудь интересное может получиться, если Oracle решит открыть архитектуры современных процессоров, но ожидать этого события, затаив дыхание — тоже не лучшая идея.

OpenRISC — полностью открытая архитектура процессора для встроенных приложений; у них полностью готов один процессор (OpenRISC 1000). Сделаны несколько коммерческих версий OpenRISC 1000, существуют и эталонные реализации (такие как mor1kx). Ядро Linux поддерживает OpenRISC с версии 3.1, которая вышла в 2011 году, а порт на Debian существует с 2014 года. Правда, работа в рамках дистрибутива Debian прекратилась в 2016-м. Работа над кодом OpenRISC для ядра тоже замедлилась, хотя в 2017 году появилась поддержка SMP. В целом, OpenRISC как будто потерял бóльшую часть динамики разработки, какая была раньше.

Сейчас максимальная активность вроде бы связана с архитектурой RISC-V. Этот проект ориентируется, в основном, на архитектуру набора команд (ISA), а не на конкретные реализации, но существуют и примеры дизайна свободного оборудования. Western Digital недавно анонсировала, что будет использовать процессоры RISC-V в своём оборудовании для хранения данных — это может привести к поставкам RISC-V в миллиардном масштабе. Есть набор средств разработки для тех, кто хочет поиграться с этим процессором, и доступны многие архитектуры ядра.

В отличие от OpenRISC, RISC-V нацелен на различные варианты использования. Есть надежда, что простая архитектура RISC позволит относительно легко сделать быстрый процессор. В то же время для низкопроизводительных устройств существует сокращённый формат потока команд, с помощью которого уменьшаются требования к памяти и сокращается энергопотребление. ISA предусматривает расширения для конкретных реализаций, что облегчает эксперименты и добавление техник аппаратного ускорения.

Поддержка RISC-V в Linux появилась совсем недавно; только в версии 4.15 (релиз состоялся 28 января 2018 года). Активность разработчиков кажется весьма бурной, а в соответствующих проектах также есть поддержка необходимых инструментальных средств и библиотеки. Судя по всему, у RISC-V имеется определённая поддержка в коммерческой индустрии — по крайней мере, в организацию RISC-V Foundation вступило много компаний. В ближайшее время эта архитектура должна продолжать развитие.

Решение аппаратной проблемы?


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

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

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

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

В спецификациях RISC-V ничего не сказано, что конкретные варианты реализаций обязаны публично открывать свою архитектуру. Даже если RISC-V добьётся успеха на рынке, есть высокие шансы, что реальные процессоры не станут поставляться со свободно лицензируемым дизайном. Крупные заказчики (которые строят дата-центры по собственным проектам) могут настоять на получении дизайна микросхем — или просто создать собственный — но у остальных довольно слабая переговорная позиция.

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

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

Комментарии 44

    0
    Cтарый добрый 386 тоже «не допускает никакого спекулятивного доступа к памяти» по причине отсутствия спекулятивного выполнения как такового.
      0
      То-то и оно…
      Спекулятивный доступ дает выигрышь в быстродействии. Если его нет, то получится более медленное исполнение. Вот и выбирайте… Быстро, но с уязвимостью, или медленно, но без уязвимости.

        0
        Интересно, а для эксплуатирования Meltdown на старых INTEL CPU программный код будет отличаться? Т.е. надо ли для каждого отдельного проца писать свой код или он будет одинаковый для всех INTEL CPU?
          0
          по идее принцип одинаковый.
          но фиг знает как различается работа с кешем и прочее.
          –1
          либо можно попробовать построить более простое ядро без излишних вычислительных блоков, без переупорядочивания, зато ядер побольше.
          Сейчас и программисты получше научились работать с многопоточностью, и инструменты появились.
            0
            будет жуткое падение производительности.
            все эти изменения порядка выполнения инструкций нужны для того, чтобы утилизировать все блоки проца. иначе каждый такт почти все мозги будут простаивать.
              0
              тут спорный момент. В современных процессорах слишком много вычислительных блоков. И и так очень много протаивает. Если их количество уменьшить, но ядер сделать сильно больше — на этом вполне можно сыграть. Плюс — можно ввести отдельные специализированные ядра для видео, криптографии…
              Конечно, софт придется переписывать, чтобы получить преимущества, а не наоборот уйти в прошлое.
              Представьте себе, у вас 1000 более простых ядер, и вы даете ядра процессу в единоличное пользование. Без переключений контекста.
                0
                не все задачи паралелятся.
                а если учесть, что, например на десктопе, наиболее критичен поток ГУИ, то совсем печально.

                1000 ядер почти бессмыслены в прикладных задачах общего характера.
                  0
                  1. с гуи как раз все намного проще.
                  Там куча потоков используется просто для удобства, даже не для производительности. Отдельный поток слушает нажатия кнопок, отдельный — движения мыши. А процессор видяхи — так вообще прям создан для параллельных вычислений.
                  2. Наверное, не все задачи параллелятся, но вот я с ходу не смог придумать такую задачу. Все, что я встречал — это просто такая реализация. И скорее всего, ноги росли из начала 2000-х, когда даже 2-процессорные компы были редкостью.
                  3. А почему нет? Каждой вкладке браузера можно выдать даже не по одному потоку. Отдельно для гуи, отдельно для бизнес-логики. И это, кстати, может уменьшить латенси. А то, если честно, напрягает, когда набираешь код в idea, а на экране все появляется где-то через секунду. И у меня не дохлый комп. core i7, 16 гб. памяти, ssd.
                    0
                    по поводу латенси, кстати, надо вспомнить, что потоки сами по себе добавляют тормозов в виде накладных расходов на переключение контекста.

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

                      да, я знаю. Но в реальности в голову приходит только какая-нибудь глупость, вроде синуса от синуса от… А на практике часто оказывается, что мат. модель можно изменить, например, сделать ее ассоциативной.
                      Либо, если результат дискретный — можно попытаться сделать иммитацию тех же спекулятивных вычислений, вроде вычисления на других ядрах наиболее вероятных результатов вычисления предыдущей операции с последующим отбрасыванием того, что не угадал.
                        0
                        ну почему же глупость.
                        любая задача где композиция аггрегативных функций.
                        их много
        +2
        Безопасность линукса часто объясняют простотой исправлений и обновлений, доступных каждому, а открытые исходники ставят в пример как возможность исследования на предмет ошибок для их последующего исправления.
        А как исправлять баги процессора, которые благодаря открытым исходника будет искать значительно проще, чем в процессорах с закрытым описанием?
          +1
          А как исправлять баги процессора, которые благодаря открытым исходника будет искать значительно проще, чем в процессорах с закрытым описанием?

          Если бы Specter/Meltdown наши скажем ещё в 4 пне, то возможно он бы уже давно был исправлен, но его нашли(ну по крайней мере официально) не так давно, в итоге куча чипов да ещё и разных архитиктур оказалась забагована(интересно они что друг у друга покупают модули, или вообще у треттих фирм).
            +1
            Все ради шанса, что будет баг найден раньше и исправлен меньшей кровью? Сомнительно. Разнообразные баги вроде громкого ShellShock могут незамеченно существовать в опенсорсе десятилетиями.
            0
            А зачем их исправлять. Напечатал новые процессоры, а старые — выбросил продал врагу. В конце концов, если будут открытые исходники, то неразумно покупать только у одного вендора процессоров — их надо печатать по необходимости, — желательно, самостоятельно.
              0
              А в чем тогда принципиальная разница между процессорами с открытым и закрытым описанием?
              И было бы очень интересно посмотреть на самостоятельное изготовление процессора.
                0
                на таком техпроцессе дома/вгараже — нереально.
                а вот всякие ПЛИС… но тоже сомнительный вариант.

                было бы интересно если бы в проце был небольшой кусочек плиса. наверное.
                  0
                  Чтобы прошить ПЛИС — нужно иметь рабочую систему, а это либо держать два компьютера, либо усложнять (а значит, увеличивать количество критических элементов) само устройство компьютера.
                  К тому же ПЛИС, которые могут содержать в себе полноценный процессор, стоят как минимум на порядок дороже процессора. Дешевле регулярно покупать исправленную версию серийного производства.
                  А на счет «иметь кусочек ПЛИСа в процессоре» — в некотором смысле, микрокод именно эту функцию и выполняет.
                    0
                    ну да. микрокод в какойто мере позволяет модифицировать проц.
                    но сопроцессор с плис позволил бы расширять.
                    есть же железки отдельные для всякой хитрой математики и прочего.
                      0
                      Почему бы вам не взять отладочную плату для ПЛИС с разъемом PCI (PCIe)? Тут и плис, и шина близкая к процессору.
                        0
                        ну да. можно.
                        но почему бы это не сделать штатной частью.
                        какие переспективы открываются!
                          0
                          Потому что это нужно будет считанным единицам, а это дорогостоящее оборудование.
                0
                Чтобы печатать — нужны технологии, а «самостоятельно» для печати на приличном уровне есть не так много вариантов. Да и «печать по необходимости» кратно увеличивает цену — будет у вас i386 по цене i3.
                0

                Подобного рода уязвимости — это далеко не так страшно, как бекдоры от анб

                +2
                Еще ядро MIPS забыли.
                Вроде бы открытые исходники для академических нужд.

                Правда, что-то мне не верится, что открытые исходники процессора, кто-то сможет реально смотреть/исправлять/вести отладку.

                Понятно, что openRISC или MIPS можно попробовать в FPGA. А вот аналог Core i7 ни в какой FPGA не поместится.
                  0
                  Понятно, что openRISC или MIPS можно попробовать в FPGA. А вот аналог Core i7 ни в какой FPGA не поместится.

                  Можно ведь просимулировать, да это медленно но возможно.
                    0
                    Ха. Конечно, можно просимулировать, но это будет не медленно, а ОЧЕНЬ медленно. Сравните сотни килогерц для симуляции (число взято с потолка, так как я точно не знаю частоты), десятки мегагерц на FPGA и гигагерцы в реальных камнях. Эффективнее оказывается моделировать процессор на нескольких FPGA, каким-то образом объединённых в одно устройство, и дебажить логику так.
                      0

                      FPGA избыточна потому что переконфигурируемв. А значит если на ней можно уместить какой-то процессор — значит процессор с такими характеристиками можно сделать дешевле, потому что грубее тех процесс, меньше элементов, меньше площадь кристалла или за ту же стоимость — сделать процессор с тем же тех процессом, количеством элементов и площадью — но с существенно лучшими характеристиками. Разумеется при условии достаточно массового тиража такого процессора, а при тираже больше тиража FPGA — он ещё и дешевле выйдет, потому как затраты на R&D по большему числу экземпляров размажутся.

                        0
                        Зато такой процессор будет переконфигурируемым. Например DISC — Dynamic Instruction Set Computer. Странно что в статье не упомянули об альтернативных направлениях в процессоростроении.
                      0

                      Ну, "открытые исходники для академических нужд" — это всё-таки не "свободные процессоры" и для разработки своего процессора, наверное, далеко не лучший вариант. Хотя, с точки зрения анализа это, конечно, намного лучше, чем ничего.

                    +3
                    А я не понял, каким образом будет происходить обновление тех же процессоров, если будет найдена уязвимость?
                    В софте уязвимости устраняются и пользователи просто обновляют ПО, а с процессором просто так не обновишься, и в итоге будешь и без обновлений сидеть, и с кучей открытых уязвимостей
                      0
                      Во первых в процессоре бывает микрокод, равно как и софтовые заплатки могут помочь.
                      Во вторых, речь идёт о том, что в открытой системе серьёзные баги не будут жить годами и поколениями.
                        0
                        И кто их будет искать?
                        Баги десятилетиями живут в линуксе.
                          0
                          я про хардварные баги, которых найдут к примеру 20 штук в новеньком процессоре тысяч за 40, и единственным решением будет покупка нового, а если не купишь — то уязвим для всех атак, все хаскеры знают как тебя сломать.

                          Имхо в таком случае лучше и баги пусть не находят, и все закрыто будет, чем каждый раз новый камень покупать.
                            +1
                            Вы немного наивны. Разница будет лишь в том, что вы не будете знать про уязвимости. А заинтересованные лица про них будут знать в любом случае.
                            Хардварные баги тоже можно закрыть софтом, как это сейчас делают для интеловских процов.
                            0
                            А ещё как я понимаю открытая система предполагает отсутствие лицензионных отчислений, следовательно такой процессор должен стоить дешевле. Так что при обнаружении и последующем устранении уязвимости просто покупается новый процессор.
                            +1
                            Достаём прушу, катушку чистогокремния, диаметром 1.75 и печатаем новый процессор.
                            Ну или идем к другу у которого струйник может на кремниевой болванке допечатать недостающие транзисторы, для устранения уязвимости.
                            В крайнем случе идем в ларёк покупаем чистую кремниевую болванку, а лучше пачку, и печатаем полупроводниковыми чернилами новый процессор.

                            Всё как раньше, только вместо оптических болванок — процессорные.
                            0

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

                              +1
                              Зато в открытом коде меньше/нет закладок.
                                0
                                А вот в железе… Ха!
                                А где гарантия, что в милли(-онах/-ардах) транзисторов нет аппаратной закладки, которая хитро рассредоточена по всей площади? (Ладно, это и в софте может быть)
                                А где гарантия, что тот кристалл, который вы купили в магазине, сделан по той же схеме, что вы нашли в интернете? (В софте бывает, но его можно пересобрать, а вот 10нм принтер микросхем есть не у каждого дома)

                                В общем, open hardware — хорошо, но…
                                  0

                                  Я правильно понимаю, что даже пытаться не стоит?

                                    0
                                    Пытаться можно, но готовым к КПД 0 быть нужно.

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

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