forum.opennet.ru

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

Оглавление

Критические уязвимости в подсистеме eBPF ядра Linux, opennews (??), 23-Дек-17, (0) [смотреть все]

А ведь eBPF почти продвинули как адекватную альтернативу DTrace, но видно не суд, Аноним (-), 11:04 , 23-Дек-17, (1) –5 //

Отладкой всё равно занимаются на локалхосте, где повышение привилегий не страшно, Аноним (-), 11:19 , 23-Дек-17, (2) +3 //

Цимес DTrace именно в том, что он был создан для анализа проблем в продакшене, т, Аноним (-), 13:59 , 23-Дек-17, (7) //

Цимес любого дебагера - в том что им можно поиметь всех по самые гланды , Аноним (-), 18:20 , 23-Дек-17, (16) +4
В Солярисе DTrace можно было sic пользоваться без повышения привилегий , EHLO (?), 19:26 , 23-Дек-17, (27)

Да, и во FreeBSD тоже Всё, что доступно тебе для отладки, доступно и для DTrace, Знаток (?), 12:53 , 24-Дек-17, (56)

Не знаток проприетари, но простое гугление подсказывает, что в Оракле с тобой не, EHLO (?), 13:24 , 24-Дек-17, (58) +1
CODE анон bsd usr share dtrace watch_execve dtrace failed to initialize d, Аноним (-), 17:05 , 24-Дек-17, (64) +1

По-моему, в сабже как раз и написано популярным языком что после этого ожидать , Аноним (-), 21:07 , 24-Дек-17, (72)

Сабж про пингвина Это разрешает неруту запускать дебагер в бзде А отвечал я во, Аноним (-), 02:51 , 25-Дек-17, (73) +1

И там как раз написано что случается после того как нерут что-нибудь основательн, Аноним (-), 00:09 , 26-Дек-17, (77)

Что ж теперь strace-ом и gdb юзерам запретить пользоваться , EHLO (?), 01:16 , 26-Дек-17, (81)

Представляешь, было vuln-ов связанных с трассировкой процессов И в лине и в бзд, Аноним (-), 19:09 , 26-Дек-17, (85)

Однако, простой дебагинг приложения, без влезания в ядро, намного более проста, Аноним (-), 02:50 , 26-Дек-17, (84)

Целый год радовали уязвимости, доступные через user namespace, а теперь настал ч, Аноним (-), 11:44 , 23-Дек-17, (5) +5 //

Если не ошибаюсь, оно используется песочницой хромиума для изоляции рабочих проц, Нанобот (ok), 14:13 , 23-Дек-17, (10) –1 //

в скрытых настройках хрома присутствует этот параметр , Мое имя (?), 00:42 , 24-Дек-17, (35) //

Покажи, что ли , Аноним (-), 12:29 , 24-Дек-17, (53)

тем, разумеется, кто ни разу не жаждал давать программистам для отладки рутовый , пох (?), 16:53 , 23-Дек-17, (14) //

То есть программисты, занимающиеся отладкой в проде без рутового доступа -- это , EHLO (?), 20:45 , 23-Дек-17, (30) +2 //

Нормально, если они занимаются выяснением проблемы, где именно тормозит вот этот, Знаток (?), 12:55 , 24-Дек-17, (57)

Соболезную эксплуататорам и разработчикам проприетари Что еще могу сказать, для, EHLO (?), 13:30 , 24-Дек-17, (59) +2

соболезную авторам Hello-world Которым не приходится собирать данные о работе п, Аноним (-), 14:29 , 24-Дек-17, (60) +2

Не соболезную анонимам, которые не знают что такое отладка продакшену в котор, EHLO (?), 15:24 , 24-Дек-17, (62) +2

Тяжела и неказиста участь тех кто не смог в контейнеры и виртуалки А чего таког, Аноним (-), 03:20 , 24-Дек-17, (39) +1

По ссылке уязвимости в 8-ми разных версиях ядра в разных версиях Debian, откуда , Аноним (-), 13:04 , 23-Дек-17, (6) //

The following bug was introduced in 4 9 fixed by bpf fix incorrect sign exte, Аноним (-), 14:00 , 23-Дек-17, (8) +1

Android подвержен чтобы рутануть, само собой , axredneck (?), 14:02 , 23-Дек-17, (9) +2 //

да конечно чтобы рутануть, чтобы майнера установить скрытного в системе так и ск, dasrfatwet (?), 18:09 , 23-Дек-17, (15) –2 //

Чтобы майнер был незаметным - требуется чемодан-невидимка с батарейками , Аноним (-), 18:24 , 23-Дек-17, (18) +6 //

Кстати, если у кого такой чемодан есть - дайте два И черт с ним, с майнером , Аноним (-), 22:04 , 23-Дек-17, (32) +1

И чёрт с ним, с невидимкой Пусть будет просто невесомка , Аноним (-), 12:32 , 24-Дек-17, (54)

Линус, как всегда, был прав Очень плохо, когда заранее объявляют, что данное ядр, Ilya Indigo (ok), 14:49 , 23-Дек-17, (11) +1
приведёт к невозможности использования обычными пользователями средств трассир, Аноним (-), 15:28 , 23-Дек-17, (12) –1
Есть ли где внятное сравнение на счёт пользы от внедрения JIT-та в ядро, мол пос, Аноним (-), 15:54 , 23-Дек-17, (13) –1 //

Почитай, что такое eBPF JIT только в нём , Аноним (-), 12:33 , 24-Дек-17, (55) –3

c-проблемы гениальных программистов, Аноним (-), 18:27 , 23-Дек-17, (19) –7 //

Вы забыли ссылку на своё беспроблемное, хоть и ни разу не гениальное, ядро Даж, Michael Shigorin (ok), 19:11 , 23-Дек-17, (21) //

вы забыли если вообще знали матчасть, Мишенька Plan9, Inferno, clive, gopher-o, Аноним (-), 23:15 , 23-Дек-17, (33) –5 //

Уточните пожалуйста Вы утверждаете что все эти вещи написали Вы или жеВы утвержд, ыы (?), 23:49 , 23-Дек-17, (34) +2

пропущена запятаяа что, о на этом форуме комментировать могут только те, кто пиш, Аноним (-), 00:49 , 24-Дек-17, (36) –6

А у вас точно в конце предложения Кстати предложения начинаются с большой бук, Аноним (-), 01:04 , 24-Дек-17, (37) +1

статистика С банально устарел с тех пор как он был придуман когда язык , Аноним (-), 01:34 , 24-Дек-17, (38) –3

Статистика ЧЕГО На си написано дофига кода Наверное логично что в дофига кода , Аноним (-), 03:28 , 24-Дек-17, (41)

в том и проблема сколько уже было критических уязвимостей в линуксе и других фу, Аноним (-), 03:55 , 24-Дек-17, (43) –1

Я бы понял эти претензии, если бы за тот же интервал времени не нашлось 100500 к, Аноним (-), 19:57 , 24-Дек-17, (66) +2

Не парься Их трудно как-нибудь просветить Пофиг людям, что ракеты падают не из-, Джон Ленин (?), 23:33 , 23-Фев-18, (87)

Видный специалист в криптографии и безопасности DJB готов с вами поспорить Он к, Аноним (-), 03:22 , 24-Дек-17, (40)

да что вы говорите и сколько лет у него уйдёт, чтобы переписать Linux и выложи, Аноним (-), 03:33 , 24-Дек-17, (42) –2

Наверное много Но весь прикол в том что на чём то другом - не напишут вообше -, . (?), 07:20 , 24-Дек-17, (45) +1

мда, докультивировались тут на опёнке , Аноним (-), 07:38 , 24-Дек-17, (46)

Проект размером с Linux неизбежно будет содержать много багов Часть из них окаж, Аноним (-), 20:48 , 24-Дек-17, (68)

Plan9 - ANSI CInferno - Cclive - Что это вообще Даже гугл ответ не даёт gopher-, Аноним (-), 07:49 , 24-Дек-17, (47) +2

молодец читай дальше спойлер для ленивых там написано что отменено в пользу I, Аноним (-), 09:24 , 24-Дек-17, (48) –1

Я даже спорить не буду, потому что в любом случае в любых ядрах используется асс, Аноним (-), 10:11 , 24-Дек-17, (49)

https lesswrong ru w D0 A1 D0 BE D1 84 D0 B8 D0 B7 D0 BC_ D1 81 D0 B5 D1 80 D, Ordu (ok), 12:10 , 24-Дек-17, (52)

А я и не утверждал что есть вообще что-то лучше Всё в компьютерах плохо и все к, Аноним (-), 15:21 , 24-Дек-17, (61)

Ну я и говорю софизм серого В попытке казаться взрослым и умудрённым опытом ци, Ordu (ok), 16:57 , 24-Дек-17, (63)

А может ты ещё раз перечитаешь а потом пере-перечитаешь моё сообщение Я хотел п, Аноним (-), 19:51 , 24-Дек-17, (65)
Очевидно Но ты ведь закончил этим выводом И я не вижу каким образом из этой то, Ordu (ok), 20:45 , 24-Дек-17, (67) –1
Ordu ты открыл мне глаза, большое человеческое спасибо , Аноним (-), 02:37 , 26-Дек-17, (83)
А ты научился понимать себя , Аноним (-), 21:00 , 24-Дек-17, (70) –1

Понимаешь в чём проблема, тем, что ты тут перечислил пользуются 2 5 гика Осталь, Аноним (-), 10:14 , 24-Дек-17, (50)

Он какой-то левый утюг запакует щаз, и будет наблюдать как вы его тщетно загрузи, Джон Ленин (?), 23:09 , 23-Фев-18, (86)

Ты б в описание багов заглянул, прежде чем утверждать подобное , Ordu (ok), 12:08 , 24-Дек-17, (51) +1

Это eBPF оно мне вообще надо И почему оно включено по умолчанию , Аноним (-), 07:26 , 25-Дек-17, (74) +1 //

Кто тебя знает Не надо - выключи Потому что разработчикам ядра или майнтайнерам, Аноним (-), 00:15 , 26-Дек-17, (78)
А где было написано что оно включено по умолчанию На первый вопрос ответ нет , EHLO (?), 01:21 , 26-Дек-17, (82)

Ну так какой прок от eBPF где цифры, слайды, видео История успеха, так сказать, Аноним (-), 00:34 , 26-Дек-17, (79) //

https www youtube com watch v sV3XfrfjrPo feature youtu be t 1851Это таймкод, , Аноним (88), 12:38 , 13-Авг-18, (88)

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

19. "Критические уязвимости в подсистеме eBPF ядра Linux" –7 +/–

Сообщение от Аноним (-), 23-Дек-17, 18:27

>некорректным преобразованием типов и отсутствием должных проверок
c-проблемы "гениальных" программистов

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

21. "Критические уязвимости в подсистеме eBPF ядра Linux" +/–

Сообщение от Michael Shigorin (ok), 23-Дек-17, 19:11

>>некорректным преобразованием типов и отсутствием должных проверок
> c-проблемы "гениальных" программистов
Вы забыли ссылку на своё беспроблемное, хоть и ни разу не гениальное, ядро.  Даже необязательно в исходниках.
PS @ 20190213: *своё*, о "преподаватель" _чужой_ матчасти.

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

33. "Критические уязвимости в подсистеме eBPF ядра Linux" –5 +/–

Сообщение от Аноним (-), 23-Дек-17, 23:15

>>>некорректным преобразованием типов и отсутствием должных проверок
>> c-проблемы "гениальных" программистов
> Вы забыли ссылку на своё беспроблемное, хоть и ни разу не гениальное,
> ядро.  Даже необязательно в исходниках.
вы забыли (если вообще знали) матчасть, Мишенька.
Plan9, Inferno, clive, gopher-os

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

34. "Критические уязвимости в подсистеме eBPF ядра Linux" +2 +/–

Сообщение от ыы (?), 23-Дек-17, 23:49

Уточните пожалуйста:
Вы утверждаете что все эти вещи написали Вы?
или же
Вы утверждаете что эти вещи не содержат проблемных мест?

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

36. "Критические уязвимости в подсистеме eBPF ядра Linux" –6 +/–

Сообщение от Аноним (-), 24-Дек-17, 00:49

> Уточните пожалуйста:
пропущена запятая
> Вы утверждаете что все эти вещи написали Вы?
а что, о на этом форуме комментировать могут только те, кто пишут свои собственные ядра?
> Вы утверждаете что эти вещи не содержат проблемных мест?
я утверждаю, что C/C++ и подобные - это априори дыра в безопасности кода, и никакая "гениальность", как любят себя величать программизты этих языков, не помогает почему-то.

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

37. "Критические уязвимости в подсистеме eBPF ядра Linux" +1 +/–

Сообщение от Аноним (-), 24-Дек-17, 01:04

> пропущена запятая
А у вас точно в конце предложения. Кстати.. предложения начинаются с большой буквы. Дальше продолжать будем?
> я утверждаю, что C/C++ и подобные - это априори дыра в безопасности кода
С чего Вы так решили? Или у вас <<ржавчина>> начала проявляться?

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

38. "Критические уязвимости в подсистеме eBPF ядра Linux" –3 +/–

Сообщение от Аноним (-), 24-Дек-17, 01:34

>> я утверждаю, что C/C++ и подобные - это априори дыра в безопасности кода
> С чего Вы так решили?
#. статистика;
#. С банально устарел с тех пор как он был придуман;
#. когда язык не загнан насильно в определённые рамки, это чревато последствиями - простая логика;
#. работа с памятью и указателями - проблема создателей реализация языка, и не должна становиться проблемой программиста. инкапсуляция - слышали, нет?;
#. в результате, C - не последний язык который придумали Ричи и Керниган;
> Или у вас <<ржавчина>> начала проявляться?
что-что??

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

41. "Критические уязвимости в подсистеме eBPF ядра Linux" +/–

Сообщение от Аноним (-), 24-Дек-17, 03:28

> #. статистика;
Статистика ЧЕГО? На си написано дофига кода. Наверное логично что в дофига кода - дофига багов. А вот на брейнфаке код мало кто пишет. Поэтому и уязвимостей мало. Но это ничего не говорит о безопасности программ на брейнфаке.
> #. С банально устарел с тех пор как он был придуман;
И что на его замену для системного программирования и прочих микроконтроллеров, интересно? Последние, кстати, работают в очень критичных применениях. Смотри не обделайся со страха, эксперт по безопасности.
> #. когда язык не загнан насильно в определённые рамки, это чревато последствиями
> - простая логика;
С другой стороны, "создайте систему которой может пользоваться даже дурак и только дурак захочет ей пользоваться".
> #. работа с памятью и указателями - проблема создателей реализация языка, и
> не должна становиться проблемой программиста. инкапсуляция - слышали, нет?;
А что если мне эффективнее перекинуть указатель чем 30-меговый буфер? А энкапсуляция (выучи как это пишется, позорник) может все усложнять, мешаться и делать поведение менее предсказуемым. Не все же пользуются компьютером в режиме маками.
> #. в результате, C - не последний язык который придумали Ричи и Керниган;
Но лучше для системного программирования так ничего и не появилось. Кроме, конечно же, развитий языка. На K&R C никто не пишет нынче, да и за си его большинство програмеров признает не сразу.

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

43. "Критические уязвимости в подсистеме eBPF ядра Linux" –1 +/–

Сообщение от Аноним (-), 24-Дек-17, 03:55

>> #. статистика;
> Статистика ЧЕГО? На си написано дофига кода. Наверное логично что в дофига
> кода - дофига багов. А вот на брейнфаке код мало кто
> пишет. Поэтому и уязвимостей мало. Но это ничего не говорит о
> безопасности программ на брейнфаке.
в том и проблема. сколько уже было критических уязвимостей в линуксе и других фундаментальных gnu+linux утилитах за последние несколько лет? и в основном это всё одни и те же до.банные проблемы нарушений работы с памятью. _одни и те же_ . из раза в раз! почему так получается? человеческий фактор? и как же с этим бороться? может, давайте запретим программировать на опасных языках? или, может, всё таки нужно прощаться с языками которые допускают такое поведение в коде?
>> #. С банально устарел с тех пор как он был придуман;
> И что на его замену для системного программирования и прочих микроконтроллеров, интересно?
> Последние, кстати, работают в очень критичных применениях. Смотри не обделайся со
> страха, эксперт по безопасности.
>Смотри не обделайся
лол, вот и весь разговор с вами, "высокоинтеллектуалами": оскорбления, оскорбления.. у тебя по ходу комплекс неполноценности какой-то..
а что касается контроллеров, то и тут на Си клином свет не сошёлся. за тебя погуглить? даже паскаль в разы удобнее в этом.
>> #. когда язык не загнан насильно в определённые рамки, это чревато последствиями
>> - простая логика;
> С другой стороны, "создайте систему которой может пользоваться даже дурак и только
> дурак захочет ей пользоваться".
а пока что дураки пишут Ланупсы.. и в России ракеты с гидро-метео спутниками в болота пускают..
>> #. работа с памятью и указателями - проблема создателей реализация языка, и
>> не должна становиться проблемой программиста. инкапсуляция - слышали, нет?;
> А что если мне эффективнее перекинуть указатель чем 30-меговый буфер? А энкапсуляция
> (выучи как это пишется, позорник) может все усложнять, мешаться и делать
> поведение менее предсказуемым. Не все же пользуются компьютером в режиме маками.
>А что если мне эффективнее перекинуть указатель чем 30-меговый буфер?
если у тебя возникают подобные вопросы в данном контексте, то тебе нужно пойти в отпуск, расслабиться и RTFM в конце концов..
>энкапсуляция
> (выучи как это пишется, позорник)
ты что, серьёзно? не зря ты анонима включил..
>> #. в результате, C - не последний язык который придумали Ричи и Керниган;
> Но лучше для системного программирования так ничего и не появилось.
ц
> Кроме, конечно
> же, развитий языка. На K&R C никто не пишет нынче, да
> и за си его большинство програмеров признает не сразу.
ой, надо Сишной Группе Разработчиков написать, что аноним с опеннет считает что они делают не C

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

66. "Критические уязвимости в подсистеме eBPF ядра Linux" +2 +/–

Сообщение от Аноним (-), 24-Дек-17, 19:57

> в том и проблема. сколько уже было критических уязвимостей в линуксе и
> других фундаментальных gnu+linux утилитах за последние несколько лет?
Я бы понял эти претензии, если бы за тот же интервал времени не нашлось 100500 критичных дыр на чем угодно. У мозиллы в просмотрщике на JS, у апача в ява-спруте, moinmoin на питоне, рубисты не отстали, на пхп писала толпа и лоханулись кому не лень. С практической точки зрения больше всего систем взломано из-за вебни или из-за дефолтных паролей на вход. А дыры типа сабжа - как бы фи, но вред умеренный. Иногда даже польза в виде рутаных андроидов.
> и в основном это всё одни и те же до.банные проблемы нарушений работы с
> памятью. _одни и те же_ . из раза в раз!
И что характерно в лине над ошибками работают. Но не так как ты себе это представляешь.
> почему так получается? человеческий фактор? и как же с этим бороться?
В лине прикрутили статические анализаторы и kasan и настроили fuzzing. А ты думаешь чего так бойко баги стали находить? Там и более продвинутый анализ воротят.
> может, давайте запретим программировать на опасных языках? или, может, всё таки нужно
> прощаться с языками которые допускают такое поведение в коде?
Лично ты можешь идти и прощаться с всем чем пожелаешь. Более того - я тебя совершенно не заставляю моим кодом пользоваться. Как и все остальные разработчики.
Вон на redox какой-нибудь вали и втирай там какой он офигенно безопасный. И хрен с ней с работающей операционкой и програмерами пишущими код, да? Самый безопасный компьютер все-равно выключенный, так что изволь.
> тебя по ходу комплекс неполноценности какой-то..
Это я показываю наивной макаке с горящими глазами что на сишечке держится мнооооого чего критичного. И если следовать нехитрым правилам то получается весьма даже. Вопрос в отсутствии раздолбайского подхода в критичных местах, не более.
> а что касается контроллеров, то и тут на Си клином свет не
> сошёлся. за тебя погуглить? даже паскаль в разы удобнее в этом.
Я эти микроконтроллеры програмлю, на секундочку. А ты - эксперт по гуглению с горящими глазами. Который ни в чем не разбирается, но мнение имеет. По всей отрасли еще поискать чудака который микроконтроли на паскакале удумает програмить.
Чтоб ты знал - половина работы с МК это лобовая работа с памятью. Регистры у железа замаплены в память. И надо класть нужные значения в нужные адреса. Единственным достижением от паскаля на этом пути будет истошная борьба с ветряными мельницами.
> а пока что дураки пишут Ланупсы.. и в России ракеты с гидро-метео
> спутниками в болота пускают..
И только ты один весь в белом, мистер Дон Кихот? Иди, задай уже этим ветряным мельницам.
> если у тебя возникают подобные вопросы в данном контексте, то тебе нужно
> пойти в отпуск, расслабиться и RTFM в конце концов..
Какой ты шустрый всем указывать. Тю.
> ты что, серьёзно? не зря ты анонима включил..
Ну ты то как умная клава сообщишь как тебя зовут? Интересно же кто такой гениальный.
> ой, надо Сишной Группе Разработчиков написать, что аноним с опеннет считает что
> они делают не C
Ой, ты чистый K&R C вообще видел когда-нибудь? Он заметно отличается от современных диалектов. Даже от древнючего C89. Представляешь, синтаксис K&R даже не скомпилится современными компилерами, сишные проекты которые сейчас таки потомки/наследники C89.

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

87. "Критические уязвимости в подсистеме eBPF ядра Linux" +/–

Сообщение от Джон Ленин (?), 23-Фев-18, 23:33

Не парься. Их трудно как-нибудь просветить.
Пофиг людям, что ракеты падают не из-за того, что инженеры дeбилы, а по другим причинам (например: отсутствие конкуренции, частных компаний, патентного права, поддержки, партнёрства, капитализации и вменяемого менеджмента + запугивание)
Пофиг им и то, что ко всему ведру нельзя прикрутить какой-то адский супер-мега-анализатор сходу, потому-что оно такое огромное, что его даже шланг года 3 прожевать не может (хоть и очень старается)
И вроде про rust им тоже объясняешь, типа "да, писание модулей как эксперимент -- это интересно и хорошо", они всё-равно недовольны. Но как начинаешь объяснять им что "ты радуйся, что они ассемблерных вставок хоть избегают" -- так уже "плохо, что избегают!"
Говоришь им, что в PREEMPT/RT-ядрах есть зачатки микроядерности, и звук в джеке пишется хорошо... но они снова про 12309 поясняют...

И вот никак же им не объяснишь, что на мобильных вендах всё в 1000 раз ужаснее, и что на яблочных девайсах поломали права (внезапный root), но после "починки" сломали ещё сильнее; и грузинским письмом яблоки как кирпичились 3 года назад, так и до сих пор кирпичатся.

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

40. "Критические уязвимости в подсистеме eBPF ядра Linux" +/–

Сообщение от Аноним (-), 24-Дек-17, 03:22

> я утверждаю, что C/C++ и подобные - это априори дыра в безопасности
> кода, и никакая "гениальность", как любят себя величать программизты этих языков,
> не помогает почему-то.
Видный специалист в криптографии и безопасности DJB готов с вами поспорить. Он как раз таки на си написал несколько вполне безопасных программ и даже формально обосновал как делать программы безопаснее. И почему именно так.

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

42. "Критические уязвимости в подсистеме eBPF ядра Linux" –2 +/–

Сообщение от Аноним (-), 24-Дек-17, 03:33

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

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

45. "Критические уязвимости в подсистеме eBPF ядра Linux" +1 +/–

Сообщение от . (?), 24-Дек-17, 07:20

>>Видный специалист в криптографии и безопасности DJB готов с вами поспорить
>да что вы говорите.. и сколько лет у него уйдёт, чтобы переписать Linux и выложить результат в свободный доступ?
Наверное много.
Но весь прикол в том что на чём то другом - не напишут вообше :-р
А с другойстороны - конкретно ты - вообще не напишешь. Ыма мало, гонора - много. Таких не берут в кocмoнавты! (С)  :-)

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

46. "Критические уязвимости в подсистеме eBPF ядра Linux" +/–

Сообщение от Аноним (-), 24-Дек-17, 07:38

> Но весь прикол в том что на чём то другом - не напишут вообше :-р
> А с другойстороны - конкретно ты - вообще не напишешь.
мда, докультивировались тут на опёнке..

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

68. "Критические уязвимости в подсистеме eBPF ядра Linux" +/–

Сообщение от Аноним (-), 24-Дек-17, 20:48

> да что вы говорите.. и сколько лет у него уйдёт, чтобы переписать
> Linux и выложить результат в свободный доступ?
Проект размером с Linux неизбежно будет содержать много багов. Часть из них окажется проблемами безопасности. Это данность процесса разработки софта. А любой кто этого не понимает, извините, ламо.
Более формально с академической точки зрения DJB и расписал. Без привязки к яп и прочим. У него общий подход к проблеме. А потом он для иллюстрации написал пару довольно безопасных программ. На си. И даже пообещал штуку зелени за взлом. При том там важна даже не штука зелени, как тот кто ее даст. Это почти как нобелевку получить, только в среде криптографов/безопасников.
> что это за программы, сколько в них строк кода, сколько времени у
> него на это ушло и кто проверял его код на безопасность?
Qmail, djbdns, криптографические либы, ... и таки да, там мало строк кода. В этом весь пойнт. Только маленькая программа может быть хорошо изучена, содержать мало багов, и потому - имеет шансы быть безопасной. Это весьма фундаментальное соотношение, не особо зависящее от ЯП.
Вот, просвещайся: https://en.wikipedia.org/wiki/Daniel_J._Bernstein - человек который безопасно пишет в том числе и на си. И вообще, в си чтобы безопасно писать достаточно помнить не так уж много простых правил. Для специальных применений, типа автомобилестроения, есть более суровые наборы правил типа MISRA C и автоматические валидаторы.
> да все вы разглагольствовать мастера. целый зоопарк пыхтит над несчастным пингвином, а
> из него, подлеца, продолжают лезть букашки..
Есть у програмеров свойство такое - ошибаться. При том это свойство от ЯП не зависит. Вон там питонисты рассказывают как приходится обкладывать каждую блин строку юнит-тестами и в результате тестов стало больше чем кода. И ты после этого на сишников наезжаешь? Да, блин, лол.

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

47. "Критические уязвимости в подсистеме eBPF ядра Linux" +2 +/–

Сообщение от Аноним (-), 24-Дек-17, 07:49

> я утверждаю, что C/C++ и подобные - это априори дыра в безопасности кода
> Plan9, Inferno, clive, gopher-os
Plan9 - ANSI C
Inferno - C
clive - Что это вообще? Даже гугл ответ не даёт.
gopher-os - Написано на GO, да, но примеры реального применения можно?

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

48. "Критические уязвимости в подсистеме eBPF ядра Linux" –1 +/–

Сообщение от Аноним (-), 24-Дек-17, 09:24

> Plan9 - ANSI C
молодец. читай дальше. спойлер для ленивых: там написано что отменено в пользу Inferno. а теперь 9front туда активно портирует Go
> Inferno - C
не 100%. а менее 50%. а если б проект не был заброшен, всё было бы, наверняка, переписано на Limbo. ибо таскает с собой сорцы вирт машины для компиляции и запуска на других осях.
>clive - Что это вообще? Даже гугл ответ не даёт.
lmgify: http://lsub.org/ls/clive.html
> gopher-os - Написано на GO, да, но примеры реального применения можно?
в README - там всё написано. академические цели и пруф оф концепт.. однако оно есть. и автор не поленился потрудиться и в одиночку почти написал рабочее ядро
нет, я, конечно, понимаю.. Линус уже всего добился, и деньги и работа у него есть.. какой ему смысл забросить курицу, которая несёт золотые яйца.. и вообще, сишники без работы так точно никогда не останутся, главное продолжать обновлять баги..

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

49. "Критические уязвимости в подсистеме eBPF ядра Linux" +/–

Сообщение от Аноним (-), 24-Дек-17, 10:11

Я даже спорить не буду, потому что в любом случае в любых ядрах используется ассемблер, даже в gopher, а ассемблер это ещё хуже С.

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

52. "Критические уязвимости в подсистеме eBPF ядра Linux" +/–

Сообщение от Ordu (ok), 24-Дек-17, 12:10

https://lesswrong.ru/w/%D0%A1%D0%BE%...

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

61. "Критические уязвимости в подсистеме eBPF ядра Linux" +/–

Сообщение от Аноним (-), 24-Дек-17, 15:21

А я и не утверждал что есть вообще что-то лучше. Всё в компьютерах плохо и все компьютеры подвержены уязвимостям де-факто. Единственный способ от них избавиться - избавиться от компьютеров, nuff said. А товарищ выше меня пытается убедить, что есть языки, которые уязвимостям не подвержены (потому что никто всерьёз не искал), я с такими сталкиваюсь каждый день и разводить полемику на этот счёт не очень то и хочется, мне кажется, что они просто тролли, считай что покормил.

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

63. "Критические уязвимости в подсистеме eBPF ядра Linux" +/–

Сообщение от Ordu (ok), 24-Дек-17, 16:57

> А я и не утверждал что есть вообще что-то лучше. Всё в
> компьютерах плохо и все компьютеры подвержены уязвимостям де-факто. Единственный способ
> от них избавиться - избавиться от компьютеров, nuff said.
Ну я и говорю: софизм серого. В попытке казаться взрослым и умудрённым опытом циником человек отказывается от чёрно-белого мышления, и вместо двуцветной картинки мира с однобитным цветом получает одноцветную с нульбитным. Полнейшая потеря способности воспринимать окружающий мир. Совершенно нереалистичные выводы, типа "надо отказаться от компьютеров". Ты ведь не можешь не понимать на каком-то уровне, что это не выход, что если нет способа писать безбажную программу, то это не значит, что нет способа писать менее бажную программу. На каком-то уровне понимаешь, но мышление спотыкается о нульбитность и останавливается, отказываясь выдавать более полезные продукты мышления нежели "отказаться от компьютеров".
> А товарищ
> выше меня пытается убедить, что есть языки, которые уязвимостям не подвержены
> (потому что никто всерьёз не искал), я с такими сталкиваюсь каждый
> день и разводить полемику на этот счёт не очень то и
> хочется, мне кажется, что они просто тролли, считай что покормил.
Ты хочешь сказать, что переход на одноцветную картинку вызван не попыткой преодолеть подростково-юношеские комплексы, а страхом покормить тролля? Я тебе раскрою секрет: чтобы гарантированно не кормить троллей надо не писать ничего в интернете. Это лучший способ. Но да, требует твёрдости духа и силы воли: тролли они те ещё манипуляторы, и хочешь не хочешь, а что-нибудь да напишешь им на радость. Хотя бы "я тебя игнорирую и не разговариваю с тобой" -- даже несмотря на то, что это самая развесёлая фраза для тролля, и именно ради неё он и работает: она показывает, что собеседник ввалился в глубокий конфликт, он не хочет продолжать разговор, но манипуляция сработала на отлично и он не может не продолжать, поэтому пишет фразу "я ничего не пишу".
И кстати: тебе _кажется_ что твой оппонент пытается убедить тебя в том, что "есть языки, которые уязвимостям не подвержены". Кажется в силу как раз твоей одноцветной картинки. Ну, ты сам прикинь, вот стоят перед тобой, допустим, 16777216 оппонентов и каждый показывает тебе карточку своего цвета, у всех разные карточки, покрывающие полный спектр 24-битного цвета. Но твоё восприятие одноцветно, и поэтому для тебя аргументы всех оппонентов выглядят одинаковыми. А среди этих аргументов есть почти чёрные, есть почти белые, есть откровенно серые, есть даже голубые. Но разница неуловима для тебя.
Софизмы и прочая демагогия -- это очень весёлая штука, чтобы стебать окружающих, но они обоюдоостры. Если ты ими пользуешься регулярно, ты привыкаешь ими пользоваться, и твои мозги вообще начинают работать таким образом автоматически, вплоть до искажения восприятия. Меняется твоя картинка мира, а ты этого даже не замечаешь. Собственно по этой причине совершенно невозможно общаться с политизированными и религиозными ребятами: они привыкли мыслить демагогически, и они даже не замечают этого. А если и замечают, то тут же рефлекторно вытесняют эти вещи, и продолжают "не замечать". Чтобы убедить их хоть в чём-то, даже несвязанном с политикой и религией, приходится полгода плотно разговаривать с ними на разные нейтральные для них темы, постепенно показывая им как можно мыслить эффективнее, в процессе они начинают воспринимать демагогические ходы мышления как ошибочные, и только после этого можно переходить к обсуждению с ними тем, которые им небезразличны.

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

65. "Критические уязвимости в подсистеме eBPF ядра Linux" +/–

Сообщение от Аноним (-), 24-Дек-17, 19:51

> Совершенно нереалистичные выводы, типа "надо отказаться от компьютеров".
А может ты ещё раз перечитаешь а потом пере-перечитаешь моё сообщение? Я хотел подчеркнуть, что для того, чтобы защититься нужно отказаться от компьютеров, что нереально. Я думал это очевидно.
> а страхом покормить тролля?
А ты демагог тот ещё, почище меня :) Вот переврал мои слова так переврал.
А ты строишь из себя недопсихолога. Чтобы быть действительно хорошим психологов в первую очередь нужно научиться понимать себя а потом переносить умные слова из учебников на других.

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

67. "Критические уязвимости в подсистеме eBPF ядра Linux" –1 +/–

Сообщение от Ordu (ok), 24-Дек-17, 20:45

>> Совершенно нереалистичные выводы, типа "надо отказаться от компьютеров".
> А может ты ещё раз перечитаешь а потом пере-перечитаешь моё сообщение? Я
> хотел подчеркнуть, что для того, чтобы защититься нужно отказаться от компьютеров,
> что нереально. Я думал это очевидно.
Очевидно. Но ты ведь закончил этим выводом. И я не вижу каким образом из этой точки ты можешь делать дальнейшие выводы, не отказываясь от своего нульбитного мышления. То есть не ставя крест на всех предыдущих своих рассуждениях. Я поставил этот крест за тебя, чтобы тебе не приходилось утруждать себя.
Защищаться надо, а отказываться от компьютеров недопустимо, что делать? Работать над технологиями, в частности над технологиями разработки софта, улучшая их до состояния, когда количество порождаемых багов будет минимальным. В частности, разрабатывая языки программирования, которые избавляют программиста от возможности совершать целые классы ошибок. Так ведь? Или не так?
Если так, то дальше возникают интересные догадки о том, что вынуждает тебя продолжать спор. Если не так, то объяснись -- твоя позиция непонятна.
>> а страхом покормить тролля?
> А ты демагог тот ещё, почище меня :) Вот переврал мои слова
> так переврал.
Не демагог, а как ты сам говоришь ниже -- недопсихолог. И это ты ещё не сталкивался с настоящими психологами. Вот те могут рассказать тебе про твои страхи столько, что тебе не останется ничего другого, кроме как пойти и повеситься с горя. Собственно именно поэтому, настоящие психологи, предпочитают держать свои наблюдения при себе, выдавая наружу либо конкретные рекомендации что делать, либо сократовские вопросы, которые позволяют клиенту строить своё собственное понимание происходящего в его голове, которое не включает страшного слова "страх". Или включает, если терапия идёт успешно настолько, что слово "страх" уже не страшно для клиента.
> А ты строишь из себя недопсихолога.
Вот это, кстати, тоже ошибка мышления. Я не строю из себя недопсихолога. Возможен вариант, что я строю из себя _психолога_, а получается не очень, но когда ты позволяешь себе "упрощённые" формулировки, ты опять же приучаешь свои мозги работать неверно. И в данном частном случае, и в общем тоже. Попробуй математику: она учит видеть неточности формулировок, тренирует мышление в формальных понятиях, и вообще всячески способствует развитию.
> Чтобы быть действительно хорошим психологов в
> первую очередь нужно научиться понимать себя а потом переносить умные слова
> из учебников на других.
Если бы я уподоблялся бы психологам, я бы сейчас начал бы тебе втирать про вытеснение страхов, про сопротивление, про перенос и конфронтацию. Про всё то, что сейчас здесь я могу наблюдать. Хотя нет, если бы я уподоблялся бы психологам, я бы сейчас начал задавать сократовские вопросы или конкретные рекомендации. Впрочем, по-крайней мере одну конкретную рекомендацию я уже выдал -- заняться математикой. То есть, наверное, ты всё же прав, и я уподобляюсь психологам.
А вообще, что тебе позволяет думать, что ты лучше меня знаешь, что нужно, для того, чтобы быть действительно хорошим психологом? Я в текущий момент более чем наполовину окончил своё второе образование, которое -- удивительное совпадение -- психологическое. Но что стоит за твоими словами?

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

83. "Критические уязвимости в подсистеме eBPF ядра Linux" +/–

Сообщение от Аноним (-), 26-Дек-17, 02:37

Ordu ты открыл мне глаза, большое человеческое спасибо!

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

70. "Критические уязвимости в подсистеме eBPF ядра Linux" –1 +/–

Сообщение от Аноним (-), 24-Дек-17, 21:00

> А ты строишь из себя недопсихолога. Чтобы быть действительно хорошим психологов в
> первую очередь нужно научиться понимать себя а потом переносить умные слова
> из учебников на других.
А ты научился понимать себя?

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

50. "Критические уязвимости в подсистеме eBPF ядра Linux" +/–

Сообщение от Аноним (-), 24-Дек-17, 10:14

Понимаешь в чём проблема, тем, что ты тут перечислил пользуются 2.5 гика. Остальные на Linux\*BSD. Когда тем, что ты перечислил начнут пользоваться серьёзные дяденьки, тут же начную выявлять кучу проблем, ошибок, недоработок, закладок в компиляторах\jit и б-г знает в чём ещё. Так что всё это временно. Пока я даже не вижу повсеместного использования того же GO.

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

86. "Критические уязвимости в подсистеме eBPF ядра Linux" +/–

Сообщение от Джон Ленин (?), 23-Фев-18, 23:09

>Вы забыли ссылку на своё беспроблемное, хоть и ни разу не гениальное, ядро.  Даже необязательно в исходниках.
Он какой-то левый утюг запакует щаз, и будет наблюдать как вы его тщетно загрузить пытаетесь.

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

51. "Критические уязвимости в подсистеме eBPF ядра Linux" +1 +/–

Сообщение от Ordu (ok), 24-Дек-17, 12:08

Ты б в описание багов заглянул, прежде чем утверждать подобное.

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

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

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

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

