Раскрытие уязвимостей 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 как будто потерял бoльшую часть динамики разработки, какая была раньше.
Сейчас максимальная активность вроде бы связана с архитектурой 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 добьётся успеха на рынке, есть высокие шансы, что реальные процессоры не станут поставляться со свободно лицензируемым дизайном. Крупные заказчики (которые строят дата-центры по собственным проектам) могут настоять на получении дизайна микросхем — или просто создать собственный — но у остальных довольно слабая переговорная позиция.
Наконец, даже если мы получим полностью открытые и свободные процессоры, с уязвимостями на этом уровне не будет полностью покончено. У нас есть свободное ядро, но уязвимости в ядре тоже постоянно находят. Открытое железо может придать больше уверенности, что мы сохраним контроль над нашими системами в долговременной перспективе, но это не волшебная палочка для решения всех проблем.
Впрочем, ничего из этого не должно помешать нам добиваться большей открытости и свободы в части аппаратного обеспечения. Когда-то и создание свободной операционной системы казалось непреодолимо сложной задачей, но мы сделали, причём несколько раз. Отход от проприетарного дизайна аппаратного обеспечения может стать одним из лучших шансов сохранить нашу свободу; будет глупо не попытаться сделать это.
Комментарии (42)
aleaksah
30.01.2018 17:08Безопасность линукса часто объясняют простотой исправлений и обновлений, доступных каждому, а открытые исходники ставят в пример как возможность исследования на предмет ошибок для их последующего исправления.
А как исправлять баги процессора, которые благодаря открытым исходника будет искать значительно проще, чем в процессорах с закрытым описанием?
VBKesha
30.01.2018 17:29А как исправлять баги процессора, которые благодаря открытым исходника будет искать значительно проще, чем в процессорах с закрытым описанием?
Если бы Specter/Meltdown наши скажем ещё в 4 пне, то возможно он бы уже давно был исправлен, но его нашли(ну по крайней мере официально) не так давно, в итоге куча чипов да ещё и разных архитиктур оказалась забагована(интересно они что друг у друга покупают модули, или вообще у треттих фирм).aleaksah
30.01.2018 17:35Все ради шанса, что будет баг найден раньше и исправлен меньшей кровью? Сомнительно. Разнообразные баги вроде громкого ShellShock могут незамеченно существовать в опенсорсе десятилетиями.
allter
30.01.2018 23:30А зачем их исправлять. Напечатал новые процессоры, а старые —
выбросилпродал врагу. В конце концов, если будут открытые исходники, то неразумно покупать только у одного вендора процессоров — их надо печатать по необходимости, — желательно, самостоятельно.aleaksah
30.01.2018 23:50А в чем тогда принципиальная разница между процессорами с открытым и закрытым описанием?
И было бы очень интересно посмотреть на самостоятельное изготовление процессора.kalininmr
31.01.2018 03:42на таком техпроцессе дома/вгараже — нереально.
а вот всякие ПЛИС… но тоже сомнительный вариант.
было бы интересно если бы в проце был небольшой кусочек плиса. наверное.aleaksah
31.01.2018 12:01Чтобы прошить ПЛИС — нужно иметь рабочую систему, а это либо держать два компьютера, либо усложнять (а значит, увеличивать количество критических элементов) само устройство компьютера.
К тому же ПЛИС, которые могут содержать в себе полноценный процессор, стоят как минимум на порядок дороже процессора. Дешевле регулярно покупать исправленную версию серийного производства.
А на счет «иметь кусочек ПЛИСа в процессоре» — в некотором смысле, микрокод именно эту функцию и выполняет.kalininmr
31.01.2018 16:10ну да. микрокод в какойто мере позволяет модифицировать проц.
но сопроцессор с плис позволил бы расширять.
есть же железки отдельные для всякой хитрой математики и прочего.aleaksah
31.01.2018 16:55Почему бы вам не взять отладочную плату для ПЛИС с разъемом PCI (PCIe)? Тут и плис, и шина близкая к процессору.
ToshiruWang
31.01.2018 10:26Чтобы печатать — нужны технологии, а «самостоятельно» для печати на приличном уровне есть не так много вариантов. Да и «печать по необходимости» кратно увеличивает цену — будет у вас i386 по цене i3.
nckma
30.01.2018 17:18+1Еще ядро MIPS забыли.
Вроде бы открытые исходники для академических нужд.
Правда, что-то мне не верится, что открытые исходники процессора, кто-то сможет реально смотреть/исправлять/вести отладку.
Понятно, что openRISC или MIPS можно попробовать в FPGA. А вот аналог Core i7 ни в какой FPGA не поместится.VBKesha
30.01.2018 17:26Понятно, что openRISC или MIPS можно попробовать в FPGA. А вот аналог Core i7 ни в какой FPGA не поместится.
Можно ведь просимулировать, да это медленно но возможно.pvl_1
31.01.2018 10:25Ха. Конечно, можно просимулировать, но это будет не медленно, а ОЧЕНЬ медленно. Сравните сотни килогерц для симуляции (число взято с потолка, так как я точно не знаю частоты), десятки мегагерц на FPGA и гигагерцы в реальных камнях. Эффективнее оказывается моделировать процессор на нескольких FPGA, каким-то образом объединённых в одно устройство, и дебажить логику так.
GermanRLI
31.01.2018 18:42FPGA избыточна потому что переконфигурируемв. А значит если на ней можно уместить какой-то процессор — значит процессор с такими характеристиками можно сделать дешевле, потому что грубее тех процесс, меньше элементов, меньше площадь кристалла или за ту же стоимость — сделать процессор с тем же тех процессом, количеством элементов и площадью — но с существенно лучшими характеристиками. Разумеется при условии достаточно массового тиража такого процессора, а при тираже больше тиража FPGA — он ещё и дешевле выйдет, потому как затраты на R&D по большему числу экземпляров размажутся.
atrosinenko
31.01.2018 13:07Ну, "открытые исходники для академических нужд" — это всё-таки не "свободные процессоры" и для разработки своего процессора, наверное, далеко не лучший вариант. Хотя, с точки зрения анализа это, конечно, намного лучше, чем ничего.
nckma
31.01.2018 13:09
CDmitry
30.01.2018 18:41+1А я не понял, каким образом будет происходить обновление тех же процессоров, если будет найдена уязвимость?
В софте уязвимости устраняются и пользователи просто обновляют ПО, а с процессором просто так не обновишься, и в итоге будешь и без обновлений сидеть, и с кучей открытых уязвимостейold_bear
30.01.2018 21:45Во первых в процессоре бывает микрокод, равно как и софтовые заплатки могут помочь.
Во вторых, речь идёт о том, что в открытой системе серьёзные баги не будут жить годами и поколениями.CDmitry
30.01.2018 22:12я про хардварные баги, которых найдут к примеру 20 штук в новеньком процессоре тысяч за 40, и единственным решением будет покупка нового, а если не купишь — то уязвим для всех атак, все хаскеры знают как тебя сломать.
Имхо в таком случае лучше и баги пусть не находят, и все закрыто будет, чем каждый раз новый камень покупать.old_bear
30.01.2018 22:39Вы немного наивны. Разница будет лишь в том, что вы не будете знать про уязвимости. А заинтересованные лица про них будут знать в любом случае.
Хардварные баги тоже можно закрыть софтом, как это сейчас делают для интеловских процов.
Dessloch
31.01.2018 12:23А ещё как я понимаю открытая система предполагает отсутствие лицензионных отчислений, следовательно такой процессор должен стоить дешевле. Так что при обнаружении и последующем устранении уязвимости просто покупается новый процессор.
Anymorficus
31.01.2018 10:25Достаём прушу, катушку чистогокремния, диаметром 1.75 и печатаем новый процессор.
Ну или идем к другу у которого струйник может на кремниевой болванке допечатать недостающие транзисторы, для устранения уязвимости.
В крайнем случе идем в ларёк покупаем чистую кремниевую болванку, а лучше пачку, и печатаем полупроводниковыми чернилами новый процессор.
Всё как раньше, только вместо оптических болванок — процессорные.
PositiveAlex
31.01.2018 12:19Как мне кажется, стоит вспомнить heartbleed в openssl. Код, открытый сообществу, все равно содержал уязвимость. Прежде всего, уязвимость — это баг, такой же баг, как и все остальное. И баги будут всегда, хоть в закрытом, хоть в открытом проекте, хоть в коде, хоть где-либо ещё.
Dessloch
31.01.2018 13:43+1Зато в открытом коде меньше/нет закладок.
DjPhoeniX
31.01.2018 14:59А вот в железе… Ха!
А где гарантия, что в милли(-онах/-ардах) транзисторов нет аппаратной закладки, которая хитро рассредоточена по всей площади? (Ладно, это и в софте может быть)
А где гарантия, что тот кристалл, который вы купили в магазине, сделан по той же схеме, что вы нашли в интернете? (В софте бывает, но его можно пересобрать, а вот 10нм принтер микросхем есть не у каждого дома)
В общем, open hardware — хорошо, но…
stanislavshwartsman
Cтарый добрый 386 тоже «не допускает никакого спекулятивного доступа к памяти» по причине отсутствия спекулятивного выполнения как такового.
nckma
То-то и оно…
Спекулятивный доступ дает выигрышь в быстродействии. Если его нет, то получится более медленное исполнение. Вот и выбирайте… Быстро, но с уязвимостью, или медленно, но без уязвимости.
AlexTest
Интересно, а для эксплуатирования Meltdown на старых INTEL CPU программный код будет отличаться? Т.е. надо ли для каждого отдельного проца писать свой код или он будет одинаковый для всех INTEL CPU?
kalininmr
по идее принцип одинаковый.
но фиг знает как различается работа с кешем и прочее.
dimkrayan
либо можно попробовать построить более простое ядро без излишних вычислительных блоков, без переупорядочивания, зато ядер побольше.
Сейчас и программисты получше научились работать с многопоточностью, и инструменты появились.
kalininmr
будет жуткое падение производительности.
все эти изменения порядка выполнения инструкций нужны для того, чтобы утилизировать все блоки проца. иначе каждый такт почти все мозги будут простаивать.
dimkrayan
тут спорный момент. В современных процессорах слишком много вычислительных блоков. И и так очень много протаивает. Если их количество уменьшить, но ядер сделать сильно больше — на этом вполне можно сыграть. Плюс — можно ввести отдельные специализированные ядра для видео, криптографии…
Конечно, софт придется переписывать, чтобы получить преимущества, а не наоборот уйти в прошлое.
Представьте себе, у вас 1000 более простых ядер, и вы даете ядра процессу в единоличное пользование. Без переключений контекста.
kalininmr
не все задачи паралелятся.
а если учесть, что, например на десктопе, наиболее критичен поток ГУИ, то совсем печально.
1000 ядер почти бессмыслены в прикладных задачах общего характера.
dimkrayan
1. с гуи как раз все намного проще.
Там куча потоков используется просто для удобства, даже не для производительности. Отдельный поток слушает нажатия кнопок, отдельный — движения мыши. А процессор видяхи — так вообще прям создан для параллельных вычислений.
2. Наверное, не все задачи параллелятся, но вот я с ходу не смог придумать такую задачу. Все, что я встречал — это просто такая реализация. И скорее всего, ноги росли из начала 2000-х, когда даже 2-процессорные компы были редкостью.
3. А почему нет? Каждой вкладке браузера можно выдать даже не по одному потоку. Отдельно для гуи, отдельно для бизнес-логики. И это, кстати, может уменьшить латенси. А то, если честно, напрягает, когда набираешь код в idea, а на экране все появляется где-то через секунду. И у меня не дохлый комп. core i7, 16 гб. памяти, ssd.
kalininmr
по поводу латенси, кстати, надо вспомнить, что потоки сами по себе добавляют тормозов в виде накладных расходов на переключение контекста.
а непаралелятся все задачи итерационной природы, если нежен полный результат в следующей итерации. таких много
dimkrayan
да, добавляют. Потому, что потоков сильно больше, чем ядер.
да, я знаю. Но в реальности в голову приходит только какая-нибудь глупость, вроде синуса от синуса от… А на практике часто оказывается, что мат. модель можно изменить, например, сделать ее ассоциативной.
Либо, если результат дискретный — можно попытаться сделать иммитацию тех же спекулятивных вычислений, вроде вычисления на других ядрах наиболее вероятных результатов вычисления предыдущей операции с последующим отбрасыванием того, что не угадал.
kalininmr
ну почему же глупость.
любая задача где композиция аггрегативных функций.
их много