BPF за най-малките, част първа: разширен BPF

В началото имаше технология и се казваше BPF. Погледнахме я предишен, статия за Стария завет от тази серия. През 2013 г. с усилията на Алексей Старовойтов и Даниел Боркман беше разработена негова подобрена версия, оптимизирана за съвременни 64-битови машини, която беше включена в ядрото на Linux. Тази нова технология беше накратко наречена Internal BPF, след това преименувана на Extended BPF, а сега, след няколко години, всички просто я наричат ​​BPF.

Грубо казано, BPF ви позволява да стартирате произволен код, предоставен от потребителя, в пространството на ядрото на Linux и новата архитектура се оказа толкова успешна, че ще ни трябват още дузина статии, за да опишем всички нейни приложения. (Единственото нещо, което разработчиците не са направили добре, както можете да видите в кода за изпълнение по-долу, е създаването на прилично лого.)

Тази статия описва структурата на виртуалната машина BPF, интерфейсите на ядрото за работа с BPF, инструментите за разработка, както и кратък, много кратък преглед на съществуващите възможности, т.е. всичко, от което ще се нуждаем в бъдеще за по-задълбочено изучаване на практическите приложения на BPF.

Резюме на статията

Въведение в BPF архитектурата. Първо, ще разгледаме от птичи поглед архитектурата на BPF и ще очертаем основните компоненти.

Регистри и командна система на виртуалната машина BPF. Вече имайки представа за архитектурата като цяло, ще опишем структурата на виртуалната машина BPF.

Жизнен цикъл на BPF обекти, bpffs файлова система. В този раздел ще разгледаме по-подробно жизнения цикъл на BPF обекти - програми и карти.

Управление на обекти с помощта на системното повикване bpf. С известно разбиране на системата, която вече е налице, най-накрая ще разгледаме как да създаваме и манипулираме обекти от потребителското пространство с помощта на специално системно извикване − bpf(2).

Пишем программы BPF с помощью libbpf. Разбира се, можете да пишете програми, използвайки системно повикване. Но е трудно. За по-реалистичен сценарий ядрените програмисти разработиха библиотека libbpf. Ще създадем основен скелет на BPF приложение, който ще използваме в следващите примери.

Помощници на ядрото. Тук ще научим как BPF програмите могат да имат достъп до помощните функции на ядрото - инструмент, който заедно с картите разширява фундаментално възможностите на новия BPF в сравнение с класическия.

Достъп до карти от програмите на BPF. До този момент ще знаем достатъчно, за да разберем как точно можем да създаваме програми, които използват карти. И нека дори да надникнем набързо в страхотния и могъщ верификатор.

Инструменти за разработка. Раздел за помощ за това как да сглобите необходимите помощни програми и ядро ​​за експерименти.

Заключение. В края на статията, прочелите дотук ще намерят мотивиращи думи и кратко описание на това, което ще се случи в следващите статии. Ще изброим и редица връзки за самообучение за тези, които нямат желание или възможност да чакат продължението.

Въведение в BPF архитектурата

Преди да започнем да разглеждаме архитектурата на BPF, ще се позовем за последен път (о) на класически BPF, който беше разработен в отговор на появата на RISC машини и реши проблема с ефективното филтриране на пакети. Архитектурата се оказа толкова успешна, че, родена през елегантните деветдесет години в Berkeley UNIX, тя беше пренесена в повечето съществуващи операционни системи, оцеля в лудите двадесетте години и все още намира нови приложения.

Новият BPF е разработен като отговор на повсеместното разпространение на 64-битови машини, облачни услуги и повишената нужда от инструменти за създаване на SDN (Sсофтуер-dусъвършенстван nмрежова работа). Разработен от мрежови инженери на ядрото като подобрен заместител на класическия BPF, новият BPF буквално шест месеца по-късно намери приложения в трудната задача за проследяване на Linux системи и сега, шест години след появата му, ще ни е необходима цяла следваща статия само за избройте различните типове програми.

Смешни картинки

В основата си BPF е виртуална машина с пясък, която ви позволява да изпълнявате „произволен“ код в пространството на ядрото, без да компрометирате сигурността. BPF програмите се създават в потребителско пространство, зареждат се в ядрото и се свързват към някакъв източник на събития. Събитие може да бъде например доставка на пакет до мрежов интерфейс, стартиране на някаква функция на ядрото и т.н. В случай на пакет, програмата BPF ще има достъп до данните и метаданните на пакета (за четене и, евентуално, запис, в зависимост от типа на програмата); в случай на изпълнение на функция на ядрото, аргументите на функцията, включително указатели към паметта на ядрото и т.н.

Нека разгледаме по-подробно този процес. Като начало, нека поговорим за първата разлика от класическия BPF, програмите за които са написани на асемблер. В новата версия архитектурата беше разширена, така че програмите да могат да бъдат написани на езици от високо ниво, предимно, разбира се, на C. За тази цел беше разработен бекенд за llvm, който позволява генериране на байт код за BPF архитектурата.

Архитектурата на BPF е проектирана отчасти да работи ефективно на съвременни машини. За да работи това на практика, BPF байт кодът, след като бъде зареден в ядрото, се превежда в собствен код с помощта на компонент, наречен JIT компилатор (JУст In Tаз). След това, ако си спомняте, в класическия BPF програмата беше заредена в ядрото и прикрепена към източника на събитие атомарно - в контекста на едно системно извикване. В новата архитектура това се случва на два етапа - първо кодът се зарежда в ядрото чрез системно извикване bpf(2)и след това, по-късно, чрез други механизми, които варират в зависимост от типа програма, програмата се прикрепя към източника на събитие.

Тук читателят може да има въпрос: възможно ли е? Как се гарантира безопасността на изпълнение на такъв код? Безопасността на изпълнението ни е гарантирана от етапа на зареждане на BPF програми, наречен verifier (на английски този етап се нарича verifier и аз ще продължа да използвам английската дума):

Verifier е статичен анализатор, който гарантира, че програмата няма да наруши нормалната работа на ядрото. Това, между другото, не означава, че програмата не може да се намесва в работата на системата - BPF програмите, в зависимост от типа, могат да четат и пренаписват секции от паметта на ядрото, да връщат стойности на функции, да изрязват, добавят, пренаписват и дори препраща мрежови пакети. Verifier гарантира, че изпълнението на BPF програма няма да срине ядрото и че програма, която според правилата има достъп за запис, например данните на изходящ пакет, няма да може да презапише паметта на ядрото извън пакета. Ще разгледаме верификатора малко по-подробно в съответния раздел, след като се запознаем с всички останали компоненти на BPF.

И така, какво научихме досега? Потребителят пише програма на C, зарежда я в ядрото чрез системно извикване bpf(2), където се проверява от верификатор и се превежда в естествен байткод. След това същият или друг потребител свързва програмата към източника на събитие и тя започва да се изпълнява. Разделянето на стартиране и свързване е необходимо поради няколко причини. Първо, стартирането на верификатор е сравнително скъпо и като изтегляме една и съща програма няколко пъти, ние губим компютърно време. Второ, как точно е свързана една програма зависи от нейния тип и един „универсален“ интерфейс, разработен преди година, може да не е подходящ за нови видове програми. (Въпреки че сега, когато архитектурата става по-зряла, има идея този интерфейс да се обедини на ниво libbpf.)

Внимателният читател може да забележи, че още не сме приключили със снимките. Всъщност всичко по-горе не обяснява защо BPF фундаментално променя картината в сравнение с класическия BPF. Две иновации, които значително разширяват обхвата на приложимост, са възможността за използване на споделена памет и помощни функции на ядрото. В BPF споделената памет се реализира с помощта на така наречените карти - споделени структури от данни със специфичен API. Вероятно са получили това име, защото първият тип карта, който се появи, беше хеш таблица. След това се появиха масиви, локални (на CPU) хеш таблици и локални масиви, дървета за търсене, карти, съдържащи указатели към BPF програми и много други. Това, което е интересно за нас сега, е, че BPF програмите вече имат способността да запазват състоянието между повикванията и да го споделят с други програми и с потребителско пространство.

Достъпът до картите се осъществява от потребителски процеси чрез системно извикване bpf(2)и от BPF програми, работещи в ядрото, използващи помощни функции. Освен това съществуват помощници не само за работа с карти, но и за достъп до други възможности на ядрото. Например, BPF програмите могат да използват помощни функции за препращане на пакети към други интерфейси, генериране на перф събития, достъп до структури на ядрото и т.н.

В обобщение, BPF предоставя възможност за зареждане на произволен, т.е. тестван от верификатор, потребителски код в пространството на ядрото. Този код може да запазва състояние между повиквания и да обменя данни с потребителско пространство, а също така има достъп до подсистеми на ядрото, разрешени от този тип програма.

Това вече е подобно на възможностите, предоставени от модулите на ядрото, в сравнение с които BPF има някои предимства (разбира се, можете да сравнявате само подобни приложения, например проследяване на системата - не можете да напишете произволен драйвер с BPF). Можете да отбележите по-нисък праг за влизане (някои помощни програми, които използват BPF, не изискват потребителят да има умения за програмиране на ядрото или умения за програмиране като цяло), безопасност по време на работа (вдигнете ръката си в коментарите за тези, които не са разбили системата при писане или тестване на модули), атомарност - има прекъсване при презареждане на модули и подсистемата BPF гарантира, че няма пропуснати събития (честно казано, това не е вярно за всички типове BPF програми).

Наличието на такива възможности прави BPF универсален инструмент за разширяване на ядрото, което се потвърждава от практиката: все повече и повече нови видове програми се добавят към BPF, все повече и повече големи компании използват BPF на бойни сървъри 24×7, все повече и повече стартиращите фирми изграждат своя бизнес върху решения, базирани на BPF. BPF се използва навсякъде: за защита срещу DDoS атаки, създаване на SDN (например внедряване на мрежи за kubernetes), като основен инструмент за проследяване на системата и събиране на статистически данни, в системи за откриване на проникване и пясъчни системи и др.

Нека завършим обзорната част на статията тук и разгледаме виртуалната машина и екосистемата на BPF по-подробно.

Отклонение: комунални услуги

За да можете да изпълнявате примерите в следващите раздели, може да се нуждаете от редица помощни програми, поне llvm/clang с поддръжка на bpf и bpftool, В раздела Инструменти за разработка Можете да прочетете инструкциите за асемблиране на помощните програми, както и вашето ядро. Този раздел е поставен по-долу, за да не нарушава хармонията на нашето представяне.

BPF Регистри на виртуална машина и система за инструкции

Архитектурата и командната система на BPF са разработени, като се вземе предвид фактът, че програмите ще бъдат написани на езика C и след зареждане в ядрото ще бъдат преведени в собствен код. Следователно броят на регистрите и наборът от команди са избрани с оглед на пресечната точка, в математически смисъл, на възможностите на съвременните машини. Освен това бяха наложени различни ограничения върху програмите, например доскоро не беше възможно да се пишат цикли и подпрограми, а броят на инструкциите беше ограничен до 4096 (сега привилегированите програми могат да заредят до един милион инструкции).

BPF има единадесет достъпни за потребителя 64-битови регистъра r0-r10 и програмен брояч. Регистрирам r10 съдържа указател на рамка и е само за четене. Програмите имат достъп до 512-байтов стек по време на изпълнение и неограничено количество споделена памет под формата на карти.

На BPF програмите е разрешено да изпълняват специфичен набор от помощници на ядрото от програмен тип и, наскоро, обикновени функции. Всяка извикана функция може да приема до пет аргумента, предавани в регистри r1-r5и върнатата стойност се предава на r0. Гарантирано е, че след връщане от функцията, съдържанието на регистрите r6-r9 Няма да се промени.

За ефективен превод на програми, регистри r0-r11 за всички поддържани архитектури са уникално картографирани към реални регистри, като се вземат предвид характеристиките на ABI на текущата архитектура. Например за x86_64 регистри r1-r5, използвани за предаване на функционални параметри, се показват на rdi, rsi, rdx, rcx, r8, които се използват за предаване на параметри на функции на x86_64. Например кодът отляво се превежда в кода отдясно по следния начин:

1:  (b7) r1 = 1                    mov    $0x1,%rdi
2:  (b7) r2 = 2                    mov    $0x2,%rsi
3:  (b7) r3 = 3                    mov    $0x3,%rdx
4:  (b7) r4 = 4                    mov    $0x4,%rcx
5:  (b7) r5 = 5                    mov    $0x5,%r8
6:  (85) call pc+1                 callq  0x0000000000001ee8

Регистрирам r0 също се използва за връщане на резултата от изпълнението на програмата и в регистъра r1 на програмата се предава указател към контекста - в зависимост от вида на програмата, това може да бъде например структура struct xdp_md (за XDP) или структура struct __sk_buff (за различни мрежови програми) или структура struct pt_regs (за различни видове програми за проследяване) и др.

И така, имахме набор от регистри, помощници на ядрото, стек, контекстен указател и споделена памет под формата на карти. Не че всичко това е абсолютно необходимо по време на пътуването, но...

Нека продължим описанието и да поговорим за командната система за работа с тези обекти. Всичко (Почти всички) BPF инструкциите имат фиксиран 64-битов размер. Ако погледнете една инструкция на 64-битова Big Endian машина, ще видите

Тук Code - това е кодирането на инструкцията, Dst/Src са кодировките съответно на приемника и източника, Off - 16-битов отстъп със знак и Imm е 32-битово цяло число със знак, използвано в някои инструкции (подобно на cBPF константата K). Кодиране Code има един от двата вида:

Класове инструкции 0, 1, 2, 3 дефинират команди за работа с памет. Те са наречени, BPF_LD, BPF_LDX, BPF_ST, BPF_STX, съответно. Класове 4, 7 (BPF_ALU, BPF_ALU64) представляват набор от ALU инструкции. Класове 5, 6 (BPF_JMP, BPF_JMP32) съдържат инструкции за прескачане.

По-нататъшният план за изучаване на системата за инструкции на BPF е следният: вместо да изброяваме щателно всички инструкции и техните параметри, ще разгледаме няколко примера в този раздел и от тях ще стане ясно как всъщност работят инструкциите и как да ръчно разглобете всеки двоичен файл за BPF. За да консолидираме материала по-късно в статията, ще се срещнем и с отделни инструкции в разделите за Verifier, JIT компилатор, превод на класически BPF, както и при изучаване на карти, извикване на функции и т.н.

Когато говорим за отделни инструкции, ще говорим за основните файлове bpf.h и bpf_common.h, които определят цифровите кодове на BPF инструкциите. Когато изучавате архитектура самостоятелно и/или анализирате двоични файлове, можете да намерите семантика в следните източници, сортирани по сложност: Неофициална спецификация на eBPF, Справочно ръководство за BPF и XDP, набор от инструкции, Documentation/networking/filter.txt и, разбира се, в изходния код на Linux - верификатор, JIT, BPF интерпретатор.

Пример: разглобяване на BPF в главата ви

Нека да разгледаме пример, в който компилираме програма readelf-example.c и погледнете получения двоичен файл. Ние ще разкрием оригиналното съдържание readelf-example.c по-долу, след като възстановим логиката му от двоични кодове:

$ clang -target bpf -c readelf-example.c -o readelf-example.o -O2
$ llvm-readelf -x .text readelf-example.o
Hex dump of section '.text':
0x00000000 b7000000 01000000 15010100 00000000 ................
0x00000010 b7000000 02000000 95000000 00000000 ................

Първата колона в изхода readelf е отстъп и нашата програма се състои от четири команди:

Code Dst Src Off  Imm
b7   0   0   0000 01000000
15   0   1   0100 00000000
b7   0   0   0000 02000000
95   0   0   0000 00000000

Кодовете на командите са еднакви b7, 15, b7 и 95. Спомнете си, че най-малко значимите три бита са класът на инструкцията. В нашия случай четвъртият бит от всички инструкции е празен, така че класовете инструкции са съответно 7, 5, 7, 5. Клас 7 е BPF_ALU64, а 5 е BPF_JMP. И за двата класа форматът на инструкциите е един и същ (вижте по-горе) и можем да пренапишем нашата програма по този начин (в същото време ще пренапишем останалите колони в човешка форма):

Op S  Class   Dst Src Off  Imm
b  0  ALU64   0   0   0    1
1  0  JMP     0   1   1    0
b  0  ALU64   0   0   0    2
9  0  JMP     0   0   0    0

Операция b клас ALU64 - BPF_MOV. Той присвоява стойност на целевия регистър. Ако битът е зададен s (източник), тогава стойността се взема от регистъра източник, а ако, както в нашия случай, не е зададен, тогава стойността се взема от полето Imm. Така че в първата и третата инструкция извършваме операцията r0 = Imm. Освен това JMP клас 1 операция е BPF_JEQ (скочи, ако е равно). В нашия случай, тъй като бит S е нула, той сравнява стойността на изходния регистър с полето Imm. Ако стойностите съвпадат, тогава се извършва преходът към PC + OffКъдето PC, както обикновено, съдържа адреса на следващата инструкция. И накрая, JMP Class 9 Operation е BPF_EXIT. Тази инструкция прекратява програмата, връщайки се към ядрото r0. Нека добавим нова колона към нашата таблица:

Op    S  Class   Dst Src Off  Imm    Disassm
MOV   0  ALU64   0   0   0    1      r0 = 1
JEQ   0  JMP     0   1   1    0      if (r1 == 0) goto pc+1
MOV   0  ALU64   0   0   0    2      r0 = 2
EXIT  0  JMP     0   0   0    0      exit

Можем да пренапишем това в по-удобна форма:

     r0 = 1
     if (r1 == 0) goto END
     r0 = 2
END:
     exit

Ако си спомним какво има в регистъра r1 на програмата се предава указател към контекста от ядрото и в регистъра r0 стойността се връща на ядрото, тогава можем да видим, че ако указателят към контекста е нула, тогава връщаме 1, а в противен случай - 2. Нека проверим дали сме прави, като погледнем източника:

$ cat readelf-example.c
int foo(void *ctx)
{
        return ctx ? 2 : 1;
}

Да, това е безсмислена програма, но се превежда само в четири прости инструкции.

Пример за изключение: 16-байтова инструкция

По-рано споменахме, че някои инструкции заемат повече от 64 бита. Това се отнася например за инструкциите lddw (Код = 0x18 = BPF_LD | BPF_DW | BPF_IMM) — зареждане на двойна дума от полетата в регистъра Imm, Факт е, че Imm има размер 32, а двойната дума е 64 бита, така че зареждането на 64-битова непосредствена стойност в регистър в една 64-битова инструкция няма да работи. За да направите това, две съседни инструкции се използват за съхраняване на втората част от 64-битовата стойност в полето Imm, Пример:

$ cat x64.c
long foo(void *ctx)
{
        return 0x11223344aabbccdd;
}
$ clang -target bpf -c x64.c -o x64.o -O2
$ llvm-readelf -x .text x64.o
Hex dump of section '.text':
0x00000000 18000000 ddccbbaa 00000000 44332211 ............D3".
0x00000010 95000000 00000000                   ........

Има само две инструкции в една двоична програма:

Binary                                 Disassm
18000000 ddccbbaa 00000000 44332211    r0 = Imm[0]|Imm[1]
95000000 00000000                      exit

Ще се срещнем отново с инструкции lddw, когато говорим за премествания и работа с карти.

Пример: разглобяване на BPF с помощта на стандартни инструменти

И така, ние се научихме да четем BPF двоични кодове и сме готови да анализираме всяка инструкция, ако е необходимо. Въпреки това си струва да се каже, че на практика е по-удобно и по-бързо да разглобявате програми с помощта на стандартни инструменти, например:

$ llvm-objdump -d x64.o

Disassembly of section .text:

0000000000000000 <foo>:
 0: 18 00 00 00 dd cc bb aa 00 00 00 00 44 33 22 11 r0 = 1234605617868164317 ll
 2: 95 00 00 00 00 00 00 00 exit

Жизнен цикъл на BPF обекти, bpffs файлова система

(За първи път научих някои от подробностите, описани в този подраздел от пост Алексей Старовойтов в Блог на БНФ.)

BPF обекти - програми и карти - се създават от потребителско пространство с помощта на команди BPF_PROG_LOAD и BPF_MAP_CREATE системно повикване bpf(2), ще говорим как точно се случва това в следващия раздел. Това създава структури от данни на ядрото и за всяка от тях refcount (брой препратки) е зададен на едно и файлов дескриптор, сочещ към обекта, се връща на потребителя. След като дръжката е затворена refcount обектът се намалява с единица и когато достигне нула, обектът се унищожава.

Ако програмата използва карти, тогава refcount тези карти се увеличават с единица след зареждане на програмата, т.е. техните файлови дескриптори могат да бъдат затворени от потребителския процес и пак refcount няма да стане нула:

След успешно зареждане на програма, обикновено я прикачваме към някакъв генератор на събития. Например, можем да го поставим на мрежов интерфейс, за да обработва входящи пакети или да го свържем с някои tracepoint в сърцевината. В този момент броячът на препратките също ще се увеличи с единица и ще можем да затворим файловия дескриптор в програмата за зареждане.

Какво се случва, ако сега изключим буутлоудъра? Зависи от типа генератор на събития (кука). Всички мрежови кукички ще съществуват след завършване на зареждането, това са така наречените глобални кукички. И, например, програмите за проследяване ще бъдат освободени след прекратяване на процеса, който ги е създал (и затова се наричат ​​локални, от „локални към процеса“). Технически, локалните кукички винаги имат съответен файлов дескриптор в потребителското пространство и следователно се затварят, когато процесът е затворен, но глобалните кукички не го правят. На следващата фигура, използвайки червени кръстове, се опитвам да покажа как прекратяването на програмата за зареждане влияе на живота на обектите в случай на локални и глобални кукички.

Защо има разлика между локални и глобални кукички? Изпълнението на някои видове мрежови програми има смисъл без потребителско пространство, например, представете си DDoS защита - буутлоудърът пише правилата и свързва BPF програмата към мрежовия интерфейс, след което буутлоудърът може да отиде и да се самоубие. От друга страна, представете си програма за проследяване на грешки, която сте написали на колене за десет минути - когато е завършена, бихте искали да няма оставен боклук в системата и локалните кукички ще гарантират това.

От друга страна, представете си, че искате да се свържете с tracepoint в ядрото и да събирате статистика за много години. В този случай бихте искали да завършите потребителската част и да се връщате към статистиката от време на време. Файловата система bpf предоставя тази възможност. Това е псевдофайлова система само в паметта, която позволява създаването на файлове, които препращат към BPF обекти и по този начин увеличават refcount обекти. След това товарачът може да излезе и създадените от него обекти ще останат живи.

Създаването на файлове в bpffs, които препращат към BPF обекти, се нарича "закрепване" (както в следната фраза: "процесът може да закачи BPF програма или карта"). Създаването на файлови обекти за BPF обекти има смисъл не само за удължаване на живота на локалните обекти, но и за използваемостта на глобалните обекти - връщайки се към примера с глобалната програма за защита от DDoS, искаме да можем да дойдем и да разгледаме статистиките от време на време.

Файловата система BPF обикновено се монтира в /sys/fs/bpf, но може да се монтира и локално, например така:

$ mkdir bpf-mountpoint
$ sudo mount -t bpf none bpf-mountpoint

Имената на файловата система се създават с помощта на командата BPF_OBJ_PIN BPF системно повикване. За да илюстрираме, нека вземем програма, компилираме я, качим я и я закрепим към bpffs. Нашата програма не прави нищо полезно, ние само представяме кода, за да можете да възпроизведете примера:

$ cat test.c
__attribute__((section("xdp"), used))
int test(void *ctx)
{
        return 0;
}

char _license[] __attribute__((section("license"), used)) = "GPL";

Нека компилираме тази програма и създадем локално копие на файловата система bpffs:

$ clang -target bpf -c test.c -o test.o
$ mkdir bpf-mountpoint
$ sudo mount -t bpf none bpf-mountpoint

Сега нека изтеглим нашата програма с помощта на помощната програма bpftool и погледнете придружаващите системни повиквания bpf(2) (някои неподходящи редове са премахнати от изхода на strace):

$ sudo strace -e bpf bpftool prog load ./test.o bpf-mountpoint/test
bpf(BPF_PROG_LOAD, {prog_type=BPF_PROG_TYPE_XDP, prog_name="test", ...}, 120) = 3
bpf(BPF_OBJ_PIN, {pathname="bpf-mountpoint/test", bpf_fd=3}, 120) = 0

Тук заредихме програмата с помощта на BPF_PROG_LOAD, получи файлов дескриптор от ядрото 3 и използвайки командата BPF_OBJ_PIN фиксира този файлов дескриптор като файл "bpf-mountpoint/test". След това програмата за зареждане bpftool приключи работа, но нашата програма остана в ядрото, въпреки че не я прикачихме към никакъв мрежов интерфейс:

$ sudo bpftool prog | tail -3
783: xdp  name test  tag 5c8ba0cf164cb46c  gpl
        loaded_at 2020-05-05T13:27:08+0000  uid 0
        xlated 24B  jited 41B  memlock 4096B

Можем да изтрием файловия обект нормално unlink(2) и след това съответната програма ще бъде изтрита:

$ sudo rm ./bpf-mountpoint/test
$ sudo bpftool prog show id 783
Error: get by id (783): No such file or directory

Изтриване на обекти

Говорейки за изтриване на обекти, е необходимо да се изясни, че след като изключим програмата от куката (генератор на събития), нито едно ново събитие няма да задейства нейното стартиране, но всички текущи копия на програмата ще бъдат завършени в нормалния ред .

Някои видове BPF програми ви позволяват да замените програмата в движение, т.е. осигуряват атомарност на последователността replace = detach old program, attach new program. В този случай всички активни екземпляри на старата версия на програмата ще завършат работата си и от новата програма ще бъдат създадени нови манипулатори на събития, а „атомарността“ тук означава, че нито едно събитие няма да бъде пропуснато.

Прикачване на програми към източници на събития

В тази статия няма да описваме отделно свързването на програми към източници на събития, тъй като има смисъл да се изучава това в контекста на конкретен тип програма. См. пример по-долу, в който показваме как се свързват програми като XDP.

Манипулиране на обекти с помощта на bpf System Call

Програми на BPF

Всички BPF обекти се създават и управляват от потребителско пространство с помощта на системно повикване bpf, имащ следния прототип:

#include <linux/bpf.h>

int bpf(int cmd, union bpf_attr *attr, unsigned int size);

Ето го отбора cmd е една от стойностите на type enum bpf_cmd, attr — указател към параметри за конкретна програма и size — размер на обекта според показалеца, т.е. обикновено това sizeof(*attr). В ядрото 5.8 системното извикване bpf поддържа 34 различни команди и определяне на union bpf_attr заема 200 реда. Но не бива да се плашим от това, тъй като ще се запознаем с командите и параметрите в течение на няколко статии.

Да започнем с отбора BPF_PROG_LOAD, който създава BPF програми - взема набор от BPF инструкции и го зарежда в ядрото. В момента на зареждане се стартира верификаторът, след което JIT компилаторът и след успешно изпълнение дескрипторът на програмния файл се връща на потребителя. Видяхме какво се случва с него след това в предишния раздел за жизнения цикъл на BPF обекти.

Сега ще напишем персонализирана програма, която ще зареди проста BPF програма, но първо трябва да решим какъв вид програма искаме да заредим - ще трябва да изберем тип и в рамките на този тип напишете програма, която ще премине теста за проверка. Въпреки това, за да не усложняваме процеса, ето едно готово решение: ще вземем програма като BPF_PROG_TYPE_XDP, което ще върне стойността XDP_PASS (пропуснете всички пакети). В BPF асемблер изглежда много просто:

r0 = 2
exit

След като сме решили че ние ще качим, можем да ви кажем как ще го направим:

#define _GNU_SOURCE
#include <string.h>
#include <unistd.h>
#include <sys/syscall.h>
#include <linux/bpf.h>

static inline __u64 ptr_to_u64(const void *ptr)
{
        return (__u64) (unsigned long) ptr;
}

int main(void)
{
    struct bpf_insn insns[] = {
        {
            .code = BPF_ALU64 | BPF_MOV | BPF_K,
            .dst_reg = BPF_REG_0,
            .imm = XDP_PASS
        },
        {
            .code = BPF_JMP | BPF_EXIT
        },
    };

    union bpf_attr attr = {
        .prog_type = BPF_PROG_TYPE_XDP,
        .insns     = ptr_to_u64(insns),
        .insn_cnt  = sizeof(insns)/sizeof(insns[0]),
        .license   = ptr_to_u64("GPL"),
    };

    strncpy(attr.prog_name, "woo", sizeof(attr.prog_name));
    syscall(__NR_bpf, BPF_PROG_LOAD, &attr, sizeof(attr));

    for ( ;; )
        pause();
}

Интересните събития в програмата започват с дефинирането на масив insns - нашата BPF програма в машинен код. В този случай всяка инструкция на програмата BPF е пакетирана в структурата bpf_insn. Първи елемент insns спазва инструкциите r0 = 2, второ - exit.

Отстъпление. Ядрото дефинира по-удобни макроси за писане на машинни кодове и използване на заглавния файл на ядрото tools/include/linux/filter.h бихме могли да пишем

struct bpf_insn insns[] = {
    BPF_MOV64_IMM(BPF_REG_0, XDP_PASS),
    BPF_EXIT_INSN()
};

Но тъй като писането на BPF програми в естествен код е необходимо само за писане на тестове в ядрото и статии за BPF, отсъствието на тези макроси всъщност не усложнява живота на разработчика.

След като дефинираме програмата BPF, преминаваме към зареждането й в ядрото. Нашият минималистичен набор от параметри attr включва вида на програмата, набора и броя инструкции, необходимия лиценз и име "woo", който използваме, за да намерим нашата програма в системата след изтегляне. Програмата, както беше обещано, се зарежда в системата чрез системно повикване bpf.

В края на програмата се озоваваме в безкраен цикъл, който симулира полезния товар. Без него програмата ще бъде убита от ядрото, когато файловият дескриптор, върнат от системното извикване, бъде затворен bpf, и няма да го видим в системата.

Е, ние сме готови за тестване. Нека сглобим и стартираме програмата под straceза да проверите дали всичко работи както трябва:

$ clang -g -O2 simple-prog.c -o simple-prog

$ sudo strace ./simple-prog
execve("./simple-prog", ["./simple-prog"], 0x7ffc7b553480 /* 13 vars */) = 0
...
bpf(BPF_PROG_LOAD, {prog_type=BPF_PROG_TYPE_XDP, insn_cnt=2, insns=0x7ffe03c4ed50, license="GPL", log_level=0, log_size=0, log_buf=NULL, kern_version=KERNEL_V
ERSION(0, 0, 0), prog_flags=0, prog_name="woo", prog_ifindex=0, expected_attach_type=BPF_CGROUP_INET_INGRESS}, 72) = 3
pause(

Всичко е наред, bpf(2) ни върна манипулатор 3 и ние влязохме в безкраен цикъл с pause(). Нека се опитаме да намерим нашата програма в системата. За да направим това, ще отидем на друг терминал и ще използваме помощната програма bpftool:

# bpftool prog | grep -A3 woo
390: xdp  name woo  tag 3b185187f1855c4c  gpl
        loaded_at 2020-08-31T24:66:44+0000  uid 0
        xlated 16B  jited 40B  memlock 4096B
        pids simple-prog(10381)

Виждаме, че има заредена програма в системата woo чийто глобален идентификатор е 390 и в момента се изпълнява simple-prog има отворен файлов дескриптор, сочещ към програмата (и ако simple-prog тогава ще свърши работата woo ще изчезне). Както се очаква, програмата woo взема 16 байта - две инструкции - от двоични кодове в BPF архитектурата, но в естествената си форма (x86_64) вече е 40 байта. Нека да разгледаме нашата програма в оригиналния й вид:

# bpftool prog dump xlated id 390
   0: (b7) r0 = 2
   1: (95) exit

без изненади. Сега нека да разгледаме кода, генериран от JIT компилатора:

# bpftool prog dump jited id 390
bpf_prog_3b185187f1855c4c_woo:
   0:   nopl   0x0(%rax,%rax,1)
   5:   push   %rbp
   6:   mov    %rsp,%rbp
   9:   sub    $0x0,%rsp
  10:   push   %rbx
  11:   push   %r13
  13:   push   %r14
  15:   push   %r15
  17:   pushq  $0x0
  19:   mov    $0x2,%eax
  1e:   pop    %rbx
  1f:   pop    %r15
  21:   pop    %r14
  23:   pop    %r13
  25:   pop    %rbx
  26:   leaveq
  27:   retq

не е много ефективен за exit(2), но честно казано, нашата програма е твърде проста и за нетривиалните програми прологът и епилогът, добавени от JIT компилатора, разбира се, са необходими.

Карти

BPF програмите могат да използват структурирани области на паметта, които са достъпни както за други BPF програми, така и за програми в потребителското пространство. Тези обекти се наричат ​​карти и в този раздел ще покажем как да ги манипулираме с помощта на системно извикване bpf.

Нека кажем веднага, че възможностите на картите не се ограничават само до достъп до споделена памет. Има карти със специално предназначение, съдържащи например указатели към BPF програми или указатели към мрежови интерфейси, карти за работа с perf събития и т.н. Тук няма да говорим за тях, за да не объркаме читателя. Отделно от това, ние игнорираме проблемите със синхронизацията, тъй като това не е важно за нашите примери. Пълен списък на наличните типове карти можете да намерите в <linux/bpf.h>, а в този раздел ще вземем за пример исторически първия тип, хеш-таблицата BPF_MAP_TYPE_HASH.

Ако създадете хеш таблица в, да речем, C++, бихте казали unordered_map<int,long> woo, което на руски означава „Имам нужда от маса woo неограничен размер, чиито ключове са тип int, а стойностите са типът long" За да създадем BPF хеш таблица, трябва да направим почти същото, с изключение на това, че трябва да посочим максималния размер на таблицата и вместо да посочим типовете ключове и стойности, трябва да посочим техните размери в байтове . За да създадете карти, използвайте командата BPF_MAP_CREATE системно повикване bpf. Нека да разгледаме повече или по-малко минимална програма, която създава карта. След предишната програма, която зарежда BPF програми, тази трябва да ви изглежда проста:

$ cat simple-map.c
#define _GNU_SOURCE
#include <string.h>
#include <unistd.h>
#include <sys/syscall.h>
#include <linux/bpf.h>

int main(void)
{
    union bpf_attr attr = {
        .map_type = BPF_MAP_TYPE_HASH,
        .key_size = sizeof(int),
        .value_size = sizeof(int),
        .max_entries = 4,
    };
    strncpy(attr.map_name, "woo", sizeof(attr.map_name));
    syscall(__NR_bpf, BPF_MAP_CREATE, &attr, sizeof(attr));

    for ( ;; )
        pause();
}

Тук дефинираме набор от параметри attr, в който казваме „Имам нужда от хеш таблица с ключове и стойности на размера sizeof(int), в който мога да сложа максимум четири елемента." Когато създавате BPF карти, можете да зададете други параметри, например по същия начин, както в примера с програмата, посочихме името на обекта като "woo".

Нека компилираме и стартираме програмата:

$ clang -g -O2 simple-map.c -o simple-map
$ sudo strace ./simple-map
execve("./simple-map", ["./simple-map"], 0x7ffd40a27070 /* 14 vars */) = 0
...
bpf(BPF_MAP_CREATE, {map_type=BPF_MAP_TYPE_HASH, key_size=4, value_size=4, max_entries=4, map_name="woo", ...}, 72) = 3
pause(

Ето го системното повикване bpf(2) ни върна номера на дескрипторната карта 3 и след това програмата, както се очаква, чака допълнителни инструкции в системното повикване pause(2).

Сега нека изпратим нашата програма на заден план или да отворим друг терминал и да разгледаме нашия обект с помощта на помощната програма bpftool (можем да различим нашата карта от другите по нейното име):

$ sudo bpftool map
...
114: hash  name woo  flags 0x0
        key 4B  value 4B  max_entries 4  memlock 4096B
...

Числото 114 е глобалният идентификатор на нашия обект. Всяка програма в системата може да използва този идентификатор, за да отвори съществуваща карта с помощта на командата BPF_MAP_GET_FD_BY_ID системно повикване bpf.

Сега можем да играем с нашата хеш таблица. Нека да разгледаме съдържанието му:

$ sudo bpftool map dump id 114
Found 0 elements

празна. Нека поставим стойност в него hash[1] = 1:

$ sudo bpftool map update id 114 key 1 0 0 0 value 1 0 0 0

Да погледнем отново таблицата:

$ sudo bpftool map dump id 114
key: 01 00 00 00  value: 01 00 00 00
Found 1 element

Ура! Успяхме да добавим един елемент. Имайте предвид, че трябва да работим на ниво байт, за да направим това, тъй като bptftool не знае какъв тип са стойностите в хеш-таблицата. (Тези знания могат да бъдат прехвърлени към нея с помощта на BTF, но повече за това сега.)

Как точно bpftool чете и добавя елементи? Нека да надникнем под капака:

$ sudo strace -e bpf bpftool map dump id 114
bpf(BPF_MAP_GET_FD_BY_ID, {map_id=114, next_id=0, open_flags=0}, 120) = 3
bpf(BPF_MAP_GET_NEXT_KEY, {map_fd=3, key=NULL, next_key=0x55856ab65280}, 120) = 0
bpf(BPF_MAP_LOOKUP_ELEM, {map_fd=3, key=0x55856ab65280, value=0x55856ab652a0}, 120) = 0
key: 01 00 00 00  value: 01 00 00 00
bpf(BPF_MAP_GET_NEXT_KEY, {map_fd=3, key=0x55856ab65280, next_key=0x55856ab65280}, 120) = -1 ENOENT

Първо отворихме картата по нейния глобален идентификатор с помощта на командата BPF_MAP_GET_FD_BY_ID и bpf(2) ни върна дескриптор 3. По-нататъшно използване на командата BPF_MAP_GET_NEXT_KEY намерихме първия ключ в таблицата чрез преминаване NULL като указател към "предишния" ключ. Ако имаме ключа, можем да го направим BPF_MAP_LOOKUP_ELEMкойто връща стойност към указател value. Следващата стъпка е да се опитаме да намерим следващия елемент, като подадем указател към текущия ключ, но нашата таблица съдържа само един елемент и командата BPF_MAP_GET_NEXT_KEY се завръща ENOENT.

Добре, нека променим стойността с ключ 1, да кажем, че нашата бизнес логика изисква регистрация hash[1] = 2:

$ sudo strace -e bpf bpftool map update id 114 key 1 0 0 0 value 2 0 0 0
bpf(BPF_MAP_GET_FD_BY_ID, {map_id=114, next_id=0, open_flags=0}, 120) = 3
bpf(BPF_MAP_UPDATE_ELEM, {map_fd=3, key=0x55dcd72be260, value=0x55dcd72be280, flags=BPF_ANY}, 120) = 0

Както се очаква, това е много просто: командата BPF_MAP_GET_FD_BY_ID отваря нашата карта по ID и командата BPF_MAP_UPDATE_ELEM презаписва елемента.

Така че, след като създадем хеш таблица от една програма, можем да четем и записваме нейното съдържание от друга. Имайте предвид, че ако успяхме да направим това от командния ред, тогава всяка друга програма в системата може да го направи. В допълнение към командите, описани по-горе, за работа с карти от потребителското пространство, следното:

• BPF_MAP_LOOKUP_ELEM: намиране на стойност по ключ
• BPF_MAP_UPDATE_ELEM: актуализиране/създаване на стойност
• BPF_MAP_DELETE_ELEM: извадете ключа
• BPF_MAP_GET_NEXT_KEY: намерете следващия (или първия) ключ
• BPF_MAP_GET_NEXT_ID: позволява ви да преминете през всички съществуващи карти, така работи bpftool map
• BPF_MAP_GET_FD_BY_ID: отваря съществуваща карта по нейния глобален идентификатор
• BPF_MAP_LOOKUP_AND_DELETE_ELEM: атомно актуализира стойността на обект и връща старата
• BPF_MAP_FREEZE: направете картата неизменна от потребителското пространство (тази операция не може да бъде отменена)
• BPF_MAP_LOOKUP_BATCH, BPF_MAP_LOOKUP_AND_DELETE_BATCH, BPF_MAP_UPDATE_BATCH, BPF_MAP_DELETE_BATCH: масови операции. Например, BPF_MAP_LOOKUP_AND_DELETE_BATCH - това е единственият надежден начин за четене и нулиране на всички стойности от картата

Не всички от тези команди работят за всички типове карти, но като цяло работата с други типове карти от потребителското пространство изглежда точно същата като работата с хеш таблици.

В името на реда, нека завършим нашите експерименти с хеш таблици. Помните ли, че създадохме таблица, която може да съдържа до четири ключа? Нека добавим още няколко елемента:

$ sudo bpftool map update id 114 key 2 0 0 0 value 1 0 0 0
$ sudo bpftool map update id 114 key 3 0 0 0 value 1 0 0 0
$ sudo bpftool map update id 114 key 4 0 0 0 value 1 0 0 0

Дотук добре:

$ sudo bpftool map dump id 114
key: 01 00 00 00  value: 01 00 00 00
key: 02 00 00 00  value: 01 00 00 00
key: 04 00 00 00  value: 01 00 00 00
key: 03 00 00 00  value: 01 00 00 00
Found 4 elements

Нека се опитаме да добавим още един:

$ sudo bpftool map update id 114 key 5 0 0 0 value 1 0 0 0
Error: update failed: Argument list too long

Очаквано не успяхме. Нека разгледаме грешката по-подробно:

$ sudo strace -e bpf bpftool map update id 114 key 5 0 0 0 value 1 0 0 0
bpf(BPF_MAP_GET_FD_BY_ID, {map_id=114, next_id=0, open_flags=0}, 120) = 3
bpf(BPF_OBJ_GET_INFO_BY_FD, {info={bpf_fd=3, info_len=80, info=0x7ffe6c626da0}}, 120) = 0
bpf(BPF_MAP_UPDATE_ELEM, {map_fd=3, key=0x56049ded5260, value=0x56049ded5280, flags=BPF_ANY}, 120) = -1 E2BIG (Argument list too long)
Error: update failed: Argument list too long
+++ exited with 255 +++

Всичко е наред: както се очаква, екипът BPF_MAP_UPDATE_ELEM опитва да създаде нов, пети, ключ, но се срива E2BIG.

Така че можем да създаваме и зареждаме BPF програми, както и да създаваме и управляваме карти от потребителското пространство. Сега е логично да разгледаме как можем да използваме карти от самите програми на BPF. Можем да говорим за това на езика на трудни за четене програми в машинни макро кодове, но всъщност е дошло времето да покажем как BPF програмите всъщност се пишат и поддържат - използвайки libbpf.

(За читатели, които са недоволни от липсата на пример на ниско ниво: ще анализираме подробно програми, които използват карти и помощни функции, създадени с libbpf и да ви кажа какво се случва на ниво инструкции. За читатели, които са недоволни много, добавихме пример на съответното място в статията.)

Писане на BPF програми с помощта на libbpf

Писането на BPF програми с помощта на машинни кодове може да бъде интересно само за първи път и след това настъпва насищане. В този момент трябва да насочите вниманието си към llvm, който има бекенд за генериране на код за BPF архитектурата, както и библиотека libbpf, което ви позволява да пишете потребителската страна на BPF приложенията и да зареждате кода на BPF програмите, генерирани с помощта llvm/clang.

Всъщност, както ще видим в тази и следващите статии, libbpf върши доста работа без него (или подобни инструменти - iproute2, libbcc, libbpf-go, и т.н.) е невъзможно да се живее. Една от убийствените функции на проекта libbpf е BPF CO-RE (Compile Once, Run Everywhere) - проект, който ви позволява да пишете BPF програми, които са преносими от едно ядро ​​на друго, с възможност за изпълнение на различни API (например, когато структурата на ядрото се промени от версия към версия). За да можете да работите с CO-RE, вашето ядро ​​трябва да бъде компилирано с поддръжка на BTF (ние описваме как да направите това в раздела Инструменти за разработка. Можете да проверите дали вашето ядро ​​е изградено с BTF или не много просто - чрез наличието на следния файл:

$ ls -lh /sys/kernel/btf/vmlinux
-r--r--r-- 1 root root 2.6M Jul 29 15:30 /sys/kernel/btf/vmlinux

Този файл съхранява информация за всички типове данни, използвани в ядрото и се използва във всички наши примери за използване libbpf. Ще говорим подробно за CO-RE в следващата статия, но в тази - просто си изградете ядро ​​с него CONFIG_DEBUG_INFO_BTF.

Библиотека libbpf живее точно в директорията tools/lib/bpf ядрото и неговото развитие се извършва чрез пощенския списък [email protected]. Въпреки това се поддържа отделно хранилище за нуждите на приложения, живеещи извън ядрото https://github.com/libbpf/libbpf в която библиотеката на ядрото е огледална за достъп за четене повече или по-малко такава, каквато е.

В този раздел ще разгледаме как можете да създадете проект, който използва libbpf, нека напишем няколко (повече или по-малко безсмислени) тестови програми и да анализираме подробно как работи всичко. Това ще ни позволи по-лесно да обясним в следващите раздели как точно BPF програмите взаимодействат с карти, помощници на ядрото, BTF и т.н.

Обикновено проектите използват libbpf добавите GitHub хранилище като git подмодул, ще направим същото:

$ mkdir /tmp/libbpf-example
$ cd /tmp/libbpf-example/
$ git init-db
Initialized empty Git repository in /tmp/libbpf-example/.git/
$ git submodule add https://github.com/libbpf/libbpf.git
Cloning into '/tmp/libbpf-example/libbpf'...
remote: Enumerating objects: 200, done.
remote: Counting objects: 100% (200/200), done.
remote: Compressing objects: 100% (103/103), done.
remote: Total 3354 (delta 101), reused 118 (delta 79), pack-reused 3154
Receiving objects: 100% (3354/3354), 2.05 MiB | 10.22 MiB/s, done.
Resolving deltas: 100% (2176/2176), done.

Отивам до libbpf много просто:

$ cd libbpf/src
$ mkdir build
$ OBJDIR=build DESTDIR=root make -s install
$ find root
root
root/usr
root/usr/include
root/usr/include/bpf
root/usr/include/bpf/bpf_tracing.h
root/usr/include/bpf/xsk.h
root/usr/include/bpf/libbpf_common.h
root/usr/include/bpf/bpf_endian.h
root/usr/include/bpf/bpf_helpers.h
root/usr/include/bpf/btf.h
root/usr/include/bpf/bpf_helper_defs.h
root/usr/include/bpf/bpf.h
root/usr/include/bpf/libbpf_util.h
root/usr/include/bpf/libbpf.h
root/usr/include/bpf/bpf_core_read.h
root/usr/lib64
root/usr/lib64/libbpf.so.0.1.0
root/usr/lib64/libbpf.so.0
root/usr/lib64/libbpf.a
root/usr/lib64/libbpf.so
root/usr/lib64/pkgconfig
root/usr/lib64/pkgconfig/libbpf.pc

Следващият ни план в този раздел е следният: ще напишем BPF програма като BPF_PROG_TYPE_XDP, същото като в предишния пример, но в C, ние го компилираме с помощта на clangи напишете помощна програма, която ще го зареди в ядрото. В следващите раздели ще разширим възможностите както на програмата BPF, така и на асистентската програма.

Пример: създаване на пълноценно приложение с помощта на libbpf

Като начало използваме файла /sys/kernel/btf/vmlinux, което беше споменато по-горе, и създайте негов еквивалент под формата на заглавен файл:

$ bpftool btf dump file /sys/kernel/btf/vmlinux format c > vmlinux.h

Този файл ще съхранява всички структури от данни, налични в нашето ядро, например, ето как IPv4 хедърът е дефиниран в ядрото:

$ grep -A 12 'struct iphdr {' vmlinux.h
struct iphdr {
    __u8 ihl: 4;
    __u8 version: 4;
    __u8 tos;
    __be16 tot_len;
    __be16 id;
    __be16 frag_off;
    __u8 ttl;
    __u8 protocol;
    __sum16 check;
    __be32 saddr;
    __be32 daddr;
};

Сега ще напишем нашата BPF програма на C:

$ cat xdp-simple.bpf.c
#include "vmlinux.h"
#include <bpf/bpf_helpers.h>

SEC("xdp/simple")
int simple(void *ctx)
{
        return XDP_PASS;
}

char LICENSE[] SEC("license") = "GPL";

Въпреки че нашата програма се оказа много проста, все пак трябва да обърнем внимание на много подробности. Първо, първият заглавен файл, който включваме, е vmlinux.h, който току-що генерирахме с помощта на bpftool btf dump - сега не е необходимо да инсталираме пакета kernel-headers, за да разберем как изглеждат структурите на ядрото. Следният заглавен файл идва при нас от библиотеката libbpf. Сега ни трябва само за дефиниране на макроса SEC, който изпраща знака в съответния раздел на ELF обектния файл. Нашата програма се съдържа в раздела xdp/simple, където преди наклонената черта дефинираме вида на програмата BPF - това е конвенцията, използвана в libbpf, въз основа на името на раздела, той ще замени правилния тип при стартиране bpf(2). Самата програма на БНФ е C - много проста и се състои от един ред return XDP_PASS. И накрая, отделен раздел "license" съдържа името на лиценза.

Можем да компилираме нашата програма с помощта на llvm/clang, версия >= 10.0.0 или още по-добре, по-висока (вижте раздела Инструменти за разработка):

$ clang --version
clang version 11.0.0 (https://github.com/llvm/llvm-project.git afc287e0abec710398465ee1f86237513f2b5091)
...

$ clang -O2 -g -c -target bpf -I libbpf/src/root/usr/include xdp-simple.bpf.c -o xdp-simple.bpf.o

Сред интересните функции: посочваме целевата архитектура -target bpf и пътя към заглавките libbpf, който наскоро инсталирахме. Също така, не забравяйте за -O2, без тази опция може да ви очакват изненади в бъдеще. Нека да погледнем нашия код, успяхме ли да напишем програмата, която искахме?

$ llvm-objdump --section=xdp/simple --no-show-raw-insn -D xdp-simple.bpf.o

xdp-simple.bpf.o:       file format elf64-bpf

Disassembly of section xdp/simple:

0000000000000000 <simple>:
       0:       r0 = 2
       1:       exit

Да, проработи! Сега имаме двоичен файл с програмата и искаме да създадем приложение, което ще го зареди в ядрото. За целта библиотеката libbpf ни предлага две опции – използване на API от по-ниско ниво или API от по-високо ниво. Ще отидем по втория начин, тъй като искаме да се научим как да пишем, зареждаме и свързваме BPF програми с минимални усилия за последващото им изучаване.

Първо, трябва да генерираме „скелета“ на нашата програма от нейния двоичен файл, като използваме същата помощна програма bpftool — швейцарският нож на света на BPF (което може да се приеме буквално, тъй като Даниел Боркман, един от създателите и поддържащите BPF, е швейцарец):

$ bpftool gen skeleton xdp-simple.bpf.o > xdp-simple.skel.h

Във файла xdp-simple.skel.h съдържа двоичния код на нашата програма и функции за управление - зареждане, прикачване, изтриване на нашия обект. В нашия прост случай това изглежда пресилено, но работи и в случай, че обектният файл съдържа много BPF програми и карти и за да заредим този гигантски ELF, ние просто трябва да генерираме скелета и да извикаме една или две функции от персонализираното приложение, което пишат Да продължим сега.

Строго погледнато, нашата програма за зареждане е тривиална:

#include <err.h>
#include <unistd.h>
#include "xdp-simple.skel.h"

int main(int argc, char **argv)
{
    struct xdp_simple_bpf *obj;

    obj = xdp_simple_bpf__open_and_load();
    if (!obj)
        err(1, "failed to open and/or load BPF objectn");

    pause();

    xdp_simple_bpf__destroy(obj);
}

Тук struct xdp_simple_bpf дефинирани във файла xdp-simple.skel.h и описва нашия обектен файл:

struct xdp_simple_bpf {
    struct bpf_object_skeleton *skeleton;
    struct bpf_object *obj;
    struct {
        struct bpf_program *simple;
    } progs;
    struct {
        struct bpf_link *simple;
    } links;
};

Тук можем да видим следи от API на ниско ниво: структурата struct bpf_program *simple и struct bpf_link *simple. Първата структура конкретно описва нашата програма, написана в раздела xdp/simple, а втората описва как програмата се свързва с източника на събитието.

Функция xdp_simple_bpf__open_and_load, отваря ELF обект, анализира го, създава всички структури и подструктури (освен програмата, ELF съдържа и други раздели - данни, данни само за четене, информация за отстраняване на грешки, лиценз и т.н.) и след това го зарежда в ядрото с помощта на система обадете се bpf, което можем да проверим чрез компилиране и изпълнение на програмата:

$ clang -O2 -I ./libbpf/src/root/usr/include/ xdp-simple.c -o xdp-simple ./libbpf/src/root/usr/lib64/libbpf.a -lelf -lz

$ sudo strace -e bpf ./xdp-simple
...
bpf(BPF_BTF_LOAD, 0x7ffdb8fd9670, 120)  = 3
bpf(BPF_PROG_LOAD, {prog_type=BPF_PROG_TYPE_XDP, insn_cnt=2, insns=0xdfd580, license="GPL", log_level=0, log_size=0, log_buf=NULL, kern_version=KERNEL_VERSION(5, 8, 0), prog_flags=0, prog_name="simple", prog_ifindex=0, expected_attach_type=0x25 /* BPF_??? */, ...}, 120) = 4

Нека сега да разгледаме нашата програма, използваща bpftool. Нека намерим нейния ID:

# bpftool p | grep -A4 simple
463: xdp  name simple  tag 3b185187f1855c4c  gpl
        loaded_at 2020-08-01T01:59:49+0000  uid 0
        xlated 16B  jited 40B  memlock 4096B
        btf_id 185
        pids xdp-simple(16498)

и dump (използваме съкратена форма на командата bpftool prog dump xlated):

# bpftool p d x id 463
int simple(void *ctx):
; return XDP_PASS;
   0: (b7) r0 = 2
   1: (95) exit

Нещо ново! Програмата отпечата части от нашия изходен файл на C. Това беше направено от библиотеката libbpf, който намери раздела за отстраняване на грешки в двоичния файл, компилира го в BTF обект, зареди го в ядрото с помощта на BPF_BTF_LOAD, и след това посочи резултантния файлов дескриптор при зареждане на програмата с командата BPG_PROG_LOAD.

Помощници на ядрото

BPF програмите могат да изпълняват „външни“ функции - помощници на ядрото. Тези помощни функции позволяват на BPF програмите да имат достъп до структурите на ядрото, да управляват карти и също да комуникират с „реалния свят“ - да създават перф събития, да контролират хардуера (например пренасочване на пакети) и т.н.

Пример: bpf_get_smp_processor_id

В рамките на парадигмата „учене чрез пример“, нека разгледаме една от помощните функции, bpf_get_smp_processor_id(), определени във файл kernel/bpf/helpers.c. Връща номера на процесора, на който работи BPF програмата, която го е извикала. Но не се интересуваме толкова от неговата семантика, колкото от факта, че изпълнението му отнема един ред:

BPF_CALL_0(bpf_get_smp_processor_id)
{
    return smp_processor_id();
}

Дефинициите на помощната функция на BPF са подобни на дефинициите на системните повиквания на Linux. Тук например е дефинирана функция, която няма аргументи. (Функция, която приема, да речем, три аргумента, се дефинира с помощта на макроса BPF_CALL_3. Максималният брой аргументи е пет.) Това обаче е само първата част от дефиницията. Втората част е да се дефинира структурата на типа struct bpf_func_proto, който съдържа описание на помощната функция, която верификаторът разбира:

const struct bpf_func_proto bpf_get_smp_processor_id_proto = {
    .func     = bpf_get_smp_processor_id,
    .gpl_only = false,
    .ret_type = RET_INTEGER,
};

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

За да могат BPF програми от определен тип да използват тази функция, те трябва да я регистрират, например за типа BPF_PROG_TYPE_XDP функция е дефинирана в ядрото xdp_func_proto, който определя от идентификатора на помощната функция дали XDP поддържа тази функция или не. Нашата функция е поддържа:

static const struct bpf_func_proto *
xdp_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog)
{
    switch (func_id) {
    ...
    case BPF_FUNC_get_smp_processor_id:
        return &bpf_get_smp_processor_id_proto;
    ...
    }
}

Нови типове BPF програми са "дефинирани" във файла include/linux/bpf_types.h с помощта на макрос BPF_PROG_TYPE. Дефиниран в кавички, защото това е логическа дефиниция, а в термините на езика C дефиницията на цял набор от конкретни структури се среща на други места. По-специално във файла kernel/bpf/verifier.c всички дефиниции от файла bpf_types.h се използват за създаване на масив от структури bpf_verifier_ops[]:

static const struct bpf_verifier_ops *const bpf_verifier_ops[] = {
#define BPF_PROG_TYPE(_id, _name, prog_ctx_type, kern_ctx_type) 
    [_id] = & _name ## _verifier_ops,
#include <linux/bpf_types.h>
#undef BPF_PROG_TYPE
};

Тоест, за всеки тип BPF програма се дефинира указател към структура от данни на типа struct bpf_verifier_ops, който се инициализира със стойността _name ## _verifier_ops, т.е. xdp_verifier_ops за xdp. Структура xdp_verifier_ops определено от във файл net/core/filter.c както следва:

const struct bpf_verifier_ops xdp_verifier_ops = {
    .get_func_proto     = xdp_func_proto,
    .is_valid_access    = xdp_is_valid_access,
    .convert_ctx_access = xdp_convert_ctx_access,
    .gen_prologue       = bpf_noop_prologue,
};

Тук виждаме познатата ни функция xdp_func_proto, който ще стартира верификатора всеки път, когато срещне предизвикателство някакъв вид функции в BPF програма, вижте verifier.c.

Нека да разгледаме как една хипотетична BPF програма използва функцията bpf_get_smp_processor_id. За да направим това, пренаписваме програмата от предишния ни раздел, както следва:

#include "vmlinux.h"
#include <bpf/bpf_helpers.h>

SEC("xdp/simple")
int simple(void *ctx)
{
    if (bpf_get_smp_processor_id() != 0)
        return XDP_DROP;
    return XDP_PASS;
}

char LICENSE[] SEC("license") = "GPL";

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

static u32 (*bpf_get_smp_processor_id)(void) = (void *) 8;

това е, bpf_get_smp_processor_id е указател на функция, чиято стойност е 8, където 8 е стойността BPF_FUNC_get_smp_processor_id типа enum bpf_fun_id, който е дефиниран за нас във файла vmlinux.h (файл bpf_helper_defs.h в ядрото се генерира от скрипт, така че „магическите“ числа са ок). Тази функция не приема аргументи и връща стойност от тип __u32. Когато го стартираме в нашата програма, clang генерира инструкция BPF_CALL "правилният вид" Нека компилираме програмата и разгледаме секцията xdp/simple:

$ clang -O2 -g -c -target bpf -I libbpf/src/root/usr/include xdp-simple.bpf.c -o xdp-simple.bpf.o
$ llvm-objdump -D --section=xdp/simple xdp-simple.bpf.o

xdp-simple.bpf.o:       file format elf64-bpf

Disassembly of section xdp/simple:

0000000000000000 <simple>:
       0:       85 00 00 00 08 00 00 00 call 8
       1:       bf 01 00 00 00 00 00 00 r1 = r0
       2:       67 01 00 00 20 00 00 00 r1 <<= 32
       3:       77 01 00 00 20 00 00 00 r1 >>= 32
       4:       b7 00 00 00 02 00 00 00 r0 = 2
       5:       15 01 01 00 00 00 00 00 if r1 == 0 goto +1 <LBB0_2>
       6:       b7 00 00 00 01 00 00 00 r0 = 1

0000000000000038 <LBB0_2>:
       7:       95 00 00 00 00 00 00 00 exit

В първия ред виждаме инструкции call, параметър IMM което е равно на 8, и SRC_REG - нула. Според ABI споразумението, използвано от верификатора, това е извикване на помощна функция номер осем. След като се стартира, логиката е проста. Върната стойност от регистъра r0 копирано в r1 и на редове 2,3 се преобразува в тип u32 — горните 32 бита се изчистват. На редове 4,5,6,7 връщаме 2 (XDP_PASS) или 1 (XDP_DROP) в зависимост от това дали помощната функция от ред 0 е върнала нулева или ненулева стойност.

Нека се тестваме: заредете програмата и погледнете изхода bpftool prog dump xlated:

$ bpftool gen skeleton xdp-simple.bpf.o > xdp-simple.skel.h
$ clang -O2 -g -I ./libbpf/src/root/usr/include/ -o xdp-simple xdp-simple.c ./libbpf/src/root/usr/lib64/libbpf.a -lelf -lz
$ sudo ./xdp-simple &
[2] 10914

$ sudo bpftool p | grep simple
523: xdp  name simple  tag 44c38a10c657e1b0  gpl
        pids xdp-simple(10915)

$ sudo bpftool p d x id 523
int simple(void *ctx):
; if (bpf_get_smp_processor_id() != 0)
   0: (85) call bpf_get_smp_processor_id#114128
   1: (bf) r1 = r0
   2: (67) r1 <<= 32
   3: (77) r1 >>= 32
   4: (b7) r0 = 2
; }
   5: (15) if r1 == 0x0 goto pc+1
   6: (b7) r0 = 1
   7: (95) exit

Добре, верификаторът намери правилния помощник на ядрото.

Пример: предаване на аргументи и накрая изпълнение на програмата!

Всички помощни функции на ниво изпълнение имат прототип

u64 fn(u64 r1, u64 r2, u64 r3, u64 r4, u64 r5)

Параметрите на помощните функции се предават в регистрите r1-r5и стойността се връща в регистъра r0. Няма функции, които приемат повече от пет аргумента и не се очаква поддръжка за тях да бъде добавена в бъдеще.

Нека да разгледаме новия помощник на ядрото и как BPF предава параметри. Да пренапишем xdp-simple.bpf.c както следва (останалите редове не са променени):

SEC("xdp/simple")
int simple(void *ctx)
{
    bpf_printk("running on CPU%un", bpf_get_smp_processor_id());
    return XDP_PASS;
}

Нашата програма отпечатва номера на процесора, на който работи. Нека го компилираме и разгледаме кода:

$ llvm-objdump -D --section=xdp/simple --no-show-raw-insn xdp-simple.bpf.o

0000000000000000 <simple>:
       0:       r1 = 10
       1:       *(u16 *)(r10 - 8) = r1
       2:       r1 = 8441246879787806319 ll
       4:       *(u64 *)(r10 - 16) = r1
       5:       r1 = 2334956330918245746 ll
       7:       *(u64 *)(r10 - 24) = r1
       8:       call 8
       9:       r1 = r10
      10:       r1 += -24
      11:       r2 = 18
      12:       r3 = r0
      13:       call 6
      14:       r0 = 2
      15:       exit

В редове 0-7 записваме низа running on CPU%un, а след това на ред 8 изпълняваме познатия bpf_get_smp_processor_id. На редове 9-12 подготвяме помощните аргументи bpf_printk - регистри r1, r2, r3. Защо са три, а не две? защото bpf_printk - това е обвивка на макроси около истинския помощник bpf_trace_printk, който трябва да предаде размера на форматиращия низ.

Нека сега добавим няколко реда към xdp-simple.cтака че нашата програма да се свърже с интерфейса lo и наистина започна!

$ cat xdp-simple.c
#include <linux/if_link.h>
#include <err.h>
#include <unistd.h>
#include "xdp-simple.skel.h"

int main(int argc, char **argv)
{
    __u32 flags = XDP_FLAGS_SKB_MODE;
    struct xdp_simple_bpf *obj;

    obj = xdp_simple_bpf__open_and_load();
    if (!obj)
        err(1, "failed to open and/or load BPF objectn");

    bpf_set_link_xdp_fd(1, -1, flags);
    bpf_set_link_xdp_fd(1, bpf_program__fd(obj->progs.simple), flags);

cleanup:
    xdp_simple_bpf__destroy(obj);
}

Тук използваме функцията bpf_set_link_xdp_fd, който свързва BPF програми от тип XDP към мрежови интерфейси. Твърдо кодирахме номера на интерфейса lo, което винаги е 1. Изпълняваме функцията два пъти, за да откачим първо старата програма, ако е била прикачена. Забележете, че сега нямаме нужда от предизвикателство pause или безкраен цикъл: нашата програма за зареждане ще излезе, но програмата BPF няма да бъде убита, тъй като е свързана към източника на събитие. След успешно изтегляне и свързване, програмата ще се стартира за всеки пристигащ мрежов пакет lo.

Нека изтеглим програмата и да разгледаме интерфейса lo:

$ sudo ./xdp-simple
$ sudo bpftool p | grep simple
669: xdp  name simple  tag 4fca62e77ccb43d6  gpl
$ ip l show dev lo
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 xdpgeneric qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    prog/xdp id 669

Програмата, която изтеглихме, има ID 669 и виждаме същия ID на интерфейса lo. Ще изпратим няколко пакета на 127.0.0.1 (заявка + отговор):

$ ping -c1 localhost

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

# cat /sys/kernel/debug/tracing/trace_pipe
ping-13937 [000] d.s1 442015.377014: bpf_trace_printk: running on CPU0
ping-13937 [000] d.s1 442015.377027: bpf_trace_printk: running on CPU0

Бяха забелязани два пакета lo и обработен на CPU0 - първата ни пълноценна безсмислена BPF програма работи!

Заслужава да се отбележи, че bpf_printk Не е за нищо, че пише във файла за отстраняване на грешки: това не е най-успешният помощник за използване в производството, но нашата цел беше да покажем нещо просто.

Достъп до карти от BPF програми

Пример: използване на карта от програмата BPF

В предишните раздели научихме как да създаваме и използваме карти от потребителското пространство, а сега нека да разгледаме частта от ядрото. Нека започнем, както обикновено, с пример. Нека пренапишем нашата програма xdp-simple.bpf.c както следва:

#include "vmlinux.h"
#include <bpf/bpf_helpers.h>

struct {
    __uint(type, BPF_MAP_TYPE_ARRAY);
    __uint(max_entries, 8);
    __type(key, u32);
    __type(value, u64);
} woo SEC(".maps");

SEC("xdp/simple")
int simple(void *ctx)
{
    u32 key = bpf_get_smp_processor_id();
    u32 *val;

    val = bpf_map_lookup_elem(&woo, &key);
    if (!val)
        return XDP_ABORTED;

    *val += 1;

    return XDP_PASS;
}

char LICENSE[] SEC("license") = "GPL";

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

$ clang -O2 -g -c -target bpf -I libbpf/src/root/usr/include xdp-simple.bpf.c -o xdp-simple.bpf.o
$ bpftool gen skeleton xdp-simple.bpf.o > xdp-simple.skel.h
$ clang -O2 -g -I ./libbpf/src/root/usr/include/ -o xdp-simple xdp-simple.c ./libbpf/src/root/usr/lib64/libbpf.a -lelf -lz
$ sudo ./xdp-simple

Нека проверим дали е свързана с lo и изпратете няколко пакета:

$ ip l show dev lo
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 xdpgeneric qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    prog/xdp id 108

$ for s in `seq 234`; do sudo ping -f -c 100 127.0.0.1 >/dev/null 2>&1; done

Сега нека да разгледаме съдържанието на масива:

$ sudo bpftool map dump name woo
[
    { "key": 0, "value": 0 },
    { "key": 1, "value": 400 },
    { "key": 2, "value": 0 },
    { "key": 3, "value": 0 },
    { "key": 4, "value": 0 },
    { "key": 5, "value": 0 },
    { "key": 6, "value": 0 },
    { "key": 7, "value": 46400 }
]

Почти всички процеси бяха обработени на CPU7. Това не е важно за нас, основното е, че програмата работи и ние разбираме как да имаме достъп до карти от BPF програми - използвайки хелперов bpf_mp_*.

Мистичен индекс

Така че можем да получим достъп до картата от програмата BPF, като използваме обаждания като

val = bpf_map_lookup_elem(&woo, &key);

къде изглежда помощната функция

void *bpf_map_lookup_elem(struct bpf_map *map, const void *key)

но минаваме покрай показалец &woo към неназована структура struct { ... }...

Ако погледнем асемблера на програмата, виждаме, че стойността &woo всъщност не е дефиниран (ред 4):

llvm-objdump -D --section xdp/simple xdp-simple.bpf.o

xdp-simple.bpf.o:       file format elf64-bpf

Disassembly of section xdp/simple:

0000000000000000 <simple>:
       0:       85 00 00 00 08 00 00 00 call 8
       1:       63 0a fc ff 00 00 00 00 *(u32 *)(r10 - 4) = r0
       2:       bf a2 00 00 00 00 00 00 r2 = r10
       3:       07 02 00 00 fc ff ff ff r2 += -4
       4:       18 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 r1 = 0 ll
       6:       85 00 00 00 01 00 00 00 call 1
...

и се съдържа в премествания:

$ llvm-readelf -r xdp-simple.bpf.o | head -4

Relocation section '.relxdp/simple' at offset 0xe18 contains 1 entries:
    Offset             Info             Type               Symbol's Value  Symbol's Name
0000000000000020  0000002700000001 R_BPF_64_64            0000000000000000 woo

Но ако погледнем вече заредената програма, виждаме указател към правилната карта (ред 4):

$ sudo bpftool prog dump x name simple
int simple(void *ctx):
   0: (85) call bpf_get_smp_processor_id#114128
   1: (63) *(u32 *)(r10 -4) = r0
   2: (bf) r2 = r10
   3: (07) r2 += -4
   4: (18) r1 = map[id:64]
...

По този начин можем да заключим, че в момента на стартиране на нашата програма за зареждане, връзката към &woo беше заменен с нещо с библиотека libbpf. Първо ще разгледаме изхода strace:

$ sudo strace -e bpf ./xdp-simple
...
bpf(BPF_MAP_CREATE, {map_type=BPF_MAP_TYPE_ARRAY, key_size=4, value_size=8, max_entries=8, map_name="woo", ...}, 120) = 4
bpf(BPF_PROG_LOAD, {prog_type=BPF_PROG_TYPE_XDP, prog_name="simple", ...}, 120) = 5

Ние виждаме това 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, който създава или отваря съществуващи карти, превръщайки ги във файлови дескриптори. (Тук виждаме BPF_MAP_CREATE в изхода strace.) След това се извиква функцията bpf_object__relocate и тя е тази, която ни интересува, тъй като помним какво сме видели woo в таблицата за преместване. Изследвайки го, в крайна сметка се озоваваме във функцията bpf_program__relocate, който занимава се с преместване на карти:

case RELO_LD64:
    insn[0].src_reg = BPF_PSEUDO_MAP_FD;
    insn[0].imm = obj->maps[relo->map_idx].fd;
    break;

Така че приемаме нашите инструкции

18 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 r1 = 0 ll

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

18 11 00 00 ef eb ad de 00 00 00 00 00 00 00 00 r1 = 0 ll

Ето как информацията за картата се прехвърля към конкретна заредена 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:

static int replace_map_fd_with_map_ptr(struct bpf_verifier_env *env) {
    ...

    f = fdget(insn[0].imm);
    map = __bpf_map_get(f);
    if (insn->src_reg == BPF_PSEUDO_MAP_FD) {
        addr = (unsigned long)map;
    }
    insn[0].imm = (u32)addr;
    insn[1].imm = addr >> 32;

(пълният код може да бъде намерен по ссылке). Така че можем да разширим нашия алгоритъм:

• докато зарежда програмата, верификаторът проверява правилното използване на картата и записва адреса на съответната структура struct bpf_map

Когато изтегляте двоичния файл на ELF, като използвате libbpf Има още много неща, но ще обсъдим това в други статии.

Зареждане на програми и карти без libbpf

Както беше обещано, ето един пример за читателите, които искат да знаят как да създадат и заредят програма, която използва карти, без чужда помощ libbpf. Това може да бъде полезно, когато работите в среда, за която не можете да създавате зависимости, или да запазвате всеки бит, или да пишете програма като ply, който генерира BPF двоичен код в движение.

За да улесним следването на логиката, ще пренапишем нашия пример за тези цели xdp-simple. Пълният и леко разширен код на програмата, обсъждана в този пример, може да бъде намерена тук същност.

Логиката на нашето приложение е следната:

• създайте типова карта BPF_MAP_TYPE_ARRAY използвайки командата BPF_MAP_CREATE,
• създайте програма, която използва тази карта,
• свържете програмата към интерфейса lo,

което се превежда на човешки като

int main(void)
{
    int map_fd, prog_fd;

    map_fd = map_create();
    if (map_fd < 0)
        err(1, "bpf: BPF_MAP_CREATE");

    prog_fd = prog_load(map_fd);
    if (prog_fd < 0)
        err(1, "bpf: BPF_PROG_LOAD");

    xdp_attach(1, prog_fd);
}

Тук map_create създава карта по същия начин, както направихме в първия пример за системното извикване bpf - „ядрото, моля, направете ми нова карта под формата на масив от 8 елемента като __u64 и ми върнете файловия дескриптор":

static int map_create()
{
    union bpf_attr attr;

    memset(&attr, 0, sizeof(attr));
    attr.map_type = BPF_MAP_TYPE_ARRAY,
    attr.key_size = sizeof(__u32),
    attr.value_size = sizeof(__u64),
    attr.max_entries = 8,
    strncpy(attr.map_name, "woo", sizeof(attr.map_name));
    return syscall(__NR_bpf, BPF_MAP_CREATE, &attr, sizeof(attr));
}

Програмата също е лесна за зареждане:

static int prog_load(int map_fd)
{
    union bpf_attr attr;
    struct bpf_insn insns[] = {
        ...
    };

    memset(&attr, 0, sizeof(attr));
    attr.prog_type = BPF_PROG_TYPE_XDP;
    attr.insns     = ptr_to_u64(insns);
    attr.insn_cnt  = sizeof(insns)/sizeof(insns[0]);
    attr.license   = ptr_to_u64("GPL");
    strncpy(attr.prog_name, "woo", sizeof(attr.prog_name));
    return syscall(__NR_bpf, BPF_PROG_LOAD, &attr, sizeof(attr));
}

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

$ llvm-objdump -D --section xdp/simple xdp-simple.bpf.o

0000000000000000 <simple>:
       0:       85 00 00 00 08 00 00 00 call 8
       1:       63 0a fc ff 00 00 00 00 *(u32 *)(r10 - 4) = r0
       2:       bf a2 00 00 00 00 00 00 r2 = r10
       3:       07 02 00 00 fc ff ff ff r2 += -4
       4:       18 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 r1 = 0 ll
       6:       85 00 00 00 01 00 00 00 call 1
       7:       b7 01 00 00 00 00 00 00 r1 = 0
       8:       15 00 04 00 00 00 00 00 if r0 == 0 goto +4 <LBB0_2>
       9:       61 01 00 00 00 00 00 00 r1 = *(u32 *)(r0 + 0)
      10:       07 01 00 00 01 00 00 00 r1 += 1
      11:       63 10 00 00 00 00 00 00 *(u32 *)(r0 + 0) = r1
      12:       b7 01 00 00 02 00 00 00 r1 = 2

0000000000000068 <LBB0_2>:
      13:       bf 10 00 00 00 00 00 00 r0 = r1
      14:       95 00 00 00 00 00 00 00 exit

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

struct bpf_insn insns[] = {
    /* 85 00 00 00 08 00 00 00 call 8 */
    {
        .code = BPF_JMP | BPF_CALL,
        .imm = 8,
    },

    /* 63 0a fc ff 00 00 00 00 *(u32 *)(r10 - 4) = r0 */
    {
        .code = BPF_MEM | BPF_STX,
        .off = -4,
        .src_reg = BPF_REG_0,
        .dst_reg = BPF_REG_10,
    },

    /* bf a2 00 00 00 00 00 00 r2 = r10 */
    {
        .code = BPF_ALU64 | BPF_MOV | BPF_X,
        .src_reg = BPF_REG_10,
        .dst_reg = BPF_REG_2,
    },

    /* 07 02 00 00 fc ff ff ff r2 += -4 */
    {
        .code = BPF_ALU64 | BPF_ADD | BPF_K,
        .dst_reg = BPF_REG_2,
        .imm = -4,
    },

    /* 18 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 r1 = 0 ll */
    {
        .code = BPF_LD | BPF_DW | BPF_IMM,
        .src_reg = BPF_PSEUDO_MAP_FD,
        .dst_reg = BPF_REG_1,
        .imm = map_fd,
    },
    { }, /* placeholder */

    /* 85 00 00 00 01 00 00 00 call 1 */
    {
        .code = BPF_JMP | BPF_CALL,
        .imm = 1,
    },

    /* b7 01 00 00 00 00 00 00 r1 = 0 */
    {
        .code = BPF_ALU64 | BPF_MOV | BPF_K,
        .dst_reg = BPF_REG_1,
        .imm = 0,
    },

    /* 15 00 04 00 00 00 00 00 if r0 == 0 goto +4 <LBB0_2> */
    {
        .code = BPF_JMP | BPF_JEQ | BPF_K,
        .off = 4,
        .src_reg = BPF_REG_0,
        .imm = 0,
    },

    /* 61 01 00 00 00 00 00 00 r1 = *(u32 *)(r0 + 0) */
    {
        .code = BPF_MEM | BPF_LDX,
        .off = 0,
        .src_reg = BPF_REG_0,
        .dst_reg = BPF_REG_1,
    },

    /* 07 01 00 00 01 00 00 00 r1 += 1 */
    {
        .code = BPF_ALU64 | BPF_ADD | BPF_K,
        .dst_reg = BPF_REG_1,
        .imm = 1,
    },

    /* 63 10 00 00 00 00 00 00 *(u32 *)(r0 + 0) = r1 */
    {
        .code = BPF_MEM | BPF_STX,
        .src_reg = BPF_REG_1,
        .dst_reg = BPF_REG_0,
    },

    /* b7 01 00 00 02 00 00 00 r1 = 2 */
    {
        .code = BPF_ALU64 | BPF_MOV | BPF_K,
        .dst_reg = BPF_REG_1,
        .imm = 2,
    },

    /* <LBB0_2>: bf 10 00 00 00 00 00 00 r0 = r1 */
    {
        .code = BPF_ALU64 | BPF_MOV | BPF_X,
        .src_reg = BPF_REG_1,
        .dst_reg = BPF_REG_0,
    },

    /* 95 00 00 00 00 00 00 00 exit */
    {
        .code = BPF_JMP | BPF_EXIT
    },
};

Упражнение за тези, които не са написали това сами - намерете map_fd.

В програмата ни остава още една неразкрита част - xdp_attach. За съжаление, програми като XDP не могат да бъдат свързани чрез системно повикване bpf. Хората, създали BPF и XDP, бяха от онлайн общността на Linux, което означава, че са използвали най-познатия за тях (но не и за нормално хора) интерфейс за взаимодействие с ядрото: netlink гнезда, Вижте също RFC3549. Най-простият начин за изпълнение xdp_attach копира код от libbpf, а именно от файла netlink.c, което направихме, като го съкратихме малко:

Добре дошли в света на netlink гнездата

Отворете тип гнездо за мрежова връзка NETLINK_ROUTE:

int netlink_open(__u32 *nl_pid)
{
    struct sockaddr_nl sa;
    socklen_t addrlen;
    int one = 1, ret;
    int sock;

    memset(&sa, 0, sizeof(sa));
    sa.nl_family = AF_NETLINK;

    sock = socket(AF_NETLINK, SOCK_RAW, NETLINK_ROUTE);
    if (sock < 0)
        err(1, "socket");

    if (setsockopt(sock, SOL_NETLINK, NETLINK_EXT_ACK, &one, sizeof(one)) < 0)
        warnx("netlink error reporting not supported");

    if (bind(sock, (struct sockaddr *)&sa, sizeof(sa)) < 0)
        err(1, "bind");

    addrlen = sizeof(sa);
    if (getsockname(sock, (struct sockaddr *)&sa, &addrlen) < 0)
        err(1, "getsockname");

    *nl_pid = sa.nl_pid;
    return sock;
}

Четем от този сокет:

static int bpf_netlink_recv(int sock, __u32 nl_pid, int seq)
{
    bool multipart = true;
    struct nlmsgerr *errm;
    struct nlmsghdr *nh;
    char buf[4096];
    int len, ret;

    while (multipart) {
        multipart = false;
        len = recv(sock, buf, sizeof(buf), 0);
        if (len < 0)
            err(1, "recv");

        if (len == 0)
            break;

        for (nh = (struct nlmsghdr *)buf; NLMSG_OK(nh, len);
                nh = NLMSG_NEXT(nh, len)) {
            if (nh->nlmsg_pid != nl_pid)
                errx(1, "wrong pid");
            if (nh->nlmsg_seq != seq)
                errx(1, "INVSEQ");
            if (nh->nlmsg_flags & NLM_F_MULTI)
                multipart = true;
            switch (nh->nlmsg_type) {
                case NLMSG_ERROR:
                    errm = (struct nlmsgerr *)NLMSG_DATA(nh);
                    if (!errm->error)
                        continue;
                    ret = errm->error;
                    // libbpf_nla_dump_errormsg(nh); too many code to copy...
                    goto done;
                case NLMSG_DONE:
                    return 0;
                default:
                    break;
            }
        }
    }
    ret = 0;
done:
    return ret;
}

И накрая, ето нашата функция, която отваря сокет и изпраща специално съобщение до него, съдържащо файлов дескриптор:

static int xdp_attach(int ifindex, int prog_fd)
{
    int sock, seq = 0, ret;
    struct nlattr *nla, *nla_xdp;
    struct {
        struct nlmsghdr  nh;
        struct ifinfomsg ifinfo;
        char             attrbuf[64];
    } req;
    __u32 nl_pid = 0;

    sock = netlink_open(&nl_pid);
    if (sock < 0)
        return sock;

    memset(&req, 0, sizeof(req));
    req.nh.nlmsg_len = NLMSG_LENGTH(sizeof(struct ifinfomsg));
    req.nh.nlmsg_flags = NLM_F_REQUEST | NLM_F_ACK;
    req.nh.nlmsg_type = RTM_SETLINK;
    req.nh.nlmsg_pid = 0;
    req.nh.nlmsg_seq = ++seq;
    req.ifinfo.ifi_family = AF_UNSPEC;
    req.ifinfo.ifi_index = ifindex;

    /* started nested attribute for XDP */
    nla = (struct nlattr *)(((char *)&req)
            + NLMSG_ALIGN(req.nh.nlmsg_len));
    nla->nla_type = NLA_F_NESTED | IFLA_XDP;
    nla->nla_len = NLA_HDRLEN;

    /* add XDP fd */
    nla_xdp = (struct nlattr *)((char *)nla + nla->nla_len);
    nla_xdp->nla_type = IFLA_XDP_FD;
    nla_xdp->nla_len = NLA_HDRLEN + sizeof(int);
    memcpy((char *)nla_xdp + NLA_HDRLEN, &prog_fd, sizeof(prog_fd));
    nla->nla_len += nla_xdp->nla_len;

    /* if user passed in any flags, add those too */
    __u32 flags = XDP_FLAGS_SKB_MODE;
    nla_xdp = (struct nlattr *)((char *)nla + nla->nla_len);
    nla_xdp->nla_type = IFLA_XDP_FLAGS;
    nla_xdp->nla_len = NLA_HDRLEN + sizeof(flags);
    memcpy((char *)nla_xdp + NLA_HDRLEN, &flags, sizeof(flags));
    nla->nla_len += nla_xdp->nla_len;

    req.nh.nlmsg_len += NLA_ALIGN(nla->nla_len);

    if (send(sock, &req, req.nh.nlmsg_len, 0) < 0)
        err(1, "send");
    ret = bpf_netlink_recv(sock, nl_pid, seq);

cleanup:
    close(sock);
    return ret;
}

И така, всичко е готово за тестване:

$ cc nolibbpf.c -o nolibbpf
$ sudo strace -e bpf ./nolibbpf
bpf(BPF_MAP_CREATE, {map_type=BPF_MAP_TYPE_ARRAY, map_name="woo", ...}, 72) = 3
bpf(BPF_PROG_LOAD, {prog_type=BPF_PROG_TYPE_XDP, insn_cnt=15, prog_name="woo", ...}, 72) = 4
+++ exited with 0 +++

Да видим дали нашата програма се е свързала с lo:

$ ip l show dev lo
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 xdpgeneric qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    prog/xdp id 160

Нека изпратим ping и погледнем картата:

$ for s in `seq 234`; do sudo ping -f -c 100 127.0.0.1 >/dev/null 2>&1; done
$ sudo bpftool m dump name woo
key: 00 00 00 00  value: 90 01 00 00 00 00 00 00
key: 01 00 00 00  value: 00 00 00 00 00 00 00 00
key: 02 00 00 00  value: 00 00 00 00 00 00 00 00
key: 03 00 00 00  value: 00 00 00 00 00 00 00 00
key: 04 00 00 00  value: 00 00 00 00 00 00 00 00
key: 05 00 00 00  value: 00 00 00 00 00 00 00 00
key: 06 00 00 00  value: 40 b5 00 00 00 00 00 00
key: 07 00 00 00  value: 00 00 00 00 00 00 00 00
Found 8 elements

Ура, всичко работи. Обърнете внимание, между другото, че нашата карта отново се показва под формата на байтове. Това се дължи на факта, че за разлика от libbpf не заредихме информация за типа (BTF). Но ще говорим повече за това следващия път.

Инструменти за разработка

В този раздел ще разгледаме минималния набор от инструменти за разработчици на BPF.

Най-общо казано, не се нуждаете от нищо специално, за да разработите BPF програми - BPF работи на всяко прилично дистрибутивно ядро ​​и програмите се изграждат с clang, които могат да бъдат доставени от опаковката. Въпреки това, поради факта, че BPF е в процес на разработка, ядрото и инструментите непрекъснато се променят, ако не искате да пишете BPF програми, използвайки старомодни методи от 2019 г., тогава ще трябва да компилирате

• llvm/clang
• pahole
• нейното ядро
• bpftool

(За справка, този раздел и всички примери в статията бяха изпълнени на Debian 10.)

llvm/звън

BPF е приятелски настроен към LLVM и въпреки че напоследък програмите за BPF могат да бъдат компилирани с помощта на gcc, цялата текуща разработка се извършва за LLVM. Затова, на първо място, ще изградим текущата версия clang от git:

$ sudo apt install ninja-build
$ git clone --depth 1 https://github.com/llvm/llvm-project.git
$ mkdir -p llvm-project/llvm/build/install
$ cd llvm-project/llvm/build
$ cmake .. -G "Ninja" -DLLVM_TARGETS_TO_BUILD="BPF;X86" 
                      -DLLVM_ENABLE_PROJECTS="clang" 
                      -DBUILD_SHARED_LIBS=OFF 
                      -DCMAKE_BUILD_TYPE=Release 
                      -DLLVM_BUILD_RUNTIME=OFF
$ time ninja
... много времени спустя
$

Сега можем да проверим дали всичко е събрано правилно:

$ ./bin/llc --version
LLVM (http://llvm.org/):
  LLVM version 11.0.0git
  Optimized build.
  Default target: x86_64-unknown-linux-gnu
  Host CPU: znver1

  Registered Targets:
    bpf    - BPF (host endian)
    bpfeb  - BPF (big endian)
    bpfel  - BPF (little endian)
    x86    - 32-bit X86: Pentium-Pro and above
    x86-64 - 64-bit X86: EM64T and AMD64

(Инструкции за сглобяване clang взето от мен от bpf_devel_QA.)

Няма да инсталираме програмите, които току-що създадохме, а вместо това просто ще ги добавим PATH, например:

export PATH="`pwd`/bin:$PATH"

(Това може да се добави към .bashrc или в отделен файл. Лично аз добавям такива неща към ~/bin/activate-llvm.sh и когато трябва го правя . activate-llvm.sh.)

Пахоле и БТФ

Полезност pahole използвани при изграждане на ядрото за създаване на информация за отстраняване на грешки във формат BTF. В тази статия няма да навлизаме в подробности относно BTF технологията, освен факта, че е удобна и искаме да я използваме. Така че, ако възнамерявате да изградите вашето ядро, изградете първо pahole (без pahole няма да можете да изградите ядрото с опцията CONFIG_DEBUG_INFO_BTF:

$ git clone https://git.kernel.org/pub/scm/devel/pahole/pahole.git
$ cd pahole/
$ sudo apt install cmake
$ mkdir build
$ cd build/
$ cmake -D__LIB=lib ..
$ make
$ sudo make install
$ which pahole
/usr/local/bin/pahole

Ядра за експериментиране с BPF

Когато проучвам възможностите на BPF, искам да сглобя собствено ядро. Това, най-общо казано, не е необходимо, тъй като ще можете да компилирате и зареждате BPF програми в ядрото на дистрибуцията, но наличието на собствено ядро ​​ви позволява да използвате най-новите функции на BPF, които ще се появят във вашата дистрибуция в най-добрия случай след месеци , или, както в случая с някои инструменти за отстраняване на грешки, изобщо няма да бъдат пакетирани в обозримо бъдеще. Също така, собственото му ядро ​​кара да се чувства важно да се експериментира с кода.

За да изградите ядро, ви трябва, първо, самото ядро ​​и второ, конфигурационен файл на ядрото. За да експериментираме с BPF, можем да използваме обичайния ванилия ядро или едно от ядрата за разработка. Исторически погледнато, разработката на BPF се извършва в рамките на мрежовата общност на Linux и следователно всички промени рано или късно преминават през Дейвид Милър, поддържащия мрежата на Linux. В зависимост от тяхното естество - редакции или нови функции - мрежовите промени попадат в едно от двете ядра - net или net-next. Промените за BPF се разпределят по същия начин между bpf и bpf-next, които след това се обединяват съответно в net и net-next. За повече подробности вж bpf_devel_QA и netdev-ЧЗВ. Така че изберете ядро ​​въз основа на вашия вкус и нуждите от стабилност на системата, върху която тествате (*-next ядрата са най-нестабилните от изброените).

Извън обхвата на тази статия е да говорим за това как да управлявате конфигурационните файлове на ядрото - предполага се, че или вече знаете как да направите това, или готов да учи сам по себе си. Въпреки това, следващите инструкции трябва да са повече или по-малко достатъчни, за да ви осигурят работеща система с активиран BPF.

Изтеглете едно от горните ядра:

$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git
$ cd bpf-next

Създайте минимална работеща конфигурация на ядрото:

$ cp /boot/config-`uname -r` .config
$ make localmodconfig

Активирайте BPF опциите във файла .config по ваш избор (най-вероятно CONFIG_BPF вече ще бъде активиран, тъй като systemd го използва). Ето списък с опции от ядрото, използвани за тази статия:

CONFIG_CGROUP_BPF=y
CONFIG_BPF=y
CONFIG_BPF_LSM=y
CONFIG_BPF_SYSCALL=y
CONFIG_ARCH_WANT_DEFAULT_BPF_JIT=y
CONFIG_BPF_JIT_ALWAYS_ON=y
CONFIG_BPF_JIT_DEFAULT_ON=y
CONFIG_IPV6_SEG6_BPF=y
# CONFIG_NETFILTER_XT_MATCH_BPF is not set
# CONFIG_BPFILTER is not set
CONFIG_NET_CLS_BPF=y
CONFIG_NET_ACT_BPF=y
CONFIG_BPF_JIT=y
CONFIG_BPF_STREAM_PARSER=y
CONFIG_LWTUNNEL_BPF=y
CONFIG_HAVE_EBPF_JIT=y
CONFIG_BPF_EVENTS=y
CONFIG_BPF_KPROBE_OVERRIDE=y
CONFIG_DEBUG_INFO_BTF=y

След това можем лесно да сглобим и инсталираме модулите и ядрото (между другото, можете да сглобите ядрото, като използвате новосглобения clangдобавяйки CC=clang):

$ make -s -j $(getconf _NPROCESSORS_ONLN)
$ sudo make modules_install
$ sudo make install

и рестартирайте с новото ядро ​​(използвам за това kexec от пакет kexec-tools):

v=5.8.0-rc6+ # если вы пересобираете текущее ядро, то можно делать v=`uname -r`
sudo kexec -l -t bzImage /boot/vmlinuz-$v --initrd=/boot/initrd.img-$v --reuse-cmdline &&
sudo kexec -e

bpftool

Най-често използваната помощна програма в статията ще бъде помощната програма bpftool, доставен като част от ядрото на Linux. Той е написан и поддържан от BPF разработчици за BPF разработчици и може да се използва за управление на всички видове BPF обекти - зареждане на програми, създаване и редактиране на карти, изследване на живота на BPF екосистемата и т.н. Може да се намери документация под формата на изходни кодове за страници с ръководство в сърцевината или вече компилиран, мрежа.

Към момента на писане на тази статия bpftool идва готов само за RHEL, Fedora и Ubuntu (вижте например тази тема, който разказва недовършената история на опаковката bpftool в Дебиан). Но ако вече сте изградили вашето ядро, тогава изградете bpftool лесно като пай:

$ cd ${linux}/tools/bpf/bpftool
# ... пропишите пути к последнему clang, как рассказано выше
$ make -s

Auto-detecting system features:
...                        libbfd: [ on  ]
...        disassembler-four-args: [ on  ]
...                          zlib: [ on  ]
...                        libcap: [ on  ]
...               clang-bpf-co-re: [ on  ]

Auto-detecting system features:
...                        libelf: [ on  ]
...                          zlib: [ on  ]
...                           bpf: [ on  ]

$

(тук ${linux} - това е вашата директория на ядрото.) След изпълнение на тези команди bpftool ще бъдат събрани в директория ${linux}/tools/bpf/bpftool и може да се добави към пътя (преди всичко към потребителя root) или просто копирайте в /usr/local/sbin.

събирам bpftool най-добре е да използвате последното clang, сглобен по описания по-горе начин и проверете дали е сглобен правилно - като използвате например командата

$ sudo bpftool feature probe kernel
Scanning system configuration...
bpf() syscall for unprivileged users is enabled
JIT compiler is enabled
JIT compiler hardening is disabled
JIT compiler kallsyms exports are enabled for root
...

което ще покаже кои функции на BPF са активирани във вашето ядро.

Между другото, предишната команда може да се изпълни като

# bpftool f p k

Това се прави по аналогия с помощните програми от пакета iproute2, където можем например да кажем ip a s eth0 вместо ip addr show dev eth0.

Заключение

BPF ви позволява да обуете бълха, за да измерите ефективно и да промените в движение функционалността на ядрото. Системата се оказа много успешна, в най-добрите традиции на UNIX: прост механизъм, който ви позволява да (пре)програмирате ядрото, позволи на огромен брой хора и организации да експериментират. И въпреки че експериментите, както и разработването на самата BPF инфраструктура, далеч не са завършени, системата вече има стабилен ABI, който ви позволява да изградите надеждна и най-важното ефективна бизнес логика.

Бих искал да отбележа, че според мен технологията стана толкова популярна, защото от една страна може играя (архитектурата на една машина може да се разбере горе-долу за една вечер), а от друга страна, за решаване на проблеми, които не могат да бъдат решени (красиво) преди нейната поява. Тези два компонента заедно карат хората да експериментират и мечтаят, което води до появата на все по-иновативни решения.

Тази статия, макар и не особено кратка, е само въведение в света на BPF и не описва „разширени“ функции и важни части от архитектурата. Планът занапред е нещо подобно: следващата статия ще бъде преглед на типовете BPF програми (има 5.8 типа програми, поддържани в ядрото 30), след което най-накрая ще разгледаме как да пишем истински BPF приложения, използвайки програми за проследяване на ядрото като пример, тогава е време за по-задълбочен курс по BPF архитектура, последван от примери за BPF мрежи и приложения за сигурност.

Предишни статии от тази серия

1. BPF за най-малките, част нула: класически BPF

Връзки

1. Справочно ръководство за BPF и XDP — документация за BPF от cilium, или по-точно от Daniel Borkman, един от създателите и поддържащите BPF. Това е едно от първите сериозни описания, което се отличава от останалите с това, че Даниел знае точно какво пише и там няма грешки. По-специално, този документ описва как да работите с BPF програми от типа XDP и TC с помощта на добре познатата помощна програма ip от пакет iproute2.

2. Documentation/networking/filter.txt — оригинален файл с документация за класически и след това разширен BPF. Добро четиво, ако искате да се задълбочите в асемблерния език и техническите архитектурни детайли.

3. Блог за BPF от facebook. Актуализира се рядко, но уместно, както пишат там Алексей Старовойтов (автор на eBPF) и Андрий Накрийко - (поддържащ) libbpf).

4. Тайните на bpftool. Забавна нишка в Twitter от Quentin Monnet с примери и тайни за използване на bpftool.

5. Потопете се в BPF: списък с материали за четене. Огромен (и все още поддържан) списък с връзки към документация на BPF от Куентин Моне.

Източник: www.habr.com