FreeRTOS содержит множественные уязвимости в TCP/IP стеке

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

Ну и дебилы, раз так делают. Я не удивлюсь, если они после этого свои пальцы в розетки начнут совать, предварительно расковыряв контакты электросети.

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

Так то, ходили толксы, что blackberry до андрюши жили в разы дольше от меньшей батарейки.

Без гуглоаппсов и подобного дерьма почти любое устройство на андроиде в разы дольше начинает жить.

Хотя время уже упущено. Ибо есть ARM Mbed.

Это та самая хипстерская штуковина, SDK которой спроектировано так, чтобы без веб-инструментов не работать?

Если бы ты не был настолько ленив и глуп, то прежде чем задавать эти наитупейшие вопросы про наличии хоть какого юзеринтерыпйса во FreeRTOS и консоли в частности, ты, пожалуй, сходил бы хоть Википедию почитать... И, внезапно, узрел бы там, что эта т.н. ОС состоит из менее чем десятка заголовочных файлов, парочка из которых представляют из себя реализацию tcp/ip-стека. Так же ты мог бы и поглубже завернуть и узнать, что, например, из подобных ОС честенько реализацию printf() выбрасывают за ненадобностью и из-за тяжеловесности, а не петь тут про UART-консольку. Но это ведь не про тебя, прочесть пять строк текста. С пятью-то звёздами...

Линукс это не ембед.

Очень даже embedded. Встраиваемое железо тоже не стоит на месте.

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

Линукс не умеет нормально в RT, есть пара костылей. QNX это самая продвинутая RT

То есть, линукс сам по себе не умеет RT и для RT там есть костыли, а QNX это не костыли. Странное утверждение. На x86 быструю микроядерную ОС без костылей сделать невозможно в принципе. А на других архитектурах есть другие действительно RT решения.

Тебе нужно бросать айти и идти в государственную службу, я серьёзно

В интернете много глупых советов. Например, тут только вчера кто-то захотел поставить Python 3.7, а ему в ответ стали советовать сменить Ubuntu на Gentoo, Arch Linux или FreeBSD. Не хотелось бы употреблять слово «идиоты», поэтому назову их ораторами. В интернете много ораторов, которые могут посоветовать любую чушь. Но я предпочитаю думать своей головой. Она сообразила: тема IoT мне лично для работы не нужна, но интересна. Поэтому я из любопытства купил несколько книжек и куплю на первое время два ESP32 (два - чтобы изучать связь между ними). Хотя более популярно начинать изучение темы с Arduino или с STM32. Из них к обсуждаемой теме относится STM32.

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

Можно называть и библиотекой. Но принято называть ОС, что кстати более правильно, так как библиотек много. А раз она отвечает своему назначению, то полноценная.

По сути любая ОС это библиотека функций.

На x86 быструю микроядерную ОС без костылей сделать невозможно в принципе.

Дело не в микроядре.

На обычном x86 предсказуемый отклик сделать невозможно, потому что там под капотом крутится ring -1 с собственной прошивкой.

По сути любая ОС это библиотека функций.

По сути да. А если защиты памяти в системе нет, то и по реализации не отличается от любой библиотеки. :)

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

То есть, линукс сам по себе не умеет RT и для RT там есть костыли, а QNX это не костыли.

Как минимум, Линукс - это универсальная ОС, а QNX заточена под RT. Есть решения: RTAI, Xinomai, PREEMPT_RT, но они не полноценные или со своими тараканами, типа вытеснения ядра, по сути это линукс поверх микроядра. Real Time - это не про скорость,

а QNX это не костыли

QNX - это просто микроядро и куча батареек в юзерспейсе (за батарейки по сути дерут деньги, ну и за понты еще).

А когда в линуксе делаешь сискол, то в общем случае он может призвать дьявола, не выходя из ring 0.

Как минимум, Линукс - это универсальная ОС, а QNX заточена под RT.

Вот только костыли есть в обоих случаях. О чём и речь.

Есть решения: RTAI, Xinomai, PREEMPT_RT, но они не полноценные или со своими тараканами, типа вытеснения ядра, по сути это линукс поверх микроядра.

Но зачем, когда для задач реального времени можно поставить что-то типа FreeRTOS, а для остального вкатить тот же линукс?

Real Time - это не про скорость,

Я в курсе про предсказуемое время отклика.

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

Ути. А в каком-нибудь MIPS-е с MMU их нет?

Есть решения: RTAI, Xinomai, PREEMPT_RT, но они не полноценные или со своими тараканами, типа вытеснения ядра

Xenomai. Расскажи о тараканах этих решений.

по сути это линукс поверх микроядра

Ни одно из упомянутых решений не является «Linux поверх микроядра». Максимум, RTAI и Xenomai - это «Linux поверх HAL».

Ути. А в каком-нибудь MIPS-е с MMU их нет?

Тут простым языком изложено, в чём дело:

https://microkerneldude.wordpress.com/2008/03/13/q-what-is-the-difference-bet...

The cost of hardware-based protection comes in the form of system-call exception (to change the execution mode from user to kernel, aka “trapping into the kernel”) and the cost of setting up, maintaining and tearing down mappings (manipulating page tables and MMU). Kernel entry costs anything from one cycle (Itanium) via a dozen or so cycles (decent RISC processors) to many hundreds of cycles (x86). Mapping-related cost come mostly in the form of handling TLB misses (typically a few dozen cycles). For most loads (exhibiting decent locality) the mapping overhead is low, except on processors without a tagged TLB (x86 is again the main offender) where the TLB is completely flushed on each context switch (leading to many TLB reloads just after the switch).

the form of system-call exception

Это из прошлого века статья? Там бы еще про far jump на call gate вспомнили.

the form of system-call exception

Это из прошлого века статья? Там бы еще про far jump на call gate вспомнили.

Накладные расходы на переключение контекста не зависят от того, делается ли вход в ядро по int, sysenter или call far, так что не умничай.

citation needed

Seriously?

Значит скоро пофиксят, это же СПО

Это уже SoC, а не МК.

воот и я про что. только термины подзабыл. действительно, с тцп это уже system on chip

Это статья как раз из этого века. Ей хоть и 10 лет, но речь там идёт про подходы, используемые в современных микроядрах.

В чём смысл реалтайма на звонилках?

Возможно, я не проверял оба два факта.

А я проверил: поставил на аппарат с андроидом прошивку без гуглоаппсов. Теперь его можно не заряжать почти что неделю, если пользоваться как звонилкой и не нагружать тяжёлыми приложениями. И это при том, что аппарату почти 8 лет, а аккумулятор там я ни разу не менял.

Хм, интересно, что будет с моим аппаратом, который я и без этого за рабочую неделю(5d) обычно 1 раз заряжаю?:) Ну, если далеко по навигатору не ездить.

Теперь его можно не заряжать почти что неделю

Значит, у вас очень короткая неделя. Впрочем, Android не является системой реального времени, не предназначен для микроконтроллеров и следовательно не имеет отношения к обсуждаемой теме.

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

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

повторюсь потому что freertos для мк в которых очень мало flash и ram, а нужено параллельное выполнение задач, плюс mcu не имеют mmu, а для линукса нужно mmu( я не беру в учет uglibc которая эмулирует работу mmu), я же написал не беру в рассчет nommu, конечно можно запустить, только зачем это делать?, когда у вас частота проца 64 mhz например, и 128 кбайт озу?, nommu хорошо для микроконтроллеров в которых можно внеш. sram поставить и т.п. и она нативная(есть доступ по адрессному пространству), только напрактике linux в продакшене под микрокнтроллеры не кто не использует вы же не хочете получить хард фолт, поэтому для mcu и используют rtos, а не линукс, плюс переходите по ссылке на предыдущие комменты, чтобы не выпадал у вас смысал написанного и максиму на mcu используют mpu и то мало кто

linux тоже для embedded, выбирайте выражения!

Без гуглоаппсов и подобного дерьма почти любое устройство на андроиде в разы дольше начинает жить.

У меня валяется телефон с дохлой батарейкой. С gapps время работы 10 часов, без них 15 дней.

а чем «костыли рт» отличаются от «действительно рт решений»?

А почему в любом модеме интерфейс пользователя с командной строкой есть?

Потому что других способов общатся с модемом нет. это стандартный api.

Если нет командной строки. то как ты будешь устройство с этой ОС отлаживать, например перезапускать упавшую программу или хотя бы смотреть логи загрузки самой ОС?

сам напишешь то что тебе нужно, основываясь на том что есть у тебя в контроллере - экран, tty или голубиная почта. FreeRTOS - это ядро

Ситечко с дырками от решета

я не беру в учет uglibc которая эмулирует работу mmu

Ещё раз, для непонятливых

2. s/uglibc/uclibc

3. нет никакой эмуляции mmu (va == pa)

Не только TCP/IP: https://cloud.ncrmnt.org/index.php/s/RC6awJNqwDKESQb

Зачем? А потому что могу ;)

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

и почему вы предлались к тому что я написл

искажённие информации

не нужно linux запускать на микроконтроллерах

а это пусть люди сами решают нужно или нет [1] - такая возможность присутствует.

[1] https://community.st.com/s/global-search/uclinux

вообще-то, многозадачность можно получить и без операционной системы, по крайней мере в которых микроконтроллерах. Так, в ESP32 с двумя ядрами можно разделить программу на задачи, и каждой задаче в явном виде задать ядро, на котором она должна выполняться. Есть и ещё способы. Не буду углубляться, так как не разбираюсь в теме(как и большинство участников обсужления). Но RTOS добавляет свои средства управления многозадачностью(в FreeRTOS), а бывает и многопоточность ( в Mongoose OS).

то Есть, многопоточность - в ChibiOS.

Ни одно из упомянутых решений не является «Linux поверх микроядра».

Ты как его не назови, но по сути это система с планировщиком.

Xenomai. Расскажи о тараканах этих решений.

Прикручивание пятой ноги к собаке может для тебя и норм, в место того, чтобы спокойно писать код, ещё желательно в удобной IDE с компиляцией и деплоем с помощью одной кнопки.

Потому что опенсорс (под лицензией MIT, вроде), как опенбсд и другие, новости про них появляются тут регулярно.

Да и Windows ведь никто же отменял. Например, 8 или 7 версии или более ранних версий. Особенно в банках и финансовых организциях, верно ведь????

Не надо ляля: https://github.com/ARMmbed/mbed-cli/blob/master/README.md