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

"Критические уязвимости в подсистеме eBPF ядра Linux"	+/–
Сообщение от opennews (??), 23-Дек-17, 11:04
В подсистеме eBPF (http://prototype-kernel.readthedocs.io/en/latest/bpf/), позволяющей запускать обработчики для трассировки, анализа работы подсистем и управления трафиком, выполняемые внутри ядра в специальной виртуальной машине с JIT, выявлена (http://openwall.com/lists/oss-security/2017/12/21/2) серия уязвимостей, которые могут быть использованы локальным атакующим для запуска кода с правами ядра через загрузку специально оформленного eBPF-приложения. Выявленные уязвимости проявляются в ядрах Linux 4.9+ и 4.14+, но в общем виде проблемы в eBPF представляют опасность начиная с ядра 4.4, в котором появилась возможность загрузки программ eBPF непривилегированными пользователями. Так как помимо опубликованных исследователями прототипов эксплоитов (https://bugs.chromium.org/p/project-zero/issues/detail?id=14...) в сети выявлено (https://www.decadent.org.uk/ben/blog/bpf-security-issues-in-...) наличие публично доступного рабочего эксплоита для получения root-доступа через данные уязвимости, рекомендуется срочно отключить поддержку запуска eBPF непривилегированными пользователями при помощи "sysctl kernel.unprivileged_bpf_disabled=1", что приведёт к невозможности использования обычными пользователями средств трассировки и анализа производительности (https://www.opennet.ru/opennews/art.shtml?num=45391) на базе eBPF. Исправление пока доступно только в виде (https://git.kernel.org/linus/0c17d1d2c61936401f4702e1846e2c1...) патчей (https://git.kernel.org/linus/3db9128fcf02dcaafa3860a69a8a55d...), которые ещё не включены в основной состав ядра. Дистрибутивы пока не выпустили обновления: Debian (https://security-tracker.debian.org/tracker/CVE-2017-16995),  openSUSE (https://lists.opensuse.org/opensuse-security-announce/2017-12/), Fedora (https://bugzilla.redhat.com/show_bug.cgi?id=1528519) и Ubuntu (https://people.canonical.com/~ubuntu-security/cve/2017/CVE-2...). Проблемы не затрагивают ядро из состава SUSE Linux Enterprise (https://www.suse.com/security/cve/CVE-2017-16995/) и Red Hat Enterprise Linux 5, 6 и 7 (https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2017-16996). Отмечается, что публично доступные эксплоиты корректно не работают в Debian 9 с ядром 4.9 (eBPF включен по умолчанию для обычных пользователей), но, по мнению разработчиков (https://www.decadent.org.uk/ben/blog/bpf-security-issues-in-...) Debian, могут быть легко адаптированы для атаки. Уязвимости вызваны восемью ошибками (CVE-2017-16996 (https://security-tracker.debian.org/tracker/CVE-2017-16996)), появившимися в ядре 4.14, и одной ошибкой в ядре 4.9 (CVE-2017-16995 (https://security-tracker.debian.org/tracker/CVE-2017-16995)). Проблемы вызваны (https://bugs.chromium.org/p/project-zero/issues/detail?id=14...) некорректным преобразованием типов и отсутствием должных проверок в коде верификации eBPF-приложений (bpf/verifier.c), что позволяет осуществлять управляемое чтение и запись в произвольные области памяти ядра. Ряд проблем вызван тем, что в проверочном вызове check_alu_op() не осуществляется разделение между операциями BPF_ALU64|BPF_MOV|BPF_K (знаковое заполнение при чтение 32-разрядных значений в 64-разрядные ячейки) и BPF_ALU|BPF_MOV|BPF_K (добавочное заполнение нулями). Другие проблемы связаны с некорректным обрезанием значений регистров при преобразовании в значения меньшего размера, отсутствием проверки выхода за границы и выравнивания указателя стека. URL: http://openwall.com/lists/oss-security/2017/12/21/2 Новость: https://www.opennet.ru/opennews/art.shtml?num=47792
Ответить | Правка | Cообщить модератору

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

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

1. "Критические уязвимости в подсистеме eBPF ядра Linux"	–5 +/–
Сообщение от Аноним (-), 23-Дек-17, 11:04
А ведь eBPF почти продвинули как адекватную альтернативу DTrace, но видно не судьба и после такого никто в трезвом уме не будет unprivileged bpf оставлять. С безопасностью там, судя по всему, всё очень плохо, если в первый же заход 9 уязвимостей нашли.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	2. "Критические уязвимости в подсистеме eBPF ядра Linux"	+3 +/–
	Сообщение от Аноним (-), 23-Дек-17, 11:19
	Отладкой всё равно занимаются на локалхосте, где повышение привилегий не страшно. А вот по умолчанию лучше бы отключить, пока не вылижут.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	7. "Критические уязвимости в подсистеме eBPF ядра Linux"	+/–
	Сообщение от Аноним (-), 23-Дек-17, 13:59
	Цимес DTrace именно в том, что он был создан для анализа проблем в продакшене, т.е. гарантирует что что бы ты ни сделал, никакие приложения не грохнутся, не изменят своего состояния, и вообще система не уйдет в паник. Это все на солярке конечно, на линуксе я слышал он работает не лучше других трассировочных поделок
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

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

	27. "Критические уязвимости в подсистеме eBPF ядра Linux"	+/–
	Сообщение от EHLO (?), 23-Дек-17, 19:26
	> Цимес DTrace именно в том, что он был создан для анализа проблем > в продакшене, т.е. гарантирует что что бы ты ни сделал, никакие > приложения не грохнутся, не изменят своего состояния, и вообще система не > уйдет в паник. Это все на солярке конечно, на линуксе я > слышал он работает не лучше других трассировочных поделок В Солярисе DTrace можно было(sic!) пользоваться без повышения привилегий?
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	56. "Критические уязвимости в подсистеме eBPF ядра Linux"	+/–
	Сообщение от Знаток (?), 24-Дек-17, 12:53
	> В Солярисе DTrace можно было(sic!) пользоваться без повышения привилегий? Да, и во FreeBSD тоже. Всё, что доступно тебе для отладки, доступно и для DTrace.
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	58. "Критические уязвимости в подсистеме eBPF ядра Linux"	+1 +/–
	Сообщение от EHLO (?), 24-Дек-17, 13:24
	>> В Солярисе DTrace можно было(sic!) пользоваться без повышения привилегий? > Да, и во FreeBSD тоже. Всё, что доступно тебе для отладки, доступно > и для DTrace. Не знаток проприетари, но простое гугление подсказывает, что в Оракле с тобой не согласны: https://docs.oracle.com/cd/E26502_01/html/E28556/gkygl.html "Users need at least one of the three DTrace privileges in order to use any of the DTrace functionality." ну поскольку начинается юление, давай уточнять. Возможно профилирование внутри ядра для непривилегированного юзера без повышения привилегий?
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	64. "Критические уязвимости в подсистеме eBPF ядра Linux"	+1 +/–
	Сообщение от Аноним (-), 24-Дек-17, 17:05
	>> В Солярисе DTrace можно было(sic!) пользоваться без повышения привилегий? > Да, и во FreeBSD тоже. Всё, что доступно тебе для отладки, доступно и для DTrace. анон@bsd % /usr/share/dtrace/watch_execve   dtrace: failed to initialize dtrace: DTrace requires additional privileges root@bsd # sysctl security.bsd.unprivileged_proc_debug:1 security.bsd.unprivileged_proc_debug: 0 -> 1 aнон@bsd % /usr/share/dtrace/watch_execve dtrace: failed to initialize dtrace: DTrace requires additional privileges aнон@bsd % truss /usr/share/dtrace/watch_execve|tail openat(AT_FDCWD,"/dev/dtrace/fbt",O_RDONLY|O_CLOEXEC,00) ERR#13 'Permission denied' openat(AT_FDCWD,"/dev/dtrace/nfscl",O_RDONLY|O_CLOEXEC,00) ERR#2 'No such file or directory' openat(AT_FDCWD,"/dev/dtrace/dtmalloc",O_RDONLY|O_CLOEXEC,00) ERR#13 'Permission denied' openat(AT_FDCWD,"/dev/dtrace/dtrace",O_RDWR|O_CLOEXEC,00) ERR#13 'Permission denied' openat(AT_FDCWD,"/dev/dtrace/fasttrap",O_RDWR|O_CLOEXEC,00) ERR#13 'Permission denied' dtrace: write(2,"dtrace: ",8)                 = 8 (0x8) failed to initialize dtrace: DTrace requires additional privileges write(2,"failed to initialize dtrace: DTr"...,67) = 67 (0x43) exit(0x1)                     process exit, rval = 1
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	72. "Критические уязвимости в подсистеме eBPF ядра Linux"	+/–
	Сообщение от Аноним (-), 24-Дек-17, 21:07
	> root@bsd # sysctl security.bsd.unprivileged_proc_debug:1 По-моему, в сабже как раз и написано популярным языком что после этого ожидать...
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	73. "Критические уязвимости в подсистеме eBPF ядра Linux"	+1 +/–
	Сообщение от Аноним (-), 25-Дек-17, 02:51
	>> root@bsd # sysctl security.bsd.unprivileged_proc_debug:1 > По-моему, в сабже как раз и написано популярным языком что после этого > ожидать... Сабж про пингвина. Это: > sysctl -d security.bsd.unprivileged_proc_debug > security.bsd.unprivileged_proc_debug: Unprivileged processes may use process debugging facilities разрешает неруту запускать дебагер в бзде. А отвечал я вообще на: > Да, и во FreeBSD тоже. Всё, что доступно тебе для отладки, доступно и для DTrace. Что, как видно из лога, не соответсвует реальности.
	Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

	77. "Критические уязвимости в подсистеме eBPF ядра Linux"	+/–
	Сообщение от Аноним (-), 26-Дек-17, 00:09
	> Сабж про пингвина. И там как раз написано что случается после того как нерут что-нибудь основательно отдебажит. Как угодно но дебагинг это сложная и привилегированная штука, откуда вытекают некоторые соотношения.
	Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

	81. "Критические уязвимости в подсистеме eBPF ядра Linux"	+/–
	Сообщение от EHLO (?), 26-Дек-17, 01:16
	>> Сабж про пингвина. > И там как раз написано что случается после того как нерут что-нибудь > основательно отдебажит. Как угодно но дебагинг это сложная и привилегированная штука, > откуда вытекают некоторые соотношения. Что ж теперь strace-ом и gdb юзерам запретить пользоваться?
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

	85. "Критические уязвимости в подсистеме eBPF ядра Linux"	+/–
	Сообщение от Аноним (-), 26-Дек-17, 19:09
	> Что ж теперь strace-ом и gdb юзерам запретить пользоваться? Представляешь, было vuln-ов связанных с трассировкой процессов. И в лине и в бздях. Уж ptrace какой-нибудь отродясь подставлял все что можно.
	Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

	84. "Критические уязвимости в подсистеме eBPF ядра Linux"	+/–
	Сообщение от Аноним (-), 26-Дек-17, 02:50
	>> Сабж про пингвина. > И там как раз написано что случается после того как нерут что-нибудь > основательно отдебажит. Как угодно но дебагинг это сложная и привилегированная штука, > откуда вытекают некоторые соотношения. Однако, простой дебагинг приложения, без "влезания" в ядро, намного более простая штука, чем сабж с  JIT. Но, повторюсь - тема этой ветки было утверждение анонима что в солярисе и бзде dtrace можно было использовать без дополнительных привелегий. Это не так. Возможно, анон перепутал с truss, которым можно потрейсить системные вызовы (аналог strace).
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

5. "Критические уязвимости в подсистеме eBPF ядра Linux"	+5 +/–
Сообщение от Аноним (-), 23-Дек-17, 11:44
Целый год радовали уязвимости, доступные через user namespace, а теперь настал черёд eBPF. Кому вообще в голову пришло по дефолту включать их для обычных пользователей.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	10. "Критические уязвимости в подсистеме eBPF ядра Linux"	–1 +/–
	Сообщение от Нанобот (ok), 23-Дек-17, 14:13
	> Кому вообще в голову пришло по дефолту включать их для обычных пользователей? Если не ошибаюсь, оно используется песочницой хромиума для изоляции рабочих процессов
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	35. "Критические уязвимости в подсистеме eBPF ядра Linux"	+/–
	Сообщение от Мое имя (?), 24-Дек-17, 00:42
	в скрытых настройках хрома присутствует этот параметр.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	53. "Критические уязвимости в подсистеме eBPF ядра Linux"	+/–
	Сообщение от Аноним (-), 24-Дек-17, 12:29
	Покажи, что ли.
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	14. "Критические уязвимости в подсистеме eBPF ядра Linux"	+/–
	Сообщение от пох (?), 23-Дек-17, 16:53
	> Кому вообще в голову пришло по дефолту включать их для обычных пользователей. тем, разумеется, кто ни разу не жаждал давать программистам для отладки рутовый доступ на прод.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	30. "Критические уязвимости в подсистеме eBPF ядра Linux"	+2 +/–
	Сообщение от EHLO (?), 23-Дек-17, 20:45
	>> Кому вообще в голову пришло по дефолту включать их для обычных пользователей. > тем, разумеется, кто ни разу не жаждал давать программистам для отладки рутовый > доступ на прод. То есть программисты, занимающиеся отладкой в проде без рутового доступа -- это нормально? =))
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	57. "Критические уязвимости в подсистеме eBPF ядра Linux"	+/–
	Сообщение от Знаток (?), 24-Дек-17, 12:55
	> То есть программисты, занимающиеся отладкой в проде без рутового доступа -- это > нормально? =)) Нормально, если они занимаются выяснением проблемы, где именно тормозит вот этот вот JOIN шести уровней. Вообще говоря, Sun Microsystems презентовала DTrace как инструмент для решения проблемы с тормозами Oracle.
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	59. "Критические уязвимости в подсистеме eBPF ядра Linux"	+2 +/–
	Сообщение от EHLO (?), 24-Дек-17, 13:30
	>> То есть программисты, занимающиеся отладкой в проде без рутового доступа -- это >> нормально? =)) > Нормально, если они занимаются выяснением проблемы, где именно тормозит вот этот вот > JOIN шести уровней. > Вообще говоря, Sun Microsystems презентовала DTrace как инструмент для решения проблемы > с тормозами Oracle. Соболезную эксплуататорам и разработчикам проприетари. Что еще могу сказать, для нас отладка в проде, как и разработчики ковыряющиеся в проде, это как минимум нештатная ситуация.
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

	60. "Критические уязвимости в подсистеме eBPF ядра Linux"	+2 +/–
	Сообщение от Аноним (-), 24-Дек-17, 14:29
	соболезную авторам Hello-world. Которым не приходится собирать данные о работе программы в продакшене, из-за какого нить рейса в коде.
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	62. "Критические уязвимости в подсистеме eBPF ядра Linux"	+2 +/–
	Сообщение от EHLO (?), 24-Дек-17, 15:24
	> соболезную авторам Hello-world. Которым не приходится собирать данные о работе программы > в продакшене, из-за какого нить рейса в коде. Не соболезную анонимам, которые не знают что такое отладка. "продакшену" в котором разработчиком и админом работает один и тот же анонимный эникей-переросток продолжаю соболезновать.
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	39. "Критические уязвимости в подсистеме eBPF ядра Linux"	+1 +/–
	Сообщение от Аноним (-), 24-Дек-17, 03:20
	> тем, разумеется, кто ни разу не жаждал давать программистам для отладки рутовый > доступ на прод. Тяжела и неказиста участь тех кто не смог в контейнеры и виртуалки. А чего такого ужасного если прогер получит рут в виртуалке? Хостеры такого рута вообще каждому встречному раздают.
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

6. "Критические уязвимости в подсистеме eBPF ядра Linux"	+/–
Сообщение от Аноним (-), 23-Дек-17, 13:04
>Уязвимости вызваны восемью ошибками (CVE-2017-16996), появившимися в ядре 4.14 По ссылке уязвимости в 8-ми разных версиях ядра в разных версиях Debian, откуда взята информация про 8-мь ошибок появившихся в ядре 4.14?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	8. "Критические уязвимости в подсистеме eBPF ядра Linux"	+1 +/–
	Сообщение от Аноним (-), 23-Дек-17, 14:00
	The following bug was introduced in 4.9: * fixed by "bpf: fix incorrect sign extension in check_alu_op()" The following bugs were introduced in 4.14: * fixed by "bpf/verifier: fix bounds calculation on BPF_RSH" * fixed by "bpf: fix incorrect tracking of register size truncation" * fixed by "bpf: fix 32-bit ALU op verification" * fixed by "bpf: fix missing error return in check_stack_boundary()" * fixed by "bpf: force strict alignment checks for stack pointers" * fixed by "bpf: don't prune branches when a scalar is replaced with * fixed by "bpf: fix integer overflows"
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

9. "Критические уязвимости в подсистеме eBPF ядра Linux"	+2 +/–
Сообщение от axredneck (?), 23-Дек-17, 14:02
Android подвержен? (чтобы рутануть, само собой)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	15. "Критические уязвимости в подсистеме eBPF ядра Linux"	–2 +/–
	Сообщение от dasrfatwet (?), 23-Дек-17, 18:09
	да конечно чтобы рутануть, чтобы майнера установить скрытного в системе так и скажи.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

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

	32. "Критические уязвимости в подсистеме eBPF ядра Linux"	+1 +/–
	Сообщение от Аноним (-), 23-Дек-17, 22:04
	> Чтобы майнер был незаметным - требуется чемодан-невидимка с батарейками :) Кстати, если у кого такой чемодан есть - дайте два! И черт с ним, с майнером.
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	54. "Критические уязвимости в подсистеме eBPF ядра Linux"	+/–
	Сообщение от Аноним (-), 24-Дек-17, 12:32
	>> Чтобы майнер был незаметным - требуется чемодан-невидимка с батарейками :) > Кстати, если у кого такой чемодан есть - дайте два! И черт > с ним, с майнером. И чёрт с ним, с невидимкой. Пусть будет просто невесомка.
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

11. "Критические уязвимости в подсистеме eBPF ядра Linux"	+1 +/–
Сообщение от Ilya Indigo (ok), 23-Дек-17, 14:49
Линус, как всегда, был прав! Очень плохо, когда заранее объявляют, что данное ядро будет LTS. Все, кому не лень, а как раз именно те кому лень тщательно тестировать, постараются запихнуть в него по-скорее всё что можно без должного тестирования.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

12. "Критические уязвимости в подсистеме eBPF ядра Linux"	–1 +/–
Сообщение от Аноним (-), 23-Дек-17, 15:28
""приведёт к невозможности использования обычными пользователями средств трассировки и анализа производительности на базе eBPF. "" А обычные пользователи это точно использовали? Описание столь же нелепое как в половины сервисов в оффтопе.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

13. "Критические уязвимости в подсистеме eBPF ядра Linux"	–1 +/–
Сообщение от Аноним (-), 23-Дек-17, 15:54
Есть ли где внятное сравнение на счёт пользы от внедрения JIT-та в ядро, мол поставили его себе и у нас маршутизатор на 146% ускорился, ну или там реально системные вызовы залетали, а до этого каждый по одной миллисекунде на вход в ядро тратил?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	55. "Критические уязвимости в подсистеме eBPF ядра Linux"	–3 +/–
	Сообщение от Аноним (-), 24-Дек-17, 12:33
	Почитай, что такое eBPF. JIT только в нём.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

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

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

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

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

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

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

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

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

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

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

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

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

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

	46. "Критические уязвимости в подсистеме eBPF ядра Linux"	+/–
	Сообщение от Аноним (-), 24-Дек-17, 07:38
	> Но весь прикол в том что на чём то другом - не напишут вообше :-р > А с другойстороны - конкретно ты - вообще не напишешь. мда, докультивировались тут на опёнке..
	Ответить | Правка | ^ к родителю #45 | Наверх | 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 - там всё написано. академические цели и пруф оф концепт.. однако оно есть. и автор не поленился потрудиться и в одиночку почти написал рабочее ядро нет, я, конечно, понимаю.. Линус уже всего добился, и деньги и работа у него есть.. какой ему смысл забросить курицу, которая несёт золотые яйца.. и вообще, сишники без работы так точно никогда не останутся, главное продолжать обновлять баги..
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

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

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

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

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

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

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

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

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

74. "Критические уязвимости в подсистеме eBPF ядра Linux"	+1 +/–
Сообщение от Аноним (-), 25-Дек-17, 07:26
Это eBPF оно мне вообще надо? И почему оно включено по умолчанию?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	78. "Критические уязвимости в подсистеме eBPF ядра Linux"	+/–
	Сообщение от Аноним (-), 26-Дек-17, 00:15
	> Это eBPF оно мне вообще надо? Кто тебя знает? Не надо - выключи. > И почему оно включено по умолчанию? Потому что разработчикам ядра или майнтайнерам дистра было надо, очевидно.
	Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

	82. "Критические уязвимости в подсистеме eBPF ядра Linux"	+/–
	Сообщение от EHLO (?), 26-Дек-17, 01:21
	> Это eBPF оно мне вообще надо? И почему оно включено по умолчанию? А где [было написано что] оно включено по умолчанию? На первый вопрос ответ "нет".
	Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

79. "Критические уязвимости в подсистеме eBPF ядра Linux"	+/–
Сообщение от Аноним (-), 26-Дек-17, 00:34
Ну так какой прок от eBPF (где цифры, слайды, видео)? История успеха, так сказать...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	88. "Критические уязвимости в подсистеме eBPF ядра Linux"	+/–
	Сообщение от Аноним (88), 13-Авг-18, 12:38
	https://www.youtube.com/watch?v=sV3XfrfjrPo&feature=youtu.be... Это таймкод, вот.
	Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

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

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