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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Про магнитные ленты - мои знания ограничиваются википедией, я лишь знаю что бывают неперезаписываемые - для архивационных целей (цена за ТБ заметно меньше чем у 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 софт может оказаться скомпроментированным аналогично описанному выше, только вероятность этого ниже.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

если 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

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

Судя по этому документу, защиту «от доступа к БИОС-чипу» добавили в ядро 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

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

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