Comments 23
Эммм. Я дико извиняюсь, а не поздновато ли для такого перевода? Такое ощущение что взгляд двухлетней давности. А то и дольше.
без ущерба таким ключевым свойствам, как… безопасность
https://www.opennet.ru/opennews/art.shtml?num=52640
https://www.opennet.ru/opennews/art.shtml?num=54932
https://www.opennet.ru/opennews/art.shtml?num=55371
https://www.opennet.ru/opennews/art.shtml?num=55388
https://www.opennet.ru/opennews/art.shtml?num=55576
А так никакого ущерба
Если отойти от всяких Spectre и Meltdown, то я никак не могу понять, зачем непривелигированному пользователю позволять грузить BPF программы по дефолту (sysctl kernel.unprivileged_bpf_disabled)? Они бы ещё модули ядра разрешили бы грузить.
BPF ? Welcome to FreeBSD 2.1-RELEASE (C) 1995.
Во FreeBSD - BFP не менее универсален. А то, что Вы называете прокладкой, скорее всего в Linux-е называется libpcap.
Его язык можно привернуть во FreeBSD к чему-то кроме фильтрации пакетов?
> А то, что Вы называете прокладкой, скорее всего в Linux-е называется libpcap.
Натурально, вы не понимаете. libpcap выполняет компиляцию выражений типа «src ip 1.2.3.4 and udp port 5000» в программу на языке BPF (байткоде). А дальше этот фильтр в виде байткода инжектится в ядро, где уже и выполняется профильной VM. Так у всех, но могут отличаться детали языка VM, и метод её работы (например, eBPF переводит в машинный код исполняющего процессора, вставляя, разумеется, защиты против всякого зацикливания).
eBPF линукса это реализация идеи «у нас уже есть неплохая VM для всякого мелкого кода, можно привернуть к ещё чему-то». Тут могут быть 100500 применений — в той же фильтрации пакетов напрямую (только надо определить цели), в шедулинге, в логике OOM киллера, да где угодно…
Привернуть eBPF наверное можно "еще к чему-то", тольно зачем ? В статье изначально весь посыл был о фильтрации именно сетевого трафика, что в *BSD уже много лет достигается средствами netgraph и BPF. Статья на Wikipedia не обьясняет в чем принципиальное отличие BPF от eBPF, кроме того, что eBPF можно привернуть "еще к чему-то". Из чего можно сделать вывод, что eBPF это "наш правидный BPF" от линуксоидов.
Не могу понять, почему в статье нет ни одного упоминания, что BPF расшифровывается как "Berkley Packet Filter", появилось уже почти 30 лет назад и давно известно в других ОС (Solaris/FreeBSD/OpenBSD):
Потому, что в статье идёт речь про eBPF, а не BPF.
От BPF в eBPF только название.
Остается только догадываться, чему там учат на курсах администраторов Линукс, если авторы не видят разницы между BPF и eBPF
Вот что думает по этому поводу автор самого eBPF, Алексей Старовойтов:
There was something already in the Linux kernel which had similar properties called BPF (Berkeley Packet Filter): A minimal instruction set that can be used to filter packets before they are seen by an application such as tcpdump. I borrowed that name for my "ingredient" and called it eBPF, where 'e' stands for 'extended'
Several years later the distinction between eBPF and classic BPF has vanished. My "universal ingredient" has taken over under the name BPF.
Он и в Линуксе появился лет 20 назад. Но фокус в том, что сейчас это "немножко" больше чем просто фильтр пакетов
Это конечно хорошо. Я понимаю что в мире оркестровки контейнеров и всяком таком это очень круто. Но вот мне просто интересно, что если сравнить BPF на Linux с тем же FreeBSD где netgraph и ipfw? Да, докеры и кубы и прочее на фряхе не работают как нужно, но если откинуть этот момент, и допустим для задач маршрутизации и фильтрацтей трафика, стоил ли выкинуть фряху и заменить на линуху с BPF, в надежде получить ощутимый пруфит, или оно все же не дотягивает до веками словшишейся системы на BSD именно для таких задач?)
На сейчас же это «ну заменили какой-то слой в ядре — ну и что?» — реально ни о чём.
В чём смысл сравнивать freebsd с остальными версиями линуха? Кто-то выбрал свою ос и врятли соберётся переносить инфраструктуру на другую ось, даже если там нет проблем с фаерволом
Почему сообщество разработчиков ядра заменяет iptables на BPF?