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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Уязвимости/бэкдоры могут быть в коде самого 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?

На что могут быть способны бэкдоры 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 интернет шлюза?

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 интернет шлюза?

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

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

А что еще кроме 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.

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? (комментарий)