Важный вопрос о сокете FM2+

Чтобы найти флешки с переключателем защиты от записи, в поиске на AliExpress напиши Netac U335 (старее) или U335S (новее). Насчёт бекдоров: я разбирал одну флешку (а одну сломал в процессе: клеем залиты и чип с платы оторвался), но лишних чипов - для связи с внешним миром - не нашёл.

Единственное, чем с моей точки зрения мог бы навредить бэкдор в такой флешке - или в определённый момент испортить данные (но такое может случиться и случайно, просто из-за глюка в прошивке контроллера флешки, для ресета которого есть сервисные утилиты - правда, только виндовые), или в определённый момент флешка прикинется клавиатурой и введёт sudo rm -rf / - в надежде что ты уже вводил команды sudo недавно и консоль пароля не спросит. Но это - только пакости: порча данных, а не их утаскивание.

Но ведь твоя схема зависит от безопасности PXE, прошивок сетевых контроллеров и, возможно, роутера. Поэтому, локальная загрузка - безопаснее, т.к. проще: меньше переменных в твоём уравнении. Разве что ты можешь надеяться на необычность твоей схемы, под которую бэкдоры не с'адаптируются.

где взять read-only microsd

Берёшь обычную SD с физическим переключателем защиты от записи, или вставляешь MicroSD в переходник на SD с таким переключателем, и через кабель-адаптер SD-to-MicroSD (наверняка есть у китайцев, или сам спаяй) - подключаешь к одноплатнику. Правда, где ты возьмёшь свободный одноплатник, я не знаю - все одноплатники напичканы блобами, а EOMA68 ещё не вышел

Чтобы найти флешки с переключателем защиты от записи, в поиске на AliExpress напиши Netac U335 (старее) или U335S (новее).

Ya ne veru sovremennomu oborudovaniu, v 20** yy u spetsluzhb veroyatno sil'no upali moral'nie printsipi.

IMHO krome CDROM u nas ne ostalos' drugih emkih variantov true RO nositeley (s uchetom nalichia pereshivaemogo firmware v bolee sovremennih privodah i devices).

Насчёт бекдоров: я разбирал одну флешку (а одну сломал в процессе: клеем залиты и чип с платы оторвался), но лишних чипов - для связи с внешним миром - не нашёл.

Znachit backdoor v osnovnom chipe, tol'ko i vsego ...

Ещё есть магнитная лента неперезаписываемая, современная - может хранить терабайты, только движки для нее дороговаты.

То есть, ты считаешь - контроллер флешки может обладать коммуникационными возможностями, про которых не сказано в датащите? В любом случае, без физически присоединённых антенн, он не сможет вещать далеко

В любом случае, без физически присоединённых антенн, он не сможет вещать далеко

Что мешает ему расширить свой документированный протокол дополнительными недокументированными командами, аналогично тому, как в процах есть потайные команды повышения привилегий до рута?

Зачем для этого дополнительный канал связи? Разве недостаточно основного?

Но ведь твоя схема зависит от безопасности PXE,

В каком смысле?

прошивок сетевых контроллеров и,

Ты ведь упоминал про существование open source сетевых карт? Они поддерживают PXE загрузку?

возможно, роутера.

Меня пока вполне устроит временное прямое включение загружаемого компа в PXE сервер прямым кабелем без промежуточных коммуникационных устройств.

Поэтому, локальная загрузка - безопаснее, т.к. проще: меньше переменных в твоём уравнении.

Для локальной загрузки я могу использовать только IDE CDROM, но как его подключить например к ARM одноплатнику?

Разве что ты можешь надеяться на необычность твоей схемы, под которую бэкдоры не с'адаптируются.

После обсуждения на ЛОРе уже не необычная :)

где взять read-only microsd
Берёшь обычную SD с физическим переключателем защиты от записи, или вставляешь MicroSD в переходник на SD с таким переключателем, и через кабель-адаптер SD-to-MicroSD (наверняка есть у китайцев, или сам спаяй) - подключаешь к одноплатнику. Правда, где ты возьмёшь свободный одноплатник, я не знаю - все одноплатники напичканы блобами, а EOMA68 ещё не вышел

Перепробовал все свои SD карты и переходники, их переключатель «RO/RW» игнорируется моим линуксом и всегда монтируется в режиме RW, при этом нормально сохраняются любые изменени файлов даже в RO положении переключателя карты/переходника. IMHO такой переключатель ни от чего не защищает, это тупо индикатор для драйвера, который драйвер может просто игнорировать при желании.

Ещё есть магнитная лента неперезаписываемая, современная - может хранить терабайты, только движки для нее дороговаты.

