Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к уд..."	+/–
Сообщение от opennews (?), 10-Дек-18, 11:47
Раскрыта (https://blog.zimperium.com/freertos-tcpip-stack-vulnerabilit.../) детальная информация о 13 уязвимостях, выявленных в ходе аудита TCP/IP-стека открытой операционной системы FreeRTOS (https://www.freertos.org/), последнее время развиваемой (https://www.opennet.me/opennews/art.shtml?num=47649) компанией Amazon. Шесть уязвимостей потенциально позволяют организовать выполнение кода через отправку специально оформленных IP- и TCP-пакетов, а также сетевых запросов с использованием протоколов DNS, LLMNR и HTTPS.  Восемь уязвимостей могут привести к утечке содержимого памяти процессов-обработчиков. Одна уязвимость может применяться для отравления кэша DNS (подстановки фиктивных значений). ОС FreeRTOS поставляется под лицензией MIT и в основном применяется на различных микроконтроллерах, встраиваемых устройствах, системах промышленной автоматики и оборудовании интернета вещей (IoT). Уязвимости устранены начиная с выпуска 1.3.2 (https://github.com/aws/amazon-freertos/release), всем пользователям устройств на базе FreeRTOS рекомендуется срочно обновить прошивки или ограничить доступ к устройствам из внешних сетей. Проблемы также проявляются в TCP/IP-стеке WHIS Connect для проприетарных систем OpenRTOS и SafeRTOS, основанном на коде FreeRTOS. URL: https://blog.zimperium.com/freertos-tcpip-stack-vulnerabilit.../ Новость: https://www.opennet.me/opennews/art.shtml?num=49753
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к уд..."	+17 +/–
Сообщение от iv (?), 10-Дек-18, 11:47
> проприетарных систем > OpenRTOS умеют называть проекты.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	2. "В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к уд..."	+12 +/–
	Сообщение от Аноним (2), 10-Дек-18, 11:50
	В свете эпичности уязвмостей ирония более уместна в отношении названия SafeRTOS
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	17. "В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к уд..."	+3 +/–
	Сообщение от nonimus (?), 10-Дек-18, 15:15
	Там просто знак пропущен в конце, из-за чего и недопонимание. Free RTOS! Open RTOS! Safe RTOS! т.е. Освободите! Откройте! За безопасный RTOS! Вполне уместные лозунги, вообще-то.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	20. "В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к уд..."	+1 +/–
	Сообщение от Гит (?), 10-Дек-18, 17:19
	Это просто фишинг.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	49. "В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к уд..."	+/–
	Сообщение от Прохожий (??), 12-Дек-18, 04:10
	Безопасность - это лишь иллюзия и самообман! С одной стороны - открытые исходные тексты позволяют активно дыры исправлять, а с другой - не менее активно уязвимость находить. :)
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	57. "В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к уд..."	+/–
	Сообщение от Аноним (-), 12-Дек-18, 16:36
	The most dangerous time is whan you feel yourself safe...
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

	10. "В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к уд..."	+17 +/–
	Сообщение от Аноним (10), 10-Дек-18, 12:52
	Есть еще вариант назвать систему PoRTOS. Единственное, что она будет делать - жрать ресурсы. (тонкий литературный юмор)
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	15. "В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к уд..."	+4 +/–
	Сообщение от Аноним (15), 10-Дек-18, 14:37
	А в AtOS всё будет атомарно и при этом в логах она будет печально жаловаться на то, как ей тяжело?
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	43. "В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к уд..."	+/–
	Сообщение от Аноним (-), 11-Дек-18, 22:11
	А Д'Артаньян по сценарию где появляется?
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	16. "В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к уд..."	+2 +/–
	Сообщение от Fracta1L (ok), 10-Дек-18, 15:04
	А половина здешних комментаторов работает под управлением d'Artagnan
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	30. "В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к уд..."	+/–
	Сообщение от имя (?), 10-Дек-18, 18:35
	99.999999999999999999999999% тогда уж. Раз я Дартаньян, а все остальные - известно кто.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	11. "В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к уд..."	+3 +/–
	Сообщение от имя (?), 10-Дек-18, 13:07
	OpenVMS ещё есть, настолько же «открытая».
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	14. "В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к уд..."	+2 +/–
	Сообщение от fi (ok), 10-Дек-18, 14:11
	ну в те времена даже интерфейсы выданные пользователям уже делали систему Open…. А вот попробовал бы ты тогда под QNX сделать свой драйвер! Все драйверы делала компания под заказ ну и за понятные деньги.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	44. "В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к уд..."	+/–
	Сообщение от Аноним (-), 11-Дек-18, 22:18
	Ну вот поэтому у меня отрос заказик заменить громадный ПЦ с этим непотребством на мелкий арм с линухом :). Там вообще все драйверы готовые, никакого реалтайма там на самом деле никому не надо, и вообще я не понимаю как и почему они долбанулись настолько чтобы туда qnx запихать. Походу у людей была эйфория с переизбытка инвесторовских денег, или типа того.
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	25. "В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к уд..."	+/–
	Сообщение от Школьник (ok), 10-Дек-18, 18:14
	SCO OpenServer еще когда-то была, столь же "открытая"
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	12. "В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к уд..."	+3 +/–
	Сообщение от nobody (??), 10-Дек-18, 13:41
	Хотел про название LibreRTOS пошутить, а оно и правда есть такое...
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	32. "В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к уд..."	+/–
	Сообщение от Аноним (32), 10-Дек-18, 18:55
	http://nic.open
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к уд..."	–3 +/–
Сообщение от Michael Shigorin (ok), 10-Дек-18, 11:51
Н-да, так недолго превратиться в Real-Time Operating Malware...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

5. "В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к уд..."	+3 +/–
Сообщение от Аноним (5), 10-Дек-18, 12:10
С BuguRTOS'ом то всё нормально?)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	6. "В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к уд..."	+/–
	Сообщение от Аноним (6), 10-Дек-18, 12:16
	Да вообще лучшая ОС, надеюсь там нет этой уязвимости.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	9. "В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к уд..."	+3 +/–
	Сообщение от Аноним (9), 10-Дек-18, 12:42
	Надо понимать, что и FreeRTOS, и BuguRTOS - это всего лишь довольно простые (ну, не совсем) функции для диспетчеризацией потоков, примитивов синхронизации, управления памятью. А не ОС как это можно представить себе по типу Linux или какой-нибудь QNX. FreeRTOS распух, ибо понапихали туда всего из-за популярности. Но он не перестал быть больше похож на SDK или фреймворк, чем ОС. Сабжевый сетевой стек там опционален, на самом деле, многие его отключают, или заменяют на LWIP. Но уязвимости эпичные, да :) На всяких необновляемых IoT устройствах это далеко не последние продолбы
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	33. "В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к уд..."	+/–
	Сообщение от Cradle (?), 10-Дек-18, 19:25
	вообще-то нужно довольно сильно головой удариться чтобы на сабж https ставить, и tcp/ip стек там не то что бы отключают, его там обычно включают только по особым празникам, потому что система предназначена для контроллеров совсем другого уровня. А так, если берут 1$ контроллер и пихают туда tcp/ip + https, то это скорее признак или большой жабы, или еще какого кривомыслия разработчиков, но пользоваться этим все равно врядли кто сможет. Потому что за 2$ (в серии) уже можно взять SoC с человеческим arm/mips для линуха и не париться.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	34. "В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к уд..."	+/–
	Сообщение от Аноним (34), 10-Дек-18, 20:50
	> 2$ (в серии) уже можно взять SoC с человеческим arm/mips для линуха Это где ж такое щястье?
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	37. "В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к уд..."	+/–
	Сообщение от Forth (ok), 10-Дек-18, 22:21
	ar9331 правда партией по пять штук хотя бы.
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	45. "В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к уд..."	+/–
	Сообщение от Аноним (-), 11-Дек-18, 22:22
	> ar9331 правда партией по пять штук хотя бы. А ты его потребление видел, пардон? Сабж запускают на совем микроконтроллерах - и там с управлением питанием сильно лучше чем в 9331. Так что реально даже от батареек какое-то более вмняемое время работать. А с 9331... ну в общем это разные весовые категории, даже не конкуренты толком.
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	51. "В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к уд..."	+/–
	Сообщение от Cradle (?), 12-Дек-18, 13:01
	да, оно самое ar9331 например, если в серии, да и оллвинеры если не самые последние тоже по таким ценам идут, у нас как-то по R16 предложение было. Речь о том что если вам нужен tcp/ip + https, да еще и от батареек, то умнее взять SoC на котором уже можно нормальный линух поставить, чем извращаться с мелюзгой. Или брать толстые PIC32 или STM32 по ценам в 2-3 раза выше. И в большинстве случаев tcp/ip и https нужен там где есть стационарное питание, или automotive.
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	54. "В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к уд..."	+/–
	Сообщение от Аноним (54), 12-Дек-18, 14:18
	> SoC на котором уже можно нормальный линух поставить, чем извращаться с мелюзгой. С точки зрения простоты разработки и менее кривых протоколов и кучи фич - да. А вот с точки зрения потребления - все же это разные классы систем. > Или брать толстые PIC32 или STM32 по ценам в 2-3 раза выше. Они вообще конкурируют очень условно. Как таковые разные категории и по потреблению и по свойствам. На STM32 кстати линух есть на старшие модели. Кто-то портанул. Ессно внешнюю память добавить придется, в кристалле ресурсов мало даже у топовых моделей пока.
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	60. "В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к уд..."	+/–
	Сообщение от Forth (ok), 12-Дек-18, 20:31
	>> ar9331 правда партией по пять штук хотя бы. > А ты его потребление видел, пардон? Конечно видел. Это же не мешает его использовать, если нет требований по автономности питания. > Сабж запускают на совем микроконтроллерах - > и там с управлением питанием сильно лучше чем в 9331. Так > что реально даже от батареек какое-то более вмняемое время работать. А > с 9331... ну в общем это разные весовые категории, даже не > конкуренты толком. У нас в компании бывает берут и ar9331, если питание не батарейное и надо что-то недорогое, толстое и на Linux. Между прочим одна из причин как раз такие грабли с безопасностью.
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	36. "В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к уд..."	+/–
	Сообщение от Аноним (36), 10-Дек-18, 22:18
	Ничего безумного в использовании tcp/ip+https на микроконтроллере нет. Сети и шифрование - оно всегда нужно, даже на девайсах, которые работают годами на батарейке. Альтернативные более простые протоколы, конечно, тоже есть, но их использование не всегда оправдано.
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	47. "В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к уд..."	+2 +/–
	Сообщение от Аноним (47), 11-Дек-18, 22:57
	> Ничего безумного в использовании tcp/ip+https на микроконтроллере нет. Кроме того что это дофига кода. Довольно большого и сложного. И конечно же это не вытоптанная поляна, в отличие от какого-нибудь линя с openssl-ем. Поэтому вот вам глючная и кастрированная реализация монструозного протокола, а заодно пачку вулнов впридачу. Это к легиону багов в комплект, которые вылезут если попытаться взаимодействовать с более-менее произвольными серверами по этому самому. А если сервер не произвольный - то, пожалуй, tcp/ip+https далеко не лучшая идея на свете.
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	40. "В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к уд..."	+1 +/–
	Сообщение от Alatar (??), 11-Дек-18, 13:29
	Я бы сказал напротив, головой надо удариться, что бы ставить SoC с человеческим arm/mips для линуха, к которому снаружи надо ещё внешний флеш и ДДР ставить, развесистый PMIC и прочую не менее развесистую обвзяку, там где надо всего лишь снять данные с пары сенсоров и отправить их на сервер. Ведь это решение будет не только на порядок дороже по компонентам, это автоматом требует минимум четырёхслойку с нормами порядка 0.1/0.1 и более дорогой монтаж (линукс-пригодных SoC-ов в не-BGA корпусах можно по пальцам пересчитать, а про SoC-ки со встроенной памятью я вообще всего пару раз в жизни слышал). Кроме того, человеческий Линукс будет грузиться примерно на два порядка дольше и повышать уровень сложности инфраструктуры разработки/деплоя в несколько раз. Про разницу в энергопотреблении вообще лучше даже не думать.
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	46. "В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к уд..."	+/–
	Сообщение от Аноним (47), 11-Дек-18, 22:53
	> и ДДР ставить, развесистый PMIC и прочую не менее развесистую обвзяку, Ну вон allwinner сделал мультичип с 64 мегом DRAM. Это правда для видеорегистраторов, позиционируется, но ничему не противоречит и куда-то еще. А PMIC узкоглазые давно придумали заменять на "глупый" регуль и хак с резистором и GPIO. Получается 2 уровня DVFSа почти нахаляву. В лине из-за этого даже новую категорию "power manager"-ов запилили. Резистор на GPIO теперь тоже типа power manager, my a$$. Китайцы вообще довольно креативны на тему как делать дешево и круто, у них можно многому научиться. > там где надо всего лишь снять данные с пары сенсоров и > отправить их на сервер. Основная проблема подхода - в убогости реализации протоколов. Потом окажется что через вон тот роутер "почему-то" не пролезает. А через соседний - все ок. Натыкался на такое с lwIP. Шифрование? Хыхы, в половине случаев такие сцыкуют - и система целиком перехватывается на раз-два-три любым кто это захотел. А вон пров, хочет чтоб вы pptp сперва сделали, а потом будет интернет. На линухе то это фигня вопрос. А вот без... ых-ых-ых... > Ведь это решение будет не только на порядок дороже по компонентам, На порядок - не будет. SoC нынче дешевые. А МК способные потянуть TCP/IP и шифрование - стоят весьма прилично, опять же. > порядка 0.1/0.1 и более дорогой монтаж (линукс-пригодных SoC-ов в не-BGA корпусах > можно по пальцам пересчитать, а про SoC-ки со встроенной памятью я > вообще всего пару раз в жизни слышал). У allwinner например такой есть. Стоит как и все allwinner'овские чипы копейки. Ну и если плату на фабе делать то там пофиг bga или не bga. А самому... можно взять готовый модуль и одноплатник, наконец, если уж сложно. Они тоже недорогие нынче. > Кроме того, человеческий Линукс будет грузиться примерно на два порядка дольше Как бы системы несколько разного калибра. Тут уж ой. Хотя конкретика очень зависит от того как и что, на самом деле. Рекорд загрузки кутевой проги в лине - 0.3 секунды после power up системы. Из которых половину OMAP в boot ROM просадил. > и повышать уровень сложности инфраструктуры разработки/деплоя в несколько раз. Вот как раз разработка и деплой там как раз очень простые. И дебаг. Но если надо за совсем уж миллисекунды на режим выходить - тут да, МК куда лучше. > Про разницу в энергопотреблении вообще лучше даже не думать. С другой стороны, мало кушать - наверное не про работу с TCP/IP и потребный для этого обвес. Они как-то изначально не об этом.
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

	48. "В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к уд..."	–1 +/–
	Сообщение от Michael Shigorin (ok), 11-Дек-18, 23:55
	Вот тут было занятно, спасибо :)
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	50. "В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к уд..."	+/–
	Сообщение от Alatar (??), 12-Дек-18, 12:19
	Ну ок, про китайцев соглашусь - я при разработке как-то их обычно не рассматриваю, ориентируюсь на более традиционных производителей: TI, Silabs/EnergyMicro, NXP/Freescale, STM, Atmel/Microchip и тд. Я очень долго работал в области промышленной автоматики и в надёжность китайских систем я до сих пор не верю. Хотя довелось поработать и в компании, которая в Automotive решениях заменяла китайский симком на китайский клон китайского симкома для удешевления и считала что это нормально. По стоимости: для TCP/IP и ssl/tls в общем достаточно STM32F1 c 128 кило флеша. Ну может 256. Правда внутри, конечно, лучше использовать не http, а что-то более машино-ориентированное. Более того, тот же самый TLS запихивается даже в F0. Цена в пару баксов, при этом это будет более-менее универсальное решение, которое при необходимости можно мигрировать на другую элементную базу. Если же закладываться на уникальный чип от алвинер, то возможность манёвра в случае чего гораздо хуже. Кстати, раз уж зашла речь, не знаете как у них с гарантиями доступности, на какой жизненный цикл можно рассчитывать? >> Основная проблема подхода - в убогости реализации протоколов. Это 100%. Если есть специфические требования, типа поддержки IPSec, GRE и далее в том же духе, то я буду яростно настаивать на решении на базе Линукса. Но, в большинстве случаев в ИоТе всё проще. >> Рекорд загрузки кутевой проги в лине - 0.3 секунды Скорее всего, академический эксперимент. Для быстрой загрузки требуется хороший камень, быстрый флэш с квад-spi и кучи чаловеко-часов на оптимизацию. То что я видел в реальной жизни - обычно секунд 10-30. Сам пытался добиться быстрой загрузки на TI AM3359, ни фига не вышло с имевшимся железом. >> Вот как раз разработка и деплой там как раз очень простые. На МК ещё более простые =) >> мало кушать - наверное не про работу с TCP/IP и потребный для этого обвес Тоже "очень зависит от того как и что". Я долгое время занимался разработкой ИоТ устройств непрерывного мониторинга с расчётным времени работы от батареи 7 лет. На линуксовых системах это в принципе невозможно.
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	55. "В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к уд..."	+/–
	Сообщение от Аноним (-), 12-Дек-18, 15:29
	> Ну ок, про китайцев соглашусь - я при разработке как-то их обычно не рассматриваю Ну а я вот встретил это в весьма приличном эмбедовочном применении. Олимекс, конечно же, а не платки с али, так подороже, зато апстрим знает что произвел, дружественный к опенсорцу (на половину CAD файлы есть, кой-что даже в KiCad, можете хоть сами нашлепать, если пупок не развяжется). И понимают особенности эмбеда, так что через год купить платки и модули, чтобы не переделывать проект - не вопрос. А на али как повезет, ессно. Хотя для себя или для случаев когда повтор на бис не планируется я и более китайские варианты использую. Работает нормально. Если руки из правильного места и свою систему и железку знать, конечно. > ориентируюсь на более традиционных производителей: TI, Silabs/EnergyMicro, > NXP/Freescale, STM, Atmel/Microchip и тд. У них свое фирменное проклятие в виде оверинженерии, переклина на проприетарных средствах разработки, ну и конских цен на все это и враждебности экосистемы в целом к линуху. Хотя STMы я таки использую. Но вообще совсем не как конкурента китайским ARM, весьма разные сегменты :D > промышленной автоматики и в надёжность китайских систем я до сих пор не верю. Лично видел год аптайма на моей железке. Так и не придумал чему там ломаться - в всех критичных местах кондеры керамические, процы я вгоняю на вменяемые параметры DVFS, несколько donwclock-нув относительно маркетинга. Вачдог китайцы сделать дотумкивают, etc. Ну в общем железки как железки. А заодно комьюнити куда как поприятнее чем у упомянутых. Нормальные линуксоиды, с которыми можно быстро перетереть критичные вопросы. А с каким-нибудь BSP от упомянутых фирмачей можно долго прыгать, пытаясь почесать левой ногой правое ухо, потому что какие-то маркетоиды у производителя возомнили что линукс - это вот так. А сами они конечно на винде и вообще толком не в курсе. > решениях заменяла китайский симком на китайский клон китайского симкома для удешевления > и считала что это нормально. Симком это модули модемов чтоли? Модули как модули, работают более-менее вроде. А если сильно надо - радикально передернуть всяко можно. А я вот видел кучу олимексовских борд с китайскими процами в контроллерах для околопромышленных штук. AFAIK этого уже довольно много распихано везде. Ну и вообще, я уверен что Olimex как фирма под откровенной халтурой не подпишется. Хорошие дешевые девборды всегда были их визитной карточкой. Эту же марку они держат и во всем остальном. > По стоимости: для TCP/IP и ssl/tls в общем достаточно STM32F1 c 128 > кило флеша. Ну может 256. Ну и стоит он такой как-то не доллар все-же. За доллар разве что STM32F0 какой, с совсем другими ресурсами. > Правда внутри, конечно, лучше использовать не http, а что-то более машино-ориентированное. Ну вот и я о чем. > Более того, тот же самый TLS запихивается даже в F0. Сжирая большую часть ресурсов и сильно урезанно, ага. Покажите мне как RSA на F0 с 16 кил флеша и 4 кил оперативы запускается и работает. Ну а что, это часть TLS. А если реализовать только subset - тогда с ПРОИЗВОЛЬНЫМ серваком оно не сконтачится. А раз так - может и ну его нафиг TLS тогда? Гимора много, профита мало %) > Цена в пару баксов, при этом это будет более-менее универсальное решение, Дык покажите запуск RSA и более-менее приличного портфолио крипты на F0 за именно 2 бакса. Хотя возможно 2 бакса имелось в виду в партии от 1000 или даже 10 000 штук, конечно. Ну и вообще, M0 довольно голимое и обкоцаное ядро. Хотя-бы M3 - все-таки лучше. Ну ладно, M0+ накрайняк. Для меня загадка почему ST не переделает мелочь посимпатичнее, F0 как-то так себе по состоянию на сейчас. F1 еще ладно, F103 до сих пор прикольные по цена/фичи. Но вот производительность какого-нибудь RSA там... :D. С эллиптикой конечно лучше, но вот это уже не про произвольно взятый ремотный сервер. > на какой жизненный цикл можно рассчитывать? - (Olimex) How long A10/A20 will be available? - (Allwinner) Forever. С олимексовскими бордами и модулями - olimex не вчера в эмбедовке, знают как надо. С алиэкспресс как повезет, можно расчитывать на то видишь, не более. Если вы сами по себе платы хотите делать - как договоритесь и затаритесь, конечно. Олимекс например конкретно затарились теми же A10/A20 (десятки тысяч чипов). И спрашивали allwinner о доступности. Оказалось, если набирается заказ более 1000 чипов, AW просто запустит кастомный батч конкретно под заказ. Поэтому и forever. Кстати они и чипами барыжат. Даже штучно можно купить. Конечно не за доллар - возиться с S&H за доллар олимексу все же не хочется, это только китайцы с али могут. > Это 100%. Если есть специфические требования, типа поддержки IPSec, GRE и далее > в том же духе, то я буду яростно настаивать на решении на базе Линукса. Как по мне - я буду яростно настаивать на том что IPSec must die и если клиент не убедится, ему ЭТО будет имплементить кто-то другой, от греха подальше. В заведомо стремные авантюры я не ввязываюсь :) > Но, в большинстве случаев в ИоТе всё проще. Главное, чтобы ваш IoT потом не разваливался от тыкания палочкой. >>> Рекорд загрузки кутевой проги в лине - 0.3 секунды > Скорее всего, академический эксперимент. Да какая на... разница? Там подробно расписаны фазы оптимизации, от и до. И 90% этого можно повторить на любом линухе. Близость к этой величине зависит от уровня хардкорности. Для такого время старта это конечно станет не похоже на нормальный линь. Сразу пинок кернелом нужной программы. Так что управление ... ну если прога что-то запустит потом, будет и управление, конечно. А не запустит - будет task specific система. У меня типовое время взлета "обычного" минимального дебиана на 1-2 ядерной шняге с процом на гигагерц около 6 секунд. Я особо не оптимизил, uboot немного только отрихтовал - никого и так не напрягало. Если попросят - я могу основательно оттяпать, но пока всем и так ЗБС было. И это таки с системдой и вачдогованием не только системы но и иерархии процессов под системдой, так что если они сдохнут, системд их перезапустит. А если сдохнет он - тогда аппаратный вачдог сработает. Или ядерный как вариант, у меня оба тикают. Два лучше чем 1. Хотя срабатывание я вообще 1 раз видел. Ну и систему я обычно тюню чтобы при первом намеке на глюки делала ребут. > Для быстрой загрузки требуется хороший камень, быстрый флэш с квад-spi Еще можно eMMC или UHS SD. Они довольно быстрые. > и кучи чаловеко-часов на оптимизацию. Что вы там собираетесь делать кучу часов, интересно? Подолбаться конечно придется, но вообще-то то что см. выше опубликовано было довольно мелкой фирмочкой и как бы отшлепать все это может любой неглупый системщик за обозримое время. Не моментально, но ничего такого уж страшного там нет. Если человек Linux знает. Если это вендоюзер, который железку и ОС не знает - он конечно просадит дофига времени. А я их знаю. Ради лулзов я даже десктоп на одноплатнике себе подымал. Работало даже, хоть и не очень шустренько. > То что я видел в реальной жизни - обычно секунд 10-30. Да это кой-кому надо просто вынуть руки из неправильного места, забить на ветеран-юникс-ретардов и прочие ископаемые BSP и включить головной мозг. У меня порядка 6 сек вышло при том что я даже не оптимизил толком. А если я оптимизить удумаю то и еще отыграю. Ценой потери фич и гибкости, конечно же. И если потом вдруг это потребуется, икоты будет больше. Чудес не бывает. > Сам пытался добиться быстрой загрузки на TI AM3359, ни фига не вышло с > имевшимся железом. Ну а я на китайцах взлетаю довольно нормально. Меня 6 секунд не парят как таковые. Можно и еще обкоцать, но народ и это время загрузки толком не замечает, так что я особо не упирался. > На МК ещё более простые =) Дебажить глюки TLS на мк как мне кажется будет нифига не проще. Ну вот есть у меня такое ощущение. На линухе я запущу wireshark или tcpdump, а вот на мк... уже будет отдельное приключение на много человекочасов, как мне кажется. >>> мало кушать - наверное не про работу с TCP/IP и потребный для этого обвес > Тоже "очень зависит от того как и что". TCP не создан под такие допущения. Если UDP - еще может быть. С кучей оговорок. > Я долгое время занимался разработкой ИоТ устройств непрерывного мониторинга > с расчётным времени работы от батареи 7 лет. На линуксовых системах это в принципе невозможно. Да и без линукса на именно такое время - натрахаешься. А, простите, где и какой вы интернет берете чтобы это 7 лет от батареи работало? И какого размера та батарея? Я себе это вижу как-то так - куча реально маложручих датчиков на МК которые могут от батареи работать и правда дофига, но вот TCP/IP с TLS им явно ни к чему. А с них агрегация на некий гейтвей, уже с линухом, и вот ему электричества побольше уже надо. Но там он заодно и сотовый модем не обломится с его амперными импульсами, или вайфай приличной мощностью к черту на рога. Или полноценный эзернет, со всеми прибамбасами. Но это мое мнение, если кто считает что у него лучше получается - да и флаг ему.
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	61. "В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к уд..."	+/–
	Сообщение от Alatar (??), 13-Дек-18, 00:23
	>> У них свое фирменное проклятие в виде оверинженерии, переклина на проприетарных средствах разработки, ну и конских цен на все это и враждебности экосистемы в целом к линуху. О да, индусский код обвзяки от STM это страшно. Это одна из причин, почему я их предпочитаю не использовать. У EnergyMicro, ныне принадлежащей силабсу, с этим было гораздо лучше (при силабсах вроде пока тоже нормально). Да, разрабатывал я под линуксом без проблем, коллеги тот же самый проект пилили под виндой - кому что удобнее, и главное прозрачно переносимо. >> Ну и стоит он такой как-то не доллар все-же. ну да, бакса 2-3 >> А раз так - может и ну его нафиг TLS тогда? Гимора много, профита мало %) Не понял логику =) А что если не TLS? Своё шифрование городить? Так ещё больше уязвимостей огребёшь. Я ж говорю, классическая задача для датчика - собрать данные и слить на сервак в центр. Для этого зачастую самое удобное решение - TCP/IP. Шифровать в современных реалиях надо по-любому, аутентифицировать тоже крайне желательно. А вот контачиться с ПРОИЗВОЛЬНЫМ серваком - это уже далеко не всегда нужно. >> У меня типовое время взлета "обычного" минимального дебиана на 1-2 ядерной шняге с процом на гигагерц около 6 секунд. Надо будет как-нибудь поиграться, может мне действительно просто с железом не везло. >> На линухе я запущу wireshark или tcpdump, а вот на мк... Ну никто не мешает запустить tcpdump с другой стороны канала =) >> А, простите, где и какой вы интернет берете чтобы это 7 лет от батареи работало? И какого размера та батарея? Так я и говорю, очень зависит от того, как и что =). В этом проекте контекст немного другой. Инет брали обычный GPRS/3G с модулей Telit и TCP-соединение в этом случае они же обеспечивали. А 7 лет обеспечивалось тем, что связь активировалась дважды в сутки по расписанию дабы слить данные плюс пару раз в месяц по событию. А батарейки были обычные литийтионилхлоридные размера D (причём желательно от SAFT, с китайско-корейскими производителями и накувыркались изрядно). 4 во времена AVR и 3 когда на EFR32 перешли. >> Я себе это вижу как-то так Видение совершенно закономерное и правильное. У нас так и было, пачка датчиков которые по радио (в последней реинкорнации по BLE) сливали данные в гейт, а он уже делал первичную обработку и сливал в центр. Проблема в том, что гейту внешнее питание тоже взять неоткуда было. Не, был и вариант с внешним питанием, только стоил он на порядок дороже. Зато там да, уже и линукс был и IPSec клятый (в условиях тендера особо не поспоришь)...
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	52. "В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к уд..."	+/–
	Сообщение от Cradle (?), 12-Дек-18, 13:31
	> там где надо всего лишь снять данные с пары сенсоров и отправить их на сервер все правильно, только IMHO это как раз тот случай когда tcp/ip, tls и https не оправданы и с батарейным питанием не совместимы, а если в каком-то случае без них никак, то скорее всего ошибка в дизайне всей системы. Тоже если что ембедовку для iot разрабатываю, немного в курсе, но могу конечно и не знать что-то.
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

	62. "В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к уд..."	+/–
	Сообщение от Alatar (??), 13-Дек-18, 00:32
	https совершенно не оправдан, это я согласен полностью. TCP/IP - можно придумать юзкейс, хотя как правило он в подобных системах реализован на уровне внешней железки. А вот TLS очень даже оправдан. С учётом того, что сейчас в большинстве контроллеров аппаратное шифрование, он становиться вполне доступным по ресурсам.
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	63. "В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к уд..."	+/–
	Сообщение от Forth (ok), 13-Дек-18, 10:35
	> https совершенно не оправдан, это я согласен полностью. TCP/IP - можно придумать > юзкейс, хотя как правило он в подобных системах реализован на уровне > внешней железки. А вот TLS очень даже оправдан. С учётом того, > что сейчас в большинстве контроллеров аппаратное шифрование, он становиться вполне доступным > по ресурсам. TLS много памяти ест, с процессором обычно особых проблем нет, Cortex M4 тот же очень быстрая машина. Память-то вся SRAM обычно, никакого DDR.
	Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

	22. "В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к уд..."	+/–
	Сообщение от пятачок (?), 10-Дек-18, 18:02
	C бугуртом все норм, но в проектах предпочитаю использовать самописную РТОС.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	24. "В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к уд..."	–1 +/–
	Сообщение от Аноним (24), 10-Дек-18, 18:10
	А BolgenRTOS ещё не зарелизился? ;)
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

8. "В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к уд..."	+1 +/–
Сообщение от Аноним (8), 10-Дек-18, 12:39
https://github.com/aws/amazon-freertos/releases/tag/v1.3.2 v1.3.2 tagged this on Aug 23
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	35. "В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к уд..."	+/–
	Сообщение от Аноним (35), 10-Дек-18, 21:49
	https://github.com/aws/amazon-freertos/blob/master/CHANGELOG.md 1.4.4
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

18. "В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к уд..."	+/–
Сообщение от Аноним (18), 10-Дек-18, 16:44
One does not simply write a network stack.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

19. "В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к уд..."	+/–
Сообщение от Гит (?), 10-Дек-18, 17:17
Ось для хом которые тащат зонды в свои проекты.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	21. "В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к уд..."	+1 +/–
	Сообщение от pavlinux (ok), 10-Дек-18, 17:31
	Поспорим на  250000$, что в твоих проектах найду под сотню дыр, десяток из них со сливом конфед.
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	23. "В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к уд..."	+1 +/–
	Сообщение от A.Stahl (ok), 10-Дек-18, 18:09
	У тебя нет таких денег.
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	27. "В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к уд..."	–3 +/–
	Сообщение от pavlinux (ok), 10-Дек-18, 18:26
	> У тебя нет таких денег. Слух, ущeрбный, что ты делаешь на IT ресурсе? У тебя примитивная логика даже не развита.
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	31. "В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к уд..."	+2 +/–
	Сообщение от A.Stahl (ok), 10-Дек-18, 18:37
	>У тебя примитивная логика даже не развита. А у тебя, похоже, развита только она.
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	26. "В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к уд..."	+1 +/–
	Сообщение от annual slayer (?), 10-Дек-18, 18:15
	лол, даже для хромоге дырки столько не стоят
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	28. "В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к уд..."	+/–
	Сообщение от pavlinux (ok), 10-Дек-18, 18:27
	> лол, даже для хромоге дырки столько не стоят $$$3.1415 млн. приз вроде.
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	29. "В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к уд..."	+/–
	Сообщение от annual slayer (?), 10-Дек-18, 18:31
	тогда не понятно, зачем ты тут на мелочи размениваешься
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	39. "В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к уд..."	+/–
	Сообщение от Аноним (39), 11-Дек-18, 09:38
	Это же pavlinux, он иначе-то и не умеет.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	38. "В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к уд..."	+/–
	Сообщение от Аноним (38), 11-Дек-18, 08:10
	Срок? Что считать "моим" проектом? (Пойдет ли проект где я разработчик, при этом он открытый) Что ты понимаешь под сливом конфед.? Т.к. проект уровня сабжа как раз, и в самом себе не содержит данных узера, как ты понимаешь. Т.е. по факту я бы тебя нанял скажем на пару месяцев за 25к для нахождения 100 дыр. Если будет меньше - то, вероятно, тебе придется заплатить 25к :) Ну, может сойдемся на нулях, если хотя бы десяток дыр найдешь.
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	58. "В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к уд..."	+/–
	Сообщение от pavlinux (ok), 12-Дек-18, 17:00
	>  я бы тебя нанял  скажем на пару месяцев за 25к для нахождения 100 дыр. Так чего скучаем? Пишем, нанимаем!
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

41. "В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к уд..."	+/–
Сообщение от Аноним (41), 11-Дек-18, 15:32
Где желающие переписать FreeRTOS на хрусте? Только оно на целевые архитектуры, боюсь, после не влезет.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	53. "В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к уд..."	+/–
	Сообщение от Cradle (?), 12-Дек-18, 13:34
	даже наверное и влезет, только что это даст? В таких багах обычно виноваты руки, а не язык.
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	56. "В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к уд..."	+/–
	Сообщение от Аноним (-), 12-Дек-18, 16:33
	Даст оно ложную уверенность очередного теоретика по типу Ordu в какой-то сферической безопасности в вакууме. А я ему пожелаю со своей стороны накодить себе на своем фетише хотя-бы автопилот/систему стабилизацит чего-нибудь летучего или скоростного. И критерий тестов безопасности будет крайне прост. Если система не размажет своего автора за обозримое время - QC passed :)
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

	59. "В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к уд..."	+/–
	Сообщение от Анонн (?), 12-Дек-18, 17:07
	> Даст оно ложную уверенность очередного теоретика по типу Ordu в какой-то сферической безопасности в вакууме. А ложная она, потому что все, в чем анон не сечет - фигня, внимания не стоящая. > А я ему пожелаю со своей стороны накодить себе на своем фетише хотя-бы автопилот/систему стабилизацит чего-нибудь летучего или скоростного. Если опеннетные писатели автопилотов не в курсе целой кучи методов верификации для разработки критичных частей софта, то это однозначно говорит о том, что этих методов не существует и ими никто не пользуется!
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема