The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



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

Оглавление

В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к уд..., opennews (?), 10-Дек-18, (0) [смотреть все]

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


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

34. "В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к уд..."  +/
Сообщение от Аноним (34), 10-Дек-18, 20:50 
> 2$ (в серии) уже можно взять SoC с человеческим arm/mips для линуха

Это где ж такое щястье?

Ответить | Правка | Наверх | Cообщить модератору

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

45. "В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к уд..."  +/
Сообщение от Аноним (-), 11-Дек-18, 22:22 
> ar9331 правда партией по пять штук хотя бы.

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

Ответить | Правка | Наверх | Cообщить модератору

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

54. "В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к уд..."  +/
Сообщение от Аноним (54), 12-Дек-18, 14:18 
> SoC на котором уже можно нормальный линух поставить, чем извращаться с мелюзгой.

С точки зрения простоты разработки и менее кривых протоколов и кучи фич - да. А вот с точки зрения потребления - все же это разные классы систем.

> Или брать толстые PIC32 или STM32 по ценам в 2-3 раза выше.

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

Ответить | Правка | Наверх | Cообщить модератору

60. "В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к уд..."  +/
Сообщение от Forthemail (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 далеко не лучшая идея на свете.

Ответить | Правка | Наверх | 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 и потребный для этого обвес. Они как-то изначально не об этом.

Ответить | Правка | Наверх | Cообщить модератору

48. "В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к уд..."  –1 +/
Сообщение от Michael Shigorinemail (ok), 11-Дек-18, 23:55 
Вот тут было занятно, спасибо :)
Ответить | Правка | Наверх | 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 им явно ни к чему. А с них агрегация на некий гейтвей, уже с линухом, и вот ему электричества побольше уже надо. Но там он заодно и сотовый модем не обломится с его амперными импульсами, или вайфай приличной мощностью к черту на рога. Или полноценный эзернет, со всеми прибамбасами. Но это мое мнение, если кто считает что у него лучше получается - да и флаг ему.

Ответить | Правка | Наверх | 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 клятый (в условиях тендера особо не поспоришь)...

Ответить | Правка | Наверх | 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 очень даже оправдан. С учётом того, что сейчас в большинстве контроллеров аппаратное шифрование, он становиться вполне доступным по ресурсам.
Ответить | Правка | Наверх | Cообщить модератору

63. "В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к уд..."  +/
Сообщение от Forthemail (ok), 13-Дек-18, 10:35 
> https совершенно не оправдан, это я согласен полностью. TCP/IP - можно придумать
> юзкейс, хотя как правило он в подобных системах реализован на уровне
> внешней железки. А вот TLS очень даже оправдан. С учётом того,
> что сейчас в большинстве контроллеров аппаратное шифрование, он становиться вполне доступным
> по ресурсам.

TLS много памяти ест, с процессором обычно особых проблем нет, Cortex M4 тот же очень быстрая машина.
Память-то вся SRAM обычно, никакого DDR.

Ответить | Правка | Наверх | Cообщить модератору

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

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




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру