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

"25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
Сообщение от opennews (??), 27-Май-20, 10:47
Исследователи из компании NCC Group опубликовали результаты аудита свободного проекта  Zephyr, развивающего операционную систему реального времени (RTOS), нацеленную на оснащение устройств, соответствующих концепции "Интернет вещей" (IoT, Internet of Things). В ходе аудита было выявлено 25 уязвимостей в Zephyr и 1 уязвимость в MCUboot. Разработка Zephyr ведётся при участии компаний Intel... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=53033
Ответить | Правка | Cообщить модератору

Сообщения

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

1. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+6 +/–
Сообщение от Аноним (1), 27-Май-20, 10:47
>обращение по отрицательному номеру системного вызова приводит к целочисленному переполнению На кой вообще было использовать знаковый тип для номеров системных вызовов? В случае беззнакового, при -1 была бы попытка вызвать самый последний из возможных. При его отсуствии, выдалась бы соответствующая ошибка.
Ответить | Правка | Наверх | Cообщить модератору

	15. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+1 +/–
	Сообщение от Аноним (15), 27-Май-20, 12:08
	согласен, использование signed/unsigned должно как бы отражать предметную область. Если бы отрицательные номера системных вызовов имели практический смысл - ваще ок. Но использовать -2^N...2^N-1 диапазон, когда используешь по факту 0...2^N - ну такое. Всегда, когда работаешь с числами на ЭВМ, знак или беззнак нужно выбирать, исходя из того, какой wraparound тебе нужен по смыслу/менее катастрофичен.
	Ответить | Правка | Наверх | Cообщить модератору

	32. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
	Сообщение от Аноним (-), 27-Май-20, 14:03
	Обычно на wraparound все кладут, а потом получают СЮРПРИЗ! Ну или как вариант можно чекать в рантайме результат. Только скорость математики в несколько раз обвалится, из-за разбавления проверками.
	Ответить | Правка | Наверх | Cообщить модератору

	60. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
	Сообщение от HyC (?), 27-Май-20, 16:34
	На него все кладут потому-что формально тип кагбе автоматически приводится, компилятор не матерится, а череп морщить чего оно там по контексту надо, что можно и что нельзя не царское дело. Поэтому как 50 лет грабли собирали так их же до сих пор и собирают. Приведение без явного на то указания знакового типа к беззнаковому нужно запретить вообще, а беззнакового к знаковому только с учетом расширения разрядности при таком приведении. Чтоб компилятор по рукам больно бил. Но легаси трогать низзя же...
	Ответить | Правка | Наверх | Cообщить модератору

	61. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+3 +/–
	Сообщение от Аноним (61), 27-Май-20, 16:49
	А когда предлагаешь новые проекты на Rust начинать, где такой проблемы нет (и многих других), начинают шипеть и нечленораздельно возмущаться.
	Ответить | Правка | Наверх | Cообщить модератору

	98. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	–1 +/–
	Сообщение от Онаним (?), 28-Май-20, 00:01
	Нет кода - нет проблем, в принципе.
	Ответить | Правка | Наверх | Cообщить модератору

	111. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
	Сообщение от Аноним (111), 28-Май-20, 16:11
	> А когда предлагаешь новые проекты на Rust начинать, где такой проблемы нет > (и многих других), начинают шипеть и нечленораздельно возмущаться. Потому что там других проблем есть, начиная с хайподр@черской экосистемы завязанной на стремную мозиллу.корп. Когда у ЯП вся экосистема завязана на 1 корпораса прославившегося в основном поимением своих девелоперов - это очень так себе заявка. Разве что на залет. Ну и синтаксис у этого хруста какой-то инопланетный. Иные проги на этом самому страшному си++ уже втыкают.
	Ответить | Правка | К родителю #61 | Наверх | Cообщить модератору

	64. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	–1 +/–
	Сообщение от Аноним (64), 27-Май-20, 17:18
	> На него все кладут потому-что формально тип кагбе автоматически приводится, Проблема не в приведении типа. А в том что если вы даже просто допустим суммируете 2 32-битных числа, результат в 32 бита лезть вовсе уже и не обязан, например. Аналогично, далеко не всем и не всегда очевидно: если есть два unsigned, и из меньшего вычитается большее - то будет чего и почему? :) Это означает что в принципе результат может получиться вообще совсем не тот который изначально подразумевал програмер: Ноль программистов ругал сердитый шеф Потом уволил одного - и стало их FF! ("10 программистов проект решили сделать") > Поэтому как 50 лет грабли собирали так их же до сих пор и собирают. Ну, вообще, в свежих компилерах завезли ASAN, UBSAN, а в шланге и вроде integer sanitizer. Так что автоматические граблесобиралки подвезли. Но все же протупить програмеры умеют. Впрочем, такая фигня много где. Некоторые вон вообще до eval() на входных данных допирают в скриптовых языках, сумрачные гении. > Но легаси трогать низзя же... Ну вообще сказать что в стандарте X и новее - вот так, а что не так - ERROR! И в принципе катило бы наверное.
	Ответить | Правка | К родителю #60 | Наверх | Cообщить модератору

	99. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
	Сообщение от Annual (??), 28-Май-20, 00:10
	> Ну, вообще, в свежих компилерах завезли ASAN, UBSAN, а в шланге и > вроде integer sanitizer. Так что автоматические граблесобиралки подвезли. Дрянь же все эти ASAN. Потому что плохо сочетаются с языком. А в языке явно сделано зловредно. Переполнения сложнообнаружимы и неопределённое поведение. То есть отсутствуют нормальные языковые средства и это зловредно внесённая особенность языка. __builtin_add_overflow тоже редкая дрянь (потому что a + b превращается в __builtin_add_overflow и грубо расходится с традиционным синтаксисом C). Вообще в C надо сказать все необходимые элементы есть. Например сигналы... longjmp... Но...  У б людки так и продолжают совать правила с необнаружимыми переполнениями. А в последние времена эти вы б л ядочные "санитайзеры".
	Ответить | Правка | Наверх | Cообщить модератору

	112. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
	Сообщение от Аноним (-), 28-Май-20, 16:25
	> Дрянь же все эти ASAN. > Потому что плохо сочетаются с языком. В смысле? Чего там сочетаться должно? Оно всего лишь компиляется несколько иначе, с другими либами, и в рантайме чекает всевозможные дурные ситуации. Ну и да, оно конечно просаживает скорость и жрет RAM, как и все иные решения такого плана. Но если кто хотел безопасность любой ценой... > А в языке явно сделано зловредно. Переполнения сложнообнаружимы и неопределённое поведение. Да, вот специально сидели и думали как прострелить себе пятку :) > в __builtin_add_overflow и грубо расходится с традиционным синтаксисом C). В традиционном синтаксисе не было ничего конкретного про то как это обрабатывается. На самом деле тут свинью подложили процессоры. У них нет каких-то исключений или чего-то такого при вещах типа переполнения математики или смены знака. Всего лишь взвозится флаг в регистре состояния. Сие не было большой проблемой на 8-битных машинах, на асме, когда безопасность вообще никого не интересовала как класс, сети были чем-то из области научной фантастики. Время шло, а вот эта идея так и осталась. И самые навороченные процы все равно обезьянят это с древних 8-битников. В чем проблема? В том что a+b в лучшем случае делается 1 асмовой командой. Но если захотеть чекать флаги, это уже несколько команд, ветвления с условием и прочая требуха. И если так сделать на каждую операцию, в результате имеется жирный код и проседание математики в разы. И если это будет в каком-нибудь сжатии или крипто... ну, блин, алгоритмы до сих пор то с asm вставками или intrinsic иной раз приходится делать, а тут еще это поднажмет. > Вообще в C надо сказать все необходимые элементы есть. Из си можно в принципе вылепить что угодно. Он один такой гибкий вроде бы. > Например сигналы... Они не часть стандарта си - это POSIX. > longjmp... Странная штука, но позволяет сделать ооооочень странные и ооочень годные вещи. См например чего в lwan.ws с ним изобразили. > Но...  У б людки так и продолжают совать правила с необнаружимыми переполнениями. Я честно говоря не понимаю какая проблема в новом стандарте задефайнить определенное поведение и считать остальное багами. Чего мешает то? > А в последние времена эти вы б л ядочные "санитайзеры". Санитайзеры, кстати, неплохо делают свое дело. Отлавливая весьма хитрые ситуации в рантайме.
	Ответить | Правка | Наверх | Cообщить модератору

	82. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+2 +/–
	Сообщение от Аноним84701 (ok), 27-Май-20, 19:07
	> Только скорость математики в несколько раз обвалится, из-за разбавления проверками. Но далеко не всегда и далеко не везде: #include <limits.h> #include <stdio.h> #include <stdlib.h> #define unlikely(x) __builtin_expect(!!(x), 0) int main(int argc, char **argv) {   int i = 0, add = atoi(argv[2]), max = atoi(argv[3]);   printf("int max %d\n", INT_MAX);   if (*argv[1] != 'c') {     puts("unchecked");     for (; i < max; i += add);   } else {     puts("checked\n");     while (i < max) {       int of = __builtin_add_overflow(i, add, &i);       if (unlikely(of)) {         if (of)           puts("overflow detected!!1\n");         break;       }     }   }   printf("i = %d\n", i);   return 0; } старенький i5 M, тайминги: % export TIMEFMT=$'%E' % gcc -Wall -Wextra -Wpedantic -O3 addbench. #gcc 9 % time ./a.out c 1 2147483647 int max 2147483647 checked i = 2147483647 2,10s % time ./a.out u 1 2147483647 int max 2147483647 unchecked i = 2147483647 2,05s % for i in {1..50}; do time ./a.out c 1 2147483647 > /dev/null; done 2>&1 | awk '{sum+=$1}END{print "avg:" sum/NR}'|column         avg:1,8536  # checked % for i in {1..50}; do time ./a.out u 1 2147483647 > /dev/null; done 2>&1 | awk '{sum+=$1}END{print "avg:" sum/NR}'|column avg:1,8606  # unchecked Бонус: % time ./a.out c 2 2147483647 int max 2147483647 checked overflow detected!!1 i = -2147483648 1,21s % time ./a.out u 2 2147483647 int max 2147483647 unchecked ^C 21,80s   #неопределенное поведение, оно такое.
	Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

	94. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+1 +/–
	Сообщение от Forth (ok), 27-Май-20, 21:52
	Бенч неправильный для современных процов с их конвейерами. Одно сложение в цикле и сразу проверка на выход. Да, во втором случае есть еще одна на overflow, как видно из objdump, но её видать съедает предсказатель переходов или еще какой микрокодовый гремлин. :) Интереснее так: #include <limits.h> #include <stdio.h> #include <stdlib.h> #define unlikely(x) __builtin_expect(!!(x), 0) int main(int argc, char **argv) {   int i = 0, j=0,k=0,l=0, add1 = atoi(argv[2]), add2 = atoi(argv[3]), add3 = atoi(argv[4]), add4 = atoi(argv[5]), max = atoi(argv[6]);   printf("int max %d\n", INT_MAX);   if (*argv[1] != 'c') {     puts("unchecked");     while (i < max) {       i += add1;       j += add2;       k += add3;       l += add4;     }   } else {     puts("checked\n");     while (i < max) {       int of = __builtin_add_overflow(i, add1, &i);       if (unlikely(of)) {         if (of)           puts("overflow detected!!1\n");         break;       }       int ofj = __builtin_add_overflow(j, add2, &j);       if (unlikely(ofj)) {         if (ofj)           puts("overflow detected!!1\n");         break;       }       int ofk = __builtin_add_overflow(k, add3, &k);       if (unlikely(ofk)) {         if (ofk)           puts("overflow detected!!1\n");         break;       }       int ofl = __builtin_add_overflow(l, add4, &l);       if (unlikely(ofl)) {         if (ofl)           puts("overflow detected!!1\n");         break;       }     }   }   printf("i = %d\n", i);   printf("j = %d\n", j);   printf("k = %d\n", k);   printf("l = %d\n", l);   return 0; } time ./a.out u 1 1 1 1 2147483647 int max 2147483647 unchecked i = 2147483647 j = 2147483647 k = 2147483647 l = 2147483647 real    0m0,745s user    0m0,745s sys     0m0,000s time ./a.out c 1 1 1 1 2147483647 int max 2147483647 checked i = 2147483647 j = 2147483647 k = 2147483647 l = 2147483647 real    0m1,326s user    0m1,326s sys     0m0,000s Оно и неудивительно, ведь в непроверяемом варианте gcc нагенерил:   d0:   01 da                   add    edx,ebx       j += add2;   d2:   41 01 ec                add    r12d,ebp       k += add3;   d5:   45 01 f5                add    r13d,r14d       l += add4;   d8:   45 01 f8                add    r8d,r15d     while (i < max) {   db:   39 ca                   cmp    edx,ecx   dd:   7c f1                   jl     d0 <main+0xd0> А в проверяемом: 16e:   39 d1                   cmp    ecx,edx 170:   0f 8e 69 ff ff ff       jle    df <main+0xdf>       176:   01 da                   add    edx,ebx       178:   70 0f                   jo     189 <main+0x189>       17a:   41 01 ec                add    r12d,ebp       17d:   70 0a                   jo     189 <main+0x189>       17f:   45 01 f5                add    r13d,r14d       182:   70 05                   jo     189 <main+0x189>       184:   45 01 f8                add    r8d,r15d       187:   71 e5                   jno    16e <main+0x16e>
	Ответить | Правка | Наверх | Cообщить модератору

	104. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
	Сообщение от Аноним84701 (ok), 28-Май-20, 02:18
	> Бенч неправильный для современных процов с их конвейерами. Одно сложение в цикле > и сразу проверка на выход. Вообще-то так и задуманно (без конвееров и мельтдов^W спекулятивного выполнения конечно было бы медленнее) ;). Тут упор не в числодробление, а в проверки "там и сям". См. например соседнюю новость и дырку из-за signed размера для malloc https://www.opennet.dev/opennews/art.shtml?num=53003 > Проблема вызвана некорректной обработкой отрицательных значений параметра, определяющего размер копируемой области, из-за использования ассемблерных оптимизаций, там тоже народ так же аргументировал, что вставки-проверки размера будут сильно тормозить (хотя на фоне "жирного" вызова malloc, "экономия" на проверке параметра - по-любому смахивает на "экономию на спичах") ... > Интереснее так: > time ./a.out u 1 1 1 1 2147483647 > unchecked > real    0m0,745s >... > time ./a.out c 1 1 1 1 2147483647 > checked > real    0m1,326s > Оно и неудивительно, ведь в непроверяемом варианте gcc нагенерил: >   d0:   01 da       %  gcc -Wall -Wextra -Wpedantic -O2 addbench3.c % for i in {1..20}; do time ./a.out c 1 1 1 1 2147483647 > /dev/null; done 2>&1 | awk '{sum+=$1}END{print "avg:" sum/NR}'|column avg:4,63 % for i in {1..20}; do time ./a.out u 1 1 1 1 2147483647 > /dev/null; done 2>&1 | awk '{sum+=$1}END{print "avg:" sum/NR}'|column avg:2,8205 Двойной if(of) - это моя промашка, остатки разных вариаций (проглядел и не удалил, благо убирается при оптимизации компилятором и на результат не влияет). Ну и  числодробилку без проверок можно сделать еще быстрее ;-) #include <limits.h> #include <stdio.h> #include <stdlib.h> typedef int v4si __attribute__ ((vector_size (16))); int main(int argc, char **argv) {     v4si cnts = {0,0,0,0};     v4si add = {atoi(argv[2]), atoi(argv[3]),         atoi(argv[4]), atoi(argv[5]) };     int max = atoi(argv[6]);        printf("int max %d\n", INT_MAX);     puts("unchecked");     while (cnts[0] < max) {         cnts += add;     }     printf("i = %d\n", cnts[0]);     printf("j = %d\n", cnts[1]);     printf("k = %d\n", cnts[2]);     printf("l = %d\n", cnts[3]);   return 0; } % gcc -Wall -Wextra -Wpedantic -O3 addbench3.c %  for i in {1..50}; do time ./a.out u 1 1 1 1 2147483647 > /dev/null; done 2>&1 | awk '{sum+=$1}END{print "avg:" sum/NR}'|column avg: 1,8596
	Ответить | Правка | Наверх | Cообщить модератору

	108. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
	Сообщение от Forth (ok), 28-Май-20, 08:51
	Там не malloc, там memcpy. Как раз в той новости про memcpy патч перформанс никак не затрагивает. Потому что проверки попросту не те, в патче же видно, поменяли знаковые на беззнаковые. Больше их не стало. Я за то, чтобы не вставлять проверки на переполнение везде безусловно, потому что на монстрах типа интела оно ненамного тормозит всё. На жалких армах типа cortex-m с его убогим конвейером на три инструкции каждый бранч на счету. Вот уж где loop unroll бывает дает жару. :) Конечно надо это проверить тщательно составленным бенчмарком, но чудес на арме не жду.
	Ответить | Правка | Наверх | Cообщить модератору

	109. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
	Сообщение от Аноним84701 (ok), 28-Май-20, 12:33
	> Там не malloc, там memcpy. Верно, что-то меня на маллоке "перемкнуло". > Как раз в той новости про memcpy патч перформанс никак не затрагивает. > Потому что проверки попросту не те, в патче же видно, поменяли Да не, в комментариях (как обычно) ушли в сторону и обсуждали проверки на переполнение "в целом": https://www.opennet.dev/openforum/vsluhforumID3/120702.html#77 > Как максимум процессоры взводят флаг состояний. Но если после каждой операции проверять эти флаги - это перестанет быть си и станет чем-то типа яваскрипта по скоростью работы. - - > Я за то, чтобы не вставлять проверки на переполнение везде безусловно, потому что на монстрах типа интела оно ненамного тормозит всё. >... > Конечно надо это проверить тщательно составленным бенчмарком, но чудес на арме не  жду. Я за "арм-у армово, десктопу/серверу десктопово", а не компромиссные решения по типу "а то вдруг!". Есть профайлеры и PGO -- если п(р)огроммист не умеет ими пользоваться, то ... пусть уж лучше его код хотя бы на "жирнопроцах" по умолчанию с проверками выполняется.
	Ответить | Правка | Наверх | Cообщить модератору

	113. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+1 +/–
	Сообщение от Аноним (-), 28-Май-20, 16:27
	> Но далеко не всегда и далеко не везде: >       int of = __builtin_add_overflow(i, add, &i);   Только вот код непортабельный, а так все хорошо, прекрасная маркиза. Я и еще круче могу - asm() и телемаркет, там можно насовать очень злой и эффективный код. Только он еще менее портабельный...
	Ответить | Правка | К родителю #82 | Наверх | Cообщить модератору

	115. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
	Сообщение от Аноним84701 (ok), 28-Май-20, 17:00
	>> Но далеко не всегда и далеко не везде: >>       int of = __builtin_add_overflow(i, add, &i); > Только вот код непортабельный, а так все хорошо, прекрасная маркиза. Компилируется и работает на штеуде и второпишке с ее armv7 (там конечно более ощутимые просадки, но не суть), а любителям запускать на тостерах – никто не запрещает использовать "труЪшный" вариант. Или сразу писать на JS, там вообще будет суперпортабельно (если оно запустится). Никогда не понимал, почему все должны ориентироваться на самое "слабое звено" и дружно страдать. 🙄 > Я и еще круче могу - asm() и телемаркет, там можно насовать очень > злой и эффективный код. Только он еще менее портабельный... Дык делайте, кто же вам запрещает? o_O Кстати, внезапно – в том же линуксе или glibc полным полно  больших кусков непортабельного асма. Потому что сферический портабельный вариант на практике мало кого устраивал скоростью.
	Ответить | Правка | Наверх | Cообщить модератору

	118. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+1 +/–
	Сообщение от Аноним (-), 28-Май-20, 17:24
	> Компилируется и работает на штеуде и второпишке с ее armv7 При том на обоих небось gcc или шланг. Так конечно можно, но все же портабельность профакивается. > – никто не запрещает использовать "труЪшный" вариант. Или сразу писать на > JS, там вообще будет суперпортабельно (если оно запустится). Там будет суперлагуче и ресурсожорко. И все же у настоящих мастеров все схвачено на именно портабельном си. За что мы их и уважаем. > Никогда не понимал, почему все должны ориентироваться на самое "слабое звено" и > дружно страдать. 🙄 Ну, не ориентируйся, я разрешаю. В принципе я тоже местами gcc'шные фичи юзаю, НО если нечто вообще реализуемо без этого - оно делается без этого. Убивать портабельность неизвестно ради чего - так себе идея. Поэтому я ради лулзов заметил что большинство конструкций жрется даже tcc. Что мне симпатично. > Дык делайте, кто же вам запрещает? o_O Иногда даже и делаю. Но редко и по делу. Потому что нафиг мне такой код кроме крайней необходимости... > Кстати, внезапно – в том же линуксе или glibc полным полно   > больших кусков непортабельного асма. В вот конкретно Linux их не так давно основательно побустали. В глибсе это в основном в performance critical местах. > Потому что сферический портабельный вариант на практике > мало кого устраивал скоростью. И тем не менее, все культурные софтины оставляют чисто сишный fallback. Потому что вчера вон на OpenRISC народ хотел, сегодня еше RISCV вылупился, и на них всех асм писать можно и подзадолбаться. Во всяком случае, будет хорошо если код под них соберется, а потом может и оптимизируют, если это реально нужно и актуально. А когда код вообще не собирается - это все же голимо...
	Ответить | Правка | Наверх | Cообщить модератору

	125. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
	Сообщение от Аноним84701 (ok), 28-Май-20, 19:38
	>> Компилируется и работает на штеуде и второпишке с ее armv7 > При том на обоих небось gcc или шланг. Так конечно можно, но все же портабельность профакивается. Сделай в виде макро и #ifdef (да, так тоже можно – если кто спросит, то я разрешил) и будет тебе портабельность. Будто есть еще сотня альтернатив (а в кланге компатибельность с gcc старательно наращивали чисто из любви к процессу). Или я что-то пропустил и есть компиляторы, поддерживающие больше платформ, чем gcc (или хотя бы clang/llvm)? o_O Ну вообще, тогда только C89, только хардкор! Или MS все же допилил поддержку C99? > Там будет суперлагуче и ресурсожорко. Угу, а без выравнивания, SIMD/векторизации/интринсиков и прочего "непортабельного" – все будет всего лишь медленно и печально. Какой-нибудь конвертер PDF -> PNG или WM-Compositor будут работать в 1/x от возможного, зато их можно будет запустить на тостере. Профит, млин. > И все же у настоящих мастеров все схвачено на именно портабельном си. То-то  проблем с компиляцией линукс клангом не было никогда (лишь "небольшие помехи") </ирония> https://www.opennet.dev/opennews/art.shtml?num=47232 > Обеспечена возможность сборки ядер Linux 4.4 и 4.9 при помощи Clang > 19.09.2017 22:01 . . > Ну, не ориентируйся, я разрешаю. В принципе я тоже местами gcc'шные фичи юзаю, НО если нечто вообще реализуемо без этого - оно делается без этого. Убивать портабельность неизвестно ради чего - так себе идея. Fallback никто не запрещал (но в демке выше, он, как бы, никуда не уперся). Да и с тем, что скорость и безопасность выполнения == "неизвестно ради чего", лично я категорически не согласен. А речи про сферическо-вакуумную портабельность (и необходимые "жертвы") я уже лет 20 слышу. Даже если софт имеет смысл запускать на 1½ платформах. Стремиться к идеалу, это конечно хорошо, но я все же предпочитаю софт с поддержкой 3½ платформ и характеристиками скорости выполнения/безопасности на "хорошо-отлично", вместо  "ну .... зато оно  работает на 100500 платформах, вот!" (именно так оно почему-то в реальности обычно выходит). > В вот конкретно Linux их не так давно основательно побустали. В глибсе это в основном в performance critical местах. Ну вон и там, выше -- такое performance critical место. А в glibc их там "овердофига" только для IA – те же оптимизации mem*/str*  отдельно для *86, MMX/SSE2/3/4/4.2/AVX очень даже внушают. > И тем не менее, все культурные софтины оставляют чисто сишный fallback. Потому что вчера вон на OpenRISC народ хотел, сегодня еше RISCV вылупился, > и на них всех асм писать можно и подзадолбаться. Во всяком случае, будет хорошо если код под них соберется, > а потом может и оптимизируют, если это реально нужно и актуально. А когда код вообще не собирается - это все же голимо... Сдается мне, что споришь ты по большей части с какими-то собственными мыслями. Давай по порядку: 1. можно цитату, где я запрещал делать fallback? Вынеси в макро или инлайн/сделай ifdef, пропиши в системе сборки и будет тебе "щастье". Просто пихать все это в демку на 15 строк, как бы, немного оверкилл. 2. "на асм писать" было вообще-то предложением анонима - у мну этого нет даже в "векторизированном" варианте, хотя интринсики/SIMD туда так и просятся. 3. Изначально рассматривалась ситуация, когда оптимизация - "это реально нужно и актуально". Т.е. когда доп. проверки исключали из-за того что "тормозят".
	Ответить | Правка | Наверх | Cообщить модератору

	135. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
	Сообщение от Аноним (135), 29-Май-20, 17:58
	> Сделай в виде макро и #ifdef (да, так тоже можно – если > кто спросит, то я разрешил) и будет тебе портабельность. Прости, 84701, но я со своей стороны считаю что: 1) ifdef делает код просто !!!ГАДКИМ!!! 2) Это ломает восприятие логики кода посторонними. Или мной через пару годков. 3) В целом это поле для лажи и багов, поскольку эффективно тестировать код с множеством вариантов сборки довольно проблематично. 4) Более того - если увлечься этими опциями, комбинаторный взрыв сделает 3) невозможным. > Будто есть еще сотня альтернатив (а в кланге компатибельность с gcc старательно > наращивали чисто из любви к процессу). Я использую типы C99 + аккуратное понимание какие у меня данные, так чтобы UB просто не возникал. И, конечно, запустить под asan/ubsan и посмотреть чего они скажут. Я даже в случае МК стараюсь чтобы большая часть алгоритма кроме самой работы с железом работала и на PCшной стороне. Это как раз о плюсах портабельности - на PC можно использовать мощную инструментацию которую на МК поюзать не катит. > Или я что-то пропустил и есть компиляторы, поддерживающие больше платформ, чем gcc Есть платформы, где нет GCC, допустим. Не то чтобы я ими пользуюсь (для меня это таки no-go) но все же я предпочитаю не сжигать мосты, если есть такая возможность. Потому что случаи разно бывают, а переписывать код заново я почему-то не люблю, если бы любил, иначе был бы вебмакакой с бидоном или чем там. > (или хотя бы clang/llvm)? Ну например под ряд штук понимаемых sdcc? Правда будем честны, я не особо тестировал свои конструкции типа забавных macro. И все же, я ломаю совместимость только как неизбежное зло, если это абсолютно необходимо для очень жирного плюса или фичи, и это по другому не извлекается. Ну да, скажем, сказать компилеру в какую секцию положить мне вот это - априори нестандартно. Но даже так это сделано макро. Если я захочу сменить тулчейн, я переопределю 1 макро в 1 хидере и оно станет збс и там. > Ну вообще, тогда только C89, только хардкор! Таки я юзаю C99 и полагаю что относительно живые тулсы его должны более-менее уметь. Если даже tcc умеет - ну, гм... > Или MS все же допилил поддержку C99? Не знаю. Они для начала не допилили поддержку наборов команд которые меня могут интересовать. > Угу, а без выравнивания, SIMD/векторизации/интринсиков и прочего "непортабельного" – Вообще, теоретически, jit имеет шансы сгенерить аналог -march=native -mtune=native. Однако с учетом свойств JS и решительного нежелания юзерей ждать компила столько же сколько это gcc -Ofast будет делать - оно как-то так очень теоретически, а практически тяжелая математика в лушчем случае разика в 3 тормознее. А про предсказуемые тайминги можно забыть. И нафиг мне такой МК сдался? :) > можно будет запустить на тостере. Профит, млин. На тостере ресурсов не хватит. Как показал пример мозилской читалки, даташит на МК оно может рендерить в жыэс минут 5. А потом скончаться по OOM. На компе с 16 гигз оперативы. Потому что выполнить :D 900-страничный док конвертированный в js даже ему слабо oO. > То-то  проблем с компиляцией линукс клангом не было никогда (лишь "небольшие > помехи") </ирония> И таки пример - например автор LZ4, обтяпавший все на сях, без асма. Правда компилерспецифичные штуки постепенно навешал, да. И сделал код нечитаемым трэшом. >> Обеспечена возможность сборки ядер Linux 4.4 и 4.9 при помощи Clang >> 19.09.2017 22:01 В ядре Linux всегда ориентировались на GCC-only и юзали ряд фич. В том числе и позабавнее. Скажем, много кто догадывается про макро BIT(x) (1 << x). Это очевидно и любой вменяемый прогер это напишет. Однако ж эффективно "инвертировать" сие определение (т.е. получив число, определить какой номер бита выставлен) - явно труднее. Однако у gcc и для этого есть builtin. Проблема в том что вот как раз благодаря таким плюхам собрать его чем-то еще... гм :) > Fallback никто не запрещал (но в демке выше, он, как бы, никуда не уперся). Если это именно демка, и хрен с ней, а вот если это уже реальная прога.. расстреливать за его отсутствие, тухлыми помидорами, если не было реально сильных причин (как в примере с секциями). > Да и с тем, что скорость и безопасность выполнения > == "неизвестно ради чего", лично я категорически не согласен. Не вижу ничего криминального обеспечивать безопасность путем due diligence. Если у меня например 12-битные сэмплы ADC, я могу быть уверен что суммировать их в uint16 и тем более 32 будет безопасно, даже worst case. До определенного предела. И это не переполнится (я делаю сэмплам & 0xFFF так что даже сбой железа ADC не сможет вызвать это). > А речи про сферическо-вакуумную портабельность (и необходимые "жертвы") я уже лет 20 > слышу. Даже если софт имеет смысл запускать на 1½ платформах. Проблемы начинаются когда захочется запустить это на соседней платформе и/или другом компилере. И ощущать себя как чуваки из колибри ОС мне почему-то совсем не хочется. > "хорошо-отлично", вместо  "ну .... зато оно  работает на 100500 > платформах, вот!" (именно так оно почему-то в реальности обычно выходит). Более того: на МК builtins может или не быть или они могут вести к нежелательным побочным эффектам. А когда я не могу реюзать код это все же голимо. > Ну вон и там, выше -- такое performance critical место. Это вообще абстрактный синтетический тест с 0-й полезностью в реальном мире. > А в glibc их там "овердофига" только для IA – те же > оптимизации mem*/str*  отдельно для *86, MMX/SSE2/3/4/4.2/AVX очень даже внушают. Между нами, я написал себе свои memcpy/memset/memmove для МК. Как разумный компромисс между скоростью и размером. Как небольшие, читаемые и понятные мне конструкции на си. А то что на асме оно могло бы быть лучше - гм, зато я могу использовать эти при early boot вообще всего чего я касаюсь. А на асме переписывать это для всех железок... хм... > 1. можно цитату, где я запрещал делать fallback? Нигде, но это сделает код более гадким и нечитаемым, и еще вопрос кто и сколько багов потом посадит неверно трактовав это и что оно делало. > тебе "щастье". Просто пихать все это в демку на 15 строк, > как бы, немного оверкилл. Я видел к чему это может прийти - и предпочту чтобы такое счастье было от меня подальше :) > 2. "на асм писать" было вообще-то предложением анонима - у мну этого > нет даже в "векторизированном" варианте, хотя интринсики/SIMD туда так и просятся. Я на асме обычно другому поводу. А как аналог "mov SP, R3" на сях сделать? Ну вот не mmaped SP и все тут, а загнать в него нужное - часть процедуры "handover" окружения для следующей части. И вот тут уже приходится смириться с asm(). > Т.е. когда доп. проверки исключали из-за того что "тормозят". Для себя я предпочту исключить проверки в тугих местах 1) проверив входные данные 2) просчитав что поюзаным типам ОК даже краевые случаи. Да, это требует немного не быть буратиной. Но мне кажется что си для таких подходов и делался. Если я буду буратиной в какой-нить фирмвари, мне достаточно просто тупануть в ее логике и все сгорит к чертям.
	Ответить | Правка | Наверх | Cообщить модератору

	122. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
	Сообщение от Michael Shigorin (ok), 28-Май-20, 18:34
	>>> Но далеко не всегда и далеко не везде: >>>       int of = __builtin_add_overflow(i, add, &i); >> Только вот код непортабельный, а так все хорошо, прекрасная маркиза. > Компилируется и работает на штеуде и второпишке с ее armv7 На e2k в прошлом году бы ещё не собралось: http://altlinux.org/lcc#builtin > Никогда не понимал, почему все должны ориентироваться на самое > "слабое звено" и дружно страдать. 🙄 Потому что wintel уже есть/был (предпочитаемое подчеркнуть). > Кстати, внезапно – в том же линуксе или glibc полным полно   > больших кусков непортабельного асма. Потому что сферический > портабельный вариант на практике мало кого устраивал скоростью. В ядре-то понятно, а вот когда где попало без generic'ов идёт вот такое -- досадно порой.  Причём не от того, что оптимизировали, а от того, что невыоптимизировали как следует (отрываемо).
	Ответить | Правка | К родителю #115 | Наверх | Cообщить модератору

	16. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+4 +/–
	Сообщение от Аноним (16), 27-Май-20, 12:13
	Не удивлён. Встречаются те, которые пишут просто int вместо uint8, uint32 в коде для микроконтроллеров с 32 кб флеша и 4 кб ОЗУ.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	34. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+1 +/–
	Сообщение от Аноним (-), 27-Май-20, 14:12
	В случае 32-битных микроконтроллеров - у него один фиг регистры 32 бита и от уменьшения uinit код может и не улучшиться. А иногда и ухучшается. Относительно int тот же uint32_t явно конкретнее указывает пожелания, int на разных железках может быть разным и это так себе. А так там бутлоадер приведен офигеть просто. В мк с 32 кил кода он вообще влезет, интересно? Там алгоритмов напихано побольше чем в GRUB, пожалуй :)
	Ответить | Правка | Наверх | Cообщить модератору

	47. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+1 +/–
	Сообщение от Аноним (47), 27-Май-20, 15:05
	>4 кб ОЗУ. >32-битных микроконтроллер именно столько озу у 32битных микроконтроллеров и бывает. не больше не меньше
	Ответить | Правка | Наверх | Cообщить модератору

	65. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+1 +/–
	Сообщение от Аноним (64), 27-Май-20, 17:20
	> именно столько озу у 32битных микроконтроллеров и бывает. не больше не меньше Я не понял 1 момент: - Это вы поумничать решили, будучи не в теме? - Или вы решили покапитанить? Я прямо 50/50. Ну так, глядя на вон тот STM32F с 16 кил флеша и 4 кило рамы. И да, он 32-битный при этом, а что? :)
	Ответить | Правка | Наверх | Cообщить модератору

	105. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
	Сообщение от с (?), 28-Май-20, 03:10
	> STM32F это что? ты сам то в теме? stm32f1* и stm32f4* это арм разных поколений, м3 и м4, уж обьем озу там есть из чего выбрать, у голубой таблетки за 50р 20кб. А 4кб при 32битах это экстим какойто.
	Ответить | Правка | Наверх | Cообщить модератору

	114. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+1 +/–
	Сообщение от Аноним (-), 28-Май-20, 16:50
	> это что? Это семейство процов STM32F. > ты сам то в теме? (посматривая на свежезапаяный STM32): STM'ы навороченные, орать что он на 100% в теме может только полнейший дилетант. Там даже в F1xx железки такие что > stm32f1* и stm32f4* это арм разных поколений, м3 и м4, Они не "разных поколений" а скорее "разного масштаба". Эти линейки живут параллельно и не являются заменой друг друга. F1 это относительно мелкие, простые - и дешевые штуки. С достаточно нафиченой однако ж периферией, чем и интересен. А конкретно F103 стал "золотым стандартом" отрасли: его растащили на цитаты и его клоны и перепевки выпускает наверное с полдюжины фирм. А F4 - большие навороченные камни "выше среднего", с совсем другим потреблением, сложностью системы и прочим. Они могут больше - но и сложнее. > уж обьем озу там есть из чего выбрать, у голубой таблетки за 50р 20кб. Так выбирайте, кто ж против? Однако чем больше флеша и рамы тем дороже чип. А пойнт F1xx - например, по сравнению с AVR (arduino, etc) он и дешевле и фичастее в разы. > А 4кб при 32битах это экстим какойто. Это всего лишь младшие представители семейств. Для многих микроконтроллерных задач 4K более чем достаточно. А чем больше флеха и оператива, тем больше кристалл и дороже и прожорливее чип. Вообще, в случае МК счастье не в гигазах оперативы, не в гигагерцах тактовой, а в том что все это относительно простое, предсказуемое, можно сунуться в жесткий реалтайм, отмеряя времена реакции в микро-, если не наносекундах. Можно сунуть это как last line of defence, отработающий защиту когда все вокруг подвело. Например, есть automotive исполнение этого добра. То-есть это можно ставить в критичные подсистемы автомобиля - и производитель утверждает что если вы все делаете как они пишут, их чип не убьет юзера о фонарный столб. А вы засунете этот ваш blue pill в такое применение? И в случае если юзера вдруг размажет - ответите в суде?
	Ответить | Правка | Наверх | Cообщить модератору

	147. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
	Сообщение от с (?), 30-Май-20, 06:13
	> орать что он на 100% в Я не утвержрал есть и stm8f это другое семейство? ну очевидно, впрочем нет, литера f всего лишь тэг о чем-то там говорящий, так же как и l о низком потреблении, а вот циферка после уже характеристика проца по объему фич и герцам, поэтому библиотеки зовутся stm32f1xx.h >> stm32f1* и stm32f4* это арм разных поколений, м3 и м4, > Они не "разных поколений" а скорее "разного масштаба". Эти линейки живут параллельно > и не являются заменой друг друга. Ну ок, "поколений" не то слово, но скажем атом и i5, но извините, атом это старая порезанная модель той же линейки что и коре2дуо из которой все вылупилось, не силен в номенклатуре арм, и не уверен что корректно ее перекладывать на интел. и мое удивление вызывает имеено факт зачеса f1 и f4 в одну гребенку, а там же и f7.. > Так выбирайте, кто ж против? Однако чем больше флеша и рамы тем > дороже чип. Это что ж такое надо делать чтобы 50р было дорого. > в случае если юзера вдруг размажет - ответите в суде? Глупый вопрос, - это чистая арифметика, какой % сбоит, если не большой, то можно и компесации платить, и это все просчитывается и залепленность грязью фотодатчика в том числе. > (посматривая на свежезапаяный STM32): Какбы я любитель, я очень много времени убил на hse, который то работает, то не работает, на разных платах с разными компонентами, по итогу плюнул и перешел на hsi.
	Ответить | Правка | Наверх | Cообщить модератору

	148. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
	Сообщение от Аноним (148), 30-Май-20, 11:34
	>  есть и stm8f это другое семейство? Абсолютно. Это некое собственное 8-битное ядро STMicro вместо ARM. Единственное что их хоть как-то роднит - периферия местами вроде бы похожа, так что с них по задумке ST можно смигрировать на STM32 относительно малой кровью. Но я знаком с этим семейством только краем глаза и никогда его не програмил. У китайцев есть и более интересные артефакты. Например нечто с периферией которая клон F103, но процессорным ядром RISCV. В этом месте мы начинаем немного понимать чипмейкерские концепции "core", "uncore", "HW IP, version X" и как все это компонуется. > ну очевидно, впрочем нет, литера f всего лишь тэг о чем-то там говорящий, так же как > и l о низком потреблении, а вот циферка после уже характеристика > проца по объему фич и герцам, поэтому библиотеки зовутся stm32f1xx.h У STM довольно сложная система обозначений. STM32F отсылает на все семейство, довольно разнообразное, но имеющее что-то общее в виде потуг обеспечить хотя-бы частичную обратную совместимость между выводками. Работает до известного предела, но если например F103 не хватило, можно найти более крутой чип с [почти] тем же пинаутом, которому не сильно переделывать софт и относительно малой кровью уйти на него, так что радикально переделывать проект все же не придется. На самом деле 32L тоже "частично совместимы" с F. У low power есть свои особенности и много, так что о 100% совместимости речь не идет, но превращение ежа в ужа с практической точки зрения описывается относительно компактным Migration Guide рассказывающим на что обратить внимание. И если ему следовать то это ... все же проще чем зафигачить совсем новый проект на совсем новом железе. Собственно вот это вот портфолио чипов - и есть главный козырь STMicro, имхо. Если освоил технологию но вот надо бы немного отманеврировать в ту или иную сторону, толи кушая поменьше, толи считая побыстрее, у них это можно. Как некий постепенный апгрейд, вместо того чтобы одним махом обана, переделывай, дескать с ноля. На этом факте пристроилось несколько умников склонировавших интерфейсы периферии F103 и вывесивших нечто совместимое. Так что если STMicro залупится, для F1xx есть куча фирм готовых подхватить знамя, если его вдруг отдать решат :) > Ну ок, "поколений" не то слово, но скажем атом и i5, но извините, атом это старая > порезанная модель той же линейки что и коре2дуо из которой все вылупилось, > не силен в номенклатуре арм, и не уверен что корректно ее перекладывать на интел. Это не совсем корректное сравнение. В том плане что F1xx вообще никто не резал, это была первая успешная линейка Cortex-M. А то что потом на ее основе сделали другие flavours, попутно местами улучшив "HW IP" в "uncore" по итогам - да, и что? В embedded другие парадигмы. Там даже сцаный pic16 до сих пор в ходу. Хоть он и крап. > и мое удивление вызывает имеено факт зачеса f1 и f4 в одну гребенку, а там же и f7.. Это придумал сам STMicro, на той почве что оно частично совместимо и изначально растет из одного семейства технологий. > Это что ж такое надо делать чтобы 50р было дорого. 1) Где купить именно оригинальный F4, за именно 50 рублей - лично я не знаю. А сыкотный китайский полунедоклон от мутного поставщика - уже не то. 2) Кроме этого, F4 тупо сложнее. Если цель прилететь из точки A в точку B, одномоторная Cessna значительно проще чем Boeing 767. И если цель доставить 200 пассажиров вместе с собой не стояла, зачем бодаться с изучением в разы более сложной штуки? 3) Есть еще mass production. И там народ давится за каждую копейку. И даже если я не целюсь в mass production - я таки в целом следую их инженерным паттернам. Считая что во первых это имеет свой пойнт, а во вторых - кто знает, никогда не знаешь что взбредет в бошку хомячкам. И возможность растиражировать свое решение - это то что и отличает инженеров и наколенщиков с ардуиной. > Глупый вопрос, - это чистая арифметика, Ну во первых управляющие задачи не только арифметика. Во вторых чем больше софта и железа, тем больше всего может сбойнуть и тем труднее удерживать происходящее под надежным контролем. Тойота узнала эту нехитрую истину сложным способом, подпортив репутацию. Ибо когда вы отпускаете педаль газа, но машина уходит в разгон вы имеете очень валидные причины обделать водительское сидение :) > какой % сбоит, если не большой, то можно и компесации платить, и это все просчитывается > и залепленность грязью фотодатчика в том числе. У тойоты как я понял трабл на самом деле был не в датчиках, а в том что они наворотили фирмваре - и поплатились за это. >> (посматривая на свежезапаяный STM32): > Какбы я любитель, я очень много времени убил на hse, который то работает, то не работает, > на разных платах с разными компонентами, по итогу плюнул и перешел на hsi. Как бы у STMicro есть весьма подробный гайд про осцилляторы и их DOS и DONTS. Это слаботочная высокочастотная цепь, требующая к себе определенного внимания и некоего понимания физики процессов. И вот это тоже отличает нормального инженера от ардуиншика. Первый может повторить на бис, используя научный подход. Второй... ему или везет, или он не понимает что вообще за нафиг. Если оно надо - могу найти номер доки. Кварцы сами по себе не такая простая штука как кажутся. И конкретно у STM32 есть прикольный CSS (clock security system), при том опять же потому что это _деликатная_ цепь. И если она откажет в run time - нехило бы иметь какой-то план на этот случай отличный от полностью повисшего чипа. И когда монитор сам перекидывает это на HSI и генерит NMI - ну, мы по крайней мере знаем что это все же не уровень ардуины а кое-что покруче.
	Ответить | Правка | Наверх | Cообщить модератору

	149. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
	Сообщение от с (?), 31-Май-20, 14:34
	> У китайцев есть и более интересные артефакты Спасибо, но уже рано (поглядывая на десяток тестовых платы на какомто клоне, который даже в режим записи прошивки по джамперу не переходит)) ). > У STM довольно сложная система обозначений. Это я понял, а еще что у них корявые доки, и вообще если сравнивать с программирование модуля ядра линукса, скажем, это земля и небо, st очень убогонько ведет сопроводиловку. > Собственно вот это вот портфолио чипов - и есть главный козырь STMicro, > имхо. Если освоил технологию Технологию чего? > Это придумал сам STMicro Понятно, лично для себя я определил это как больше маркетинговый параметр, мешать кучу из m3 и m4 ядер арм в одну линейку такое себе > 1) Где купить именно оригинальный F4, за именно 50 рублей - лично > я не знаю. А сыкотный китайский полунедоклон от мутного поставщика - > уже не то. Я про f103 вообщето, хотя и их теперь действительно ссыкотно брать, уже обжогся > 2) Кроме этого, F4 тупо сложнее На ф4 даже не смотрю, не вижу смысла, на орбиту мне ничего запускать не надо, а отдать по хттп в аварийной ситуации когда все порушилось простенькую страничку с примитивной формой изменения состояния пина или частоты pwm справится и 103. > И даже если я не целюсь в mass production - я таки > в целом следую их инженерным паттернам. Нууу кстате, это очень интересная тема, лично я уже пару лет просматривая всякие диайвайные (прости господи) каналы на ютубе из супер популярных девайсов с мк назову 2 - это паяльник и осциллограф, оба примерно за 3к рублей и оба на 103, что как мне кажется дикий оверпрайс, впрочем, пытясь заниматься вопросом в рамках работы, точнее это вообще не мой профиль, но так уж вышло, что правой пяткой я оказался близко, так вот Во-первых, интересуясь начинкой всяких штук, еще не одной стм нигде не встречал, кроме упомянытых, а на работе всякого железа много. Во-вторых, из того, что есть на рынке все не то, железки типо умные и совмещают функционал, но на лично мой взгляд плохо, и за их цену проще купить 2 - каждая из которых будет заниматься своей задачей в полном объеме реализуя возможности, даже общался с одним блогером, но нету объемов которые бы дали съэкономить, в переспективе да, но в нашей стране строить столь далекие планы не принято. > Тойота узнала эту нехитрую истину сложным > способом, подпортив репутацию. это пионеры, никто не заставляет их ошибки повторять, да и все эти ньюансы описанны сто раз во всякой фантаскической литературе 70 летней давности, никто не мешает рядом с мозгом разместить второй, который будет контролировать вменяемость первого. > Как бы у STMicro есть весьма подробный гайд про осцилляторы и их > DOS и DONTS. Это слаботочная высокочастотная цепь, требующая к себе определенного > внимания и некоего понимания физики процессов. И вот это тоже отличает > нормального инженера от ардуиншика. Первый может повторить на бис, используя научный > подход. Второй... ему или везет, или он не понимает что вообще > за нафиг. Нашел я тему в форуме, где обсуждались как раз мои проблемы стм, кто-то напинал поставщика плат за нарушение техпроцесса производства, неотмытый флюс и все решилось, ктото сам промывал, ктото чтото напаивал дополнительно > Если оно надо - могу найти номер доки. Кварцы сами по себе > не такая простая штука как кажутся. И конкретно у STM32 есть > прикольный CSS (clock security system), при том опять же потому что > это _деликатная_ цепь. И если она откажет в run time - > нехило бы иметь какой-то план на этот случай отличный от полностью > повисшего чипа. И когда монитор сам перекидывает это на HSI и > генерит NMI - ну, мы по крайней мере знаем что это > все же не уровень ардуины а кое-что покруче. Пытался я по докам стм завести dac ничерта не вышло, там готовый код по сути, но не вышло, да и не очень-то хотелось, так из любопытсва. В общем-то, я бы описал свой "интерес" как потыкать палкой, хорошей такой палкой, основательно потыкать, но сильно углубляться в нарушения референсной схемотехники и всякие патазитные емкости этим вызванные я не хочу, давно уже забыл про тоэ и переходные процессы и большого желания вспоминать нет, мне вполне комфортно в рамках ит, даже программирование вод винду бесит отсутствием вменяемой документации и непреодалимыми подводными камнями в которые упарывался в рамках попыток, но программирования и нет в должностой инструкции, так что все нормально)) > Если оно надо - могу найти номер доки Есть гораздо более высокоуровневые вопросы, которые в рамках ардуинского доминирования, которое сводится к непарься-возьми-готовое-вот-ссыка, мне так и не удалось разрешить, глупо было бы, наверное, их задавать здесь, поскольку, по-хорошему, вменяемым ответом должен быть обзор-или-статья, не знаю, в общем объемная работа. Но в целом я бы пообщался с носителем..
	Ответить | Правка | Наверх | Cообщить модератору

	150. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
	Сообщение от Аноним (-), 01-Июн-20, 02:28
	> который даже в режим записи прошивки по джамперу не переходит)) ). Если это про F1xx то там 2 сигнала, boot0 и boot1, это 2 джампера. Неверный уровень на boot1 приведет к boot from RAM. Но узкоглазые могут и корпус без кремния продать. > а еще что у них корявые доки, Не согласен. Я по ним научился инициализировать чип и работать с железками "с ноля". Без чужих либ и непонятной магии. Даже не знаю как еще лучше проверить качество док. Единственное что оно в нескольких разных доках распихано. У атмел авр проще, но они намного примитивнее. > и вообще если сравнивать с программирование модуля ядра линукса, скажем, это земля и > небо, st очень убогонько ведет сопроводиловку. Не соглашусь. А, мелкий чит: если хочется понять как по минимум врубается, у DiHALT статейка "что надо чтобы мигнуть светодиодом на STM32". Для проприетарного компилера, но идея понятна. Туда же и диаграммы clock tree чипа. > Технологию чего? Как ST делает чипы, как формируют семейства, как они работают, какие особенности у железок. И как все это стыковать между собой. А когда общий вид понятен, остальное будет неким diff'ом, заметно меньше чем полное знание. Если изучать каждый такой чип с ноля, довольно быстро захочется застрелиться, имхо. > Понятно, лично для себя я определил это как больше маркетинговый параметр, мешать > кучу из m3 и m4 ядер арм в одну линейку такое себе Это навороченное портфолио более-менее родственных чипов на разные задачи. Так что умеючи работать с кем-то из них можно попытаться и на соседей перелезт, железо знакомое будет. МК ценен периферийными железками, откуда такая копипаста блоков. > Я про f103 вообщето, хотя и их теперь действительно ссыкотно брать, уже обжогся Я их беру у поставщиков которым реально влупить претензии и они имеют соглашения о дистрибуции, есть определенная репутация. Даже чипидип продает те как STM32, именно STMicro, а вон те GD32 - Gigadevice. Клон, но явно маркирован (и вдвое дешевле). На самом деле ща ЧиД, терра, платан и т.п. - интерфейс к группе складов с которых индустриалы кормятся. Аналогично про farnell/mouser/.. если не в РФ. Да, иногда это ведет к странноватым условиям поставки. > все порушилось простенькую страничку с примитивной формой изменения состояния пина или > частоты pwm справится и 103. Если не ошибаюсь, у выводка F1xx Ethernet только у F107. Куда F103 ее девать будет? Меня сие не парит особо по причине дружбы с одноплатниками на пингвине. Эти если надо хоть торенты нальют. > всякие диайвайные (прости господи) каналы на ютубе из супер популярных девайсов > с мк назову 2 - это паяльник и осциллограф, оба примерно за 3к рублей и оба на 103, Я 103 видел в робопылесосе и чем-то бытовом, 32L - в мыше. STMicro был одной из первых фирм прочухавших что cortex M штука годная, так что они попадаются. И имеют плюс в виде бутлоадера, так что шьются любым 3V сериальным шнурком. > что как мне кажется дикий оверпрайс, Вопрос в конечном итоге в том слабо ли сделать дешевле и/или лучше :P. Иногда народ доходит до отчаяния - и вон на радиокоте некто сделал аж VNA. Видимо посмотрев на цены. > одним блогером, но нету объемов которые бы дали съэкономить, в переспективе > да, но в нашей стране строить столь далекие планы не принято. В РФ вообще заниматься именно масспродакшном ... затея сильно на любителя. > это пионеры, никто не заставляет их ошибки повторять, Фундаментальная проблема проста и озвучена DJB: чем сложнее система, тем больше багов. И если оно делает что-то важное, баги последнее что там нужно. > никто не мешает рядом с мозгом разместить второй, который будет контролировать > вменяемость первого. Мистер Ш любит спрашивать кто будет проверять проверяющего. В принципе я придумал ответ "пусть проверяют друг друга". Но это достаточно сложный путь. Если почитать firmware safety guide все того же STMicro можно и без этого получить пару дюжин дельных идей. > кто-то напинал поставщика плат за нарушение техпроцесса производства, неотмытый флюс и > все решилось, ктото сам промывал, ктото чтото напаивал дополнительно 1) В доке описывающей особенности применения STM с кварцами подробно рассказано что напаивается, почему, какие грабли, как понять WTF. 2) Кварцы стоит брать известного поставщика, с даташитом. 3) Там важна разводка. Максимально близко к чипу, симметрично, правильно огорожено землей. У STM есть примеры + разбор чужих ошибок.   4) И естественно никакого флюса, особенно если он не безотмывочный. Там токи в микроамперах при частотах в мегагерцы. Это не очень простое сочетание, оно не прощает лажу. Разводка платы на самом деле о том чтобы думать в терминах токов и их излучений. > Пытался я по докам стм завести dac ничерта не вышло, там готовый > код по сути, но не вышло, да и не очень-то хотелось, так из любопытсва. Хм... скоро попробую DAC как раз. На вид вроде вполне понятная железка. Только он довольно слаботочный, это надо понимать. > и всякие патазитные емкости этим вызванные я не хочу, давно уже > забыл про тоэ и переходные процессы и большого желания вспоминать нет, С железом совсем без этого все же трудно. Физика такая штука что хрен обманешь - и если это не вышло, лягается и временами довольно странно. А тут еще софт и железо - и тупняк в одном легко отольется в другом. Иногда даже матерые волки наступают на очень странные грабли. У DiHalt есть рассказ как он клавиатуру сканировал. Само по себе это просто как тапок, перебирай сигналы да смотри что прочлось, понятно что нажато. Но он это необдуманно фигачил на максимальной скорости. И в итоге ... все это стало излучать на частоте под мегагерц. И "завоняло" само себя своим же излучением :). И да, такое можно вкостылить программно. > отсутствием вменяемой документации и непреодалимыми подводными камнями в которые упарывался > в рамках попыток, но программирования и нет в должностой инструкции, так > что все нормально)) Увы, не любят програмеры документацию писать. Что хуже ее в конторах пишут техписы которые не програмеры. Поэтому иногда там случаются баги и несоответствия. ST в этом хорош неким избытком инфо - кроссчек описания выявляет несоответствия. > должен быть обзор-или-статья, не знаю, в общем объемная работа. Но в > целом я бы пообщался с носителем.. Там в нормальном виде наверное скорее на книжку потянет. Для себя я вижу пойнт МК в взаимодействии с внешним миром. И при этом совсем уйти от физики все же не получится - при полном игноре оно подкинет немало забавных сюрпризов. Мир работает по этим правилам. А купить готовое - да, но это не дает понимания тех правил. И при попытке "всего то протянуть пару проводов" странная фигня запросто повторится. Как вариант, компании иногда разделяют это на "железячника" и "програмера", 2 разных людей, но когда оно программно-аппаратная штука, это тоже гарантирует немало интересных моментов.
	Ответить | Правка | Наверх | Cообщить модератору

	151. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
	Сообщение от с (?), 01-Июн-20, 18:05
	> 2 джампера. Неверный уровень на boot1 приведет к boot from RAM. > Но узкоглазые могут и корпус без кремния продать. Там gd, пробовал все комбинации, мигает светодиодиком тестовым и все, прозванивал мультиком цепи этих джамперов - все ровно так как на оригинальных. >> а еще что у них корявые доки, > Не согласен. Я по ним научился инициализировать чип и работать с железками CMSIS ?, Мб. Мне так глубоко не надо, я остановился на SPL. Вероятно это очень глупо, но ничего другого я не нашел, а spl документирован довольно так себе, я только пару недель назад нашел вменяемый обзор всего этого добра, ну и он не утешителен, какбы гуи мне нафиг не упало, git'а мне достаточно, а очередной блокнотик в топ-ку, подбор правильных параметров компилятора отдельная песня. По сути за 10 месяцев с монента появления первого образца проект нарисовался, на git, cmake и gcc-eabi под чистым линуксом. хотя попытка прикрутить переферию на i2c была провальной, если через while(xx & FLAG); делать, работает, а если через прерывания, то виснит, точнее там какието не совсем прерывания, и по итогу флаг не возвращается в 0, а приобретает значение которое не описанно в либе с ним и перезапускает обработчик события и сбросы не помогают. И в документации ничего релевантного не нашел. > Не соглашусь. А, мелкий чит: если хочется понять как по минимум врубается, > у DiHALT статейка "что надо чтобы мигнуть светодиодом на STM32". Для > проприетарного компилера, но идея понятна. Туда же и диаграммы clock tree > чипа. "проприетарного компилера" это который gcc-arm-none-eabi-9-2020-q2-update-x86_64-linux с сайта developer.arm.com >> Технологию чего? > Как ST делает чипы, как формируют семейства, как они работают, какие особенности > у железок. Ну это такое, 100р примлемая цена, чтобы запихать в каждый "выключатель", f4 уже избыточен, а потом связываем с x86, родной и хорошо знакомой. таков мой кейс. >> Я про f103 вообщето, хотя и их теперь действительно ссыкотно брать, уже обжогся > Я их беру у поставщиков которым реально влупить претензии и они имеют А я на алике ))) > Если не ошибаюсь, у выводка F1xx Ethernet только у F107. Куда F103 > ее девать будет? В W5500, вот их много встречал, точнее w5100 встечал, а пользуюсь W5500, так себе работает, из фаерфокса на ноуте идеально, а с негоже с телефона, чаще глючит. > Меня сие не парит особо по причине дружбы > с одноплатниками на пингвине. Эти если надо хоть торенты нальют. Ну да, я поэтому и остановился на почти самом примитивном чипе, на самом примитивном из 32 бит, зачем колхозить чтото сложное, когда можно завернуть на дешевый линукс, интел както анонсировал квакр кажись, там x86 в размере монетки, не знаю как оно пошло, но одноплатник покупать я так и не решился, зачем он мне, у меня 5 шт девайсов на i7 в моем единоличном пользовании, из них 3 ноута, а пользуюсь 2мя устройствами, остальные, хз продать/подарить/на запчасти оставить. > так что шьются любым 3V сериальным шнурком. Это был критерий выбора. >> что как мне кажется дикий оверпрайс, > Вопрос в конечном итоге в том слабо ли сделать дешевле и/или лучше Вопрос хороший, - не слабо, конечно персонально для меня это не будет что-то на мк, скорее софт, но в целом делают же, медленно и както колхозно, но делают, тот же осциллограф, за 7-15-50 зачем он мне, за 3 то дорого, там компонентов рублей на 500, экран еще рублей 200-300. Но возвращаясь, в массовое производство запускать, хрен угадаешь как пойдет, я на эти грабли наступал, конечно не запуская чтото там свое, но классная бесплатная фича, друзья/сокурсники не оценили, а через сколькото лет выходит тоже самое только частично платное, и с кучей ограничений и теперь в каждом чайнике, да офигеть. > В РФ вообще заниматься именно масспродакшном ... затея сильно на любителя. В РФ вообще сильно на любителя Так правильнее ИМХО )) > чем сложнее система, тем больше багов. Да поэтому юниксвей наше все, поэтому я и решил не тратить 1500р на умный выключатель, работающий через китайские сервера, а собрать его самостоятельно, за 300р и кучу убитого времени, а бонусом пойдет понимание че-как, и я его собрал, и сейчас обдумываю стоит ли оно все того. > Мистер Ш любит спрашивать кто будет проверять проверяющего Это Шигорин? )) Вообще я думаю 20/80, тоесть условно 20% это критичные функции их и надо проверять, а условная 3я ступень проверяет 20% второй, получаем некую функцию стремящуюся к нулю, ну а дальше арифметика расскажет, где надо остановиться чтобы не уйти в минус. > 1) В доке описывающей особенности применения STM с кварцами подробно рассказано что > напаивается, почему, какие грабли, как понять WTF. > 2) Кварцы стоит брать известного поставщика, с даташитом. > 3) Там важна разводка. Максимально близко к чипу, симметрично, правильно огорожено землей. > У STM есть примеры + разбор чужих ошибок. > 4) И естественно никакого флюса, особенно если он не безотмывочный. Не это не то, 2 разных платки от разных продаванов с чуть разными компонентами, работали с hse нормально относительно, иногда глючило, но когда я начал имеено на 2х проверять, одна работает другая нет, на 3ей контрольной работает, помыл ту что глючила, вроде норм стало, но потом опять начало, ваще rtc не трогал, чтото там в районе http менял, а оно не инициализируется, сижу туплю, а оно хренак и заработало, 94 секунды инициализации rtc, да офигеть, еще чтото поменял 180 стало. но до того работало же, 1-2 секунды подтупливало, но не больше, менялась только прошивка, может компилятор лишка оптимизировал, да вроде все отрубленно, очень странная история. > Увы, не любят програмеры документацию писать делал не так давно к api dns хостинга обвязку, а то старая на html завязанная сломалась после обновления сайта, два дня убил, эти обезьянки как-то сделали, что когда в xml меняешь теги одного уровня местами оно не работает, пришлось делать чтобы буква в бутву, пробел в пробел, а там дока в пдф кривая и перекошенная с корявыми шрифтами, уф, как будто в бочку с го-ом нырнул, пара месяцев прошла 100% срабатывание. > Там в нормальном виде наверное скорее на книжку потянет Да есть такие видеоуроки, пол ютуба, как раз запустите-тыкнете-кнопочку-эту-ту-подвяжите-либу-и-вот-готово. Возможно в части переферии это адекватно, но в моем кейсе - завести это на чистом линуксе без всякой гуятины, инфы очень мало и квик старта не хватает. Я бы поробовал RTOS, но даже начинать боюсь. Скажем копмиляция ядра линукса, конфетка, хочешь гуи, хочешь тоже самое в консоле, хочешь в тексте, поиск адекватный, найти модуль посмотреть зависимости включить, у бизибокса примерно тоже. А у rtosa это все гуятина заполняет по каким-то неявным критериям, и вытыкивать их у меня нет желания, покрайней мере так я понял из обзора.
	Ответить | Правка | Наверх | Cообщить модератору

	152. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
	Сообщение от Аноним (-), 04-Июн-20, 04:03
	> Там gd, GD32F? Какой именно? Я посматривал на них, но купить пока не сподвигся, увы. > пробовал все комбинации, мигает светодиодиком тестовым и все, прозванивал мультиком > цепи этих джамперов - все ровно так как на оригинальных. Значит в boot не попадает. Для бута обычно boot0=1, boot1=0, но лучше по даташиту уточнить. >> Не согласен. Я по ним научился инициализировать чип и работать с железками > CMSIS ? И даже bare metal (==только мой код). Если я смог с ноля проинитить и поработать с железками по формальному описанию, наверное оно ОК. Да, объемистое. > Мб. Мне так глубоко не надо, я остановился на SPL. А я так по жизни хочу сунуться в некоторые странные места между железом и софтом, попробовав там странные вещи. Для некоторых из этих приключений я предпочту быть с чипом "на ты" и хорошо понимать что и почему он делает. А еще мне любопытно, насколько я готов доверить свою тушку своему коду. > Вероятно это очень глупо, но ничего другого я не нашел, а spl > документирован довольно так себе, Вот собственно этим мне такие штуки и не нравятся. Возможно я олдскульный, или типа того, но мне было интересно можно ли их прогать на манер штук типа AVR (не путать с ардуино) когда мы просто идем и просто делаем что хотели, по описанию железок. Без кучи чьих-то там либ делающих хрен бы его знает что. > По сути за 10 месяцев с монента появления первого образца проект нарисовался, > на git, cmake и gcc-eabi под чистым линуксом. Я тоже все под линухом делаю. И некий самопал для себя юзает make и baremetal. Конечно без gcc и гита не обошлось. > "проприетарного компилера" это который gcc-arm-none-eabi-9-2020-q2-update-x86_64-linux DiHalt в основном маздаец и это было для какого-то виндового проприетарного компилера. На предмет того как чип вообще на самом деле работает и чего надо сделать (минимаьлно - включить клок GPIO порта и ставить/сбрасывать биты его BSRx/BSRRx). Но идея понятна и я когда-то для начала повторил с GCC, а потом и еще навернул. > Ну это такое, 100р примлемая цена, чтобы запихать в каждый "выключатель", f4 > уже избыточен, а потом связываем с x86, родной и хорошо знакомой. таков мой кейс. Если говорить об одной из хотелок для лично себя, у меня задумано примерно два уровня, МК на нижнем уровне и одноплатники с линем на верхнем. > А я на алике ))) Ну вот это напрасно - там никогда не знаешь что подсунут. А осваивать незнакомый чип не будучи уверенным в нем - жестковато. В том плане что отличать свои глюки от глюков чипа все же хорошая идея. > В W5500, вот их много встречал, А, в этих. Вариант наверное, не имел с ними дел особо. > Ну да, я поэтому и остановился на почти самом примитивном чипе, на > самом примитивном из 32 бит, Лично мне они нужны как интерфейс к физическому миру и жесткий реалтайм. Это не обязательно подразумевает тонны сложной математики или чего там еще. Покрутить вон тот шаговик - это о формировании времянок. А зачем там куча RAM и флеша? > Это был критерий выбора. Ну я нахожу его удобным - у меня есть куча этого добра. Тем более что потом туда можно прицепиться терминалкой и ругаться отладочными сообщениями. Можно трекать flow фирмвары не очень мешая ей работать в реальном времени. > он мне, за 3 то дорого, там компонентов рублей на 500, экран еще рублей 200-300. Есть кстати несколько самодельных осцилов, см на радиокоте допустим. Вот туда кстати более жирное типа F3/F4 уже имеет некий смысл. Для "медленных" сигналов катит даже звуковуха (с небольшим довеском). И для чисто цифровых вещех осцил не настолько уж и сильно нужен во многих случаях. Тем более что безбашенно им ткнуться абы куда, например в кварц опять же не выйдет (это как раз и сорвет генерацию). > через сколькото лет выходит тоже самое только частично платное, и с > кучей ограничений и теперь в каждом чайнике, да офигеть. Ну просто иногда так бывает что народу заходит какая-то странная и кривая фигня, о чем изначально никогда бы не подумал. > Так правильнее ИМХО )) Пожалуй. > за 300р и кучу убитого времени, а бонусом пойдет понимание че-как, > и я его собрал, и сейчас обдумываю стоит ли оно все того. Экспериенс вполне может стоить того. А возможность делать себе (и не только) кастомные железки по-моему все же прикольно. Хоть и далеко не самое простое начинание. > Вообще я думаю 20/80, Если что-то такое интересно, стоит почитать про подходы повышения надежности управляющих систем. Вон в новости про тройное резервирование. Пойнт в том что они считают одинаково и все трое шлют команду. Если все одинаковые, выполняем. Если не совпадают, можно определить кто из трех сглючил и перезапустить/отключить, выполнив команду одинаковую для 2 из 3 систем. Но это ближе к полетам в космос и прочим откровенно опасным применениям, когда сбой приводит к крупным проблемам. У того же ST есть гайды как улучшить надежность фирмвари в дурацких ситуациях в пределах 1 чипа. > функцию стремящуюся к нулю, ну а дальше арифметика расскажет, где надо > остановиться чтобы не уйти в минус. В очень критичных системах делают 3 одинаковых и выбор 2 из 3. А закольцевать проверку на себя - это моя идея. Люблю неожиданные решения для "нерешаемых" проблем. > Не это не то, 2 разных платки от разных продаванов с чуть > разными компонентами, работали с hse нормально относительно, иногда глючило, Там много всего может быть не так. Может быть клон STM кривой, может быть разводка платы неудачная (китайцы великие копапастеры а не великие разработчики), может кварцы хреновые. Грубо говоря у вас стартовый рецепт содержит ряд неопределенностей, их довольно много и это делает понимание проблемы не совсем простой. Собственно это может быть аргументом за покупку девборда с оригинальным чипом, от кого-то из фирм известных разработками плат, которые откровенный фуфел не гонят. А кот когда есть уверенность что код работает ОК, можно сделать плату самому или поюзать что-то более подозрительное. Тогда станет понятнее где косяк. В общем проблемы намного удобнее заруливать по 1. А не когда сразу клубок из дюжины возможных причин. > и заработало, 94 секунды инициализации rtc, да офигеть, еще чтото поменял > 180 стало. но до того работало же, 1-2 секунды подтупливало, но > не больше, менялась только прошивка, может компилятор лишка оптимизировал, да вроде > все отрубленно, очень странная история. RTC как таковой имеет право медленно стартовать, но при комнатной температуре это обычно "несколько секунд". При минусах даже у STMicro с тем кварцем что у них они замеряли время старта 120 секунд. В кварцевых генераторах колебания нарастают медленно. В эн мегагерц - несколько миллисекунд (по меркам микроконтроллеров это заметно). А 32768 типично секунды. Его обычно запускают 1 раз при powerup системы - а при reset'ах он продолжает тикать и хранить время, в чем и есть половина смысла. У части чипов даже есть отдельный Vbat для батарейки питающей RTC когда остальной чип выключен, чтобы время не слетало и тикало. > Возможно в части переферии это адекватно, но в моем кейсе - завести > это на чистом линуксе без всякой гуятины, инфы очень мало и квик старта не хватает. Да, и собственно поэтому я однажды и сделал себе нечто странное, просто makefiles и baremetal без всяких либ. С минимумом допущений и требований. С cmsis так тоже можно собирать, самому по себе gcc не так уж интересно что за код. И таки я стал с GCC на ты. Вплоть до понимания как скомпоновать конкретный формат бинарника и объяснить линкеру свои пожелания. Фирмвара - бинарь в нестандартном формате. Поэтому без гламурных гуев потребуется познакомиться с линкерскриптом, объясняющим компилеру где какая память и как это размещать в секциях. Но там ничего ужасного. И есть ряд готовых примеров, собственно. А так - ну вот я никакие мега IDE и не использую. Geany вообще к микроконтроллерам не относится, что не мешает ему редактировать файлы и пинать make. > Скажем копмиляция ядра линукса, конфетка, хочешь гуи, хочешь тоже самое в консоле, Да, их система конфигурации мне нравится. Хотя опять же когда заходит именно вопрос о сборке, там не все так просто. Процесс линковки ядра нифига не простой (т.к. нестандартная структура бинаря), сменить флаги компилеру в произвольном виде тоже не совсем удобно. При том у ядра даже сложнее чем фирмваре, из-за формирования на ходу бинарных "шапок" типа PE-файла, претендующего что это "EFI Stub", декомпрессора "до ядра" и проч. Я так сбилдовал хренову кучу кернелов, включая кросскомпил для одноплатников, не говоря о десктопных. > хочешь в тексте, поиск адекватный, найти модуль посмотреть зависимости включить, у > бизибокса примерно тоже. А у rtosa это все гуятина заполняет по > каким-то неявным критериям, и вытыкивать их у меня нет желания, покрайней > мере так я понял из обзора. Я в ртосы предпочел не лазить, мне от МК столько не надо. Да, я при этом упускаю некое направление - но мне IMHO хватит иных вариантов.
	Ответить | Правка | Наверх | Cообщить модератору

	153. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
	Сообщение от с (?), 04-Июн-20, 10:09
	> GD32F? Какой именно? https://ibb.co/B2SqR6c это не gd, я видимо хотел купить, но решил не заморачиваться и не распаляться. https://ibb.co/2ZWfvD8 а это весь парк, почти, справа не оригиналы, фото одного выше, а второй не смог нормально сфотать, там еле видно. но в целом, если считать остальные оригиналами, а нет никаких оснований этого не делать, они работают идентично, хотя есть особенности, но после организации земли не заметно. да, я сдуру купил у продована 10 шт, а они оказались теми самыми кривыми репликами, поэтому потом по 2 брал много у кого, 3 раза были косяки, но предьявить нечего, на странице 100 раз написанно stm, а на 101 что реплика, и все привет, но в целом не пробема, у нормальных магазинов есть и то и то, оригиналы чуть дороже. на черном текстолите не видел клонов, и пайка лучше, на синем бывало кнопочка отваливалась по дороге и кондеры некоторые очень криво напаяны. > Значит в boot не попадает. не попадает, но ноги я звонил, все ровно, резистор на 10к в порядке, конечно мультик у меня не для смд, но блин, на оригиналах все точно так же. > И даже bare metal я так понял что это и есть cmsis BSRRx, это оттуда. ну собственно этот цмсис это самый нижний уровень, там вся тарабарщена задефайнена, а спл попытка ее в человеко читаемый вид превести, но не удачная, потому что с документацией у стм вышел фейл, потом был хал, тоже не особо, а потом ртос, но он тяжеловат, и вот сейчас проде появилось чтото новое, как спл, но совместимое с ртос, я мельком глянул, там и есть ртос, но в осномном заглушки и типа пользовательский код здесь, нафиг не хочу, опять непонятными блокнотиками связываться. > А я так по жизни хочу сунуться в некоторые странные места я уже совался, особо ничего интесного, впрочем, не скажу что сильно пригодилось, но и не скажу что зря. думаю со временем сделают, чтото что будет дешево и без заморочек особых, так что большого смысла нет, но уровень диванного аналитика, погрешность пляс минус 50 процентов. > Без кучи чьих-то там либ делающих хрен бы его знает что. а спл тем и хорош, его очень просто выпилить, и остаться на голых регистрах. >> По сути за 10 месяцев с монента появления первого образца проект нарисовался, >> на git, cmake и gcc-eabi под чистым линуксом. > Я тоже все под линухом делаю. И некий самопал для себя юзает > make и baremetal. Конечно без gcc и гита не обошлось. > DiHalt в основном маздаец ну в теории реверс инжениринг, берем среду любую она скорее всего юзает дефолтный гцц от арм, вместо гцц хреначим скрипты которые логирую параметры запуска, и выясняем что запускается и как, но не заморочно это. > примерно два уровня, МК на нижнем уровне и одноплатники с линем на верхнем. Ну да на линукс чистый завернуть с 386 я не точно выразился >> А я на алике ))) > Ну вот это напрасно - там никогда не знаешь что подсунут. нормально там все, главное у явных леваков не брать, а так как на любов базаре. >> В W5500, вот их много встречал, > А, в этих. Вариант наверное, не имел с ними дел особо. очень высокоуровневые, много чего нельзя, но я брал их разчета, как можно проще. > Лично мне они нужны как интерфейс к физическому миру вот оно и есть, я еще с ком портом пытался играться, но там печально все в начале 00, а тут работу поменял и время позволяет и по работе надо, точнее было бы не плохо, так то никто не требует. решил вот позамиматься. > Есть кстати несколько самодельных осцилов, я самый примитивный и взял, pwm нормально смотреть, а профессиональные, которые spi сниффирятмогу конечно, но смысла не вижу, я не собираюсь профессионально этим заниматься. > Если что-то такое интересно, стоит почитать про подходы повышения надежности управляющих это курс отдельный, я его слушал, но ничерта не поню, какието схемы рисовали.. > Вон в новости про тройное резервирование. ну это сомнительно, если честно, все равно есть точка отказа, коммутатор, или тот мк. > В очень критичных системах делают 3 одинаковых и выбор 2 из 3. это cepf, первая ассоциация, хорошая штука. > Там много всего может быть не так. Может быть клон STM кривой, ну опять же, код rtc не меняется, меняется сильно потом, уже в главном цикле, а то работает, то нет, не думаю что аппаратное, если вме выпилить то чисто rtc работает нормально. > RTC как таковой имеет право медленно стартовать да и с ресета нормально пашет, и иногда помогало пальцем на кварц прикоснуться, не на землю, а именно пальцем, я потом еще везде пытался пощамыкать, но только с пальца заводилось)) > У части чипов даже есть отдельный Vbat для батарейки питающей RTC это знаю, я ноги изучил и даташит прочел по диагонали. > И таки я стал с GCC на ты. а я давно перестал, щас тыкался много нового появилось. > Да, их система конфигурации мне нравится. Хотя опять же когда заходит именно > вопрос о сборке, там не все так просто. Процесс линковки ядра > Я в ртосы предпочел не лазить, мне от МК столько не надо. да, если бы гарантировали уровень ядра линукса то было бы огонь, а так, тонко надо переписывать самому, и смысла нет
	Ответить | Правка | К родителю #152 | Наверх | Cообщить модератору

	154. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
	Сообщение от Аноним (-), 07-Июн-20, 17:58
	> https://ibb.co/B2SqR6c Это не GD. Какой-то "CS". У клонов _бывают_ отличия, надо смотреть даташиты. > это не gd, я видимо хотел купить, но решил не заморачиваться и не распаляться. Да. GD были первыми кто это придумал, подошли к сдиранию качественно и вот у них AFAIK совместимость довольно приличная. А у остальных варьируется. Финальное слово за даташитом. > https://ibb.co/2ZWfvD8 Маркировку не видно... > не делать, они работают идентично, хотя есть особенности, но после организации земли не заметно. И да, кварцы там китайцы раскидали абы как, первое что им в бошку пришло. Гайд от STMicro они не читали, кой-как нарисовали и скорее на алиэкспресс продавать. Это так по китайски... > в целом не пробема, у нормальных магазинов есть и то и то, оригиналы чуть дороже. Просто я не в курсе всех клонов и понятия не имею насколько они отличаются. То что китайса мамой клянеся что клона касяственая - ничего не значит, кроме желания продать. > не попадает, но ноги я звонил, все ровно, резистор на 10к в > порядке, конечно мультик у меня не для смд, но блин, на оригиналах все точно так же. Тогда возможно клон в этом отличается или у него вообще не прошит бут, мало ли. У STMicro его шьют в отдельный регион (System Memory), рядом с option bytes и инфо о чипе, а чего делают китайцы - зависит от. GD вроде достаточно точно клонировал особенности, но я даже его палочкой пока не тыкал. Если вы видали Linux kernel и их дрова, и встречали историю про FTDI проучившую клоны под виндой своим драйвером то сможете понять юмор с одним первоапрельским патчем, заимплементившим для линя саботаж FTDI клонов так же как виндовый. Конечно его не комитили, это прогеры прикололись, линуху то пофиг и он и с клонами работает, а вот в винде с некоего момента эмбедеры выкусили горя, узнав что в их кабеле был клон. >> И даже bare metal > я так понял что это и есть cmsis BSRRx, это оттуда. Один из регистров GPIO порта, выставляет или сбрасывает биты порта. Сам по себе - "адрес в памяти". Помигать светодиодом это он. CMSIS - определяет регистры и т.п.. Я просто для себя сделал с ноля определения, макросы и функции - идея чем-то похожа, но реализация 100% моя, с ноля. Вплоть до стартапа. Адреса регистров из даташита, конечно. И да, это канительно и было больше для экспериментов и понимания. Впрочем, не помешало допинать до нескольких реально примененных фирмварин. > ну собственно этот цмсис это самый нижний уровень, там вся тарабарщена задефайнена, А мне как-то стало интересно - могу ли я что-то подобной отгрохать сам =). Заодно познакомился с компилером и чипом "на ты". > удачная, потому что с документацией у стм вышел фейл, потом был хал, тоже не особо, На мое мнение у STM 1) Хорошее железо и доки на него. 2) CMSIS 50/50. 3) Всякие кубы и проч наводят на меня ужас =) > блокнотиками связываться. Ну вот я и не связывался, и однажды нежелание иметь дело с непонятными чужими штуками завело меня довольно далеко - когда я сделал абсолютно все сам. > но и не скажу что зря. Я думаю что мне пригодится. Уже периодически пригождается, впрочем самые интересные и сложные штуки еще впереди. > а спл тем и хорош, его очень просто выпилить, и остаться на голых регистрах. Может быть. Просто для того что я на самом деле хочу, один черт надо хорошее понимание чипа, т.к. некоторые будут весьма плотным программно-аппаратным взаимодействием, при том без права на ошибку. > дефолтный гцц от арм, вместо гцц хреначим скрипты которые логирую параметры > запуска, и выясняем что запускается и как, но не заморочно это. Можно найти линкерскрипты и т.п. + некоторое инфо в гугле. Так что на практике работает, я себе линкерскрипт и командлайны скроил. Постепенно сделав довольно продвинутые вещи типа LTO+GC sections, так небось половина и не умеет, а процентов 20-30 кода "испаряется" без каких либо потерь. > Ну да на линукс чистый завернуть с 386 я не точно выразился Я умею в одноплатники на ARM, запиливая под это небольшие и аккуратные дебианы, оптимизнутые под задачу. > нормально там все, главное у явных леваков не брать, а так как на любов базаре. Вот поэтому я и предпочитаю брать STшки у нормальных поставщиков. Чесать репу мои это глюки или непонятного клона все же не хочется. > очень высокоуровневые, много чего нельзя, но я брал их разчета, как можно проще. Ну с ними я не работал. Я скорее приделаю STM'а на UART/SPI/I2C одноплатника и из тамошнего линя с ним побеседую. Ну да, придется какую-то прогу - "гейт" на одноплатнике развесить. > я самый примитивный и взял, pwm нормально смотреть, а профессиональные, которые spi > сниффирятмогу конечно, но смысла не вижу, я не собираюсь профессионально этим заниматься. Если мне spi приспичит снифать, я туда имхо МК с простой фирмварью отправлю, который мне выбросит что наснифал в понимаемом мной под линем формате :) > это курс отдельный, я его слушал, но ничерта не поню, какието схемы рисовали.. У stmicro отдельный апнот есть на тему. И тут вопрос в том надо ли оно? Если да - ну, прочитаете апнот. А не надо - так и болт с ним. Не все в космос летят или рулят чем-то опасным и вопрос в том насколько плох взглюк железки. > ну это сомнительно, если честно, все равно есть точка отказа, коммутатор, или тот мк. И тем не менее, самые сложные и наиболее сбоящие компоненты - проверяются. И даже с арбитрами до некоторой степени решаемо. > ну опять же, код rtc не меняется, меняется сильно потом, уже в > главном цикле, а то работает, то нет, не думаю что аппаратное, > если вме выпилить то чисто rtc работает нормально. RTC оперирует токами единицы микроампер. Поэтому любые утечки типа китайского флюса могут вызвать проблемы. По тем же причинам нарастание колебаний нифига не моментальное. А наводки с соседних дорожек или дурно сделаной земли весьма фатальны. У ST опять же есть мануалы на тему рекомендуемых кварцев и проч, но что китайцы их читали - не похоже. Иначе они не стали бы 32768 так далеко от проца ставить. > да и с ресета нормально пашет, и иногда помогало пальцем на кварц > прикоснуться, не на землю, а именно пальцем, я потом еще везде > пытался пощамыкать, но только с пальца заводилось)) Колебания не нарастают или очень медленно нарастают походу. И да, осциллом такое мониторить малореально: щуп имеет свойство убивать колебания наповал. Ну вот деликатная штука эти цепи RTC, потому что задуманы работать от мелкой батареечки годами - используют минимум энергии. > это знаю, я ноги изучил и даташит прочел по диагонали. Ну вот он для этого - можно все вырубить а RTC останется и будет какие-то микроамперы кушать, так что какого-нибудь CR2032 ему хватит на дофига лет. > а я давно перестал, щас тыкался много нового появилось. Основы все остались прежними. А новое - ну да, местами есть, но ничего эдакого вроде. > да, если бы гарантировали уровень ядра линукса то было бы огонь, Вообще на старших H7 даже портанули линух. Но смысл в таком комбо ... понятен тому кто его портировал :)
	Ответить | Правка | К родителю #153 | Наверх | Cообщить модератору

	52. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
	Сообщение от Lex (??), 27-Май-20, 15:48
	В теории, знаковые и беззнаковые должны были всем упростить жизнь и сделать её лучше.. по крайней мере, так казалось на заре подобного типизированного подхода... А теперь - воистину какой-то дурацкий цирк и дырявая абстракция со всеми этими интами-юинтами-8-16-32-64-итп
	Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

	62. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
	Сообщение от Аноним (61), 27-Май-20, 16:52
	Всему виной дебильные правила неявного приведения. При том что typecast в uin32_t можно сделать и на void* по недосмотру(попутав переменные), во весело потом.
	Ответить | Правка | Наверх | Cообщить модератору

	95. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
	Сообщение от Аноним (95), 27-Май-20, 21:55
	> typecast в uin32_t можно сделать и на void* по недосмотру Давно уже такое не позволяется ни гнутыми сями ни шлангом. Нужен промежуточный каст в (u)intptr_t
	Ответить | Правка | Наверх | Cообщить модератору

	100. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+1 +/–
	Сообщение от Forth (ok), 28-Май-20, 00:42
	Может я что не так понимаю? Ну ладно, вот такое сделаем в одну сторону и в другую:                                                                                                                                                                                                                                      #include <stdio.h> #include <stdlib.h> #include <stdint.h> int main(void) {   uint64_t i = 1;   void *p;   p = (void*) i;   printf("%s", (char*) p);   i = (uint64_t) p;   printf("%ld", i);   return 0; } gcc -g -Wall -Wextra -Wpedantic -O3 -std=c99 test.c ./a.out Segmentation fault (core dumped) P.S. gcc version 9.3.0 Дефолтные флаги (gcc test.c) конечно тоже молчит как партизан. uint64_t ессно потому, что процессор 64 битный.
	Ответить | Правка | Наверх | Cообщить модератору

	103. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
	Сообщение от Аноним (95), 28-Май-20, 02:13
	> Ну ладно, вот такое сделаем в одну сторону и в другую: Это потому что у тебя размер int-а увеличен по сравнению с условием (uint32_t). Последний в void * на 64-битной машине не скастится.
	Ответить | Правка | Наверх | Cообщить модератору

	106. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
	Сообщение от Forth (ok), 28-Май-20, 08:35
	Это у меня под рукой не было компилятора для 32 битной системы. Я-то думал это и так очевидно и можно на примере uin64_t показать. Но это же opennet, тут надо разжевывать. Ладно, вот 32 бита: #include <stdio.h> #include <stdlib.h> #include <stdint.h> int main(void) {   uint32_t i = 1;   void *p;   p = (void*) i;   printf("%s", (char*) p);   i = (uint32_t) p;   printf("%d", i);   return 0; } Выдачи от gcc ожидаемо нет: $CC -g -Wall -Wextra -Wpedantic -O3 -std=c99 test.c Здесь $CC это: arm-phytec-linux-gnueabi-gcc (GCC) 7.3.0
	Ответить | Правка | Наверх | Cообщить модератору

	110. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
	Сообщение от Аноним (95), 28-Май-20, 14:52
	> Это у меня под рукой не было компилятора для 32 битной системы. Use -m32, Luke > Но это же opennet, тут надо разжевывать. Но это же opennet, тут не принято дочитывать то, на что отвечаешь. Это про: >> Последний в void * на 64-битной машине не скастится.
	Ответить | Правка | Наверх | Cообщить модератору

	31. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	–1 +/–
	Сообщение от Z (??), 27-Май-20, 13:52
	Использование int это Unix style :)
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	33. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
	Сообщение от 1 (??), 27-Май-20, 14:09
	неа - тут ты неправ
	Ответить | Правка | Наверх | Cообщить модератору

	35. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+1 +/–
	Сообщение от Аноним (-), 27-Май-20, 14:12
	Это C89 античный. И это грабли - потому что на разных железках размер int не гарантирован одинаковым. Это создает поле для багов.
	Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

	53. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+2 +/–
	Сообщение от Lex (??), 27-Май-20, 15:51
	По большому счету, у него вообще не должно быть «размера». А то, это уже какой-то byte/word/dword/итп, а не типо_абстракция_для_высокоуровневого_языка
	Ответить | Правка | Наверх | Cообщить модератору

	63. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
	Сообщение от Аноним (61), 27-Май-20, 16:54
	C и не является языком высокого уровня. Проходит по категории среднего.
	Ответить | Правка | Наверх | Cообщить модератору

	67. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	–2 +/–
	Сообщение от Аноним (64), 27-Май-20, 17:27
	> C и не является языком высокого уровня. Проходит по категории среднего. Он разный. Вон libcello показывает как из него слепить нечто довольно высокоуровневое. Если оно зачем-то надо. Некоторые на нем умудряются объекты наворачивать. Хоть их изначально там и нет.
	Ответить | Правка | Наверх | Cообщить модератору

	83. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+1 +/–
	Сообщение от Аноним84701 (ok), 27-Май-20, 19:31
	>> C и не является языком высокого уровня. Проходит по категории среднего. > Он разный. Вон libcello показывает как из него слепить нечто довольно высокоуровневое. > Если оно зачем-то надо. Некоторые на нем умудряются объекты наворачивать. Хоть > их изначально там и нет. Э-э-э, я вас расстрою, но возможность с помощью костыле и подпорок придать похожий вид - ну совершенно не показатель "высокоуровневости": while GetMessage(ADDR msg, 0,0,0) .if !TranslateAccelerator(hwnd, hAccel, ADDR msg)     invoke TranslateMessage, ADDR msg     invoke DispatchMessage, ADDR msg .endif .endw ...    CLASS CSprite       CMETHOD destructor       CMETHOD setBitmap    ; sets bitmap for sprite       CMETHOD move     ; move sprite ...       yPos   dd  ?       speed   dd  ?    CSprite ENDS LOCAL TempRect:RECT invoke GetClientRect, hWnd, ADDR TempRect xor  ebx, ebx .WHILE ebx < MAX_SMILIES   newobject CSprite ...   method esi, CSprite, setBitmap, eax Это древний MASM, если что. Возможность наколхозить макросами "типа OOP", функц. вызовы и прочее - и близко не дает поддержку на уровне компилятора соотв. ЯП (тех же проверок синтаксиса, семантики и особенно нормальных сообщений об ошибках).
	Ответить | Правка | Наверх | Cообщить модератору

	116. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
	Сообщение от Аноним (116), 28-Май-20, 17:01
	> похожий вид - ну совершенно не показатель "высокоуровневости": Если можно глушить высокоуровневыми примитивами - это показатель высокоуровневости, очевидно. > >   method esi, CSprite, setBitmap, eax ... > > Это древний MASM, если что. Да, из ассемблера можно сделать что угодно. Более того - в конечном итоге любая программа будет потоком инструкций для проца. Представимым как ассемблер, стало быть. > Возможность наколхозить макросами "типа OOP", функц. вызовы и прочее - и близко > не дает поддержку на уровне компилятора соотв. ЯП (тех же проверок > синтаксиса, семантики и особенно нормальных сообщений об ошибках). Все это вообще совсем другой вопрос, не имеющий отношения к уровневости языка как такового. И это, у совсем высокоуровневых с диагностикой как раз полный швах, пихоны и явыскрипты валятся в runtime, чем немало задалбывают. Потому что вместо прогера это все валится сразу юзерям на бошку.
	Ответить | Правка | Наверх | Cообщить модератору

	66. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
	Сообщение от Аноним (64), 27-Май-20, 17:26
	> По большому счету, у него вообще не должно быть «размера». Офигенно. До тех пор пока не захочется - Сделать что-то с данными в памяти. - Сохранить это в файл. - Передать это по сети. ...и чтоб с другой стороны еще и поняли что именно им передали, например?! И желательно не в ламерском вебмакачном представлении когда число 100500 занимает цуко 6 байтов хотя реально лезет в 3. А, ну да, правильные парни используют конские либы сериализации или плачутся как это трудно, да? :) > А то, это уже какой-то byte/word/dword/итп, а не типо_абстракция_для_высокоуровневого_языка Си хорош тем что позволяет залезать в довольно низкоуровневые дела. Один из немногих ЯП который смог подвинуть асм в глубоко системных вещах. И в этом плане - ну вот есть у вон той железки допустим регистр. И он 16 битов. Потуги обращаться к нему с другими порциями - ни к чему хорошему не ведут. И очень хорошо что можно задекларить сие как uint16_t, допустим.
	Ответить | Правка | К родителю #53 | Наверх | Cообщить модератору

	86. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	–1 +/–
	Сообщение от Lex (??), 27-Май-20, 20:14
	И... что ? Без какого-либо стандарта передачи данных, на другом конце всё равно не поймут, хоть запередавайся. Такое «оправдание» откровенно дырявой абстракции - даже хуже вебмакакства. Если речь о работе с числами, то совершенно очевидно, что работать оно должно ожидаемо, а не черти как.. и всё из-за того, что «силой гения высоколобых умников нельзя просто взять и работать с числами». В конечном счёте это, скорее всего, упирается ни в какие не в размеры( слыхал что-нибудь о выравнивании, на котором прямо сейчас, скорее всего, гораздо больше памяти тратится ), а в оптимизации вычислений, т.к 64-битной машине считать 32-битные числа будет таки ощутимо проще, чем 8-битному «процу». Вот отсюда, скорее всего, и растут ноги сего цирка с числами. п.с: кстати о размере.. интересно, а у строк тоже ограничение на размер - 8/16/32/64 байта или, всё-таки, нет и, тем не менее, на другом конце их при передаче отлично «понимают» ?)
	Ответить | Правка | Наверх | Cообщить модератору

	117. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
	Сообщение от Аноним (-), 28-Май-20, 17:13
	> И... что ? И - то. Абстрактный int - совсем не то же что uint32_t. Когда у меня есть последний - я точно знаю что он может быть передан как 4 байта (в провод, воздух, файл, ...). А когда это int - вот тут уже большой вопрос как это передавать, как понять сколько это займет, ... > Без какого-либо стандарта передачи данных, на другом конце всё равно не поймут, > хоть запередавайся. Да блин, с int неизвестного размера вы даже прочитать записанный собой же файл так с наскока не сможете - а откуда вы знаете где этот int заканчивается? Есть некоторые variable-length кодировки integer'ов, но они как раз "транспортные" и неэффективны на тему применения математики сразу к этому представлению процом. > Такое «оправдание» откровенно дырявой абстракции - даже хуже вебмакакства. Глядя на то как электроны выжирают ресурсы - я что-то не уверен. > Если речь о работе с числами, то совершенно очевидно, что работать оно > должно ожидаемо, а не черти как.. и всё из-за того, что > «силой гения высоколобых умников нельзя просто взять и работать с числами». Ну и вот uint32_t по сравнению с int хрен знает какого размера - это вот как раз в эту сторону шаги. Так мы по крайней мере знаем сколько в этот тип лезет и можем осмысленно состыковывать это с теми данные которые жуем. А если это int какой-то, который на вон той системе еще и не столько, а столько - упс. > размеры( слыхал что-нибудь о выравнивании, на котором прямо сейчас, скорее всего, > гораздо больше памяти тратится ) Походу, вебмакака взялась учить системщика его ремеслу... ну-ну, удачи. > машине считать 32-битные числа будет таки ощутимо проще, чем 8-битному «процу». > Вот отсюда, скорее всего, и растут ноги сего цирка с числами. Да никакой оно не цирк, сама по себе работа с числами более-менее в духе того что проц реально делает. А то что оно может быть по разному - и делает сие undefined. > п.с: кстати о размере.. интересно, а у строк тоже ограничение на размер > - 8/16/32/64 байта или, всё-таки, нет и, тем не менее, на > другом конце их при передаче отлично «понимают» ?) В сях условились что байт равный нулю - завершает строку. Спорный вопрос хорошо ли это, да и всегда можно завести свой тип, где допустим длина явно указана. Но сисколы и проч хотят вот такое. В этом месте вебмакаки кажется начинают догадываться, что парсинг строк далеко не самое эффективное занятие на свете. А потом приходит гугл, берет БОЛЬШОЙ тапок и объявляет: извините. ребята, но мы заколебались платить за сервера и трафик. Поэтому HTTP/2 будет бинарным, и ниипет.
	Ответить | Правка | Наверх | Cообщить модератору

	76. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	–1 +/–
	Сообщение от Ordu (ok), 27-Май-20, 18:07
	> На кой вообще было использовать знаковый тип для номеров системных вызовов? Потому что без разницы. > В случае беззнакового, при -1 была бы попытка вызвать самый последний из возможных. В случае беззнакового не было бы -1, был бы 0xff...ff, и он был бы явно недопустимым. Вопрос в другом, почему не выполнить проверку? Ты получаешь данные извне, им заведомо нельзя верить, должна автоматически включаться паранойя, и она должна заставлять продумать вообще все возможные и даже невозможные варианты, и они все должны быть покрыты проверками.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

2. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+1 +/–
Сообщение от ryoken (ok), 27-Май-20, 10:52
>> Примечательно, что среди ключевых достоинств Zephyr упоминается разработка с оглядкой на безопасность. Утверждается, что все стадии разработки проходят обязательные этапы подтверждения безопасности кода: fuzzing-тестирование, статический анализ, испытания на проникновение, рецензирование кода, анализ внедрения бэкдоров и моделирование угроз. ну ага
Ответить | Правка | Наверх | Cообщить модератору

	5. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	–2 +/–
	Сообщение от Аноним (5), 27-Май-20, 11:08
	25 - неплохое число уязвимостей для Целой Операционной Системы. Давай сравним это число с количеством уязвимостей в любой другой оси? Например, операционной системы GNU/Linux (начиная с ядра и заканчивая калькуляторами).
	Ответить | Правка | Наверх | Cообщить модератору

	8. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+5 +/–
	Сообщение от Аноним (8), 27-Май-20, 11:14
	А в Zephyr есть калькулятор? А то будет не очень честное сравнение.
	Ответить | Правка | Наверх | Cообщить модератору

	37. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	–1 +/–
	Сообщение от Аноним (-), 27-Май-20, 14:14
	> не помогли, вопреки наставлениям местных диванных экспертов Ну ты то покажешь как пихтонрасты операционки и прошивки микроконтроллеров кодят? А то вон написали redox, так он походу даже реактос обогнал по степени [не]нужности.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	79. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
	Сообщение от anonymous (??), 27-Май-20, 18:43
	А что мешает rust для МК использовать?
	Ответить | Правка | Наверх | Cообщить модератору

	119. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
	Сообщение от Аноним (119), 28-Май-20, 18:06
	> А что мешает rust для МК использовать? Его навороченность как-то совершенно не внушает в этом случае. Лично я хочу в МК максимально простое и понятное мне окружение, в идеале где я понимаю каждый битик. На сях я так могу. Вплоть до отсутствия стартап-кода и либ и взлета чипа целиком моим кодом (чсх сишным, без асма). А нафига? Чтобы оно было максимально предсказуемое и надежное, разумеется.
	Ответить | Правка | Наверх | Cообщить модератору

	132. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
	Сообщение от Вебмакака (?), 29-Май-20, 00:15
	Юзер314 это ты? Стек чем на С без ассемблера настраиваешь, или на полшишечки не считается?
	Ответить | Правка | Наверх | Cообщить модератору

	136. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
	Сообщение от Аноним (136), 29-Май-20, 18:22
	> Юзер314 это ты? Стек чем на С без ассемблера настраиваешь, Cortex-M можно застартить вообще совсем без асма. Я проверял. Там в таблице векторов 0-е смещение - адрес стэка. При power up проц сам это вгружает в SP. Более того, как оказалось, null pointer в ARM очень не любят и если попытаться это прочитать - Cortex M такой клевый hard fault в репу сразу дает %). Это, кажется, единственный случай когда мне hard fault выпал не в тестовых целях а как результат моего програмизма, немало меня удивив. > или на полшишечки не считается? На Cortex M3 теоретиески можно и без полшишечки. Но... 1) Я не знаю как при bootload полностью корректно выполнить handover не потеряв немного стэка без чего-то типа mov SP, r3. 2) Глобальное разрешение/запрет IRQ делается таки тоже регистром который не mmaped. Можно включать выключать все irq на уровне периферии через mmaped регистры, но это дольше и вообще изврат.
	Ответить | Правка | Наверх | Cообщить модератору

	141. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
	Сообщение от Forth (ok), 29-Май-20, 19:23
	1) Использование предоставленных производителем платформы средств типа armlib (__user_setup_stackheap() например) . Ну да, там сделают mov sp, на нам-то не пофиг? 2) Опять же как в 1). CMSIS макросы и прочее. Не надо доводить до абсурда, а то работу будет некогда работать.
	Ответить | Правка | Наверх | Cообщить модератору

	146. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
	Сообщение от Аноним (-), 30-Май-20, 01:07
	> 1) Использование предоставленных производителем платформы средств типа armlib 1) Я не люблю фирму ARM и не хочу пользоваться их либами, особенно на мутных условиях. 2) Мне было интересно как магия устроена на самом деле и слабо ли ее мне самому. Я любопытный. 3) Я не очень прусь от идеи подписываться за хрен знает чей код далеющий хрен знает что. > 2) Опять же как в 1). CMSIS макросы и прочее. Для себя я написал нечто, частично реализующее подобные штуки. Да, оно не совместимо с какой-то мутной хренотой от фиг знает кого. Только это не мои проблемы. > Не надо доводить до абсурда, а то работу будет некогда работать. Логика галерного раба какая-то. Я не являюсь таковым, облом.
	Ответить | Правка | Наверх | Cообщить модератору

	131. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
	Сообщение от Вебмакака (?), 29-Май-20, 00:07
	Особая микроконтроллерная атмосфера. Так, срачи Си против ассемблера не очень давно были актуальны.
	Ответить | Правка | К родителю #79 | Наверх | Cообщить модератору

	139. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
	Сообщение от Аноним (148), 29-Май-20, 18:48
	> Особая микроконтроллерная атмосфера. Ну... когда есть только твой код, более нифига, и это поднимает довольно навороченый чип, создает для C более окружение и все это работает... без непонятных либ и даже стартапа... это по своему прикольно - знать где и почему в фирмваре лежит каждый битик. > Так, срачи Си против ассемблера не очень давно были актуальны. Ну я упер у чувака с DSPICом reed solomon'а. Ессно на сях, ессно того же легендарного Phil Karn KA9Q. Интересно, у кого-нибудь в принципе хватит духа ТАКОЕ на асме выписывать? И на сколько архитектур этого геройства хватит :)
	Ответить | Правка | Наверх | Cообщить модератору

	142. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
	Сообщение от Forth (ok), 29-Май-20, 19:30
	Главное не увлекаться. Я лично предпочитаю вариант, когда разработчики получают ТЗ, описание алгоритмов и архитектуры проекта, затем проектируют устройство из того что нужно, берут BSP, библиотеки, RTOS  и т.п. И делают в итоге за 3 месяца, а не за год, качественно и в срок. Ну да, не знают где какие битики лежат в FW да и не надо.
	Ответить | Правка | Наверх | Cообщить модератору

	144. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
	Сообщение от Аноним (-), 30-Май-20, 00:48
	> И делают в итоге за 3 месяца, а не за год, качественно и в срок. Это пока внутрь этих штук не посмотришь. Да и что такое BSP для микроконтроллера? Если вдруг кр00той эксперт не в курсе, микроконтроллеры поставляются как незапаянные чипы. Поэтому "boart support package" в ситуации когда этот самый борд под задачу делается, гм, допустим, мной - это вообще как и кто BSP релизить должен?! Или это имеется в виду что купить ардуину и поюзать... ? :) > Ну да, не знают где какие битики лежат в FW да и не надо. А потом случается педаль газа у тойоты и дико ср00щие кирпичами водилы. А так все хорошо, прекрасная маркиза.
	Ответить | Правка | Наверх | Cообщить модератору

	145. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
	Сообщение от Аноним (145), 30-Май-20, 00:57
	p.s. разок мне просто ...дец как приперло - и я за 2 дня и налутал борд и отрихтовал под это фирмваре. Но скроить с ноля девайс за 2 дня все же несколько экстрим.
	Ответить | Правка | Наверх | Cообщить модератору

	49. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	–1 +/–
	Сообщение от Аноним (1), 27-Май-20, 15:31
	>Очередные сишные дыры)) Ну чё, ну давай Electron в STM32F103 запихаем. Нам-то слабо что-ли?
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	57. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
	Сообщение от Lex (??), 27-Май-20, 16:14
	Ну чё, ну давай Win7 в STM32F103 запихаем. Нам-то слабо что-ли? Ненаучо. По слухам, православная сишечка с плюсами и безо всяких электронов. полюбому влезть должно и еще 99% памяти свободной останется.
	Ответить | Правка | Наверх | Cообщить модератору

	78. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	–1 +/–
	Сообщение от Аноним (78), 27-Май-20, 18:43
	А вот и не смешно. В этот МК JS/Python проекты не влазят. А на C++ либы влазят
	Ответить | Правка | Наверх | Cообщить модератору

	87. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+1 +/–
	Сообщение от Lex (??), 27-Май-20, 20:17
	За применение плюсОв для мк с действительно серьезно ограниченной памятью ИМХО надо сс.ными тряпками бить.. возможно, даже по лицу. Для полноты ещё не хватает вспомнить про ардуину :)
	Ответить | Правка | Наверх | Cообщить модератору

	92. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	–1 +/–
	Сообщение от Аноним (1), 27-Май-20, 21:28
	Я проводил опыт. Намеренно налепил иерархию классов с виртуальными методами и всё это скомпилил для Ардуины и залил. Был сам удивлён, что катастрофы с занимаемыми ресурсами не произошло.
	Ответить | Правка | Наверх | Cообщить модератору

	107. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+1 +/–
	Сообщение от Lex (??), 28-Май-20, 08:45
	> Я проводил опыт. Намеренно налепил иерархию классов с виртуальными методами и всё > это скомпилил для Ардуины и залил. Был сам удивлён, что катастрофы > с занимаемыми ресурсами не произошло. На тиньку 13-ю с 1Кб флеш + 64 байта озу / на тиньку 2313-ю с 2Кб флеша и 128 байтами озу.. Или на мегу 8-ю с 8Кб флеш + 1Кб озу код заливали ?) Или, "стандартные" для ардуины платы все-таки не зря начинаются с мк типа ATmega328( 32Кб флеш + 2Кб озу ) и вплоть до ATmega2560( 256Кб флеш + 8Кб озу ) и еще жирнее.. и это даже в случае с AVR - который сам по себе типо легковесный и весь энергоэффективный такой. На самом деле, та же ардуина и не сказать, что сжирает какие-то непомерные ресурсы, но нередко норм написанный код прошивки на Сях весит столько же или меньше, чем только базовая ардуиновская "жирнота". К примеру, ту же атмегу 8-ю надо еще умудриться забить кодом, т.к 8Кб - это очень много( если дело не касается работы с картами памяти и файловыми системами итп ), но с ардуиной.. такой проблемы обычно не возникает
	Ответить | Правка | Наверх | Cообщить модератору

	140. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
	Сообщение от Аноним (148), 29-Май-20, 18:51
	Вот кстати одна штука которую в расте вроде слегка просекли как в си и некоторые растоманы нормально юзали: макросы. Они не генерят код. То-есть это compile-time вычисления, и довольно навороченные вещи в коде всего лишь тривиальная константа, крайне быстрая и эффективная. Плюсовики этим похвастать как правило не могут.
	Ответить | Правка | Наверх | Cообщить модератору

	90. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+1 +/–
	Сообщение от Аноним (1), 27-Май-20, 21:24
	Так камрад Самоподобный топит за то, что всякие сишечки надо заменить managed языками.
	Ответить | Правка | К родителю #57 | Наверх | Cообщить модератору

	121. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
	Сообщение от Аноним (-), 28-Май-20, 18:29
	> Ну чё, ну давай Win7 в STM32F103 запихаем. Нам-то слабо что-ли? А что, чувак Ubuntu на AVR загружал... :). В F103 есть варианты с FSMC (внешняя шина).
	Ответить | Правка | К родителю #57 | Наверх | Cообщить модератору

	134. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
	Сообщение от Lex (??), 29-Май-20, 16:51
	> А что, чувак Ubuntu на AVR загружал... :) Мб все-таки на ARM загружал ? А то, для интереса бегло поискал, не попалось ни одной соотв. новости
	Ответить | Правка | Наверх | Cообщить модератору

	137. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
	Сообщение от Аноним (137), 29-Май-20, 18:26
	> Мб все-таки на ARM загружал ? Нет! На AVR - что и сделало это достижение убер-эпиком. Он прицепил ей жирный внешний RAM на шину и ... сэмулировал ARMv5 (!!!) c mmu. > А то, для интереса бегло поискал, не попалось ни одной соотв. новости Да вроде даже тут на опеннете и было. Правда с какой скоростью AVR эмулирует ARMv5 все наверное догадались. Чувак грузил убунту на этом около суток, чтоли. Но все же смог зайти в шелл и даже набрать пару команд, хоть это и напоминало пошаговую стратегию: вы ввели команду - ход переходит к CPU :D
	Ответить | Правка | Наверх | Cообщить модератору

6. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+7 +/–
Сообщение от Аноним (-), 27-Май-20, 11:12
Сейчас снова набегут растоманы с криками "ко-ко-ко! это всё ваш небезопасный Ц! вы все должны писать на расте!" вместо того, чтобы самим написать на своём расте что-нибудь полезное.
Ответить | Правка | Наверх | Cообщить модератору

	10. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+9 +/–
	Сообщение от Аноним (10), 27-Май-20, 11:16
	ко-ко-ко! это всё ваш небезопасный Ц! вы все должны писать на расте!
	Ответить | Правка | Наверх | Cообщить модератору

	13. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+4 +/–
	Сообщение от qetuo (?), 27-Май-20, 11:48
	Как ни странно, вместо "растоманов" обычно прибегают фанатики анти-"растоманы", приплетающие раст по поводу и без.
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	18. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
	Сообщение от Аноним (16), 27-Май-20, 12:18
	Конечно! Они уже создали микропитон и esptuino на джаваскрипте! Подумаешь, что памяти в 10 раз больше кушает, в 50 раз медленней циклы работают, для домашней поделки то хватит, а для промышленной партии в сотни тысяч такие расходы уже несовместимы с жизнью.
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

Часть нити удалена модератором

	27. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	–2 +/–
	Сообщение от Аноним (16), 27-Май-20, 13:40
	Суть одно: криков много, дела мало. Поэтому и в одну кучу.
	Ответить | Правка | К родителю #57 | Наверх | Cообщить модератору

	75. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
	Сообщение от Аноним (137), 27-Май-20, 17:55
	> Суть одно: криков много, дела мало. Поэтому и в одну кучу. Ну почему, иногда показывают свои высер-автоматизации. Так что потом даже ардуинщик ощущает себя белым человеком по сравнению с такими упражнизмами...
	Ответить | Правка | Наверх | Cообщить модератору

	39. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	–2 +/–
	Сообщение от Аноним (-), 27-Май-20, 14:18
	> Ясно Чего тебе ясно? Один микроконтроллерщик назвал весь этот сброд пихтонрасами. Отличное название, почти всю кучу хайпованых макак верящих в серебряные пули включает.
	Ответить | Правка | К родителю #57 | Наверх | Cообщить модератору

Часть нити удалена модератором

	54. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
	Сообщение от Аноним (54), 27-Май-20, 15:53
	На C есть примеры не дырявых программ, очевидно что дело не в языке программирования.
	Ответить | Правка | К родителю #75 | Наверх | Cообщить модератору

	56. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	–1 +/–
	Сообщение от Fracta1L (ok), 27-Май-20, 16:09
	> На C есть примеры не дырявых программ Это какие?
	Ответить | Правка | Наверх | Cообщить модератору

	74. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
	Сообщение от Аноним (-), 27-Май-20, 17:53
	> Это какие? DJBDNS например. А так в любой большой программе есть баги. Часть из них приводит к каким-то дивидендам для атакуюших. Вон в плагинах вордпресса никаких переполнений буферов, только это почему-то совершенно не мешает.
	Ответить | Правка | Наверх | Cообщить модератору

	96. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	–1 +/–
	Сообщение от Аноним (47), 27-Май-20, 22:17
	Hello World
	Ответить | Правка | К родителю #56 | Наверх | Cообщить модератору

	102. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
	Сообщение от Аноним (102), 28-Май-20, 01:52
	А тебе уже говорили какие.
	Ответить | Правка | К родителю #56 | Наверх | Cообщить модератору

	68. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	–1 +/–
	Сообщение от Аноним (-), 27-Май-20, 17:44
	> Что у фанатиков дырявой сишки бошки такие же дырявые) Ну ты то надеюсь хотя-бы операционку уже растовую используешь, как самый умный? Или это как с тем чуваком, нахваливавшим NT ... до момента когда он таки наконец ее попробовал.
	Ответить | Правка | К родителю #75 | Наверх | Cообщить модератору

	80. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	–1 +/–
	Сообщение от WD40 (?), 27-Май-20, 18:47
	У тебя тоже есть уязвимость. Если вакансии будут только на крестах, то с голоду можно помереть.
	Ответить | Правка | К родителю #75 | Наверх | Cообщить модератору

	88. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
	Сообщение от Lex (??), 27-Май-20, 20:19
	Но кого мы обманываем. Скорее всего, если вакансии и будут, то на не_плюсах ..:)
	Ответить | Правка | Наверх | Cообщить модератору

	124. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
	Сообщение от Аноним (124), 28-Май-20, 18:42
	Ну это смотря какая причина наличия вакансий... Я видел одну, год висела, на делфи: сделай всё за три рубля называется, и все накопленные грехи искупи.
	Ответить | Правка | Наверх | Cообщить модератору

7. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
Сообщение от Аноним (10), 27-Май-20, 11:14
SASOS-нули с безопасностью
Ответить | Правка | Наверх | Cообщить модератору

9. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+1 +/–
Сообщение от Страдивариус (?), 27-Май-20, 11:14
> В IPv4 стеке платформы выявлена удалённо эксплуатируемая уязвимость, приводящая к повреждению памяти при обработке определённым образом модифицированных ICMP-пакетов. Шел 2020 год, а школоте упорно не давали забывать про вариации ping of death.
Ответить | Правка | Наверх | Cообщить модератору

	12. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	–1 +/–
	Сообщение от ryoken (ok), 27-Май-20, 11:33
	> Шел 2020 год, а школоте упорно не давали забывать про вариации ping > of death. Уверен, для кого-то это будет новостью :D.
	Ответить | Правка | Наверх | Cообщить модератору

14. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+1 +/–
Сообщение от Аноним (1), 27-Май-20, 12:05
>Дополнительно был изучен код открытого загрузчика MCUboot, в котором была найдена одна неопасная уязвимость, которая может привести к переполнению буфера при испльзовании протокола SMP (Simple Management Protocol) через UART. На Rust переполнений буфера быть не может!
Ответить | Правка | Наверх | Cообщить модератору

	19. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
	Сообщение от Аноним (16), 27-Май-20, 12:20
	Почему же её назвали Rust, почему уж сразу не Shit или какой-нить Punk?
	Ответить | Правка | Наверх | Cообщить модератору

	36. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+1 +/–
	Сообщение от Father Karras (?), 27-Май-20, 14:14
	Кто-то из моих адептов пережил так неудачно сфейленный мной армагеддец. И продолжает в том же духе.
	Ответить | Правка | Наверх | Cообщить модератору

	40. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
	Сообщение от Аноним (-), 27-Май-20, 14:20
	> Почему же её назвали Rust, почему уж сразу не Shit или какой-нить Punk? Shithonrust Punk. Железный человек, судя по описанию. Бухой и ржавый.
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

	20. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
	Сообщение от Аноним (15), 27-Май-20, 12:23
	Могут, скорее их проэксплуатировать нельзя просто. Доводилось встречать растописцев, которые кроме овнершипа и лайфтаймов дальше внимательно спеку не читали, поэтому try-catch в Rust-стиле (обработка panic, возникающей при любых операциях, где у чего-то задекларирован фиксированный размер и адресация по индексам) и не производится. Ну спасибо что хоть прога на проде падает в прайм-тайм, а не светит дырками.
	Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

22. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+2 +/–
Сообщение от Аноним (22), 27-Май-20, 12:58
интернет свищей
Ответить | Правка | Наверх | Cообщить модератору

	28. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
	Сообщение от Аноним (16), 27-Май-20, 13:42
	> интернет дрищей fixed
	Ответить | Правка | Наверх | Cообщить модератору

	69. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+2 +/–
	Сообщение от Аноним (-), 27-Май-20, 17:46
	> интернет овощей //так честнее
	Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

	93. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+1 +/–
	Сообщение от Аноним (1), 27-Май-20, 21:39
	Ну это про тех, кто топит за IoT даже там, где не особо-то и нужно.
	Ответить | Правка | Наверх | Cообщить модератору

	120. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+1 +/–
	Сообщение от Аноним (119), 28-Май-20, 18:11
	> Ну это про тех, кто топит за IoT даже там, где не особо-то и нужно. Тебе может и не нужно. А мне пригодится идея стать распределенным...
	Ответить | Правка | Наверх | Cообщить модератору

	126. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
	Сообщение от Аноним (126), 28-Май-20, 21:06
	Ну так распределяйся. Мне IoT пц как нужно. Но в том виде в каком за него топят - не нужно. Они его топят - и это правильно.
	Ответить | Правка | Наверх | Cообщить модератору

	138. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
	Сообщение от Аноним (137), 29-Май-20, 18:36
	> Ну так распределяйся. Я это уже слегка попробовал и, вообще, понравилось. Однажды я смогу процитировать одного персонажа и не соврать. > Но в том виде в каком за него топят - не нужно. Смотря кто топит. Если жирные корпорации и их дружки, то от них понятно что ожидать: очередной шпионаж, тоталконтрол и мелкие пакости.
	Ответить | Правка | Наверх | Cообщить модератору

26. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+1 +/–
Сообщение от Аноним (-), 27-Май-20, 13:30
> Разработка Zephyr ведётся при участии компаний Intel. Ясно-понятно. Дырки-то в процах уже заштопали циганской иглой с белыми нитками.
Ответить | Правка | Наверх | Cообщить модератору

	29. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+2 +/–
	Сообщение от WD40 (?), 27-Май-20, 13:44
	"цыган встал на цыпочки и сказал цыплёнку: «Цыц»"
	Ответить | Правка | Наверх | Cообщить модератору

	30. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	–2 +/–
	Сообщение от Аноним (15), 27-Май-20, 13:50
	Вот разнылись-то, а. Meltdown и Spectre как были в стадии proof-of-concept, так и поныне там. Нужна хренова туча одновременно выполненных условий, чтобы у тебя с компа украли чувствительную инфу таким образом. Вероятность того, что пароли сопрут, вкрутив нормальный руткит с кейлоггером или тупо запудрив голову Машке из бухгалтерии, гораздо выше.
	Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

	41. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+1 +/–
	Сообщение от Аноним (41), 27-Май-20, 14:22
	Однако идея стыбзить все то же самое БЕЗ руткита и кейлогера яваскриптом каким - очень даже. А безопасник потом сойдет с ума пытаясь найти руткит которого нет.
	Ответить | Правка | Наверх | Cообщить модератору

	58. Скрыто модератором	–1 +/–
	Сообщение от пох. (?), 27-Май-20, 16:32
	Не ссцы, они обычно не могут найти и того, который есть и прямо у них под носом. И с ума вовсе не сходят, был бы ум... И да, потрахивая раз в две недели толстую бухгалтершу Машу, можно получить искомое без рута, кейлогера и яваскриптов.
	Ответить | Правка | Наверх | Cообщить модератору

	70. Скрыто модератором	+/–
	Сообщение от Аноним (-), 27-Май-20, 17:48
	> Не ссцы, они обычно не могут найти и того, который есть и прямо у них под носом. Ну так на то он и руткит :). Хотя руткиты имеют свойство довольно хорошо себя демаскировать аномалиями. > И с ума вовсе не сходят, был бы ум... Ну, блин, без ума это не безопасник а картонная эмуляция оного. > И да, потрахивая раз в две недели толстую бухгалтершу Машу, можно получить > искомое без рута, кейлогера и яваскриптов. И что характерно, это тоже практикуется.
	Ответить | Правка | Наверх | Cообщить модератору

42. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+1 +/–
Сообщение от Аноним (42), 27-Май-20, 14:26
Тыкните их носиком в RUST!
Ответить | Правка | Наверх | Cообщить модератору

	46. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
	Сообщение от Аноним (46), 27-Май-20, 14:55
	Привет! А что ты написал на своём RUST, чтобы тыкать кого-то "носиком"?
	Ответить | Правка | Наверх | Cообщить модератору

	50. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	–1 +/–
	Сообщение от Аноним (1), 27-Май-20, 15:37
	Ой, не надо. Пахнет сильно резко!
	Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

	71. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+1 +/–
	Сообщение от Аноним (-), 27-Май-20, 17:49
	> Тыкните их носиком в RUST! А давай ты лучше сам в него ткнешься и вместо пиндежа на форуме что-нибудь дельное накодишь?
	Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

	97. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
	Сообщение от Аноним (-), 27-Май-20, 23:06
	С добрым утром! https://github.com/ixy-languages/ixy-languages
	Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

43. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+1 +/–
Сообщение от YetAnotherOnanym (ok), 27-Май-20, 14:29
>  уязвимость, приводящая к повреждению памяти при обработке определённым образом модифицированных ICMP-пакетов PoD4IoT.
Ответить | Правка | Наверх | Cообщить модератору

45. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+3 +/–
Сообщение от None (??), 27-Май-20, 14:55
Если бы я был серьёзным оператором бот-нет сетей, участие в подобный проектах "ОС" было бы одним из моих основных приоритетов. Вкладываться в будущее ведь надо.
Ответить | Правка | Наверх | Cообщить модератору

	51. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
	Сообщение от Аноним (1), 27-Май-20, 15:40
	И пользователю выгодно. Майнят, тем самым, кофе заваривая.
	Ответить | Правка | Наверх | Cообщить модератору

	59. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+2 +/–
	Сообщение от оператор (?), 27-Май-20, 16:34
	да ладно, время на фигню тратить. Эти обезьяны и так все за нас сделают. Будущее безоблачно. "Интернет свищей", ага.
	Ответить | Правка | К родителю #45 | Наверх | Cообщить модератору

73. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
Сообщение от Аноним (73), 27-Май-20, 17:53
>. Специфичный для приложений код комбинируется с адаптированным под конкретное применение ядром и образует монолитный исполняемый файл для загрузки и запуска на определённом оборудовании. вспоминается Cray.. и их catamount..
Ответить | Правка | Наверх | Cообщить модератору

81. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+2 +/–
Сообщение от Аноним_ (?), 27-Май-20, 18:49
Интернет щелей.
Ответить | Правка | Наверх | Cообщить модератору

85. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
Сообщение от commiethebeastie (ok), 27-Май-20, 19:54
>обращение по отрицательному номеру системного вызова приводит к целочисленному переполнению Главное в индийские ракеты её не ставьте.
Ответить | Правка | Наверх | Cообщить модератору

	101. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
	Сообщение от Michael Shigorin (ok), 28-Май-20, 01:00
	Winwars 2000?..
	Ответить | Правка | Наверх | Cообщить модератору

	123. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
	Сообщение от Аноним (124), 28-Май-20, 18:39
	Цива же
	Ответить | Правка | Наверх | Cообщить модератору

	133. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
	Сообщение от Аноним (95), 29-Май-20, 01:38
	> Главное в индийские ракеты её не ставьте. Почему в индийские-то? Тут осенью первый запуск 'Ariane VI' планируют. Вот и посмотрим, осилят ли проггеры повторение успеха первого запуска "Ariane V" или нет?
	Ответить | Правка | К родителю #85 | Наверх | Cообщить модератору

	143. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+/–
	Сообщение от commiethebeastie (ok), 29-Май-20, 20:26
	> Почему в индийские-то? Ядерный Ганди в циве. Он настолько миролюбивый, что вызывает переполнение и начинает стрелять по всем ядерными ракетами.
	Ответить | Правка | Наверх | Cообщить модератору

91. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."	+2 +/–
Сообщение от Аноним (91), 27-Май-20, 21:28
S in IOT stands for "Security"
Ответить | Правка | Наверх | Cообщить модератору

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

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