#bsd #hate 

Обновлять ли блобы или нет?

https://codon.org.uk/~mjg59/blog/p/to-update-blobs-or-not-to-update-blobs/
Человек тут верно описывает все за и против обновления микрокода в
железе. Ты можешь доверять производителю и верить что его обновление
будет исправлять косяки и улучшать безопасность. Можешь не верить, но у
тебя возможно всё равно не будет выбора ухода к другому.

Я вот точно не доверяю ни Intel, ни AMD, но куда деваться? Свои CPU я
сделать не могу. Эльбрус является закрытой экосистемой в целом.
Производители ARM -- всё аналогично. Я могу например не допускать
применений, где всё будет уязвимо: не подключать к Интернету, не
запускать точно недоверенный софт и всё в таком духе. Я знаю, уверен что
у меня в каждом Intel-based компьютере есть Intel ME со своими backdoor.
Но не представляю как их можно эксплуатировать. А даже если как-то и
можно хитрим образом (не знаю, подсунуть шрифты которые являются Тьюринг
полными и через их выполнение что-то спустить в Intel ME и он... да даже
не знаю что он бы мог сделать такого, что мне что-то бы испортило, с
точки зрения безопасности). DoS вот можно сделать -- это да. Не
смертельно для меня.

Но я вот и не обновляю микрокод. Возможно он что-то исправляет в плане
безопасности. Возможно что-то делает только хуже, добавляет backdoor. Я
никак не могу этого узнать. Это полностью закрытое ПО. И я интерпретирую
железку как содержающую ROM. Если железка из коробки не работает (вроде
в каких-то AMD процессорах нельзя было запустить Linux, без обновления
прошивки?), то значит считаем это браком, не работающей моделью железа,
а меня обманули и кинули на деньги, дав не работающий продукт.
Обновление микрокода это равносильно тому, что у меня забрали прежнее
изделие и выдали новое. Я приобрёл вот именно то, что было до этого, я
его использовал годами/месяцами и знаю особенности или просто в курсе
недостатков с которыми готов мириться. Обновил микрокод -- у тебя на
руках уже другое изделие, где внезапно какие-то другие особенности,
баги, глюки, проблемы могут всплыть, но меня прежде всё устраивало, я не
просил замены.

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

Коллега как-то спрашивал: неужели для меня есть разница между тем, что
например есть компьютер с CD-ROM, где ты должен вставить диск, чтобы он
с него загрузился и заработал, и тем, что диск бы был в нём вставлен
заранее и сам привод просто скотчем закрыт. Да! Тут принципиальная
разница! В одном случае предполагается что я управляю устройством,
загружая в него какой-то код, а во втором случае это не предполагается и
мне дают некое законченное готовое к применению изделие. Если в первом
случае будет полностью свободный софт, никакого TiVoization, то наверное
это ok, допустим. Но такого же почти никогда не бывает.

Фигня с обновлением микрокода ещё и в следующем. Вот я такой беру и
wget-ом по ссылке с сайта производителя качаю бинарник для заливки в
CPU. А где гарантия что по моему IP/стране/AS они не подсунут мне
какой-то особенный, не такой как у всех? Можно же будет сделать
целенаправленную атаку supply chain? Когда я в магазине приобретаю CPU,
то можно подсунуть для страны особые CPU, но никто же заранее не знает
кто и когда именно возьмёт в магазине физический процессор? Не, конечно
же тоже можно сделать, но сильно дороже и нужно быть сильно большой шишкой.

И вот когда OpenBSD (c42a501865e4a91b8fa172840f9a0d35935fde90) без
спросу полезла после установки в Интернете качать прошивку для CPU, то
это абсолютно недопустимейший пиздец. Именно после этого момента я
никогда не буду рассматривать данную ОС для чего бы то ни было. Да, в
ней много интересного было сделано, но подобные шаги и решения за
пользователя совершенно недопустимы ни под каким предлогом. Причём либо
это самомнение всяких Тео такое огроменное (что наверняка так и есть),
что они считают что производителям процессоров можно доверять а их
пользователи тупые дебилы и доверять им нельзя, либо это выглядит вообще
как закладка: отчитываемся кто только что поставил OpenBSD, если что и
сразу можем подсунуть особую firmware, атаковать по сути.

У меня Meltdown/Spectr-уязвимые процессоры и я не включаю software
mitigation для них. Я просто понимаю, что у меня дырявое говно от Intel,
на котором нельзя безопасно гонять чужой код, явно недоверенный софт. Я
и не гоняю.

    [оставить комментарий]
    комментарий 0:
    From: kmeaw
    Date: 2026-03-05 23:05:35Z
    
    > Но не представляю как их можно эксплуатировать.
    
    На каждый цикл процессора сложить побайтово все регистры общего
    назначения и отсортировать.
    
    Если в полученной последовательности будет подпоследовательность
         {0x13, 0x37, 0xba, 0xbe, 0xca, 0xfe}, то считать это кодом A,
    если {0xab, 0xba, 0xba, 0xbe, 0xc0, 0xde}, то считать это кодом B.
    
    Подмешать такие байты будет несложно в сетевые пакеты, раскладка их
    по регистрам достаточно стабильна и предсказуема для фиксированной
    версии ОС.
    
    Берём все такие коды за последние 200мс, применяем какие-нибудь
    фильтры, чтобы убрать повторы, проверить целостность и аутентичность,
    и получаем чистый поток бит, который медленно пишем куда-нибудь в SMRAM.
    
    Когда накопили достаточно данных, генерируем прерывание и исполняем.
    Результат кодируем с помощью задержек сетевых пакетов.
    
    Необязательно встраиваться в процессор, это может быть NIC, которая
    подгрузит нужный код в память хоста на следующей перезагрузки, её
    можно вызвать импульсом на reset или срабатыванием защиты источника
    питания. Большинство прошивок материнских плат либо не проверяют
    такой код совсем, либо доверяют всему, что подписал производитель.
    
    Аналогично может произойти с GPU, когда WebGL загрузит специальный
    злодейский шейдер (или для пользователей браузеров без js на экран
    выведется хитрый узор), диск может внезапно материализовать что-то
    в загрузочной области по характерному профилю нагрузки (пользователь
    качает большой файл на диск, а злодей отдаёт его с плавающей скоростью)
    или записи в нешифрованную область (там мог бы быть /var/log/auth.log).
    
    Если злодей близко, то почти любой электронный компонент мог бы быть
    радиоприёмником и/или передатчиком, иногда даже тогда, когда изначально
    не был для этого спроектирован.
    
    > А где гарантия что по моему IP/стране/AS они не подсунут мне
    > какой-то особенный, не такой как у всех? Можно же будет сделать
    > целенаправленную атаку supply chain? Когда я в магазине приобретаю CPU,
    > то можно подсунуть для страны особые CPU, но никто же заранее не знает
    > кто и когда именно возьмёт в магазине физический процессор?
    
    А не наоборот ли? Грузовик процессоров едет по понятному фиксированному
    маршруту, его могут перехватить как спецслужбы, так и организованные
    преступники, в оверлейную сеть его так просто не спрячешь, маршруты
    меняются редко. Когда CPU до меня доедет, я не увижу разницы. Если мой
    текущий процессор испортить, а в магазине рядом по хорошей цене будет
    замена, то именно её я скорее всего и куплю.
    
    Микрокод я хотя бы сравнить могу. Вот тут, например, пытаются собрать все
    известные: https://github.com/platomav/CPUMicrocodes
    
    Таким образом, ситуация, когда
    
    > сам привод просто скотчем закрыт
    
    сильно лучше, чем когда что-то зафиксировано на уровне flash/ROM или даже
    топологии интегральной микросхемы. Ведь в этом случае я могу скотч отклеить,
    вытащить диск и сравнить его содержимое с таким же у других людей.
    
    А в случае, когда вместе соберётся достаточное количество замотивированных
    и квалифицированных людей, они смогут сделать свой диск со свободным софтом.
    
    Вот что действительно зло - это когда в устройстве есть eFUSE, которые
    включены по-умолчанию, препятствующие откату микрокода/прошивки. Механизм
    в целом полезный для безопасности, но на его включение, на мой взгляд, должно
    быть явно санкционировано владельцем устройства, желательно отламыванием
    какой-нибудь части, чтобы это было видно при покупке б/у.
    
    комментарий 1:
    From: Sergey Matveev
    Date: 2026-03-06 07:18:22Z
    
    *** kmeaw@kmeaw.com [2026-03-03 12:37]:
    >Подмешать такие байты будет несложно в сетевые пакеты [...]
    
    Всё так, согласен. Я имел в виду air-gapped случай. С наличием сетевых
    подключений всё печально. Это не отменяет возможность DoS, конечно,
    порче данных, при получении, как предложено, картинки особой.
    
    >Если злодей близко, то почти любой электронный компонент мог бы быть
    >радиоприёмником и/или передатчиком, иногда даже тогда, когда изначально
    >не был для этого спроектирован.
    
    Это да. Даже без явных backdoor-ов, само по себе железо может неплохо
    сливать данные по побочным каналам.
    
    >А не наоборот ли? Грузовик процессоров едет по понятному фиксированному
    >маршруту, его могут перехватить как спецслужбы, так и организованные
    >преступники, в оверлейную сеть его так просто не спрячешь, маршруты
    >меняются редко. Когда CPU до меня доедет, я не увижу разницы. Если мой
    >текущий процессор испортить, а в магазине рядом по хорошей цене будет
    >замена, то именно её я скорее всего и куплю.
    
    Но как убедиться, что именно мне попал "нужный" процессор? Подкупить
    продавца? Внедрить продавца нужного? Тут уж можно проще и домой ко мне
    залезть и поменять всё что угодно. Тут будет атаковано уже множество
    людей. Однозначно, вне всяких сомнений, это запросто делается, спору
    нет, но не целенаправлено же ради одного человека.
    
    >Микрокод я хотя бы сравнить могу.
    
    Это если есть источники откуда можно взять их эталонный хэш. А сколько
    людей будет качать ничего не проверяя? Впрочем, это на их совести, как и
    скачивание бинарных пакетов, JS и прочего. Но да, хотя бы есть
    потенциальная возможность сравнения. Насколько вижу, fw_update в
    OpenBSD, судя по man, должен качать с их сайта, где есть подписанные
    SHA256 хэши файлов. Железо же простому смертному нет возможности
    проверить, согласен.
    
    >Вот тут, например, пытаются собрать все
    >известные: https://github.com/platomav/CPUMicrocodes
    
    Здорово!
    
    >> сам привод просто скотчем закрыт
    >сильно лучше, чем когда что-то зафиксировано на уровне flash/ROM или даже
    >топологии интегральной микросхемы. Ведь в этом случае я могу скотч отклеить,
    >вытащить диск и сравнить его содержимое с таким же у других людей.
    
    Если речь про то, что CD проще достать и прочитать штатными средствами,
    нежели чем что-то в микросхеме -- это да. Если речь про то, что
    накопитель с данными есть нечто хорошее, то вопрос "можно ли его
    перезаписать?". Если можно, то используя недокументированные возможности
    или уязвимости/баги, можно код обновить зловредом. Не заниматься же
    проверкой содержимого flash перед каждой загрузкой?
    
    Лично я не против заклеенного CD-ROM. Для меня это равносильно ROM.
    Главное что не предполагается, что я должен туда что-то загружать
    самостоятельно. Это устройство само в себе, законченное и готовое к
    работе. Если бы не было бы скотча и мне надо бы было вставлять диск,
    то это уже другая история, хотя для компьютера/устройства разницы,
    конечно же, нет.
    
    >А в случае, когда вместе соберётся достаточное количество замотивированных
    >и квалифицированных людей, они смогут сделать свой диск со свободным софтом.
    
    Ну и по факту много ли мы видим прошивок свободных? Не, возможно их
    мало, потому что производители железа делают так, чтобы усложнить всем
    жизнь, плюс отсутствует документация и всё такое прочее. А может не так
    много заинтересованных в этом людей? Поэтому только на очень особенных
    компьютерах мы можем иметь свободный BIOS (UEFI?). С WiFi вообще,
    насколько помню (но специально давно не выяснял, вообще WiFi не
    использую уже лет 15), всё настолько плохо, что вроде нет современных
    решений (для быстрых версий WiFi) не требовавших закрытый blob. Лично
    меня не интересует возня с железками: я хочу купить готовое к работе
    устройство. Конструктор штука полезная, но предоставляйте его тем кто
    заинтересован. Это как GNU/Linux: не законченная ОС, а конструктор.
    
    Когда производитель даёт мне устройство, но где только RAM, а ты уж сам
    загружай в него мозги -- то он мне даёт конструктор, framework, мол сам
    делай из него полноценное устройство. Он конечно даёт и свой вариант
    блоба, но нефиг меня заставлять выполнять его работу. Если он даёт
    возможность перепрошить flash, но в нём изначально есть уже что-то,
    делающее устройство из коробки работающим: то ok, уже лучше, но вопрос
    как защитить flash от перезаписи (это выполнимая задача, можно сделать).
    
    >Вот что действительно зло - это когда в устройстве есть eFUSE, которые
    >включены по-умолчанию, препятствующие откату микрокода/прошивки. Механизм
    >в целом полезный для безопасности, но на его включение, на мой взгляд, должно
    >быть явно санкционировано владельцем устройства, желательно отламыванием
    >какой-нибудь части, чтобы это было видно при покупке б/у.
    
    Согласен и про полезность, и про явное санкционирование.