Регистрация функций-помощников

SPL
Посмотрим на то, как гипотетическая программа BPF использует функцию bpf_get_smp_processor_id. Для этого перепишем программу из нашего предыдущего раздела следующим образом:

Символ bpf_get_smp_processor_id определяется в <bpf/bpf_helper_defs.h> библиотеки libbpf как

то есть, bpf_get_smp_processor_id — это указатель на функцию, значение которого равно 8, где 8 — это значение BPF_FUNC_get_smp_processor_id типа enum bpf_fun_id, которое определяется для нас в файле vmlinux.h (файл bpf_helper_defs.h в ядре генерируется скриптом, поэтому «магические» числа — это ok). Эта функция не принимает аргументов и возвращает значение типа __u32. Когда мы запускаем ее в нашей программе, clang генерирует инструкцию BPF_CALL «правильного вида». Давайте скомпилируем программу и посмотрим на секцию xdp/simple:

В первой же строчке мы видим инструкцию call, параметр IMM которой равен 8, а SRC_REG — нулю. По ABI-соглашению, используемому verifier, это и есть вызов функции-помощника под номером восемь. После ее запуска логика простая. Возвращенное значение из регистра r0 копируется в r1 и на строчках 2,3 приводится к типу u32 — верхние 32 бита обнуляются. На строчках 4,5,6,7 мы возвращаем 2 (XDP_PASS) или 1 (XDP_DROP) в зависимости от того, вернула ли функция-помощник со строчки 0 нулевое или ненулевое значение.
Проверим себя: загрузим программу и посмотрим на вывод bpftool prog dump xlated:

Хорошо, verifier нашел правильный kernel-helper.
Пример: передаем аргументы и, наконец, запускаем программу!
Все функции-помощники на уровне выполнения имеют прототип

Параметры функциям-помощникам передаются в регистрах r1—r5, а значение возвращается в регистре r0. Функций, принимающих больше пяти аргументов — нет и добавлять их поддержку в будущем не предполагается.
Давайте посмотрим на новый kernel helper и то как BPF передает параметры. Перепишем xdp-simple.bpf.c следующим образом (остальные строки не изменились):

Наша программа печатает номер CPU, на котором она запущена. Скомпилируем ее и посмотрим на код:

В строках 0-7 мы записываем на стек строку running on CPU%u\n, а затем на строке 8 запускаем знакомый нам bpf_get_smp_processor_id. В строках 9-12 мы подготавливаем аргументы хелпера bpf_printk — регистры r1, r2, r3. Почему их три, а не два? Потому что bpf_printk — это макрос-обертка вокруг настоящего хелпера bpf_trace_printk, которому требуется передать размер форматной строки.
Давайте теперь добавим пару строчек к xdp-simple.c, чтобы наша программа подсоединялась к интерфейсу lo и по-настоящему запускалась!

Здесь мы используем функцию bpf_set_link_xdp_fd, которая подсоединяет программы BPF типа XDP к сетевым интерфейсам. Мы захардкодили номер интерфейса lo, который всегда равен 1. Мы запускаем функцию два раза, чтобы сначала отсоединить старую программу, если она была присоединена. Заметьте, что теперь нам не нужен вызов pause или бесконечный цикл: наша программа-загрузчик завершит работу, но программа BPF не будет уничтожена, так как она подсоединена к источнику событий. После успешной загрузки и подсоединения, программа будет запускаться для каждого сетевого пакета, приходящего на lo.
Загрузим программу и посмотрим на интерфейс lo:

Программа, которую мы загрузили имеет ID 669 и тот же ID мы видим на интерфейсе lo. Пошлем пару пакетов на 127.0.0.1 (request + reply):

и теперь посмотрим на содержимое отладочного виртуального файла /sys/kernel/debug/tracing/trace_pipe, в который bpf_printk пишет свои сообщения:

Два пакета были замечены на lo и обработаны на CPU0 — наша первая полноценная бессмысленная программа BPF отработала!
Стоит заметить, что bpf_printk не даром пишет в отладочный файл: это не самый удачный хелпер для использования в production, но наша цель была показать что-то простое.
Доступ к maps из программ BPF
Пример: используем мап из программы BPF
В предыдущих разделах мы научились создавать и использовать мапы из пространства пользователя, а теперь посмотрим на ядерную часть. Начнем, как водится, с примера. Перепишем нашу программу xdp-simple.bpf.c следующим образом:

В начало программы мы добавили определение мапа woo: это массив из 8 элементов, в котором хранятся значения типа u64 (на C мы определили бы такой массив как u64 woo[8]). В программе "xdp/simple" мы получаем номер текущего процессора в переменную key и затем при помощи функции-помощника bpf_map_lookup_element получаем указатель на соответствующую запись в массиве, которую увеличиваем на единицу. В переводе на русский: мы подсчитываем статистику того, на каком CPU были обработаны входящие пакеты. Попробуем запустить программу:

Проверим, что она подцепилась к lo и пошлем немного пакетов:

Теперь посмотрим на содержимое массива:

Почти все процессы были обработаны на CPU7. Нам это не важно, главное, что программа работает и мы поняли как получить доступ к мапам из программ BPF — при помощи хелперов bpf_mp_*.
Мистический указатель
Итак, мы можем получать доступ из программы BPF к мапу при помощи вызовов вида

где функция-помощник выглядит как

но мы же передаем указатель &woo на безымянную структуру struct { ... }...
Если мы посмотрим на ассемблер программы, то увидим, что значение &woo на самом деле не определено (строчка 4):

и содержится в релокациях:

Но если мы посмотрим на уже загруженную программу, то увидим указатель на правильный map (строка 4):

Таким образом, мы можем сделать вывод, что в момент запуска нашей программы-загрузчика ссылка на &woo была на что-то заменена библиотекой libbpf. Для начала мы посмотрим на вывод strace:

Мы видим, что libbpf создала мап woo и потом загрузила нашу программу simple. Посмотрим более пристально на то, как мы загружаем программу:

• вызываем xdp_simple_bpf__open_and_load из файла xdp-simple.skel.h
  
• которая вызывает xdp_simple_bpf__load из файла xdp-simple.skel.h
  
• которая вызывает bpf_object__load_skeleton из файла libbpf/src/libbpf.c
  
• которая вызывает bpf_object__load_xattr из libbpf/src/libbpf.c

Последняя функция, кроме всего прочего, вызовет bpf_object__create_maps, которая создает или открывает существующие maps, превращая их в файловые дескрипторы. (Это то место, где мы видим BPF_MAP_CREATE в выводе strace.) Дальше вызывается функция bpf_object__relocate и именно она нас и интересует, так как мы помним, что мы видели woo в таблице релокаций. Исследуя ее, мы, в конце-концов попадаем в функцию bpf_program__relocate, которая и занимается релокациями мапов:

Итак, мы берем нашу инструкцию

и заменяем в ней регистр-источник на BPF_PSEUDO_MAP_FD, а первый IMM на файловый дескриптор нашего мапа и, если он равен, например, 0xdeadbeef, то в результате мы получим инструкцию

Именно так информация о мапах передается в конкретную загруженную программу BPF. При этом мап может быть как создан при помощи BPF_MAP_CREATE, так и открыт по ID при помощи BPF_MAP_GET_FD_BY_ID.
Итого, при использовании libbpf алгоритм следующий:

• во время компиляции для ссылок на мапы создаются записи в таблице релокации
  
• libbpf открывает объектник ELF, находит все используемые мапы и создает для них файловые дескрипторы
  
• файловые дескрипторы загружаются в ядро как часть инструкции LD64

Как вы понимаете, это еще не все, и нам придется заглянуть в ядро. К счастью, у нас есть зацепка — мы прописали значение BPF_PSEUDO_MAP_FD в регистр-источник и можем погрепать его, что приведет нас в святая всех святых — kernel/bpf/verifier.c, где функция с характерным названием заменяет файловый дескриптор на адрес структуры типа struct bpf_map:

(полный код можно найти по ссылке). Так что мы можем дополнить наш алгоритм:

• во время загрузки программы verifier проверяет корректность использования мапа и прописывает адрес соответствующей структуры struct bpf_map

При загрузке бинарника ELF при помощи libbpf происходит еще много событий, но мы обсудим это в рамках других статей.
Загружаем программы и мапы без libbpf
Как и обещалось, вот пример для читателей, которые хотят знать, как создать и загрузить программу, использующую мапы, без помощи libbpf. Это может быть полезно, когда вы работаете в окружении, для которого не можете собрать зависимости, или экономите каждый бит, или пишете программу типа ply, которая генерирует бинарный код BPF налету.
Для того, чтобы было проще следовать за логикой, мы для этих целей перепишем наш пример xdp-simple. Полный и немного расширенный код программы, рассматриваемой в этом примере, вы можете найти в этом gist.
Логика нашего приложения следующая:

• создать мап типа BPF_MAP_TYPE_ARRAY при помощи команды BPF_MAP_CREATE,
  
• создать программу, использующую этот мап,
  
• подсоединить программу к интерфейсу lo,

что переводится на человеческий как

Здесь map_create создает мап точно так же, как мы делали это в первом примере про системный вызов bpf — «ядро, пожалуйста, сделай мне новый мап в виде массива из 8 элементов типа __u64 и верни мне файловый дескриптор»:

Программа тоже загружается просто:

Сложная часть prog_load — это определение нашей программы BPF в виде массива структур struct bpf_insn insns[]. Но так как мы используем программу, которая у нас есть на C, то мы можем немного схитрить:

Итого, нам нужно написать 14 инструкций в виде структур типа struct bpf_insn (совет: возьмите дамп сверху, перечитайте раздел про инструкции, откройте linux/bpf.h и linux/bpf_common.h и попробуйте определить struct bpf_insn insns[] самостоятельно):

Упражнение для тех, кто не стал писать это сам — найдите map_fd.
В нашей программе осталась еще одна нераскрытая часть — xdp_attach. К сожалению, программы типа XDP нельзя подсоединить при помощи системного вызова bpf. Люди, создававшие BPF и XDP были из сетевого сообщества Linux, а значит, они использовали самый привычный для них (но не для нормальных людей) интерфейс взаимодействия с ядром: netlink sockets, см. также RFC3549. Самый простой способ реализации xdp_attach — это копирование кода из libbpf, а именно, из файла netlink.c, что мы и проделали, немного укоротив его: