BPF за најмалите, прв дел: продолжен BPF

На почетокот имаше технологија и се викаше BPF. Ја погледнавме претходниот, старозаветна статија од оваа серија. Во 2013 година, преку напорите на Алексеј Старовоитов и Даниел Боркман, беше развиена подобрена верзија на истата, оптимизирана за модерни 64-битни машини, која беше вклучена во кернелот на Линукс. Оваа нова технологија накратко беше наречена 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 машините и го реши проблемот со ефикасно филтрирање на пакети. Архитектурата се покажа како толку успешна што, родена во деведесеттите во Беркли 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 наречена проверувач (на англиски оваа фаза се нарекува проверувач и јас ќе продолжам да го користам англискиот збор):

Проверувачот е статичен анализатор кој осигурува дека програмата не го нарушува нормалното функционирање на кернелот. Ова, патем, не значи дека програмата не може да се меша во работата на системот - програмите BPF, во зависност од видот, можат да читаат и препишуваат делови од меморијата на јадрото, да враќаат вредности на функции, да скратуваат, додаваат, препишуваат па дури и препраќање мрежни пакети. Верификаторот гарантира дека извршувањето на програмата BPF нема да го сруши кернелот и дека програмата што, според правилата, има пристап за запишување, на пример, податоците на пакетот што оди, нема да може да ја презапише меморијата на кернелот надвор од пакетот. Ќе го разгледаме верификаторот малку подетално во соодветниот дел, откако ќе се запознаеме со сите други компоненти на BPF.

Значи, што научивме досега? Корисникот пишува програма во C, ја вчитува во кернелот користејќи системски повик bpf(2), каде што се проверува од проверувач и се преведува на мајчин бајтекод. Потоа истиот или друг корисник ја поврзува програмата со изворот на настанот и таа започнува да се извршува. Одвојувањето на багажникот и поврзувањето е неопходно од неколку причини. Прво, водење на проверувач е релативно скапо и со преземање на истата програма неколку пати губиме време на компјутерот. Второ, точно како е поврзана програмата зависи од нејзиниот тип, а еден „универзален“ интерфејс развиен пред една година можеби не е погоден за нови типови на програми. (Иако сега кога архитектурата станува позрела, постои идеја да се обедини овој интерфејс на ниво libbpf.)

Внимателниот читател може да забележи дека сè уште не сме завршиле со сликите. Навистина, сето горенаведено не објаснува зошто BPF фундаментално ја менува сликата во споредба со класичниот BPF. Две иновации кои значително го прошируваат опсегот на применливост се можноста за користење на споделена меморија и помошни функции на кернелот. Во BPF, споделената меморија се имплементира со користење на таканаречените мапи - споделени структури на податоци со специфичен API. Веројатно го добиле ова име затоа што првиот тип на мапа што се појавил е хеш-табела. Потоа се појавија низи, локални (по процесорски) хаш табели и локални низи, стебла за пребарување, мапи кои содржат покажувачи кон програмите BPF и многу повеќе. Она што ни е интересно сега е дека BPF програмите сега имаат можност да ја опстојуваат состојбата помеѓу повиците и да ја споделуваат со други програми и со корисничкиот простор.

До мапи се пристапува од кориснички процеси користејќи системски повик bpf(2), и од програмите BPF кои работат во јадрото користејќи помошни функции. Покрај тоа, помошниците постојат не само за работа со мапи, туку и за пристап до други способности на кернелот. На пример, BPF програмите можат да користат помошни функции за препраќање пакети до други интерфејси, генерирање на настани на perf, пристап до структурите на јадрото итн.

Накратко, 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, сет на инструкции, Документација/вмрежување/филтер.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, соодветно. 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 Класа 9 операција е 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 - програми и мапи - се креираат од корисничкиот простор користејќи команди BPF_PROG_LOAD и BPF_MAP_CREATE системски повик bpf(2), ќе зборуваме за тоа како точно се случува ова во следниот дел. Ова создава структури на податоци на јадрото и за секоја од нив refcount (бројот на референци) е поставен на еден, а дескрипторот на датотеката што покажува на објектот се враќа на корисникот. Откако ќе се затвори рачката refcount објектот се намалува за еден, а кога ќе достигне нула, предметот се уништува.

Ако програмата користи мапи, тогаш refcount овие карти се зголемуваат за еден по вчитувањето на програмата, т.е. нивните дескриптори на датотеки може да се затворат од корисничкиот процес и уште refcount нема да стане нула:

По успешното вчитување на програмата, обично ја прикачуваме на некој вид генератор на настани. На пример, можеме да го ставиме на мрежен интерфејс за да ги обработиме дојдовните пакети или да го поврземе со некои tracepoint во јадрото. Во овој момент, референтниот бројач исто така ќе се зголеми за еден и ќе можеме да го затвориме дескрипторот на датотеката во програмата за вчитување.

Што ќе се случи ако сега го исклучиме подигнувачот? Тоа зависи од типот на генератор на настани (кука). Сите мрежни куки ќе постојат откако ќе заврши натоварувачот, тоа се таканаречените глобални куки. И, на пример, програмите за трага ќе бидат објавени откако ќе заврши процесот што ги создал (и затоа се нарекуваат локални, од „локално во процес“). Технички, локалните куки секогаш имаат соодветен дескриптор на датотека во корисничкиот простор и затоа се затвораат кога процесот е затворен, но глобалните куки немаат. На следната слика, користејќи црвени крстови, се обидувам да покажам како прекинувањето на програмата за вчитување влијае на животниот век на објектите во случај на локални и глобални куки.

Зошто постои разлика помеѓу локални и глобални куки? Извршувањето на некои видови мрежни програми има смисла без кориснички простор, на пример, замислете заштита од DDoS - подигнувачот ги пишува правилата и ја поврзува програмата BPF со мрежниот интерфејс, по што подигнувачот може да оди и да се убие. Од друга страна, замислете програма за трага за дебагирање што сте ја напишале на колена за десет минути - кога ќе заврши, би сакале да нема ѓубре во системот, а локалните куки ќе го осигураат тоа.

Од друга страна, замислете дека сакате да се поврзете со трага точка во кернелот и да собирате статистика во текот на многу години. Во овој случај, би сакале да го комплетирате корисничкиот дел и одвреме-навреме да се враќате на статистиката. Датотечниот систем 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) (некои ирелевантни линии се отстранети од излезот на траса):

$ 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

BPF програми

Сите BPF објекти се креирани и управувани од корисничкиот простор со помош на системски повик bpf, со следниов прототип:

#include <linux/bpf.h>

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

Еве го тимот cmd е една од вредностите на типот 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 чијшто глобален ID е 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 или покажувачи на мрежните интерфејси, мапи за работа со настани на перф итн. За нив нема да зборуваме овде, за да не го збуниме читателот. Освен ова, ги игнорираме проблемите за синхронизација, бидејќи тоа не е важно за нашите примери. Комплетна листа на достапни типови мапи може да се најде во <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 е глобалниот проект на нашиот објект. Секоја програма на системот може да го користи овој ID за да отвори постоечка мапа користејќи ја командата 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

Прво ја отворивме мапата со нејзиниот глобален ID користејќи ја командата 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: отворете постоечка карта според нејзиниот глобален 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 - сега не треба да го инсталираме пакетот кернел-заглавија за да дознаеме како изгледаат структурите на јадрото. Следната датотека со заглавие доаѓа кај нас од библиотеката libbpf. Сега ни треба само за да го дефинираме макрото SEC, кој го испраќа знакот до соодветниот дел од датотеката со објект ELF. Нашата програма е содржана во делот xdp/simple, каде што пред коса црта го дефинираме типот на програмата BPF - ова е конвенцијата што се користи во libbpf, врз основа на името на делот ќе го замени точниот тип при стартување bpf(2). Самата програма BPF е 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. Ајде да ја најдеме нејзината лична карта:

# 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, што одредува од ID на функцијата помошник дали 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 беа од онлајн заедницата Линукс, што значи дека ја користеа онаа што им е најпозната (но не и нормално луѓе) интерфејс за интеракција со кернелот: netlink приклучоци, исто така види RFC3549. Наједноставниот начин за имплементација xdp_attach го копира кодот од libbpf, имено, од датотеката netlink.c, што и го направивме, скратувајќи го малку:

Добредојдовте во светот на нетлинк приклучоците

Отворете тип на мрежен приклучок 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

Ајде да испратиме пинг и да ја погледнеме мапата:

$ 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/clang

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 се одвива во рамките на мрежна заедница на Линукс и затоа сите промени порано или подоцна одат преку Дејвид Милер, одржувачот на мрежи на Линукс. Во зависност од нивната природа - уредувања или нови функции - мрежните промени спаѓаат во едно од двете јадра - 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, доставен како дел од кернелот Линукс. Напишан е и одржуван од BPF програмери за BPF програмери и може да се користи за управување со сите видови BPF објекти - вчитување програми, креирање и уредување мапи, истражување на животот на екосистемот BPF итн. Може да се најде документација во форма на изворни кодови за man-страници во јадрото или, веќе составено, на мрежата.

Во времето на ова пишување 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 од цилиум, поточно од Даниел Боркман, еден од креаторите и одржувачите на BPF. Ова е еден од првите сериозни описи, кој се разликува од другите по тоа што Даниел точно знае за што пишува и таму нема никакви грешки. Конкретно, овој документ опишува како да се работи со програмите BPF од типовите XDP и TC користејќи ја добро познатата алатка ip од пакувањето iproute2.

2. Документација/вмрежување/филтер.txt — оригинална датотека со документација за класичен, а потоа продолжен BPF. Добро читање ако сакате да истражувате во асемблерскиот јазик и техничките архитектонски детали.

3. Блог за BPF од Фејсбук. Се ажурира ретко, но соодветно, како што пишуваат таму Алексеј Старовоитов (автор на eBPF) и Андриј Накриико - (одржувач). libbpf).

4. Тајните на bpftool. Забавна нишка на Твитер од Квентин Моне со примери и тајни за користење bpftool.

5. Нурнете во BPF: список на материјал за читање. Огромна (и сè уште одржувана) листа на линкови до документацијата на BPF од Квентин Моне.

Извор: www.habr.com