eBPF для начинающих: практическое введение

Современные инструменты мониторинга (Prometheus, Grafana, профилировщики) обеспечивают хорошую видимость состояния приложения, но имеют ограничения при анализе низкоуровневых проблем. Технология eBPF (Extended Berkeley Packet Filter) позволяет преодолеть этот барьер, предоставляя безопасный доступ к событиям ядра Linux. 

Статья — это практическое введение в eBPF: попробуем готовые команды для наблюдаемости, сети и безопасности, разберём, как программа попадает в ядро и взаимодействует с user-space через maps и helpers, почему верификатор отклоняет «опасный» код и чем отличаются BCC, libbpf и bpftrace. В конце — короткий обзор того, как eBPF используют Cilium, Falco и Pixie.

Материал будет полезен программистам, DevOps-инженерам, SRE-специалистам и всем, кто интересуется Linux.

С технологией eBPF я познакомился относительно недавно. Как бэкенд‑разработчик, часто настраиваю сбор метрик через условный Prometheus. В большинстве случаев этого достаточно для понимания поведения и состояния приложения. Однако, изучая вопросы производительности при высоких нагрузках, я осознал, что «слепое пятно» между кодом и железом может скрывать критические проблемы.

Здесь и вступает в игру eBPF. В отличие от традиционных инструментов (strace, perf, tcpdump), eBPF даёт унифицированный интерфейс для наблюдения за практически всеми событиями в ядре и пользовательском пространстве. Например, я начал с простого: написал скрипт на eBPF, который отслеживал все вызовы connect() из моего процесса и замерял время до установления соединения. Это позволило выявить задержки на этапе DNS‑разрешения: скрипт показал, что отдельные вызовы getaddrinfo() занимали сотни миллисекунд, что терялось в общей статистике Prometheus. В плане мониторинга я вижу eBPF не как замену, а как дополнение к привычным инструментам, когда нужно понять истинную причину проблем.

Итак, eBPF — это способ безопасно выполнять пользовательский код в ядре Linux без модулей и патчей. На практике eBPF закрывает три важных сценария:

• Наблюдаемость: телеметрия на уровне syscalls/tracepoints/uprobes (точки трассировки ядра/пользовательские точки трассировки) с минимальными накладными расходами. Например, можно отслеживать задержки каждого вызова read() или write() для конкретного процесса.

• Сеть: обработка пакетов на хуках XDP (eXpress Data Path)/TC (Traffic Control), возможность переносить логику ближе к сетевому стеку. На хуке XDP можно отфильтровать DDoS‑трафик ещё до того, как он достигнет сетевого стека ядра.

• Безопасность: контроль действий процессов в реальном времени (policy/детекция), а не постфактум по логам. Например, можно настроить политику, которая будет блокировать попытки процесса открыть файл вне разрешенной директории.

Ключевое отличие от LKM (Loadable Kernel Module) — в безопасности: eBPF‑код должен пройти верификатор до загрузки. Верификатор статически анализирует все пути исполнения и отклоняет программу, если видит риск бесконечного цикла, выхода за границы памяти, чтения неинициализированных данных или некорректной работы с указателями. За счёт этого eBPF сильно снижает класс рисков, типичных для обычных модулей ядра (kernel panic, corruption памяти, трудно отлавливаемые race‑ошибки).

При этом eBPF‑программа не вызывает произвольные функции ядра напрямую. Она работает через helpers (разрешённые API ядра) и хранит/передаёт данные через maps (структуры «ключ‑значение», ring buffer и др.). Это делает взаимодействие с user‑space контролируемым и предсказуемым.

Минимальные требования и установка

Чтобы повторить примеры из статьи, будет достаточно базового набора:

• Ядро Linux: желательно 5.8+ (для BPF_MAP_TYPE_RINGBUF), но часть примеров работает и на более ранних версиях.

• Права: обычно нужен root.

• Пакеты: clang, llvm, bpftool, libbpf-dev (или libbpf-devel), linux-headers-$(uname -r).

• BTF (для CO-RE): проверьте наличие vmlinux BTF: /sys/kernel/btf/vmlinux.

Быстрая проверка окружения:

uname -rls -l /sys/kernel/btf/vmlinuxbpftool versionclang --version

Практика

Наблюдаемость

Кто открывает файлы (openat):

bpftrace -e 'tracepoint:syscalls:sys_enter_openat { printf("%s pid=%d открывает: %s\n", comm, pid, str(args->filename)); }'

Сколько execve по UID (агрегация раз в 5 секунд):

bpftrace -e 'tracepoint:syscalls:sys_enter_execve { @by_uid[uid] = count(); } interval:s:5 { print(@by_uid); clear(@by_uid); }'

Что уже загружено в системе:

bpftool prog listbpftool map list

Дополнительно: расширенный пример мониторинга execve через BCC (Python). BCC удобен для прототипа: BPF-часть компилируется на лету, а user-space можно написать на Python.

Создадим файл exec_monitor.py со следующим содержимым:

from bcc import BPF    prog = r""" #include <uapi/linux/ptrace.h> #include <linux/sched.h>       struct data_t {     u32 pid;     char comm[TASK_COMM_LEN];     char filename[128]; };     BPF_PERF_OUTPUT(events);  int syscall__execve(struct pt_regs *ctx, const char __user *filename) {         struct data_t data = {};         data.pid = bpf_get_current_pid_tgid() >> 32;         bpf_get_current_comm(&data.comm, sizeof(data.comm));         bpf_probe_read_user(&data.filename, sizeof(data.filename), filename);     events.perf_submit(ctx, &data, sizeof(data));     return 0; }     """       b = BPF(text=prog)     b.attach_kprobe(event=b.get_syscall_fnname("execve"), fn_name="syscall__execve")       def print_event(cpu, data, size):     e = b["events"].event(data)         print(f"pid={e.pid} comm={e.comm.decode()} file={e.filename.decode(errors='replace')}")           b["events"].open_perf_buffer(print_event) while True:         b.perf_buffer_poll()

Запуск:

sudo python3 exec_monitor.py

Сеть

Проверить, есть ли attach XDP/TC и какие программы привязаны:

sudo bpftool net

Показать программы и ID на конкретном интерфейсе:

ip link showIFACE=enp0s3   # подставьте свой интерфейсsudo bpftool net show dev "$IFACE" 

Безопасность

Детект чтения /etc/shadow (пример policy/детекции):

sudo bpftrace -e 'tracepoint:syscalls:sys_enter_openat /str(args->filename)=="/etc/shadow"/ { printf("ALERT: %s pid=%d uid=%d открыл /etc/shadow\n", comm, pid, uid); }'

Посмотреть verifier log при загрузке eBPF-объекта:

# Пробуем загрузку и сохраняем подробный лог верификатораsudo bpftool prog load ./prog.o /sys/fs/bpf/my_prog verbose 2> verifier.log# Затем можно открыть лог и посмотреть причину отказа   less verifier.log

Архитектура и жизненный цикл eBPF-программы

eBPF-код проходит несколько этапов: компиляция в bytecode, загрузка через bpf() syscall, проверка верификатором, JIT и привязка к hook’у. Ниже — упрощенная схема и краткий разбор, что происходит на каждом шаге.

Анализ этапов прохождения кода

Код проходит три ключевые фазы:

1. Компиляция: C/Rust → eBPF bytecode (объектный .o). 

2. Загрузка и верификация: ядро статически проверяет каждый путь исполнения (память/циклы/типы). 

3. JIT и выполнение: bytecode превращается в нативные инструкции и вызывается на выбранном hook’е (tracepoint/kprobe/XDP и т.д.).

Взаимодействие через Maps и Helpers

Поскольку eBPF-программы работают в изолированной песочнице, они не могут напрямую обращаться к произвольным функциям ядра или памяти других процессов. Для коммуникации используются два строго определенных интерфейса:

1. Helper Functions: набор API, предоставляемый ядром для выполнения разрешенных действий (например, получение текущего времени, манипуляция сетевыми пакетами). 

2. eBPF Maps: специализированные структуры данных (Hash maps, Arrays, Ring buffers), которые служат мостом для обмена данными между пространством пользователя и ядром в режиме реального времени.

Алгоритм работы верификатора

Верификатор использует метод абстрактной интерпретации. Вместо реального выполнения кода он моделирует состояние виртуальной машины (регистров и стека), проходя по всем возможным путям исполнения.

1. Построение графа потока управления (CFG). Первым делом верификатор строит направленный граф (Directed Graph), где узлами являются блоки инструкций, а ребрами — переходы (jump).

• Детекция циклов. До недавнего времени циклы были полностью запрещены. В современных ядрах допускаются только ограниченные (bounded) циклы, количество итераций которых можно вычислить статически. 

• Глубина анализа. Верификатор ограничивает максимальное количество проверяемых инструкций (обычно до 1 млн), чтобы процесс проверки не привел к зависанию самого ядра.

2. Моделирование состояния регистров и стека

Для каждой инструкции верификатор отслеживает не только значения, но и типы данных в регистрах:

• Является ли значение в регистре R1 скаляром или указателем? 

• Если это указатель, на какую область памяти он ссылается (стек, Map, контекст пакета)? 

• Каков допустимый диапазон смещения (offset) для этого указателя?

Критерии опасных инструкций и состояний

Программа будет немедленно отклонена (Invalid instruction), если верификатор обнаружит хотя бы один сценарий, содержащий следующие нарушения:

1. Неинициализированный доступ.
   Попытка чтения из регистра, в который ранее не было записано значение, или чтение из стека, который не был предварительно заполнен. 

2. Нарушение границ памяти (Out-of-bounds).
   Попытка доступа к элементу массива или заголовку пакета без предварительной проверки длины. Например, если программа обращается к buffer[10], верификатор должен видеть в графе исполнения инструкцию сравнения, гарантирующую, что размер buffer > 10. 

3. Утечка указателей (Pointer Leaking).
   Запрещено копировать адреса памяти ядра в области, доступные пользователю (например, передавать указатель напрямую в Map). Это предотвращает атаки, направленные на обход KASLR. 

4. Некорректное завершение:
   Программа должна всегда заканчиваться инструкцией exit, при этом в регистре R0 должен находиться возвращаемый статус (целое число).

Практическое значение для разработчика

В книгах пишут, что для инженера верификатор часто становится «строгим учителем», но мне больше нравится сравнение с бдительным вахтером (ты не пройдёшь!). Сообщение Permission denied при загрузке программы зачастую сопровождается дампом состояний регистров (Verifier Log). Понимание того, как верификатор отслеживает границы памяти, позволяет писать код так, чтобы явно доказывать ядру его безопасность — например, через явные проверки:

// Пример кода, который успокаивает верификатор if (data + sizeof(struct ethhdr) > data_end) {        return XDP_DROP; // Гарантируем, что за границы пакета не выйдем }

См. раздел «Практика → Безопасность → 3.2 verifier log».

После верификации программа может безопасно работать с Maps — сохранять состояние и передавать данные в user-space.

Архитектура Maps: хранилище «ключ–значение»

С технической точки зрения, eBPF Map — это объект в памяти ядра, управление которым осуществляется через файловые дескрипторы. Ключевая особенность заключается в том, что структура данных определяется при создании и остается неизменной, что позволяет верификатору заранее знать типы и размеры данных.

Основные типы структур данных

Выбор типа Map напрямую влияет на производительность и функциональность системы:

• BPF\_MAP\_TYPE\_HASH. Универсальная хеш-таблица. Идеальна для хранения агрегированной статистики по IP-адресам или PID процессов. 

• BPF\_MAP\_TYPE\_ARRAY. Массив с фиксированным размером. Самый быстрый тип доступа, часто используется для конфигурационных флагов. 

• BPF\_MAP\_TYPE\_RINGBUF. Кольцевой буфер (появился в ядре 5.8). Современный стандарт для передачи потоковых событий из ядра в User-space. Он эффективнее устаревшего Perf Buffer за счет отсутствия лишнего копирования памяти и гарантированного порядка сообщений. 

• BPF\_MAP\_TYPE\_LRU\_HASH. Хеш-таблица с механизмом вытеснения давно неиспользуемых элементов. Критически важна для защиты от исчерпания памяти при хранении сессий сетевого трафика.

Синхронизация данных: Kernel <-> User-space

Взаимодействие между пространством пользователя и ядром происходит асинхронно, что требует понимания специфики доступа к данным.

1. Механизм системных вызовов (User-space)

Программа пользователя использует системный вызов bpf(BPF_MAP_LOOKUP_ELEM, ...) для чтения или записи данных в Map. Это позволяет, например, Python-скрипту раз в секунду считывать статистику, собранную C-программой в ядре.

2. Атомарность и Per-CPU структуры

В многоядерных системах возникает риск «состояния гонки» (race condition), когда несколько ядер одновременно пытаются обновить один и тот же счетчик в Map. Для решения этой проблемы eBPF предлагает два пути:

• Атомарные операции — использование встроенных хелперов для атомарного инкремента. 

• Per-CPU Maps. Ядро создает отдельную копию структуры данных для каждого логического ядра процессора. Программа в ядре пишет в свою локальную копию без блокировок, а User-space суммирует данные из всех копий при чтении. Это обеспечивает максимальную производительность.

Практический пример: подсчет системных вызовов

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

1. Программа eBPF при каждом вызове получает UID пользователя, использует его как ключ и инкрементирует значение в Hash Map. 

2. User-space процесс (например, на Go) периодически опрашивает эту Map и выводит топ пользователей в консоль.

Быстрая версия без разработки и команды для просмотра загруженных объектов — в разделе «Практика → Наблюдаемость».

Сравнительный анализ инструментария: BCC и libbpf

Выбор инструментария удобно свести к вопросу: вам нужно быстро потрогать идею или вы пишете переносимый production-код?

BCC (BPF Compiler Collection).

BCC — быстрый путь к прототипу: BPF-часть на C, управление/вывод — на Python (и др.).

Когда выбирать: ad-hoc диагностика, учебные примеры, прототипирование. 

Плюсы: минимум сборочной рутины, много готовых примеров, удобно обрабатывать события в Python. 

Минусы: компиляция на лету, зависимость от headers/LLVM на хосте, сложнее упаковывать и деплоить.

libbpf и концепция CO-RE (Compile Once – Run Everywhere).

Стандарт для production: собираете .o один раз, а libbpf подстраивает обращения к типам/полям под конкретное ядро через BTF.

Когда выбирать: агенты мониторинга/безопасности, сетевые datapath-компоненты, любой повторяемый деплой. 

Плюсы: быстрый старт без компиляции на хосте, меньше зависимостей, переносимость (CO-RE). 

Минусы: больше C/сборки, нужно понимать BTF/relocations и lifecycle attach’а.

bpftrace: инструмент для оперативной диагностики

Если BCC и libbpf предназначены для создания полноценных приложений (вроде агентов мониторинга), то bpftrace — это инструмент «первой помощи». Он использует предметно-ориентированный язык (DSL), вдохновленный AWK и DTrace.

Особенности bpftrace:

• Использование: однострочные команды или короткие скрипты. 

• Назначение: быстрая отладка, поиск утечек памяти, анализ задержек (latency) дисковой подсистемы прямо на «живом» сервере. 

• Синтаксис: probe /filter/ { action }

Мини-старт: примеры команд

Готовые bpftrace-однострочники (openat/execve/фильтры) вынесены в раздел «Практика». Также в нём представлены примеры взаимодействия «ядро + user-space».

Расширенные примеры

Полноразмерный пример мониторинга execve через BCC (Python) и блок команд для libbpf/CO-RE перенесены в раздел «Практика» (там же они сгруппированы по сценариям).

eBPF в реальном мире: индустриальные кейсы

Когда технология eBPF доказала свою стабильность, на её базе выросла целая экосистема инструментов, которые сегодня являются стандартом де-факто в Cloud Native среде.

Cilium: сеть и политики в Kubernetes

Традиционный стек Linux (iptables/netfilter) не был рассчитан на динамическую природу контейнеров. Cilium заменяет стандартную обработку пакетов на eBPF-программы.

• Identity-based Security: вместо фильтрации по IP-адресам (которые постоянно меняются в K8s), Cilium фильтрует трафик на основе меток (Labels) сервисов. 

• XDP Acceleration: пакеты обрабатываются на самом раннем этапе (в драйвере сетевой карты), что позволяет отражать DDoS-атаки практически без нагрузки на CPU.

Falco: runtime-безопасность

Falco — это «система обнаружения вторжений» (IDS) нового поколения.

• Анализ поведения: Falco использует eBPF для мониторинга потока системных вызовов. 

• Детекция аномалий: Если внутри контейнера внезапно запустилась оболочка sh (что нехарактерно для продакшена) или произошло чтение файла /etc/shadow, Falco мгновенно генерирует алерт. 

• Преимущество: Поскольку eBPF-программа работает в ядре, злоумышленник не может скрыть свою активность, даже если он обладает правами root внутри контейнера.

Pixie: наблюдаемость без правок кода

Pixie позволяет получить полную карту взаимодействия микросервисов, включая заголовки HTTP/gRPC и SQL-запросы, без установки Sidecar-контейнеров (как в Istio) и без внесения изменений в код приложения. Это стало возможным благодаря eBPF-аппробации (uprobes), которая подсматривает за трафиком прямо в памяти процесса.

Заключение

eBPF завершает эпоху, когда ядро было «чёрным ящиком». Сегодня это инструмент, который позволяет адаптировать операционную систему под задачи приложения, а не подстраивать приложение под ограничения ОС. Что это даёт:

• меньше «необъяснимых» задержек под нагрузкой;

• контроль над системными вызами и сетевым трафиком;

• дополнительный уровень безопасности благодаря верификатору eBPF;

• возможность изменять и тестировать логику без перезагрузки системы.

eBPF помогает лучше понимать поведение Linux-систем и точнее управлять ими.

Что можно изучить дальше

1. ebpf.io — главный хаб и документация: https://ebpf.io/ 

2. BPF Performance Tools (Brendan Gregg) — база по диагностике производительности. 

3. Liz Rice, «What is eBPF?»   — короткое вводное чтение. 

4. Cilium Documentation — сеть/политики в Kubernetes: https://docs.cilium.io/ 

5. Подборка инструментов: https://blog.rnds.pro/065-ebpf-tools

Автор статьи: Александр Донцов.

---

НЛО прилетело и оставило здесь промокод для читателей нашего блога:

-15% на заказ любого VDS (кроме тарифа Прогрев) — HABRFIRSTVDS