The OpenNET Project / Index page

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

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


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

Оглавление

25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..., opennews (??), 27-Май-20, (0) [смотреть все]

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


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.ru/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.ru/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.ru/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 Shigorinemail (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ообщить модератору

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

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




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

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