19. "Критические уязвимости в подсистеме eBPF ядра Linux"	–7 +/–
Сообщение от Аноним (-), 23-Дек-17, 18:27
>некорректным преобразованием типов и отсутствием должных проверок c-проблемы "гениальных" программистов
Ответить \| Правка \| Наверх \| Cообщить модератору


	21. "Критические уязвимости в подсистеме eBPF ядра Linux"	+/–
	Сообщение от Michael Shigorin (ok), 23-Дек-17, 19:11
	>>некорректным преобразованием типов и отсутствием должных проверок > c-проблемы "гениальных" программистов Вы забыли ссылку на своё беспроблемное, хоть и ни разу не гениальное, ядро. Даже необязательно в исходниках. PS @ 20190213: своё, о "преподаватель" _чужой_ матчасти.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	33. "Критические уязвимости в подсистеме eBPF ядра Linux"	–5 +/–
	Сообщение от Аноним (-), 23-Дек-17, 23:15
	>>>некорректным преобразованием типов и отсутствием должных проверок >> c-проблемы "гениальных" программистов > Вы забыли ссылку на своё беспроблемное, хоть и ни разу не гениальное, > ядро. Даже необязательно в исходниках. вы забыли (если вообще знали) матчасть, Мишенька. Plan9, Inferno, clive, gopher-os
	Ответить \| Правка \| Наверх \| Cообщить модератору


	34. "Критические уязвимости в подсистеме eBPF ядра Linux"	+2 +/–
	Сообщение от ыы (?), 23-Дек-17, 23:49
	Уточните пожалуйста: Вы утверждаете что все эти вещи написали Вы? или же Вы утверждаете что эти вещи не содержат проблемных мест?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	36. "Критические уязвимости в подсистеме eBPF ядра Linux"	–6 +/–
	Сообщение от Аноним (-), 24-Дек-17, 00:49
	> Уточните пожалуйста: пропущена запятая > Вы утверждаете что все эти вещи написали Вы? а что, о на этом форуме комментировать могут только те, кто пишут свои собственные ядра? > Вы утверждаете что эти вещи не содержат проблемных мест? я утверждаю, что C/C++ и подобные - это априори дыра в безопасности кода, и никакая "гениальность", как любят себя величать программизты этих языков, не помогает почему-то.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	37. "Критические уязвимости в подсистеме eBPF ядра Linux"	+1 +/–
	Сообщение от Аноним (-), 24-Дек-17, 01:04
	> пропущена запятая А у вас точно в конце предложения. Кстати.. предложения начинаются с большой буквы. Дальше продолжать будем? > я утверждаю, что C/C++ и подобные - это априори дыра в безопасности кода С чего Вы так решили? Или у вас <<ржавчина>> начала проявляться?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	38. "Критические уязвимости в подсистеме eBPF ядра Linux"	–3 +/–
	Сообщение от Аноним (-), 24-Дек-17, 01:34
	>> я утверждаю, что C/C++ и подобные - это априори дыра в безопасности кода > С чего Вы так решили? #. статистика; #. С банально устарел с тех пор как он был придуман; #. когда язык не загнан насильно в определённые рамки, это чревато последствиями - простая логика; #. работа с памятью и указателями - проблема создателей реализация языка, и не должна становиться проблемой программиста. инкапсуляция - слышали, нет?; #. в результате, C - не последний язык который придумали Ричи и Керниган; > Или у вас <<ржавчина>> начала проявляться? что-что??
	Ответить \| Правка \| Наверх \| Cообщить модератору


	41. "Критические уязвимости в подсистеме eBPF ядра Linux"	+/–
	Сообщение от Аноним (-), 24-Дек-17, 03:28
	> #. статистика; Статистика ЧЕГО? На си написано дофига кода. Наверное логично что в дофига кода - дофига багов. А вот на брейнфаке код мало кто пишет. Поэтому и уязвимостей мало. Но это ничего не говорит о безопасности программ на брейнфаке. > #. С банально устарел с тех пор как он был придуман; И что на его замену для системного программирования и прочих микроконтроллеров, интересно? Последние, кстати, работают в очень критичных применениях. Смотри не обделайся со страха, эксперт по безопасности. > #. когда язык не загнан насильно в определённые рамки, это чревато последствиями > - простая логика; С другой стороны, "создайте систему которой может пользоваться даже дурак и только дурак захочет ей пользоваться". > #. работа с памятью и указателями - проблема создателей реализация языка, и > не должна становиться проблемой программиста. инкапсуляция - слышали, нет?; А что если мне эффективнее перекинуть указатель чем 30-меговый буфер? А энкапсуляция (выучи как это пишется, позорник) может все усложнять, мешаться и делать поведение менее предсказуемым. Не все же пользуются компьютером в режиме маками. > #. в результате, C - не последний язык который придумали Ричи и Керниган; Но лучше для системного программирования так ничего и не появилось. Кроме, конечно же, развитий языка. На K&R C никто не пишет нынче, да и за си его большинство програмеров признает не сразу.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	43. "Критические уязвимости в подсистеме eBPF ядра Linux"	–1 +/–
	Сообщение от Аноним (-), 24-Дек-17, 03:55
	>> #. статистика; > Статистика ЧЕГО? На си написано дофига кода. Наверное логично что в дофига > кода - дофига багов. А вот на брейнфаке код мало кто > пишет. Поэтому и уязвимостей мало. Но это ничего не говорит о > безопасности программ на брейнфаке. в том и проблема. сколько уже было критических уязвимостей в линуксе и других фундаментальных gnu+linux утилитах за последние несколько лет? и в основном это всё одни и те же до.банные проблемы нарушений работы с памятью. _одни и те же_ . из раза в раз! почему так получается? человеческий фактор? и как же с этим бороться? может, давайте запретим программировать на опасных языках? или, может, всё таки нужно прощаться с языками которые допускают такое поведение в коде? >> #. С банально устарел с тех пор как он был придуман; > И что на его замену для системного программирования и прочих микроконтроллеров, интересно? > Последние, кстати, работают в очень критичных применениях. Смотри не обделайся со > страха, эксперт по безопасности. >Смотри не обделайся лол, вот и весь разговор с вами, "высокоинтеллектуалами": оскорбления, оскорбления.. у тебя по ходу комплекс неполноценности какой-то.. а что касается контроллеров, то и тут на Си клином свет не сошёлся. за тебя погуглить? даже паскаль в разы удобнее в этом. >> #. когда язык не загнан насильно в определённые рамки, это чревато последствиями >> - простая логика; > С другой стороны, "создайте систему которой может пользоваться даже дурак и только > дурак захочет ей пользоваться". а пока что дураки пишут Ланупсы.. и в России ракеты с гидро-метео спутниками в болота пускают.. >> #. работа с памятью и указателями - проблема создателей реализация языка, и >> не должна становиться проблемой программиста. инкапсуляция - слышали, нет?; > А что если мне эффективнее перекинуть указатель чем 30-меговый буфер? А энкапсуляция > (выучи как это пишется, позорник) может все усложнять, мешаться и делать > поведение менее предсказуемым. Не все же пользуются компьютером в режиме маками. >А что если мне эффективнее перекинуть указатель чем 30-меговый буфер? если у тебя возникают подобные вопросы в данном контексте, то тебе нужно пойти в отпуск, расслабиться и RTFM в конце концов.. >энкапсуляция > (выучи как это пишется, позорник) ты что, серьёзно? не зря ты анонима включил.. >> #. в результате, C - не последний язык который придумали Ричи и Керниган; > Но лучше для системного программирования так ничего и не появилось. ц > Кроме, конечно > же, развитий языка. На K&R C никто не пишет нынче, да > и за си его большинство програмеров признает не сразу. ой, надо Сишной Группе Разработчиков написать, что аноним с опеннет считает что они делают не C
	Ответить \| Правка \| Наверх \| Cообщить модератору


	66. "Критические уязвимости в подсистеме eBPF ядра Linux"	+2 +/–
	Сообщение от Аноним (-), 24-Дек-17, 19:57
	> в том и проблема. сколько уже было критических уязвимостей в линуксе и > других фундаментальных gnu+linux утилитах за последние несколько лет? Я бы понял эти претензии, если бы за тот же интервал времени не нашлось 100500 критичных дыр на чем угодно. У мозиллы в просмотрщике на JS, у апача в ява-спруте, moinmoin на питоне, рубисты не отстали, на пхп писала толпа и лоханулись кому не лень. С практической точки зрения больше всего систем взломано из-за вебни или из-за дефолтных паролей на вход. А дыры типа сабжа - как бы фи, но вред умеренный. Иногда даже польза в виде рутаных андроидов. > и в основном это всё одни и те же до.банные проблемы нарушений работы с > памятью. _одни и те же_ . из раза в раз! И что характерно в лине над ошибками работают. Но не так как ты себе это представляешь. > почему так получается? человеческий фактор? и как же с этим бороться? В лине прикрутили статические анализаторы и kasan и настроили fuzzing. А ты думаешь чего так бойко баги стали находить? Там и более продвинутый анализ воротят. > может, давайте запретим программировать на опасных языках? или, может, всё таки нужно > прощаться с языками которые допускают такое поведение в коде? Лично ты можешь идти и прощаться с всем чем пожелаешь. Более того - я тебя совершенно не заставляю моим кодом пользоваться. Как и все остальные разработчики. Вон на redox какой-нибудь вали и втирай там какой он офигенно безопасный. И хрен с ней с работающей операционкой и програмерами пишущими код, да? Самый безопасный компьютер все-равно выключенный, так что изволь. > тебя по ходу комплекс неполноценности какой-то.. Это я показываю наивной макаке с горящими глазами что на сишечке держится мнооооого чего критичного. И если следовать нехитрым правилам то получается весьма даже. Вопрос в отсутствии раздолбайского подхода в критичных местах, не более. > а что касается контроллеров, то и тут на Си клином свет не > сошёлся. за тебя погуглить? даже паскаль в разы удобнее в этом. Я эти микроконтроллеры програмлю, на секундочку. А ты - эксперт по гуглению с горящими глазами. Который ни в чем не разбирается, но мнение имеет. По всей отрасли еще поискать чудака который микроконтроли на паскакале удумает програмить. Чтоб ты знал - половина работы с МК это лобовая работа с памятью. Регистры у железа замаплены в память. И надо класть нужные значения в нужные адреса. Единственным достижением от паскаля на этом пути будет истошная борьба с ветряными мельницами. > а пока что дураки пишут Ланупсы.. и в России ракеты с гидро-метео > спутниками в болота пускают.. И только ты один весь в белом, мистер Дон Кихот? Иди, задай уже этим ветряным мельницам. > если у тебя возникают подобные вопросы в данном контексте, то тебе нужно > пойти в отпуск, расслабиться и RTFM в конце концов.. Какой ты шустрый всем указывать. Тю. > ты что, серьёзно? не зря ты анонима включил.. Ну ты то как умная клава сообщишь как тебя зовут? Интересно же кто такой гениальный. > ой, надо Сишной Группе Разработчиков написать, что аноним с опеннет считает что > они делают не C Ой, ты чистый K&R C вообще видел когда-нибудь? Он заметно отличается от современных диалектов. Даже от древнючего C89. Представляешь, синтаксис K&R даже не скомпилится современными компилерами, сишные проекты которые сейчас таки потомки/наследники C89.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	87. "Критические уязвимости в подсистеме eBPF ядра Linux"	+/–
	Сообщение от Джон Ленин (?), 23-Фев-18, 23:33
	Не парься. Их трудно как-нибудь просветить. Пофиг людям, что ракеты падают не из-за того, что инженеры дeбилы, а по другим причинам (например: отсутствие конкуренции, частных компаний, патентного права, поддержки, партнёрства, капитализации и вменяемого менеджмента + запугивание) Пофиг им и то, что ко всему ведру нельзя прикрутить какой-то адский супер-мега-анализатор сходу, потому-что оно такое огромное, что его даже шланг года 3 прожевать не может (хоть и очень старается) И вроде про rust им тоже объясняешь, типа "да, писание модулей как эксперимент -- это интересно и хорошо", они всё-равно недовольны. Но как начинаешь объяснять им что "ты радуйся, что они ассемблерных вставок хоть избегают" -- так уже "плохо, что избегают!" Говоришь им, что в PREEMPT/RT-ядрах есть зачатки микроядерности, и звук в джеке пишется хорошо... но они снова про 12309 поясняют... И вот никак же им не объяснишь, что на мобильных вендах всё в 1000 раз ужаснее, и что на яблочных девайсах поломали права (внезапный root), но после "починки" сломали ещё сильнее; и грузинским письмом яблоки как кирпичились 3 года назад, так и до сих пор кирпичатся.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	40. "Критические уязвимости в подсистеме eBPF ядра Linux"	+/–
	Сообщение от Аноним (-), 24-Дек-17, 03:22
	> я утверждаю, что C/C++ и подобные - это априори дыра в безопасности > кода, и никакая "гениальность", как любят себя величать программизты этих языков, > не помогает почему-то. Видный специалист в криптографии и безопасности DJB готов с вами поспорить. Он как раз таки на си написал несколько вполне безопасных программ и даже формально обосновал как делать программы безопаснее. И почему именно так.
	Ответить \| Правка \| К родителю #36 \| Наверх \| Cообщить модератору


	42. "Критические уязвимости в подсистеме eBPF ядра Linux"	–2 +/–
	Сообщение от Аноним (-), 24-Дек-17, 03:33
	>Видный специалист в криптографии и безопасности DJB готов с вами поспорить да что вы говорите.. и сколько лет у него уйдёт, чтобы переписать Linux и выложить результат в свободный доступ? > Он > как раз таки на си написал несколько вполне безопасных программ и > даже формально обосновал как делать программы безопаснее. что это за программы, сколько в них строк кода, сколько времени у него на это ушло и кто проверял его код на безопасность? --- да все вы разглагольствовать мастера. целый зоопарк пыхтит над несчастным пингвином, а из него, подлеца, продолжают лезть букашки..
	Ответить \| Правка \| Наверх \| Cообщить модератору


	45. "Критические уязвимости в подсистеме eBPF ядра Linux"	+1 +/–
	Сообщение от . (?), 24-Дек-17, 07:20
	>>Видный специалист в криптографии и безопасности DJB готов с вами поспорить >да что вы говорите.. и сколько лет у него уйдёт, чтобы переписать Linux и выложить результат в свободный доступ? Наверное много. Но весь прикол в том что на чём то другом - не напишут вообше :-р А с другойстороны - конкретно ты - вообще не напишешь. Ыма мало, гонора - много. Таких не берут в кocмoнавты! (С) :-)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	46. "Критические уязвимости в подсистеме eBPF ядра Linux"	+/–
	Сообщение от Аноним (-), 24-Дек-17, 07:38
	> Но весь прикол в том что на чём то другом - не напишут вообше :-р > А с другойстороны - конкретно ты - вообще не напишешь. мда, докультивировались тут на опёнке..
	Ответить \| Правка \| Наверх \| Cообщить модератору


	68. "Критические уязвимости в подсистеме eBPF ядра Linux"	+/–
	Сообщение от Аноним (-), 24-Дек-17, 20:48
	> да что вы говорите.. и сколько лет у него уйдёт, чтобы переписать > Linux и выложить результат в свободный доступ? Проект размером с Linux неизбежно будет содержать много багов. Часть из них окажется проблемами безопасности. Это данность процесса разработки софта. А любой кто этого не понимает, извините, ламо. Более формально с академической точки зрения DJB и расписал. Без привязки к яп и прочим. У него общий подход к проблеме. А потом он для иллюстрации написал пару довольно безопасных программ. На си. И даже пообещал штуку зелени за взлом. При том там важна даже не штука зелени, как тот кто ее даст. Это почти как нобелевку получить, только в среде криптографов/безопасников. > что это за программы, сколько в них строк кода, сколько времени у > него на это ушло и кто проверял его код на безопасность? Qmail, djbdns, криптографические либы, ... и таки да, там мало строк кода. В этом весь пойнт. Только маленькая программа может быть хорошо изучена, содержать мало багов, и потому - имеет шансы быть безопасной. Это весьма фундаментальное соотношение, не особо зависящее от ЯП. Вот, просвещайся: https://en.wikipedia.org/wiki/Daniel_J._Bernstein - человек который безопасно пишет в том числе и на си. И вообще, в си чтобы безопасно писать достаточно помнить не так уж много простых правил. Для специальных применений, типа автомобилестроения, есть более суровые наборы правил типа MISRA C и автоматические валидаторы. > да все вы разглагольствовать мастера. целый зоопарк пыхтит над несчастным пингвином, а > из него, подлеца, продолжают лезть букашки.. Есть у програмеров свойство такое - ошибаться. При том это свойство от ЯП не зависит. Вон там питонисты рассказывают как приходится обкладывать каждую блин строку юнит-тестами и в результате тестов стало больше чем кода. И ты после этого на сишников наезжаешь? Да, блин, лол.
	Ответить \| Правка \| К родителю #42 \| Наверх \| Cообщить модератору


	47. "Критические уязвимости в подсистеме eBPF ядра Linux"	+2 +/–
	Сообщение от Аноним (-), 24-Дек-17, 07:49
	> я утверждаю, что C/C++ и подобные - это априори дыра в безопасности кода > Plan9, Inferno, clive, gopher-os Plan9 - ANSI C Inferno - C clive - Что это вообще? Даже гугл ответ не даёт. gopher-os - Написано на GO, да, но примеры реального применения можно?
	Ответить \| Правка \| К родителю #36 \| Наверх \| Cообщить модератору


	48. "Критические уязвимости в подсистеме eBPF ядра Linux"	–1 +/–
	Сообщение от Аноним (-), 24-Дек-17, 09:24
	> Plan9 - ANSI C молодец. читай дальше. спойлер для ленивых: там написано что отменено в пользу Inferno. а теперь 9front туда активно портирует Go > Inferno - C не 100%. а менее 50%. а если б проект не был заброшен, всё было бы, наверняка, переписано на Limbo. ибо таскает с собой сорцы вирт машины для компиляции и запуска на других осях. >clive - Что это вообще? Даже гугл ответ не даёт. lmgify: http://lsub.org/ls/clive.html > gopher-os - Написано на GO, да, но примеры реального применения можно? в README - там всё написано. академические цели и пруф оф концепт.. однако оно есть. и автор не поленился потрудиться и в одиночку почти написал рабочее ядро нет, я, конечно, понимаю.. Линус уже всего добился, и деньги и работа у него есть.. какой ему смысл забросить курицу, которая несёт золотые яйца.. и вообще, сишники без работы так точно никогда не останутся, главное продолжать обновлять баги..
	Ответить \| Правка \| Наверх \| Cообщить модератору


	49. "Критические уязвимости в подсистеме eBPF ядра Linux"	+/–
	Сообщение от Аноним (-), 24-Дек-17, 10:11
	Я даже спорить не буду, потому что в любом случае в любых ядрах используется ассемблер, даже в gopher, а ассемблер это ещё хуже С.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	52. "Критические уязвимости в подсистеме eBPF ядра Linux"	+/–
	Сообщение от Ordu (ok), 24-Дек-17, 12:10
	https://lesswrong.ru/w/%D0%A1%D0%BE%...
	Ответить \| Правка \| Наверх \| Cообщить модератору


	61. "Критические уязвимости в подсистеме eBPF ядра Linux"	+/–
	Сообщение от Аноним (-), 24-Дек-17, 15:21
	А я и не утверждал что есть вообще что-то лучше. Всё в компьютерах плохо и все компьютеры подвержены уязвимостям де-факто. Единственный способ от них избавиться - избавиться от компьютеров, nuff said. А товарищ выше меня пытается убедить, что есть языки, которые уязвимостям не подвержены (потому что никто всерьёз не искал), я с такими сталкиваюсь каждый день и разводить полемику на этот счёт не очень то и хочется, мне кажется, что они просто тролли, считай что покормил.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	63. "Критические уязвимости в подсистеме eBPF ядра Linux"	+/–
	Сообщение от Ordu (ok), 24-Дек-17, 16:57
	> А я и не утверждал что есть вообще что-то лучше. Всё в > компьютерах плохо и все компьютеры подвержены уязвимостям де-факто. Единственный способ > от них избавиться - избавиться от компьютеров, nuff said. Ну я и говорю: софизм серого. В попытке казаться взрослым и умудрённым опытом циником человек отказывается от чёрно-белого мышления, и вместо двуцветной картинки мира с однобитным цветом получает одноцветную с нульбитным. Полнейшая потеря способности воспринимать окружающий мир. Совершенно нереалистичные выводы, типа "надо отказаться от компьютеров". Ты ведь не можешь не понимать на каком-то уровне, что это не выход, что если нет способа писать безбажную программу, то это не значит, что нет способа писать менее бажную программу. На каком-то уровне понимаешь, но мышление спотыкается о нульбитность и останавливается, отказываясь выдавать более полезные продукты мышления нежели "отказаться от компьютеров". > А товарищ > выше меня пытается убедить, что есть языки, которые уязвимостям не подвержены > (потому что никто всерьёз не искал), я с такими сталкиваюсь каждый > день и разводить полемику на этот счёт не очень то и > хочется, мне кажется, что они просто тролли, считай что покормил. Ты хочешь сказать, что переход на одноцветную картинку вызван не попыткой преодолеть подростково-юношеские комплексы, а страхом покормить тролля? Я тебе раскрою секрет: чтобы гарантированно не кормить троллей надо не писать ничего в интернете. Это лучший способ. Но да, требует твёрдости духа и силы воли: тролли они те ещё манипуляторы, и хочешь не хочешь, а что-нибудь да напишешь им на радость. Хотя бы "я тебя игнорирую и не разговариваю с тобой" -- даже несмотря на то, что это самая развесёлая фраза для тролля, и именно ради неё он и работает: она показывает, что собеседник ввалился в глубокий конфликт, он не хочет продолжать разговор, но манипуляция сработала на отлично и он не может не продолжать, поэтому пишет фразу "я ничего не пишу". И кстати: тебе _кажется_ что твой оппонент пытается убедить тебя в том, что "есть языки, которые уязвимостям не подвержены". Кажется в силу как раз твоей одноцветной картинки. Ну, ты сам прикинь, вот стоят перед тобой, допустим, 16777216 оппонентов и каждый показывает тебе карточку своего цвета, у всех разные карточки, покрывающие полный спектр 24-битного цвета. Но твоё восприятие одноцветно, и поэтому для тебя аргументы всех оппонентов выглядят одинаковыми. А среди этих аргументов есть почти чёрные, есть почти белые, есть откровенно серые, есть даже голубые. Но разница неуловима для тебя. Софизмы и прочая демагогия -- это очень весёлая штука, чтобы стебать окружающих, но они обоюдоостры. Если ты ими пользуешься регулярно, ты привыкаешь ими пользоваться, и твои мозги вообще начинают работать таким образом автоматически, вплоть до искажения восприятия. Меняется твоя картинка мира, а ты этого даже не замечаешь. Собственно по этой причине совершенно невозможно общаться с политизированными и религиозными ребятами: они привыкли мыслить демагогически, и они даже не замечают этого. А если и замечают, то тут же рефлекторно вытесняют эти вещи, и продолжают "не замечать". Чтобы убедить их хоть в чём-то, даже несвязанном с политикой и религией, приходится полгода плотно разговаривать с ними на разные нейтральные для них темы, постепенно показывая им как можно мыслить эффективнее, в процессе они начинают воспринимать демагогические ходы мышления как ошибочные, и только после этого можно переходить к обсуждению с ними тем, которые им небезразличны.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	65. "Критические уязвимости в подсистеме eBPF ядра Linux"	+/–
	Сообщение от Аноним (-), 24-Дек-17, 19:51
	> Совершенно нереалистичные выводы, типа "надо отказаться от компьютеров". А может ты ещё раз перечитаешь а потом пере-перечитаешь моё сообщение? Я хотел подчеркнуть, что для того, чтобы защититься нужно отказаться от компьютеров, что нереально. Я думал это очевидно. > а страхом покормить тролля? А ты демагог тот ещё, почище меня :) Вот переврал мои слова так переврал. А ты строишь из себя недопсихолога. Чтобы быть действительно хорошим психологов в первую очередь нужно научиться понимать себя а потом переносить умные слова из учебников на других.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	67. "Критические уязвимости в подсистеме eBPF ядра Linux"	–1 +/–
	Сообщение от Ordu (ok), 24-Дек-17, 20:45
	>> Совершенно нереалистичные выводы, типа "надо отказаться от компьютеров". > А может ты ещё раз перечитаешь а потом пере-перечитаешь моё сообщение? Я > хотел подчеркнуть, что для того, чтобы защититься нужно отказаться от компьютеров, > что нереально. Я думал это очевидно. Очевидно. Но ты ведь закончил этим выводом. И я не вижу каким образом из этой точки ты можешь делать дальнейшие выводы, не отказываясь от своего нульбитного мышления. То есть не ставя крест на всех предыдущих своих рассуждениях. Я поставил этот крест за тебя, чтобы тебе не приходилось утруждать себя. Защищаться надо, а отказываться от компьютеров недопустимо, что делать? Работать над технологиями, в частности над технологиями разработки софта, улучшая их до состояния, когда количество порождаемых багов будет минимальным. В частности, разрабатывая языки программирования, которые избавляют программиста от возможности совершать целые классы ошибок. Так ведь? Или не так? Если так, то дальше возникают интересные догадки о том, что вынуждает тебя продолжать спор. Если не так, то объяснись -- твоя позиция непонятна. >> а страхом покормить тролля? > А ты демагог тот ещё, почище меня :) Вот переврал мои слова > так переврал. Не демагог, а как ты сам говоришь ниже -- недопсихолог. И это ты ещё не сталкивался с настоящими психологами. Вот те могут рассказать тебе про твои страхи столько, что тебе не останется ничего другого, кроме как пойти и повеситься с горя. Собственно именно поэтому, настоящие психологи, предпочитают держать свои наблюдения при себе, выдавая наружу либо конкретные рекомендации что делать, либо сократовские вопросы, которые позволяют клиенту строить своё собственное понимание происходящего в его голове, которое не включает страшного слова "страх". Или включает, если терапия идёт успешно настолько, что слово "страх" уже не страшно для клиента. > А ты строишь из себя недопсихолога. Вот это, кстати, тоже ошибка мышления. Я не строю из себя недопсихолога. Возможен вариант, что я строю из себя _психолога_, а получается не очень, но когда ты позволяешь себе "упрощённые" формулировки, ты опять же приучаешь свои мозги работать неверно. И в данном частном случае, и в общем тоже. Попробуй математику: она учит видеть неточности формулировок, тренирует мышление в формальных понятиях, и вообще всячески способствует развитию. > Чтобы быть действительно хорошим психологов в > первую очередь нужно научиться понимать себя а потом переносить умные слова > из учебников на других. Если бы я уподоблялся бы психологам, я бы сейчас начал бы тебе втирать про вытеснение страхов, про сопротивление, про перенос и конфронтацию. Про всё то, что сейчас здесь я могу наблюдать. Хотя нет, если бы я уподоблялся бы психологам, я бы сейчас начал задавать сократовские вопросы или конкретные рекомендации. Впрочем, по-крайней мере одну конкретную рекомендацию я уже выдал -- заняться математикой. То есть, наверное, ты всё же прав, и я уподобляюсь психологам. А вообще, что тебе позволяет думать, что ты лучше меня знаешь, что нужно, для того, чтобы быть действительно хорошим психологом? Я в текущий момент более чем наполовину окончил своё второе образование, которое -- удивительное совпадение -- психологическое. Но что стоит за твоими словами?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	83. "Критические уязвимости в подсистеме eBPF ядра Linux"	+/–
	Сообщение от Аноним (-), 26-Дек-17, 02:37
	Ordu ты открыл мне глаза, большое человеческое спасибо!
	Ответить \| Правка \| К родителю #67 \| Наверх \| Cообщить модератору


	70. "Критические уязвимости в подсистеме eBPF ядра Linux"	–1 +/–
	Сообщение от Аноним (-), 24-Дек-17, 21:00
	> А ты строишь из себя недопсихолога. Чтобы быть действительно хорошим психологов в > первую очередь нужно научиться понимать себя а потом переносить умные слова > из учебников на других. А ты научился понимать себя?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	50. "Критические уязвимости в подсистеме eBPF ядра Linux"	+/–
	Сообщение от Аноним (-), 24-Дек-17, 10:14
	Понимаешь в чём проблема, тем, что ты тут перечислил пользуются 2.5 гика. Остальные на Linux\*BSD. Когда тем, что ты перечислил начнут пользоваться серьёзные дяденьки, тут же начную выявлять кучу проблем, ошибок, недоработок, закладок в компиляторах\jit и б-г знает в чём ещё. Так что всё это временно. Пока я даже не вижу повсеместного использования того же GO.
	Ответить \| Правка \| К родителю #48 \| Наверх \| Cообщить модератору


	86. "Критические уязвимости в подсистеме eBPF ядра Linux"	+/–
	Сообщение от Джон Ленин (?), 23-Фев-18, 23:09
	>Вы забыли ссылку на своё беспроблемное, хоть и ни разу не гениальное, ядро. Даже необязательно в исходниках. Он какой-то левый утюг запакует щаз, и будет наблюдать как вы его тщетно загрузить пытаетесь.
	Ответить \| Правка \| К родителю #21 \| Наверх \| Cообщить модератору


	51. "Критические уязвимости в подсистеме eBPF ядра Linux"	+1 +/–
	Сообщение от Ordu (ok), 24-Дек-17, 12:08
	Ты б в описание багов заглянул, прежде чем утверждать подобное.
	Ответить \| Правка \| К родителю #19 \| Наверх \| Cообщить модератору