Embox v0.5.10

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

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

А общую секьюрность вам никто не обеспечит.

Мне кажется, не совсем корректно так сравнивать. Если нет нормального пауерменеджмента, то да. А если есть?

Почему не корректно? Никакой пауерменеджмент не может обеспечить работу устройства на большом Cortex-A в несколько месяцев от одной батарейки, даже при том что устройство 100 % времени спит

И как он получает доступ, даже если MMU нет? Он может пользоваться только командами которые заявлены. Никакого доступа к памяти, если этого не предусмотренно.

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

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

Политики доступны! И повторюсь, одно дело когда находят эксплойт от переполнения стека в обычной системе, второе когда конечная система уникальна, непонятно куда у вас что вылетит. Ну это как рандомизация адресного пространства, только в глобальном масштабе (в целом у системы).

Никакой пауерменеджмент не может обеспечить работу устройства на большом Cortex-A в несколько месяцев от одной батарейки, даже при том что устройство 100 % времени спит

Да вроде же есть кортексы А-профиля с внутренней памятью и всем прочим: https://www.cnx-software.com/2016/12/30/allwinner-v3s-dual-camera-soc-comes-with-64mb-dram/

А если по кол-ву внешних компонентов всё как и у плат на М-ках, то тогда почему нет?

Политики доступны!

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

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

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

Попробую еще раз объяснить.

Embox можно сконфигурировать как полноценную ОС с изолированными пространствами процессов и если хочется сделать микроядро. Но непонятно зачем, есть прекрасный Линукс и замечательные микроядра. По сравнению с Linux Embox точно будет проигрывать в универсальной конфигурации, причем это будет небо и земля, и меньшее количество требуемых ресурсов или быстрый запуск точно не будут иметь значение. То есть Embox не замена Linux!

Идея Embox заключаются в следующем. Давайте перенесем в статику как можно больше информации о конечной системе, проанализируем ее целиком, и получим бонусы. Идея не нова, если задуматься то KBuild + скрипты OpenEmbedded (рутовая файловая система) + DevTree направлены на похожие вещи. Но у нас это сделано сквозное и получилось эффективнее. Повторюсь, только для определенных целей.

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

добавлена поддержка perl;

вот за это жирный +

Embox можно сконфигурировать как полноценную ОС с изолированными пространствами процессов и если хочется сделать микроядро.

О, тогда круто!

Но непонятно зачем, есть прекрасный Линукс и замечательные микроядра.

Да неужели же вся экономия ресурсов заканчивается после включения изолированных адресных пространств?

Поэтому, покорруптить память ядра невозможно, ну хотите, защитите MMU, одно пространство но ядро только на чтение например, есть варианты.

Согласен, прикольно если по-всякому можно сконфигурировать. Выходит, можно и на некий аналог каспера претендовать в определённых конфигурациях. При том, что каспер-то как раз только самое передовое железо требует…

IMHO современная безопасность невозможна без использования аппаратных токенов типа U2F/FIDO2, PKCS11 и т.п. вместо паролей.

У вас есть какие-то планы по их поддержке для аутентификации пользователей?

я предпочел бы тесную интеграцию shell с lua, не понимаю почему его не делают для МК.

А нужен ли вообще shell на МК по крайне мере на проде (не при отладке)?

Если только в далекой персепктиве.

У нас сейчас очень много запросов на системы где нет разных пользователей, скорее машина машина. Пароли вшиваются (или заменяются) отдельно без токенов. Это могут быть также разные профайлы, но не разные пользователи. Если требуется какой нибудь админ то можно зайти по ssh, но там тоже обычно один пользователь.

Почему не делают Вот как раз описываем Lua с возможностью вызова команд на микроконтроллере https://habr.com/ru/companies/embox/articles/496146/ Вы правы очень удобная и легкая штука!

Возможно в проде и не нужен, но вот как удобно например отлаживать если все стандарное https://habr.com/ru/companies/embox/articles/573244/

Или вот прямо CGIскрипты на MK https://habr.com/ru/companies/embox/articles/541662/

Спасибо! :)

Если требуется какой нибудь админ то можно зайти по ssh, но там тоже обычно один пользователь.

Когда кто-то заходит по SSH без упомянутых мной аппаратных криптотокенов, то безопасность на этом заканчивается.

Приватные ключи должны храниться в аппаратном крипто неизвлекаемо на обоих концах SSH канала, иначе это только имитация безопасности.

Приватные ключи должны храниться в аппаратном крипто неизвлекаемо

Это понятно!

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

Некоторое время назад, мои поиски привели меня к ZX Spectrum :) Современный вариант ATM Turbo 3 (пока в разработке). Насколько я понял, в нем нет даже блоба для BootROM. Бывает ли подобная полная открытость среди МК?

https://ru.wikipedia.org/wiki/ATM_Turbo

http://www.nedopc.org/forum/viewtopic.php?f=35&t=19415

К недостаткам ZX Spectrum можно отнести его очень слабый CPU даже разогнанный до 16 и более Mhz. На таком процессоре, к сожалению, нереально, пользоваться *nix like осью, даже специально разработанной под более современные клоны подобных процессоров, которые работают на частотах уже ближе к первопням (около 80Mhz).

Спектрумисты играются со своей NedoOS :)

https://speccy.info/NedoOS

А хотелось бы что-то хотя бы уровня https://hackaday.io/project/167311-fuzix-os

Сравнили бы свою Embox с Fusix, а открытость совместимых аппаратных таргетов с ATM Turbo 3 :)

https://github.com/EtchedPixels/FUZIX

Сравнили бы свою Embox с Fusix, а открытость совместимых аппаратных таргетов с ATM Turbo 3 :)

Да нафейхуа сравнивать ОСь, разработанную под современные тулчейны, в которой есть и MESA, и все скриптовые языки, и даже JVM… с некоей маргинальной ОСью, где аж пару юниксовых утилит сумели заимплементить… Вы прикалываетесь чтоль? :) Вы месу спортируйте на узикс, и тогда сравнивайте. Хотя, для порядку, ещё не помешало бы вам поддержку Z80 запилить в gcc и binutils.

Мне в первую очередь интересно существование наиболее открытых железок, на которых запускается Embox. Бывают такие же открытые, как ATM Turbo? Или как на словах Talos2, но только не за $10K, а примерно за $10 или чуть больше :) ? Если верить рекламе, то все прошивки Talos2 якобы открыты. Все прошивки, известные публике :)

Речь не о мощности процессора IBM Power, на котором очевидно запустится в тысячи раз больше софта, чем на МК, а про открытость и отсутствие скрытых «IBM ME», хитрого BootROM BLOB with ARM TrustZone monitor, etc. ? Есть ли что-то на базе RISC-V ?

И при этом, чтобы запускался самый базовый *nix like софт, хотя бы SSH и т.п., что описано в статьях про Embox.

Вы месу спортируйте на узикс, и тогда сравнивайте. Хотя, для порядку, ещё не помешало бы вам поддержку Z80 запилить в gcc и binutils.

Мне интересен в первую очередь headless сервер с текстовым терминалом.

Еще было бы интересно более подробное сравнение с ближайшими аналогами типа NuttX. Типа сравнительной таблицы.

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

Мы старались больше не на открытость смотреть а на популярность. Довольно хорошо поддержали STM32. Из открытых MAIX-BIT (RISC-V) наверное можно считать открытой, но там довольно мало у нас пока поддержано. Банану тут какую то поддерживали, но она тоже скорее доступная чем открытая.

ATM-Turbo 3 наверное сейчас для нас не актуально, нужно популяризовывать проект, а это на мой взгляд делается через промышленное (массовое) применение.

А хотелось бы что-то хотя бы уровня https://hackaday.io/project/167311-fuzix-os

Спасибо, интересная штука, нужно будет глянуть на досуге! :)

Спасибо, интересная штука, нужно будет глянуть на досуге! :)

Это в том смысле, что по сравнению с NedoOS, лучше хотя бы Fusix в его более поздних зрелых релизах. Ваш Embox конечно еще лучше, вопрос только в максимально открытых железках, на которых он запускается. Неужели компы на базе Z80 так уникальны своей открытостью, что больше нет ничего похожего даже среди МК?

Бывают такие же открытые, как ATM Turbo?

Да зайдите на опенкорес.орг и гляньте. Хотя я не знаю, что такого открытого в АТМ. Z80, что ли, вам кто-то открыл? Равно как и всю обвязку. А то, что схематика открыта - так этим вообще никого не удивить.

хитрого BootROM BLOB with ARM TrustZone monitor, etc. ?

Да ёкстель, вот же: https://github.com/ARM-software/arm-trusted-firmware

Я тут во всех тридах пытаюсь народу объяснить, что у АРМа, как раз таки, всё максимально открыто. По ссылке выше - исходники ATF, того самого «хитрого BootROM BLOB with ARM TrustZone monitor, etc.» Только народ вообще не внемлет.

Еще было бы интересно более подробное сравнение с ближайшими аналогами типа NuttX. Типа сравнительной таблицы.

Таблицу не приведу, хотя делали. Но вот сообщение от пользователя из нашего чата

“Недавно портирован за три недели проект, который разрабатывался два года для Линуха, потом с разными спотыкачами пытались портировать пол-года на NuttX и ещё на пару систем для встроенных решений, которые провозгласили POSIX-совместимость. Проект реализован на Си++.”

Это в том смысле, что по сравнению с NedoOS, лучше хотя бы Fusix в его более поздних зрелых релизах.

Нет, я про Fusix! интересный, на мой взгляд проект. Я без шуток.

Да ёкстель, вот же: https://github.com/ARM-software/arm-trusted-firmware

Так ведь это только пример референсного BootROM-а в вакууме?

А существует ли конкретное реальное устройство, которое можно купить в магазине, у которого можно самостоятельно менять BootROM, но только с помощью паяльника и программатора, и чтобы этот самый BootROM находился не в SoC, а снаружи в настоящем ПЗУ (однократно программируемом), а не в каком-нибудь современном модном молодежном flash «ROM», легко перешиваемым троянами?

Идеально было бы, если бы вы предложили свой Embox с таким раскладом:

1. Максимально открытая железка, на которой он запускается, с полностью открытым BootROM, и любыми другими ROM, присутствующими на плате.

2. Все ROM должны находиться во ВНЕШНИХ, чтобы можно было легко верифицировать открытость прошивки, и только ОДНОКРАТНО прошиваемых чипах, чтобы трояны и взломщики не могли самостоятельно модифицировать прошивки.

3. Поддержка U2F и/или PKCS11 (что-нибудь типа лайтового opensc)

4. Более прочный TCP/IP стек, похожий на OpenBSD.

Так ведь это только пример референсного BootROM-а в вакууме?

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

и чтобы этот самый BootROM находился не в SoC, а снаружи в настоящем ПЗУ (однократно программируемом), а не в каком-нибудь современном модном молодежном flash «ROM», легко перешиваемым троянами?

Как правило, перепрошивку внутри сока можно залочить. С внешним ПЗУ это сделать куда сложнее. Не знаю, есть ли платы, где АТФ грузится с внешней епромки. Сделать такую самому - не сложно, ибо у АРМа всё открыто. Вам достаточно будет отобразить эту епромку на загрузочный адрес, и процесс пойдёт. Но боюсь, что никому это нужно не было, и по тому, такого может и не быть.

Хотя я не знаю, что такого открытого в АТМ. Z80, что ли, вам кто-то открыл? Равно как и всю обвязку. А то, что схематика открыта - так этим вообще никого не удивить.

В ATM Turbo используется хоть одна закрытая прошивка?

Как правило, перепрошивку внутри сока можно залочить.

Это как? Битиком во FlashROM? Который легко может сбросить, кто знает потайные ходы?

В ATM Turbo используется хоть одна закрытая прошивка?

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

Не в вакууме. На армовых референсных бордах его вполне можно гонять.

Много плат поддерживает перешивку BootROM?

Например, в ARMv7 (не МК) типа AllWinner A20 (например, в апельсинках) и TI Sitara в BBB BootROM находится внутри SoC и неперешиваемый?

По тому я и посоветовал вам, господин пурист, посетить опенкорес.орг

ОК, посмотрим, что там :)

Да, но только для такого нужно существенное финансирование. И непонятна модель монетизации :(

Рынок устройств в области физической охраны помещений? Различные охранные сигнализации и т.п.? Да даже прошивка холодильника, в котором хранится что-то дорогое, подключенного к network (хотя бы даже к LAN), - а это всевозможные в т.ч. богатые производители оборудования для фармы и т.п.

Это как? Битиком во FlashROM? Который легко может сбросить, кто знает потайные ходы?

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

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

Лишь бы не оказалось, что такая залочка работает только для плебса, а особо одаренным известны тайные обходные пути. Доверия к flash ROM нет от слова совсем, какие-бы залочки не рекламировал производитель платы.

Много плат поддерживает перешивку BootROM?

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

Апельсинки, CubieTruck (CubieBoard 3), BeagleBone Black тоже хранят свой блоб BootROM в перешиваемом flash ROM?

Как правило, перепрошивку внутри сока можно залочить. С внешним ПЗУ это сделать куда сложнее.

Почему с внешним сложнее? Если в качестве чипа ROM используется однократно программируемый аналогично CR-R (а не CD-RW)?

Не знаю, есть ли платы, где АТФ грузится с внешней епромки. Сделать такую самому - не сложно, ибо у АРМа всё открыто. Вам достаточно будет отобразить эту епромку на загрузочный адрес, и процесс пойдёт.

В смысле с помощью кусачек и паяльника можно сделать даже мод готового одноплатника из магазина, который начнет грузиться с внешнего чипа с BootROM вместо прошивки внутри самого SoC?

Речь именно о самом раннем BootROM, который грузится ДО Uboot, а не после, что нередко тоже называют прошивкой, но это обычно уже mutable FS какой-то оси.

Но боюсь, что никому это нужно не было, и по тому, такого может и не быть.

В каком смысле может быть или не быть? Готовая реализация одноплатника с такой поддержкой?

Апельсинки, CubieTruck (CubieBoard 3), BeagleBone Black тоже хранят свой блоб BootROM в перешиваемом flash ROM?

Думаю, что и альтернатив тут не много. Вопрос лишь в том, что наворотил вендор, и как защитил их от перезаписи. Но это вам скажут не здесь, а только на специализированных форумах по конкретным железкам. Общий же совет - купите дев борду. Там это штатная процедура.

Все рынки которые вы описали, довольно закрытые. И нужно не с ОС (открытой) приходить, а с законченной железкой, причем сертифицированной для данной сферы. Вот если бы производители (разработчики) этих систем стали бы использовать Embox… Ну за это и боремся в принципе :)

Почему с внешним сложнее? Если в качестве чипа ROM используется однократно программируемый аналогично CR-R (а не CD-RW)?

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

В смысле с помощью кусачек и паяльника можно сделать даже мод готового одноплатника из магазина, который начнет грузиться с внешнего чипа с BootROM вместо прошивки внутри самого SoC?

Можно, при условии, что BL1 останется на внутреннем чипе. BL1 - это совершенно крошечный загрузчик, который и нужен только чтобы настроить всё необходимое для дальнейшей загрузки. Требовать вынести наружу и его - не целесообразно. Считайте, что это неотъемлемая (и открытая) часть проца.

В каком смысле может быть или не быть? Готовая реализация одноплатника с такой поддержкой?

Да, не видел таких.

Его ничто не мешает перепаять, или заменить на эмулятор ROM на базе сд карты.

Подразумевается охраняемое помещение. Кроме того важные микрокомпы можно размещать в надежном сейфе. И подмена внешнего чипа (в колодке) по крайне мере верифицируема программатором.

А как верифицировать прошивку внутри SoC?

Можно, при условии, что BL1 останется на внутреннем чипе. BL1 - это совершенно крошечный загрузчик, который и нужен только чтобы настроить всё необходимое для дальнейшей загрузки. Требовать вынести наружу и его - не целесообразно. Считайте, что это неотъемлемая (и открытая) часть проца.

В ATM Turbo с Z80 нет такой неприятности?