Можно, пожалуйста, ссылку на описание?

Что делает ее неперезаписываемой? И какое отношение она имеет к рассматриваемому кейсу, когда нужна предельно маленькая прошивка, куда не зашить современного зловреда?

IMHO M-disc выглядит куда интереснее ленты, но опять же проблема с возможностью перешивки контроллеров современных приводов.

Таким образом для PXE сервера и аутентичных readonly образов OCI контейнеров IMHO у нас не остается других вариантов кроме самых древних CDROM.

Что мешает ему расширить свой документированный протокол дополнительными недокументированными командами, аналогично тому, как в процах есть потайные команды повышения привилегий до рута?

Мы ведь сейчас говорим о флешке? Как же она хакнет твой защищённый Linux на железе с опенсорсным БИОСом? ...

Зачем для этого дополнительный канал связи? Разве недостаточно основного?

... Да ещё и воспользуется каналом связи твоего компа? Исходя из моих знаний, флешка максимум может прикинуться клавой чтобы вводить команды, для бОльшего она слишком глупа

Но ведь твоя схема зависит от безопасности PXE

В каком смысле?

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

Ты ведь упоминал про существование open source сетевых карт? Они поддерживают PXE загрузку?

Эти карты могут быть не опенсорсны в плане электрических схем и RTL, но по крайней мере способны работать на 100% опенсорсе - а в него впихнуть вредную фигню намного сложнее

Для локальной загрузки я могу использовать только IDE CDROM, но как его подключить например к ARM одноплатнику?

Через цепь переходников IDE ==> SATA ==> USB. Конечно, ты сейчас начнёшь говорить про бекдоры в прошивках передников - но почему-то тебя не беспокоят бекдоры в проприетарных блобах твоего ARM-одноплатника: ведь ARM-одноплатника без блобов, т.е. не вышедшего EOMA68, у тебя нет

Перепробовал все свои SD карты и переходники, их переключатель «RO/RW» игнорируется моим линуксом и всегда монтируется в режиме RW

Понятно. Все равно я не рассматривал SD карты всерьёз из-за их неживучести: если контроллер флешки глюканет, то ты хотя бы можешь его ресетнуть при помощи сервисной утилиты, чтобы оживить флешку - пусть и с потерей данных на ней (поэтому надо регулярно бекапить флешки). А если глюканёт контроллер карты памяти - фиг ты к нему пробьёшься через контроллер картридера - а иначе ведь по-человечески не подключить без спец.оборудования, только если паяться к контактам SD

Про магнитные ленты - мои знания ограничиваются википедией, я лишь знаю что бывают неперезаписываемые - для архивационных целей (цена за ТБ заметно меньше чем у HDD) - а бывают подороже, перезаписываемые. А разговор о них зашёл в поисках Read-Only носителя, пусть и из-за цены движков они не очень доступны простому обывателю.

А про предельно минималистичную - а, значит, и максимально безопасную, схему - я тебе уже рассказывал: coreboot+SeaBIOS+KolibriOS - и всё это на ПК без Intel_ME / AMD_PSP , подключенном к Интернету через роутер со 100% опенсорсной прошивкой LibreCMC.

Раньше ты писал, что тебе нужен свежие Linux / BSD - но ведь в них миллионы строк кода, и кто знает что там может прятаться? А на KolibriOS бэкдоров нет, потому что их никто не будет писать ради 3.5 анонимусов - это экономически невыгодно. Так вот, грузи KolibriOS прямо из БИОС-чипа по схеме, описанной выше - и будет тебе счастье: пусть и немного неудобное, но зато ультрабезопасное

Мы ведь сейчас говорим о флешке? Как же она хакнет твой защищённый Linux на железе с опенсорсным БИОСом? ...

Я планирую использовать некоторые одноплатники для потенциально опасного относительно крупного (для анализа сорцов) и/или проприетарного софта с постоянным онлайн подключением, типа чатов (например Телеграм) и браузеров.

Эти программы могут быть скомпроментированны на сколько угодно опенсорсном железе и софте как by third parties, так и самими разработчиками (например догружать спец код и прошивать буткиты).

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

Теоретически даже редко подключаемый к интернет open source софт может оказаться скомпроментированным аналогично описанному выше, только вероятность этого ниже.

В самом PXE тоже могут быть дыры.

Что за дыры? В чем их суть? Универсальные сетевые дыры типа ARP spoofing?

Тем более что на момент начала обсуждения ты не знал про опенсорсный PXE - а, значит, собирался пользоваться проприетарщиной.

Зато знал про древнючие BNC карточки :)

Через цепь переходников IDE ==> SATA ==> USB. Конечно, ты сейчас начнёшь говорить про бекдоры в прошивках передников - но почему-то тебя не беспокоят бекдоры в проприетарных блобах твоего ARM-одноплатника

А разве можно любой одноплатник загрузить с USB разъема через usb_storage? Или этим занимается уже Uboot, который умеет такое?

По PXE одноплатник ведь грузится тоже не сам своим BootROM, а из загрузчика типа Uboot?

Понятно. Все равно я не рассматривал SD карты всерьёз из-за их неживучести: если контроллер флешки глюканет, то ты хотя бы можешь его ресетнуть при помощи сервисной утилиты, чтобы оживить флешку - пусть и с потерей данных на ней (поэтому надо регулярно бекапить флешки). А если глюканёт контроллер карты памяти - фиг ты к нему пробьёшься через контроллер картридера - а иначе ведь по-человечески не подключить без спец.оборудования, только если паяться к контактам SD

Бэкапы - это само собой, они к данной теме вообще не имеют отношения, тут речь о безопасности. Какой толк от бэкапов, которые в любой момент времени могут быть удалены оператором зловреда?

Про магнитные ленты - мои знания ограничиваются википедией, я лишь знаю что бывают неперезаписываемые - для архивационных целей (цена за ТБ заметно меньше чем у HDD) - а бывают подороже, перезаписываемые. А разговор о них зашёл в поисках Read-Only носителя, пусть и из-за цены движков они не очень доступны простому обывателю.

Сомневаюсь, что существуют ленты с именно физически однократной записью, вероятно на них просто выставляется какой-то бит как на флэшках? А вот закрытую сессию CD-R ты повторно уже не запишешь при всем желании по крайне мере зловредом без перешивки прошивки привода ...

А если заполнить трэшем все оставшееся на CD-R место, то и подавно ничего туда больше не записать, верно? Запись то физически одноразовая, а не потому что выставлен некий бит (пусть даже закрытия ISO сессии).

Раньше ты писал, что тебе нужен свежие Linux / BSD - но ведь в них миллионы строк кода, и кто знает что там может прятаться? А на KolibriOS бэкдоров нет, потому что их никто не будет писать ради 3.5 анонимусов - это экономически невыгодно. Так вот, грузи KolibriOS прямо из БИОС-чипа по схеме, описанной выше - и будет тебе счастье: пусть и немного неудобное, но зато ультрабезопасное

Мне нужно для работы, а не для лазания под даркнетам, просто для начала чтобы не тырили сорцы по крайне мере буткитом :)

Если уж приспичит тырить, то пусть опять включают свои ПЭМИ сканеры ... не все котам масленица, уж слишком это просто буткитом, совсем нечестно :(

Поэтому же я упоминал про OCI образы, но их IMHO можно хранить и на шифрованных разделах больших Blueray/DVD.

Все равно заражение прошивки в современном приводе ничего не даст для попытки MITM трафика с болванки при условии ее шифрования? Поэтому чистые прошивки нужны только в самом начале на старте нешифрованных загрузчиков, ядер и возможно маленьких базовых нешифрованных rootfs.

Если эти буткиты и могут вытворять такое в теории, при условии что прошит обычный UEFI, то с coreboot'ом - вряд ли.

Уязвимости/бэкдоры могут быть в коде самого PXE, если он проприетарен.

Именно про поддержку UBoot'ом загрузки с такого носителя - не могу сказать. Но почему ты всё ещё рассматриваешь одноплатники, при их блобовости и небезопасности - для меня загадка. Например: мой коребутный G505S может прекрасно работать без блобов на 100% опенсорсных дистрибутивах, одобренных Free Software Foundation, а одноплатников таких нет. И как раз таки в блобах, для уязвимостей/бэкдоров может быть раздолье. Да ещё и нормальных дистрибутивов под одноплатники, со свежим софтом/ядрами, может и не быть: блобы могут требовать старьё, да и опенсорсный код - если он есть - не всегда закоммичен в ветку master у Linux kernel.

Какой толк от бэкапов, которые в любой момент времени могут быть удалены оператором зловреда?

Если зловред не может связаться с внешним миром - как в теоретическом случае с флешкой - то и получить команду извне на удаление данных он не сможет, только по заранее составленному расписанию-алгоритму.

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

Если эти буткиты и могут вытворять такое в теории, при условии что прошит обычный UEFI, то с coreboot'ом - вряд ли.

Какие преимущества по сравнению с UEFI или legacy BIOS дает Coreboot и вероятно Libreboot тоже в плане сопротивляемости софтовым перешивкам из неблагонадежного софта?

Уязвимости/бэкдоры могут быть в коде самого PXE, если он проприетарен.

На что могут быть способны бэкдоры 20-30 летней давности в самых древних сетевухах?

Но если рассказать об этом железе поподробнее - это всегда пожалуйста.

Можно ли с тобой пообщаться в Телеграм или другом онлайн чате по этим вопросам?

Если зловред не может связаться с внешним миром - как в теоретическом случае с флешкой - то и получить команду извне на удаление данных он не сможет, только по заранее составленному расписанию-алгоритму.

Конечно лучше сервера с бэкапами не подключать к Internet, но это невсегда возможно, иногда хотя бы косвенно они подключены через другие хосты (рабочие станции и т.п.).

Я имел ввиду, что бэкапы не относятся к теме борьбы с буткитами в том смысле, что чистота от буткитов намного важнее вероятности выхода из строя носителя с важными данными или настройками, подключенными к такой плате, но с другой стороны:

1) конечно нужно их бэкапить и

2) безопасность бэкапов зависит от отсутствия контроля над хостами бэкапов у операторов зловредов.

Именно про поддержку UBoot'ом загрузки с такого носителя - не могу сказать.

IMHO старые ARMv7 обычно грузят загрузчик типа Uboot с microSD, а он уже в свою очередь PXE или сразу ядро:

https://forum.digikey.com/t/pxe-boot-a-beaglebone-black-via-u-boot/5251

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

Просто я не знаю, куда податься, кругом засады :( Про BBB (Beaglebone Black) в IRC чатах упоминали, что в нем минимальный BootROM без зловреда в TrustZone.

X86 с их точки зрения вообще дырявое поделье, на которое не стоит тратить своего времени.

Меня в одноплатниках в первую очередь привлекает readonly BootROM, но если удастся записать Libreboot на сменный однократно программируемый ПЗУ в колодке вероятно это будет уже не хуже.

Например: мой коребутный G505S может прекрасно работать без блобов на 100% опенсорсных дистрибутивах, одобренных Free Software Foundation, а одноплатников таких нет.

Мне в первую очередь нужны Devuan, Alpine с Libre ядрами Linux и OpenBSD, со всеми ними относительно нормально работают одноплатники BBB и AllWinner.

Да ещё и нормальных дистрибутивов под одноплатники, со свежим софтом/ядрами, может и не быть: блобы могут требовать старьё, да и опенсорсный код - если он есть - не всегда закоммичен в ветку master у Linux kernel.

Упомянутые дистры на упомянутых одноплатниках работают с любыми свежими ядрами и не требуют блобных вендорских дров.

А что еще кроме X86 + Coreboot/Libreboot можешь порекомендовать?

Почему все силы Coreboot/Libreboot брошены на оборудование X86?

Неужели нет других платформ с открытыми спеками?

Как тебе Apple G3?

Насколько у них открытые прошивки OpenFirmware? OpenBIOS и т.п.?

Хотя на странице:

https://en.wikipedia.org/wiki/Coreboot

Упомянуты:

Platform: IA-32, x86-64, ARMv7,[2] ARMv8, MIPS, RISC-V, POWER8

Нашел Coreboot даже для BBB:

https://doc.coreboot.org/mainboard/ti/beaglebone-black.html?highlight=board list

Так, хорошо, а какие тогда не X86 есть платы в списке:

https://coreboot.org/status/board-status.html

Где там хоть один MIPS?

Какие преимущества по сравнению с UEFI или legacy BIOS дает Coreboot и вероятно Libreboot тоже в плане сопротивляемости софтовым перешивкам из неблагонадежного софта?

если Linux'овое ядро с нормальным конфигом (как в Artix Linux) загружено без флага «iomem=relaxed», то зловред никак не сможет получить доступ к БИОС-чипу - причём не только для его записи, но даже для чтения. Это легко проверить, попытавшись использовать flashrom в режиме «internal».

К тому же, в отличие от расширяемого по своей природе UEFI, ты не сможешь так вот запросто добавить к coreboot'у вредоносный модуль: тебе придётся встраивать «вредные исходники» глубоко в тело coreboot+SeaBIOS, собирать их под конкретное железо - причём заблаговременно выяснив конкретный конфиг, дату сборки и ревизию coreboot у того, для кого собираешь (иначе заметят!) - затем, ещё и умудриться доставить сборку в чип адресата, что весьма осложнено обстоятельствами выше. Поверь мне: с учётом крайне низкого % людей, сидящих на coreboot, никто - ни правительство, ни мафия - под этот пердолинг финансирования не выделит и заниматься не будет.

На что могут быть способны бэкдоры 20-30 летней давности в самых древних сетевухах?

Кто знает! Например, компания-создатель Computrace:

Founded in 1993 in Vancouver, British Columbia, Canada, Absolute developed a product to manage, track and secure computers regardless of the physical location of the device.

Так что такие технологии и раньше были. Поэтому глупо искать спасения в проприетарщине, пусть и довольно старой. Только опенсорс спасёт вас

Кто знает! Например, компания-создатель Computrace:

Вероятно такие: https://en.wikipedia.org/wiki/Absolute_Home_&_Office

древние трояны могут быть деактивированны относительно простыми фильтрующими правилами в Firewall интернет шлюза?

если Linux'овое ядро с нормальным конфигом (как в Artix Linux) загружено без флага «iomem=relaxed», то зловред никак не сможет получить доступ к БИОС-чипу - причём не только для его записи, но даже для чтения. Это легко проверить, попытавшись использовать flashrom в режиме «internal».

Наличие подобной защиты зависит от версии ядра?

Что скажешь про ядро: Linux 4.19.197-gnu ?

ii linux-image-4.19.197-gnu 4.19.197-gnu-1.0 amd64 GNU Linux-libre, version 4.19.197-gnu

из репозитория:

deb [arch=amd64] mirror://linux-libre.fsfla.org/pub/linux-libre/freesh/mirrors.txt freesh main

IMHO старые ARMv7 обычно грузят загрузчик типа Uboot с microSD, а он уже в свою очередь PXE или сразу ядро:

https://forum.digikey.com/t/pxe-boot-a-beaglebone-black-via-u-boot/5251

U-Boot разных версий бывают, и U-Boot посвежее может быть и совладает с загрузкой с IDE CDROM через цепь переходников IDE ==> SATA ==> USB. Правда, свежий U-Boot ещё надо умудриться водрузить на старое железо! И даже если производитель одноплатника милостиво заопенсорсил свою версию U-Boot, она как правило старая и с кастомными незаапстримленными патчами, которые придётся мучаться-портировать на свежий U-Boot прежде чем получится использовать его возможности.

Про BBB (Beaglebone Black) в IRC чатах упоминали, что в нем минимальный BootROM без зловреда в TrustZone.

Некоторых может не устраивать само существование фигни вроде TrustZone в железе. И с этой точки зрения, например, лучше выбрать coreboot'ный AMD-без-PSP чем libreboot'ный Intel-с-ME, пусть и со стёртой прошивкой ME (на Core 2 Duo такое возможно благодаря старинной версии ME)

X86 с их точки зрения вообще дырявое поделье, на которое не стоит тратить своего времени.

В общем случае, для типичного X86 с ME/PSP и дырявым UEFI, это действительно правда. Но если взять coreboot'ный AMD-без-PSP, который кстати не подвержен Meltdown - в отличие от ARM/POWER/Intel - и всяким Intel-only дырам, то с утверждением

«в ARM меньше дыр чем в твоём X86»

можно поспорить.

Меня в одноплатниках в первую очередь привлекает readonly BootROM, но если удастся записать Libreboot на сменный однократно программируемый ПЗУ в колодке вероятно это будет уже не хуже.

я тебе уже рассказал, как и на X86 можно получить readonly хранилище прошивки, но идею эту я не одобряю: доп.безопасности она - с учётом моего комментария выше - она не приносит. Это только мешает вам обновлять ваш core/libre'boot, и понижает вероятность что когда-нибудь вы вернёте долг сообществу полезными commit'ами в core/libre'boot или хотя бы баг-репортами, а не будете просто потребителями.

Мне в первую очередь нужны Devuan, Alpine с Libre ядрами Linux и OpenBSD, со всеми ними относительно нормально работают одноплатники BBB и AllWinner.

Нормальной такую работу я назвать не могу. Для работы одноплатникам требуются закрытые бинарные блобы, причём зачастую и в ОС а не только в прошивке. По степени свободы своего ПО, BBB входит в категорию «Single-board computers with serious flaws» согласно Free Software Foundation, и другие одноплатники не лучше - пожалуйста, прочти эту страницу. Пока не вышел EOMA68, обещающий быть свободным, лучше отложить идею об ARM-одноплатниках.

древние трояны могут быть деактивированны относительно простыми фильтрующими правилами в Firewall интернет шлюза?

Зависит от того, с какой частотой они пытаются «общаться с центром». Если они проявляют активность не раз в час, а раз в неделю/месяц, то вряд ли ты эту активность отследишь, чтобы создать соответствующее фильтрующее правило. Разве что создать белый список на весь Интернет, и постепенно добавлять туда нужные тебе сайты.

Ещё и нужно учитывать тот момент, что «интернет шлюз» у тебя наверняка не опенсорсный, а проприетарщина с проприетарщиной может договориться насчёт спец.флагов чтобы не показывать и не фильтровать «особые пакеты».

Наличие подобной защиты зависит от версии ядра?

Судя по этому документу, защиту «от доступа к БИОС-чипу» добавили в ядро 4.5 и она включается при помощи CONFIG_IO_STRICT_DEVMEM в конфиге твоего ядра. Есть и другие конфиги «STRICT», некоторые из которых возможно добавлены позднее. У меня сейчас в дефолтном ядре 5.15.5 на Artix Linux:

CONFIG_ARCH_HAS_STRICT_KERNEL_RWX=y
CONFIG_STRICT_KERNEL_RWX=y
CONFIG_ARCH_HAS_STRICT_MODULE_RWX=y
CONFIG_STRICT_MODULE_RWX=y
CONFIG_ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS=y
# CONFIG_IOMMU_DEFAULT_DMA_STRICT is not set
CONFIG_SECURITY_DMESG_RESTRICT=y
CONFIG_STRICT_DEVMEM=y
CONFIG_IO_STRICT_DEVMEM=y

А что еще кроме X86 + Coreboot/Libreboot можешь порекомендовать?

Рабочую станцию Talos II на POWER9, если тебе по карману. У неё опенсорсная прошивка, правда не core/libreboot, + эта пекарня работает на 100% опенсорсе и сертифицирована Free Software Foundation как «Respects Your Freedom».

Почему все силы Coreboot/Libreboot брошены на оборудование X86?

Так уж сложилось, что популярное недорогое производительное железо - это X86, и какой-нибудь RISC-V ещё не скоро станет более подходящим.

Неужели нет других платформ с открытыми спеками?

Почему же - есть RISC-V, MIPS без аналога Trustzone, и, например, Big Mess of Wires вполне себе открыт. Но одной открытости мало, иначе можно вообще сидеть со счётами и бумагой. Важны ещё производительность, доступность, цена и удобство использования - и тут с X86 пока ещё никто не сравнялся.

Как тебе Apple G3?

Не могу найти исходников БИОСа.

Насколько у них открытые прошивки OpenFirmware? OpenBIOS и т.п.?

Разумеется, бывают альтернативные платформы с открытыми прошивками, как например MIPS'овый нетбук Lemote Yeelong на котором сам Ричард Столлман в своё время сидел. Но по причинам, указанным выше, они далеко не всегда подходят.

Нашел Coreboot даже для BBB
https://doc.coreboot.org/mainboard/ti/beaglebone-black.html?highlight=board list

С этой же страницы:

This port was primarily developed as a learning exercise and there is potentially little reason to use it compared to the defacto bootloader choice of U-Boot. However, it does have some interesting practical use cases compared to U-Boot:

В-общем, на не-X86 там свои прошивки есть. Например: у Talos II, упомянутого выше, своя на 100% открытая прошивка - иначе не было бы сертификации FSF RYF - пусть и не core/libre'boot.

Можно ли с тобой пообщаться в Телеграм или другом онлайн чате по этим вопросам?

Лучше общаться здесь, т.к. надеюсь что эти вопросы/ответы потом будут гуглиться и мне не придётся отвечать 100 раз на одно и то же ;-) А так, если ты сделаешь поиск в сообщениях моего пользователя на LOR - найдёшь во всех подробностях и про ПК, и про роутер, и про много ещё чего.

U-Boot разных версий бывают, и U-Boot посвежее может быть и совладает с загрузкой с IDE CDROM через цепь переходников IDE ==> SATA ==> USB.

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

Правда, свежий U-Boot ещё надо умудриться водрузить на старое железо!

Если железо достаточно открыто, чтобы поддерживать Mainline ядро, то разве новые версии Uboot могут перестать его поддерживать?

И даже если производитель одноплатника милостиво заопенсорсил свою версию U-Boot, она как правило старая и с кастомными незаапстримленными патчами, которые придётся мучаться-портировать на свежий U-Boot прежде чем получится использовать его возможности.

Beaglebone Black поддерживается разными загрузчиками, приводил уже пример даже Coreboot, вот еще нашел:

https://www.barebox.org/doc/latest/boards/am335x.html

Вероятно на странице:

https://en.wikipedia.org/wiki/Comparison_of_boot_loaders

можно найти и другие загрузчики.

я тебе уже рассказал, как и на X86 можно получить readonly хранилище прошивки, но идею эту я не одобряю: доп.безопасности она - с учётом моего комментария выше - она не приносит.

Я не верю никаким софтовым флагам, запрещающим запись. Только readonly ПЗУ, только hardcore :)

Это только мешает вам обновлять ваш core/libre'boot, и понижает вероятность что когда-нибудь вы вернёте долг сообществу полезными commit'ами в core/libre'boot или хотя бы баг-репортами, а не будете просто потребителями.

Какая связь между production оборудованием для работы, где просто необходимо использовать readonly ПЗУ и экспериментальными железками для contributions? Неужели ты думаешь, что у энтузиастов только одна матплата на все случаи жизни?

Нормальной такую работу я назвать не могу. Для работы одноплатникам требуются закрытые бинарные блобы, причём зачастую и в ОС а не только в прошивке. По степени свободы своего ПО, BBB входит в категорию «Single-board computers with serious flaws» согласно Free Software Foundation, и другие одноплатники не лучше

BBB еще пока мало использовал, но к примеру CubieTruck AllWinner A20 прекрасно работает даже на mainline LIBRE ядре Linux без каких-либо блобов в ядре, которые есть даже у большинства пользователей X86. Т.е. на этот относительно древний одноплатник можно спокойно поставить самое последнее ядро 5.x из репозитария:

deb [arch=armhf] mirror://linux-libre.fsfla.org/pub/linux-libre/freesh/mirrors.txt freesh main

И оно будет работать даже с SATA портом и с разветвителем на несколько SATA портов, что позволяет сделать даже неплохую миниатюрную мобильную многодисковую ZFS хранилку с пропускной способностью выше 100Mb/sec (около 150Mb/sec), в которой нет привычных зондов X86 и перешиваемого троянами BIOS.

Мало того, он нормально работает даже после снятия с платы радиочипа паяльным феном.

Рабочую станцию Talos II на POWER9, если тебе по карману. У неё опенсорсная прошивка, правда не core/libreboot, + эта пекарня работает на 100% опенсорсе и сертифицирована Free Software Foundation как «Respects Your Freedom».

В курсе про них, но дороговато для меня и потом я не верю в отсутствие зондов в процессоре IBM, хоть там и все прошивки матплаты open source.

MIPS без аналога Trustzone

Пожалуйста приведи примеры популярных максимально открытых плат на базе MIPS, на которых работает main line ядро Linux и желательно OpenBSD последних релизов тоже.

Разумеется, бывают альтернативные платформы с открытыми прошивками, как например MIPS'овый нетбук Lemote Yeelong

С удовольствием бы купил его, но где ???

IMHO идеальный вариант хотя бы для SSH клиента для относительно безопасной работы?

Beaglebone Black поддерживается разными загрузчиками, приводил уже пример даже Coreboot, вот еще нашел:

https://www.barebox.org/doc/latest/boards/am335x.html

Вероятно на странице:

https://en.wikipedia.org/wiki/Comparison_of_boot_loaders

можно найти и другие загрузчики.

Хотя все они, включая соответствующий инициализации BBB фрагмент кода даже для Coreboot, являются скорее всего форками U-boot :)

И даже если производитель одноплатника милостиво заопенсорсил свою версию U-Boot, она как правило старая и с кастомными незаапстримленными патчами, которые придётся мучаться-портировать на свежий U-Boot прежде чем получится использовать его возможности.

Судя по:

https://forum.armbian.com/topic/4987-mainline-kernel-and-u-boot-on-nand/?do=f...

U-boot на AllWinner A20 нормально стартует с microSD, а дальше вероятно уже может запустить ядро с любых поддерживаемых в U-boot и одноплатником носителей.

И вот еще полезная ссылка:

https://linux-sunxi.org/U-Boot#Status_Matrix

The current U-Boot release fully supports major functions (except NAND) on all the older Allwinner SoCs (A10/A10s/A13/A20/A23/A31/A31s)

Некоторых может не устраивать само существование фигни вроде TrustZone в железе.

В IRC чате BBB, когда я активно интересовался этим вопросом в 2019 году, мне сообщили следующее:

Q:how can I be sure there is no a trojan for TrustZone?
A: you can't, but trustzone is not really supported anyway (technically there's a secure monitor, but it is only used to handle a small number of Secure Monitor Calls used to write to special registers that are not directly writable by the OS)
there's no secure-world kernel on AM335x GP devices

Q: Cortex A8 is stated to have a TrusZone? Is TI version any different?
A: I feel like I literally just answered that

Q: it means BBB CPU does not meet Cortex A8 specs?
A: it's r2p1 Cortex-A8 with neon...
and I feel like you're asking questions about things you don't really understand yet yourself
thumb2 works unlike the r1p3's we used on the Beagle/xM
also, I think it's r3p2

Q: sorry, I even do not know what r2p1 is, are these revisions?
A:yep, definitely r3p2, 
yes, cortex-a8 revisions 
r3p2 is the last revision
anyway, the short summary is: even though the cortex-a8 core itself has trustzone support, it is not usable on GP versions of the AM335x, which is what's used on the BBB

Q: can you please point me to a public explanation of this interesting issue related to TrustZone being revision specific for a Cortex A8 CPU?
A: support@ti.com can help you. ;)
except for a tiny bit of initialization after reset and a tiny SMC handler, everything on the BBB runs in public (aka "non-secure") world
has nothing to do with the cortex-a8
it's just how it's setup on the AM335x

Q: may be TZ is just not usable by end users but still usable by a trojan injected on the factory?
A: if you want to be able to trust hardware, you'll have to design your own processor and create it by soldering transistors together
have fun

Q: haha, very smart, I still can choose AllWinner
A: lol, I'd trust a TI SoC a lot more than an AllWinner one
lol, and your worried about TI's trojans'!!!  China already back-doored that one..
I'm not concerned about trustzone on the BBB... if somewhere were going on in secure world, that would be observable anyway

Q: there is known method for a root escalation in AllWinner, but for a client mode it does not matter
I would prefer something with backdoors but without already injected active trojans
A: also, it's hard to imagine what that trojan could do, given that it only has 1KB of ram that's private to secure world

Q: is not all RAM related to TZ not readable from outside?
A: there's reason to believe TI would put a trojan in their hardware... it would be easy to discover and cause terrible damage to their reputation

Q: unless they are forced to do so by NSA or by above regulations
"RAM related to TZ" is meaningless... trustzone doesn't specify anything about RAM
otherwise no way to a public market?

A: for all things trustzone: https://developer.arm.com/ip-products/security-ip/trustzone
you just seem really paranoid about a topic you know very little about
trustzone is irrelevant on the BBB

Q:sounds good, though hardly believable

A:what you do or do not believe is not my problem

Q: sure, thank you very much for your earlier suggestions
does a lack of TZ depend on BBB release year or revision
besides, DEFCON was last week, nothing is "secure" today, till all the things pointed out is fixed. ;)

A:but I'm pretty security-paranoid myself, have dug a fair bit into bootrom on the AM335x, have dumped and partially reverse-engineerd the secure part of bootrom on the DM814x (a direct ancestor of the AM335x) to see what it does
based on all that, my opinion is: there's no need to worry about bootrom
all 1Ghz Aam335x are the same die revision..
no, it applies to all AM335x SoCs, and I think all TI SoCs in general (except maybe the latest ones, I don't know much about those yet)

Q: it looks like a BBB much better in terms of security than X86?
A: X86 is horrible, though BBB isn't secure.. it wasn't designed for that.. it was designed for usablity..

Q: cannot DMA be isolated by software on X86?
A: it's only isolated if you dump a bucket of cement on it and throw it into the ocean..

A: Regarding OpenBSD, it's easier then that..  While testing efi boot, i noticed u-boto doesn't scrub memory, hence if you reboot, and halt.. EVERYTHING is still in DDR3

Q:grsec pax is known to protect from unknown errors in code
does not grsec 4.9 do it better than linux v5x?
A:anything worth a damn was already implemented by kees and pushed into mainline.

Подскажите, как прошить свой uboot на одноплатнике Beaglebone Black? (комментарий)

И с этой точки зрения, например, лучше выбрать coreboot'ный AMD-без-PSP чем libreboot'ный Intel-с-ME, пусть и со стёртой прошивкой ME (на Core 2 Duo такое возможно благодаря старинной версии ME)

Q: cannot DMA be isolated by software on X86?

A: it's only isolated if you dump a bucket of cement on it and throw it into the ocean..

Именно поэтому я и предлагаю раскидать тяжелые приложения по отдельным хостам X86, которые залиты цементом Firecracker и брошены в океан Kubernetes/OpenNebula+Kata.

Все сходится, Eureka! :)

А в качестве управляющих хостов например для Control Plane и для SSH консолей использовать одноплатники.

Почти любой копеечный ARM/MIPS SBC кроме, пожалуй, малины даст на порядок большую секурность чем x86 в смысле вероятности наличия закладок и неконтролируемого юзером поведения.

Подскажите, как прошить свой uboot на одноплатнике Beaglebone Black? (комментарий)