BPF kõige väiksematele, esimene osa: laiendatud BPF

Alguses oli tehnoloogia, mida nimetati BPF-iks. Me vaatasime selle peale kontrolli. Sel ajal on C++ analüsaatorisse lisatud kokku 66 üldotstarbelist diagnoosi., vana testamendi artiklis sellest tsüklist. 2013. aastal Alexei Starovoitovi ja Daniel Borkmani pingutuste abil töötati välja ja lisati Linuxi kernelisse selle täiustatud versioon, mis oli optimeeritud kaasaegsetele 64-bitistele masinatele. See uus tehnoloogia kandis lühikest aega nime Internal BPF, seejärel muudeti see Extended BPF-iks ja nüüd, pärast mitmeid aastaid, nimetavad kõik seda lihtsalt BPF-iks.

Üldiselt võimaldab BPF käivitada kasutaja poolt antud arbitraarset koodi Linuxi kernelis ja uus arhitektuur osutus nii edukaks, et meil on vaja veel umbes tosina artikli jagu, et kirjeldada kõiki selle rakendusi. (Ainus, millega arendajad hakkama ei saanud, nagu näete alloleval plakatil, on korraliku logo loomine.)

Selles artiklis kirjeldatakse BPF-i virtuaalse masina struktuuri, kerneliga töötamise liideseid, arendustööriistu ning ka lühikest, väga lühikest ülevaadet olemasolevatest võimalustest, st kõike seda, mida vajame edasise sügava uurimise jaoks BPF-i praktiliste rakenduste osas.

Artikli kokkuvõte

Tutvustus BPF-i arhitektuuriga. Alguses vaatame BPF-i arhitektuuri linnulennult ja määratleme peamised koostisosad.

BPF-i virtuaalse masina registrid ja käsusüsteem. Olles juba omandanud arusaama arhitektuurist, kirjeldame BPF-i virtuaalse masina ehitust.

BPF-i objektide elutsükkel, faili süsteem bpffs. Selles osas vaatame lähemalt BPF-i objektide — programmide ja kaartide — elutsüklit.

Objektide haldamine süsteemi kõne bpf abil. Olles saanud juba teatud arusaama süsteemist, vaatame lõpuks, kuidas luua ja hallata objekte kasutajaruumi kaudu erilise süsteemi kõne abil — bpf(2).

Kirjutame BPF-i programme libbpf-kasutades. Programmi kirjutamine süsteemi kõne abil on muidugi võimalik. Kuid keeruline. Rohkem realistliku stsenaariumi jaoks on tuumaprogrammeerijad töötanud välja raamatukogu libbpf. Loome kõige lihtsama BPF-i rakenduse karkassi, mida kasutame edaspidi näidetes.

Kernel Helpers. Siin saame teada, kuidas BPF programmid saavad pöörduda tuumasüsteemide abifunktsioonide poole – tööriista, mis koos kaartidega oluliselt laiendab uue BPF võimalusi võrreldes klassikalisega.

Juurdepääs kaartidele BPF programmide kaudu. Selleks ajaks teame piisavalt, et mõista, kuidas luua programme, mis kasutavad kaarte. Ja isegi piilume suure ja võimsa verifitseerija sisse.

Arendustöötlusvahendid. Tehnilised juhised selle kohta, kuidas koguda vajalikud utiliidid ja tuum eksperimenteerimiseks.

Järeldus. Artikli lõpus leiavad need, kes siiani jõudsid, julgustavaid sõnu ja lühikese ülevaate sellest, millest järgmistes artiklites juttu tuleb. Samuti loetleme mitmeid lingid iseseisvaks uurimiseks neile, kellel ei ole soovi või võimalust oodata järgmist osa.

BPF arhitektuuri sissejuhatus

Enne kui hakkame vaatama BPF arhitektuuri, viitame viimast korda (kas tõesti?) klassikalisele BPF, mis töötati välja vastusena RISC masinate tekkele ja lahendas pakettide tõhususe filtreerimise probleemi. Arhitektuur osutus nii õnnestunuks, et sündis 90ndate alguses Berkeley UNIX-is, see portiti enamikule olemasolevatest operatsioonisüsteemidest ja on ellu jäänud kahekümnendate hullustes, leidnud uusi rakendusi.

Uus BPF töötati välja vastusena 64-bitiste masinate, pilveteenuste ja hüppeliselt suurenenud nõudmistele SDN (Starkvara-dmäära nvõrgustik). Uute BPF loomine tuumainženere on täiustatud asendus klassikalisele BPF-le, ja juba poole aasta pärast leidis uus BPF rakendusi keerulises Linuxi süsteemide jälgimise praktikas, ja nüüd, kuus aastat pärast selle ilmumist, vajame me järgmiseks artikliks ainult selleks, et loetleda erinevad programmide tüübid.

VeSõLeVd PiltId

BPF on virtuaalmasin, mis võimaldab käivitada "tavalist" koodi kerneli ruumis ilma turvalisust ohustamata. BPF-i programmid luuakse kasutaja ruumis, laaditakse kerneli sisse ja ühendatakse mingisuguse sündmuse allikaga. Sündmuseks võib olla näiteks paketi edastamine võrguliidesesse, kerneli funktsiooni käivitamine jne. Paketi puhul on BPF-programmile saadaval paketi andmed ja metaandmed (lugemiseks ning võib-olla ka kirjutamiseks, sõltuvalt programmi tüübist), kerneli funktsiooni käivitamisel — funktsiooni argumendid, sealhulgas mälupunktid kerneli mälus jne.

Vaatame seda protsessi lähemalt. Esiteks räägime esimesest erinevusest klassikalisest BPF-ist, mille programmid olid kirjutatud assembleris. Uues versioonis muudeti arhitektuuri nii, et programme saab kirjutada kõrgetasemelistel keeltele, eelkõige C-le. Selle jaoks loodi llvm-i backend, mis võimaldab genereerida BPF-i arhitektuurile sobivat baitkoodi.

BPF-i arhitektuuri arendati peamiselt selleks, et see saaks tõhusalt töötada tänapäevastes seadmetes. Selleks, et see praktikas töötaks, tõlgitakse BPF-i baitkood pärast kerneli laadimist masinkoodiks komponente nimega JIT compiler abil (Just In Time). Lisaks, kui te mäletate, laaditi klassikalises BPF-is programm kerneli ja ühendati sündmuse allikaga atomaarsetena — ühe süsteemikõne kontekstis. Uues arhitektuuris toimub see kahel etapil — alguses laaditakse kood kerneli süsteemikõne abil bpf(2), seejärel, hiljem, erinevate mehhanismide abil, sõltuvalt programmi tüübist, programmil on võimalus (attaches) sündmuse allikaga ühenduda.

Siin võib lugejal tekkida küsimus: kas tõesti oli see võimalik? Kuidas tagatakse sellise koodi käitamise turvalisus? Turvalisus tagatakse BPF-programmide laadimise etappimisega, mida nimetatakse valideerijaks (inglise keeles nimetus on verifier ja ma kasutan edaspidi ingliskeelset sõna):

Verifier on staatiline analüüsija, mis tagab, et programm ei sega tuuma normaalset toimimist. See aga ei tähenda, et programm ei saaks süsteemi sekkuda — BPF programmid, sõltuvalt tüübist, saavad lugeda ja kirjutada tuuma mälu osi, muuta funktsioonide tagastatavaid väärtusi, kärpida, täiendada, kirjutada ja isegi ümber suunata võrgu pakette. Verifier tagab, et BPF programmi käivitamine ei põhjusta tuuma kokku kukkumist ja et programm, mis võib reeglitesse tuginedes kirjutada andmeid, näiteks väljamineva paketi, ei suuda kirjutada tuuma mälu väljaspool paketti. Natuke põhjalikumalt vaatame verifierit vastavas osas, pärast seda, kui tutvume kõigi teiste BPF komponentidega.

Nii et, mida me siiani õppisime? Kasutaja kirjutab programmi C keeles, laadib selle tuuma süsteemikõne abil, bpf(2), kus see läbib verifi katse ja tõlgitakse masinkoodiks. Seejärel ühendab sama või teine kasutaja programmi sündmuste allikaga ja see hakkab töötama. Laadimise ja ühendamise eristamine on vajalik mitmel põhjusel. Esiteks, verifi käivitamine on suhteliselt kallis ja laadides sama programmi mitu korda, raiskame me arvuti aega asjata. Teiseks, kuidas programm täpselt ühendatakse, sõltub selle tüübist ja üks "üldine" liides, mis loodi aasta tagasi, ei pruugi sobida uute programmide tüüpide jaoks. (Kuigi nüüd, kui arhitektuur muutub küpsemaks, on idee see liides ühtlustada tasemel) libbpf.)

Hooliv lugeja võib märkida, et me pole veel piltide osas lõpetanud. Tõepoolest, eespool öeldu ei selgita, kuidas BPF põhimõtteliselt muudab pilti võrreldes klassikalise BPF-iga. Kaks uuendust, mis oluliselt laiendavad rakendamisvõimalusi, on jagatud mälu kasutamise võimalus ja tuuma abifunktsioonid (kernel helpers). BPF-is on jagatud mälu rakendatud nii-öelda maps'i abil - jagatud andmestruktuurid kindla API-ga. Sellise nime nad said tõenäoliselt seetõttu, et esimene ilmunud maps'i tüüp oli räsitabel. Edasi on tulnud massiivid, lokaalsed (per-CPU) räsitabelid ja lokaalsed massiivid, otsingupuud, maps'id, mis sisaldavad viiteid BPF-programmidele, ja palju muud. Meid huvitab praegu fakt, et BPF-programmid said võimaluse salvestada seisundi kutsungite vahel ja jagada seda teiste programmide ning kasutajaruumi vahel.

Maps'esse pääseb kasutajaprotsessidest süsteemi kõne abil bpf(2), ning BPF-programmid, mis töötavad tuumas, pääsevad sellele ligi abifunktsioonide kaudu. Veelgi enam, abifunktsioonid ei eksisteeri mitte ainult maps'iga töötamiseks, vaid ka muude tuuma võimaluste kasutamiseks. Näiteks saavad BPF-programmid kasutada abifunktsioone pakettide ümbersuunamiseks teistele liidesele, perf-alamsüsteemi sündmuste genereerimiseks, tuuma struktuuridele ja nii edasi pääsemiseks.

Kokkuvõttes annab BPF võimaluse laadida tuuma ruumi suvalist, st verifikaatoril läbi käinud kasutaja koodi. See kood võib salvestada seisundi kutsungite vahel ja vahetada andmeid kasutajaruumi ning tal on juurdepääs selle tüübi programmidele lubatud tuuma alamsüsteemidele.

See on juba sarnane võimalustele, mida pakuvad tuumamoodulid, mille suhtes BPF-l on mõned eelised (loomulikult saab sarnaseid rakendusi võrrelda ainult sarnastega, näiteks süsteemi jälgimisega — BPF-le ei saa kirjutada suvalist draiverit). Võib märkida madalamat sisenemisläve (osad BPF-i kasutavad utiliitide ei eelda, et kasutajal oleks tuumaprogrammeerimise oskused, ega ka üldse programmeerimisoskused), käitamisohutust (tõstke käsi kommentaarides need, kellel pole olnud süsteemi riket mooduleid kirjutades või testides), aatomilisust — moodulite laadimise ajal on seisaku aeg, kuid BPF-i alamsüsteem tagab, et mitte ükski sündmus ei jää tähelepanuta (aususe nimel, see ei kehti mitte kõikide BPF-i programmiliikide kohta).

Need võimalused muudavad BPF-i universaalseks tööriistaks tuuma laiendamiseks, mida tõendab praktika: järjest rohkem ja rohkem uut tüüpi programme lisandub BPF-ile, üha rohkem suurettevõtteid kasutab BPF-i tootmisserverites 24×7, üha rohkem idufirmasid ehitab oma äri lahendustele, mille aluseks on BPF. BPF-i kasutatakse kõikjal: DDoS-rünnakute kaitseks, SDN-i loomisel (näiteks Kubernetesest võrkude rakendamine), peamise süsteemi jälgimise tööriistana ja statistika kogumisena, sissetungi tuvastamise süsteemides ja liivakasti süsteemides jms.

Lõpetame selle ülevaateosa artiklist ja vaatame virtuaalmasinat ning BPF-i ökosüsteemi põhjalikumalt.

Nüanss: utiliidid

Et saaksite järgmistes osades näidatud näiteid käivitada, võib teil olla vaja teatud arvu utiliite, vähemalt llvm/clang BPF-i toe ja bpftool. Osas Arendustooted jaotatud juhised nende utiliitide ning oma tuuma koostamiseks. See osa on paigutatud alla, et mitte segada meie arutelu selgust.

BPF virtuaalmasina registrid ja käskude süsteem

BPF arhitektuur ja käskude süsteem on loodud silmas pidades, et programmid kirjutatakse C keeles ja tõlgitakse pärast laadimist tuumasse natiivkoodi. Seetõttu valiti registrite ja käskude arv, arvestades tänapäevaste masinate võimaluste ristumisi matemaatilises mõttes. Lisaks kehtestati programmidele mitmesuguseid piiranguid; näiteks ei olnud kuni hiljuti võimalik kirjutada silmuseid ja alamprogramme, ning käskude arv oli piiratud 4096-ga (praegu saavad privileeritud programmid laadida kuni miljon käsku).

BPF-s on kasutajale ligipääsetavad üheksa 64-bitist registreid r0—r10 ja käskude loendur (program counter). Register r10 hoiab raami näidikut (frame pointer) ja on ainult lugemiseks saadaval. Programmidele on täitmise ajal ligipääsetav 512-bytesit tagasihoidlik salvestus ja piiramatu jagatud mälu kaardina (maps).

BPF programmidele on lubatud käivitada kindel funktsioonide kogum sõltuvalt programmi tüübist (kernel helpers) ja hiljuti ka tavalisi funktsioone. Iga kutsutav funktsioon võib vastu võtta kuni viis argumendit, mis edastatakse registrites r1—r5, ning tagastatav väärtus edastatakse registrisse r0. Tagatakse, et pärast funktsioonist väljumist registrite sisu r6—r9 ei muutu.

Kuna programmide tõhusaks tõlkimiseks on kõik toetatud arhitektuuride registrid r0—r11 kaardistatud selgelt tegelikele registeritele, arvestades hetke arhitektuuri ABI eripärasid. Näiteks kasutatakse x86_64 registreid r1—r5, mis edastavad funktsioonide parameetreid, registreerimiseks rdi, rsi, rdx, rcx, r8, mis on kasutusel parameetrite edastamiseks funktsioonidesse x86_64. Näiteks tõlgitakse vasakul olev kood paremal poole nii:

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

Register r0 kasutatakse ka programmi täitmise tulemuse tagastamiseks, ja registris r1 edastatakse programmile konteksti näidik — sõltuvalt programmi tüübist võib see olla näiteks struktuur struct xdp_md (XDP jaoks) või struktuur struct __sk_buff (erinevate võrguprogrammide jaoks) või struktuur struct pt_regs (erinevate jälgimisprogrammide jaoks) jne.

Nii, meil oli registeride komplekt, kernel helpers, stakk, konteksti näitaja ja jagatud mälu kujul maps. Mitte et kõik see oleks kindlasti vajalik reisil, aga…

Jätkame kirjeldust ja räägime käskude süsteemist nende objektide töötlemiseks. Kõik (peaaegu kõik) BPF-käsud on fikseeritud 64-bitise suurusega. Kui vaatate üht käsku 64-bitises Big Endian masinas, näete

Siin Kood — see on käsu kodeering, Dst/Src — need on vastavalt siht- ja allika kodeeringud, Kõrval — 16-bitine signeeritud nihkeväärtus, ja Imm — see on 32-bitine signeeritud täisarv, mida kasutatakse mõnedes käskudes (sarnane konstant K-st cBPF-is). Kodeering Kood on ühes kahest vormist:

Käskude klassid 0, 1, 2, 3 määratlevad käsud mälu töötlemiseks. Nad künditakse, BPF_LD, BPF_LDX, BPF_ST, BPF_STX, vastavalt. Klassid 4, 7 (BPF_ALU, BPF_ALU64) koosnevad ALU-käskudest. Klassid 5, 6 (BPF_JMP, BPF_JMP32) sisaldavad hüppe käske.

Edasi on BPF-käskude õppimise plaan järgmine: selle asemel, et hoolikalt loetleda kõiki käske ja nende parameetreid, vaatame siin paar näidet ja selgub, kuidas käskud tegelikult on üles ehitatud ja kuidas käsitsi disassembeldada igasuguseid binaarfailide BPF jaoks. Teema kinnistamiseks kohtame artikli edasistes osades individuaalseid käske, mis puudutavad Verifierit, JIT kompilaatorit, klassikalise BPF tõlkimist ning ka mapside ja funktsioonide kutsumist jne.

Kui räägime individuaalsetest käskudest, viitame me kernelifailidele bpf.h ja bpf_common.h, kus on määratletud BPF käsu numbrilised koodid. Kui uurite arhitektuuri ja/või vaatate üle binaare, võite leida semantika järgmistest allikatest, mis on järjestatud keerukuse järgi: Ebofficial eBPF spetsiifikatsioon, BPF ja XDP viidatud juhend, käskude komplekt, Dokumentatsioon/networking/filter.txt ja muidugi Linuxi lähtekoodis — verifier, JIT, BPF tõlkija.

Näide: disassembeldame BPF mõttes

Vaadake seda näidet, kus kompileerime programmi readelf-example.c ja vaatame, mis binaar on saadud. Avame originaalse sisu readelf-example.c allpool, pärast seda, kui oleme taastanud selle loogika binaarkoodidest:

$ 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 ................

Esimene veerg väljundis readelf — see on sisend ja meie programm koosneb seega neljast käsklusest:

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

Käskluskoodid on võrdsed b7, 15, b7 ja 95. Meenutame, et kolm madalaimat bitti tähistavad käsu klassi. Meie puhul on neljas bitt kõikide käskluste jaoks tühi, seega on käsu klassid võrdsed, vastavalt 7, 5, 7, 5. Klass 7 on BPF_ALU64, aga 5 on BPF_JMP. Mõlema klassi korral on käsu formaat sama (vt eelnevat) ja saame meie programmi ümber kirjutada nii (samuti kirjutame ülejäänud veerud inimlikus vormis):

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

Tehe b klassist ALU64 — see on BPF_MOV. See määrab väärtuse sihtregistrisse. Kui on seatud bitt s (source), siis väärtus võetakse allikaregistrist, kuid kui, nagu meie puhul, see ei ole seatud, siis väärtus võetakse väljast Imm. Seega teeme esimese ja kolmanda käsu korral operatsiooni r0 = Imm. Järgmine käsk 1 klassi JMP — see on BPF_JEQ (hüpe, kui võrdsed). Meie puhul, kuna bitt S on null, võrdleb see allikaregistri väärtust väljadega Imm. Kui väärtused kattuvad, toimub üleminek PC + Off, kus PC, nagu tavaliselt, sisaldab see järgmise käsu aadressi. Lõpuks, käsk 9 klassi JMP — see on BPF_EXIT. See käsk lõpetab programmi toimimise, tagastades kernelile r0. Lisame meie tabelisse uue veeru:

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

Saame selle ümber kirjutada mugavamas vormis:

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

Kui me meenutame, et registris r1 edastatakse programmi kaudu konteksti viidatud tuumale, ning registris r0 tagastatakse väärtus tuumale, siis võime näha, et kui konteksti viidatud on null, siis tagastame 1, vastasel juhul 2. Kontrollime, et oleme õiged, vaadates lähtekoodi:

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

Jah, see on mõttetu programm, kuid see kompileeritakse vaid neljaks lihtsaks käsuks.

Näide-erand: 16-baidine käsk

Oleme varem maininud, et mõned käsud võtavad rohkem kui 64 bitti. See kehtib näiteks käsku lddw (Code = 0x18 = BPF_LD | BPF_DW | BPF_IMM) — laadige registrisse kahe sõnaga andmed väljadest Imm. Asi on selles, et Imm on 32 byte size, and a double word — 64 bits, so we cannot load a 64-bit immediate value into a register in one 64-bit instruction. For this, two adjacent instructions are used to store the second part of the 64-bit value in the field Imm. Näidis:

$ 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                   ........

The binary program contains only two instructions:

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

We will meet again with the instruction lddw, when we talk about relocations and working with maps.

Example: disassembling BPF using standard tools

So, we have learned to read BPF binary codes and are ready to disassemble any instruction if needed. However, it is worth noting that in practice, it is more convenient and faster to disassemble programs using standard tools, for example:

$ llvm-objdump -d x64.o

Disassembly of section .text:

0000000000000000 :
 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

The life cycle of BPF objects, the bpffs filesystem

(Some details presented in this subsection were first learned from the post by Alexei Starovoitov in BPF Blog.)

BPF objects — programs and maps — are created from user space using the commands BPF_PROG_LOAD ja BPF_MAP_CREATE system call bpf(2), we will discuss how this happens in the next section. This creates kernel data structures and for each of them refcount (reference count) is set to one, and the user is returned a file descriptor pointing to the object. After closing the descriptor refcount the object’s reference count reduces by one, and when it reaches zero, the object is destroyed.

If the program uses maps, then refcount the reference count of these maps increases by one after the program is loaded, i.e., their file descriptors can be closed from the user process without causing the count refcount to drop to zero:

After successfully loading the program, we usually attach it to some event generator. For example, we can attach it to a network interface to process incoming packets or connect it to some tracepoint in the kernel. At this moment, the reference count will also increase by one, and we will be able to close the file descriptor in the loading program.

Mis juhtub, kui me nüüd laadijaga töö lõpetame? see sõltub sündmuste generaatori (hook) tüübist. Kõik võrguhooked jäävad alles pärast laadija lõpetamist, need on nn globaalhookid. Näiteks jälgimisprogrammid vabanevad pärast nende loonud protsessi lõpuleviimist (seega nimetatakse neid kohalikeks, mis tuleneb terminist 'local to the process'). Tehniliselt on kohalikud hookid alati seotud vastava failidža vaba ruumiga ja seega sulguvad protsessi lõpetamisega, samas kui globaalhookid ei sulgu. Järgmises joonises püüan punaste ristikestega näidata, kuidas laadija programmi lõpetamine mõjutab objektide eluiga kohalike ja globaalsete hookide korral.

Miks on olemas kohalike ja globaalsete hookide eraldamine? Mõnede tüüpi võrguprogrammide käitamine on mõttekas ka ilma userspace'ita, näiteks kujutage ette DDoS-kaitset - laadija määrab reeglid ja ühendab BPF programmi võrguliidesega, pärast mida laadija võib ise lõpetada. Teisest küljest, kujutage ette jälgimisprogrammi, mille te kümne minutiga ise kokku keerasite - pärast selle lõpetamist sooviksite, et süsteemis ei jääks prügi, ja kohalikud hookid tagavad selle.

Teiselt poolt, kujutage ette, et soovite ühenduda jälgimispunktiga (tracepoint) tuumas ja koguda statistikat aastaid. Sel juhul sooviksite lõpetada kasutaja osa ja aeg-ajalt statistika juurde tagasi tulla. Selle võimaluse pakub bpf failisüsteem. See on pseudo-failisüsteem, mis eksisteerib ainult mälus ja võimaldab luua faile, mis viitavad BPF objektidele, ja seeläbi pikendada refcount objekte. Pärast seda võib laadija lõpetada oma töö ja loodud objektid jäävad elama.

BPF objektide pindamine ("pin", nagu järgmises lauses: "process can pin a BPF program or map") BPF objektide jaoks failide loomine on mõttekas mitte ainult kohalike objektide elu pikendamiseks, vaid ka globaalsete objektide mugavamaks kasutamiseks - naastes DDoS-i kaitse globaalprogrammi näite juurde, tahame meil oleks aeg-ajalt võimalik tagasi tulla ja statistika peale vaadata.

BPF faili süsteem monteeritakse tavaliselt /sys/fs/bpf, kuid selle saab monteerida ka kohapeal, näiteks nii:

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

Failisüsteemis nimed luuakse käsuga BPF_OBJ_PIN BPF süsteemikõne abil. Näitena võtame mõne programmi, kompileerime, laadime ja kinnitame selle bpffs. Meie programm ei tee midagi kasulikku, toome selle koodi vaid selleks, et saaksite näidist korrata:

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

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

Kompileerime selle programmi ja loome kohaliku koopia faili süsteemist bpffs:

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

Nüüd laadime meie programmi utiliidi abil bpftool ja vaatame kaasnevaid süsteemikõnesid bpf(2) (strace väljundist on mõned asjakohatud read eemaldatud):

$ 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

Siin laadisime programmi BPF_PROG_LOAD, saime kernelilt faili deskripti 3 ja käsuga BPF_OBJ_PIN kinnitasime selle faili deskripti failina "bpf-mountpoint\/test". Pärast seda lõpetas laadimisprogramm töö, kuid meie programm jäi karneli, kuigi me ei kinnitanud seda ühelgi võrguliidesele: 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

Saame failiobjekti tavalise

unlink(2) ja pärast seda vastav programm kustutatakse: $ sudo rm .\/bpf-mountpoint\/test $ sudo bpftool prog show id 783 Error: get by id (783): No such file or directory

Objektide kustutamine

Rääkides objektide kustutamisest, tuleb täpsustada, et pärast programmi eraldamist konksust (sündmuste generaatorist) ei põhjusta ükski uus sündmus selle käivitamist, kuid kõik jooksvaid programmi eksemplarid lõpetatakse korrektselt.

Mõned BPF programmide tüübid võimaldavad programmi töö ajal vahetada, st pakuvad järjepidevust

replace = detach old program, attach new program . Sellega lõpetavad kõik vanade programmide aktiivsed eksemplarid oma töö ja uued sündmuste töötlejad luuakse juba uuest programmist, ning "järjepidevus" tähendab siin, et ükski sündmus ei jää vahele.Sellega lõpetavad kõik aktiivsed vanade programmide eksemplarid oma töö ning uued sündmuste töötlejad luuakse juba uue programmi põhjal, kusjuures "aatomiilisus" tähendab seda, et ühtegi sündmust ei jää vahele.

Programmid sündmustele liitumine

Selles artiklis ei hakka me eraldi kirjeldama programmide ühendamist sündmustele, kuna seda on mõttekas uurida konkreetse programmiliigi kontekstis. Vaata. näide allpool, kus näitame, kuidas liituvad XDP tüüpi programmid.

Objektide haldamine BPF süsteemikõne abil

BPF programmid

Kõik BPF objektid luuakse ja hallatakse kasutaja ruumist süsteemikõne abil bpf, millel on järgmine prototüüp:

#include <linux/bpf.h>

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

Siin käsk cmd on üks väärtusi enum bpf_cmd, attr — näitaja konkreetse programmi parameetritele ja size — objekti suurus näitaja järgi, st tavaliselt see on sizeof(*attr). Kerneli versioonis 5.8 toetab süsteemikõne bpf 34 erinevat käsku, ja defineerimine union bpf_attr koosneb 200 reast. Kuid see ei peaks meid hirmutama, kuna tutvume käskude ja parameetritega mitme artikli jooksul.

Alustame käsust BPF_PROG_LOAD, mis loob BPF programme — võtab BPF käsukogumi ja laadib selle ykerneli. Laadimise hetkel aktiveeritakse valideerija ning seejärel JIT kompilaator ja pärast edukat täitmist tagastatakse kasutajale programmifaili deskriptor. Olime varem näinud, mida sealt edasi toimub BPF objektide elutsükli kohta..

Praegu kirjutame kasutaja programmi, mis laadib lihtsa BPF programmi, kuid kõigepealt peame otsustama, millise programmi tahame laadida — peame valima tüüp ja selle tüübi raames kirjutama programmi, mis läbib valideerijat. Kuid et protsessi keerulisemaks mitte muuta, siin on valmis lahendus: võtame programmi tüüpi BPF_PROG_TYPE_XDP, mis tagastab väärtuse XDP_PASS (kõik paketid jätta vahele). BPF assambleeris see välja näeb väga lihtne:

r0 = 2
exit

Pärast seda, kui oleme otsustanud, mida mida me laadime, saame rääkida, kuidas me seda teeme:

#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();
}

Huvilised sündmused programmis algavad massiivi määratlemisest insns — meie BPF programm masinakoode säästev. Samuti sisaldab iga BPF käsu juhist struktuuris bpf_insn. Esimene element insns vastab käskudele r0 = 2, teine — exit.

Käik. Kernelis on määratletud mugavamad makrod masinakoode kirjutamiseks ja kasutades kernelipeade faili tools/include/linux/filter.h saaksime kirjutada

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

Kuna BPF programmide kirjutamine masinkoodides on vajalik ainult testide ja BPF artiklite kirjutamiseks, siis nende makrode puudumine ei tee arendaja elu tegelikult keerulisemaks.

Pärast BPF programmi määratlemist liigume selle laadimise juurde kernelisse. Meie minimalistlik parameetrite komplekt attr sisaldab programmi tüüpi, käskude arvu ja komplekti, kohustuslikku litsentsi ning nime "woo", mida me kasutame, et leida meie programm süsteemis pärast selle laadimist. Programm laaditakse süsteemi nagu lubatud süsteemikõne abil bpf.

Programmi lõpus satume lõpmatusse tsüklisse, mis simuleerib kasulikku koormust. Ilma selleta hävitab programm kernel, kui faili deskriptor, mille süsteemikõne meile andis, suletakse bpf, ja me ei näe seda süsteemis.

Noh, oleme testimiseks valmis. Kogume ja käivitame programmi strace, et kontrollida, kas kõik töötab nagu peab:

$ 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_VERSION(0, 0, 0), prog_flags=0, prog_name="woo", prog_ifindex=0, expected_attach_type=BPF_CGROUP_INET_INGRESS}, 72) = 3
pause(

Kõik on korras, bpf(2) meil on deskriptor 3 ja me suundume lõpmatusse tsüklisse koos pause(). Proovime nüüd leida meie programmi süsteemis. Selleks läheme teise terminali ja kasutame utiliiti 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)

Näeme, et süsteemis on laaditud programm woo mille globaalne ID on 390, ja et praegu protsessis simple-prog on avatud faili deskriptor, mis viitab programmile (ja kui simple-prog see lõpetab töö, siis woo kaob). Nagu oodata oli, programm woo võtab 16 baiti — kaks käsku — BPF arhitektuuri binaarkoodis, kuid originaali (x86_64) formaat on juba 40 baiti. Vaadake meie programmi originaalses vormis:

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

ilma üllatusteta. Nüüd vaatame koodi, mille on loonud JIT kompilaator:

# 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

ei ole kuigi tõhus exit(2), kuid õiguse nimel, meie programm on liiga lihtne, ja mitte triviaalsete programmide puhul on JIT kompilaatori poolt lisatud proloog ja epiloog kindlasti vajalikud.

Maps

BPF-programmid saavad kasutada struktuuritud mälu alasid, mis on kergesti kättesaadavad nii teistele BPF-programmidele kui ka kasutajaruumi programmidele. Need objekte nimetatakse "maps" ja käesolevas osas näitame, kuidas neid hallata süsteemikutsumise abil. bpf.

Ütleme kohe, et maps'i võimalused ei piirdu ainult juurdepääsuga jagatud mälule. On olemas spetsiaalsed kaardid, mis sisaldavad näiteks viiteid BPF-programmidele või viiteid võrguliidestele, kaardid perf-events'i jaoks ja nii edasi. Siin me neist rääkima ei hakka, et lugejat segadusse ei ajada. Lisaks ignoreerime sünkroniseerimisprobleeme, kuna need ei ole meie näidete jaoks olulised. Täieliku nimekirja saadaval olevatest kaarditüüpidest leiate. <linux/bpf.h>, ja käesolevas osas võtame me näitena ajalooliselt esimese tüübi, hash-tabeli. BPF_MAP_TYPE_HASH.

Kui loote hash-tabeli, ütleme, et C++-s ütlete: unordered_map woo, mis eesti keeles tähendab "mul on vaja tabelit, woo mis on piiranguteta suurusega, mille võtmed on tüüpi int, ja väärtused on tüüpi long." BPF-hash-tabeli loomiseks peame me tegema enam-vähem sama, arvestades, et peame määrama tabeli maksimaalse suuruse ja võtmete ning väärtuste tüübi asemel peame me täpsustama nende suurused baitides. Kaartide loomiseks kasutatakse käsku BPF_MAP_CREATE system call bpf. Vaatame üle enam-vähem minimaalse programmi, mis loob kaardi. Eelmise BPF-programmi laadimise järel peaks see teile tunduma lihtne:

$ cat simple-map.c
#define _GNU_SOURCE
#include 
#include 
#include 
#include 

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();
}

Siin määratleme parametrites kogumi, attr, kus ütlen "mul on vaja hash-tabelit, mille võtmed ja väärtused on suurusega sizeof(int), kuhu ma saan paigutada maksimaalselt neli elementi." BPF-kaartide loomisel võib määrata ka teisi parameetreid, näiteks, nagu programmide näites, määrasime objekti nimeks "woo".

Kompileerime ja käivitame programmi:

$ 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(

Siin on süsteemikutsung bpf(2) tagastas meile kaardiga seotud deskriptorinumbri 3 ja edasi programm, nagu oodatud, ootab süsteemikutses edasisi juhiseid pause(2).

Nüüd saadame meie programmi taustale või avame teise terminali ning vaatame meie objekti seejärel utiliidi abil bpftool (me saame eristada meie kaarti teistest selle nime järgi):

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

Number 114 on meie objekti globaalne ID. Iga programm süsteemis võib kasutada seda ID-d, et avada juba olemasolev kaart käsuga BPF_MAP_GET_FD_BY_ID system call bpf.

Nüüd saame hakata katsetama meie hash-tabeliga. Vaatame selle sisu:

$ sudo bpftool map dump id 114
Leitud 0 elementi

Tühi. Paneme nüüd sinna väärtuse hash[1] = 1:

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

Vaatame tabelit veel kord:

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

Hurraa! Meil õnnestus lisada üks element. Pane tähele, et selleks peame töötama baitide tasemel, kuna bptftool ei tea, milline tüüp on väärtustel hash-tabelis. (Seda teavet saab anda, kasutades BTF-d, kuid mitte nüüd.)

Kuidas bpftool täpselt elemente loeb ja lisab? Uurime, mis peidab end kapoti all:

$ 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

Esmalt avasime kaardi selle globaalsete ID-de põhjal käsuga BPF_MAP_GET_FD_BY_ID ja bpf(2) tagastas meile deskriptor 3. Edasi käsuga BPF_MAP_GET_NEXT_KEY leidis me tabelis esimese võtme, edastades NULL nagu "eelneva" võtme näitaja. Kui meil on võtme olemas, saame teha BPF_MAP_LOOKUP_ELEM, mis tagastab väärtuse näitaja value. Järgmine samm — proovime leida järgmise elemendi, edastades näitaja praegusele võtmele, kuid meie tabelis on ainult üks element ja käsk BPF_MAP_GET_NEXT_KEY toob tagasi ENOENT.

Hästi, muudetakse väärtust võtme 1 kaudu, oletame, et meie äri loogika nõuab selle määramist 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

Kuna oodatud, on see väga lihtne: käsk BPF_MAP_GET_FD_BY_ID ava meie kaardi ID kaudu, ja käsk BPF_MAP_UPDATE_ELEM ülekirjutab elemendi.

Kokkuvõttes, pärast räsitabeli loomist ühest programmist saame lugeda ja kirjutada selle sisu teisest. Pange tähele, et kui me suutsime seda teha käsurealt, siis suudab seda ka iga teine programm süsteemis. Üheks koos käitumiseks on kasutusel järgmised:

• BPF_MAP_LOOKUP_ELEM: leida väärtus võtme järgi
• BPF_MAP_UPDATE_ELEM: värskendada/luua väärtus
• BPF_MAP_DELETE_ELEM: kustutada võti
• BPF_MAP_GET_NEXT_KEY: leida järgmine (või esimene) võti
• BPF_MAP_GET_NEXT_ID: võimaldab läbida kõik olemasolevad mapid, nii töötab bpftool map
• BPF_MAP_GET_FD_BY_ID: avada olemasolev map selle globaalsete ID-de järgi
• BPF_MAP_LOOKUP_AND_DELETE_ELEM: atomaarne objekti väärtuse värskendamine ja vana tagastamine
• BPF_MAP_FREEZE: muuta map muutumatuks userspace'ist (seda toimingut ei saa tühistada)
• BPF_MAP_LOOKUP_BATCH, BPF_MAP_LOOKUP_AND_DELETE_BATCH, BPF_MAP_UPDATE_BATCH, BPF_MAP_DELETE_BATCH: massilised toimingud. Näiteks, BPF_MAP_LOOKUP_AND_DELETE_BATCH — see on ainus usaldusväärne viis lugeda ja nullida kõik väärtused mapist

Mitte kõik need käsud ei tööta kõigi mapitüüpide puhul, kuid üldiselt on töö teiste mapide tüüpidega userspace'ist sama, nagu räsitabelitega.

Korraks lõpetame meie katsetused räsitabeliga. Pidage meeles, et me lõime tabeli, kuhu võib mahtuda kuni neli võtit? Lisame veel mõned elemendid:

$ 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

Praegu on kõik hästi:

$ 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
Leitud 4 elementi

Proovime lisada veel ühe:

$ sudo bpftool map update id 114 key 5 0 0 0 value 1 0 0 0
Error: värskendamine ebaõnnestus: Argumendi loend on liiga pikk

Nagu oodatud, ei õnnestunud meil. Vaatame viga lähemalt:

$ 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 (Argumendi loend on liiga pikk)
Error: värskendamine ebaõnnestus: Argumendi loend on liiga pikk
+++ lõpetas 255 +++

Kõik on korras: nagu oodatud, käsk BPF_MAP_UPDATE_ELEM üritab luua uut, viiendat, võtit, kuid ebaõnnestub E2BIG.

Nii, me oskame luua ja laadida BPF programme ning hallata kaarte kasutajaruumi kaudu. Nüüd on loogiline vaadata, kuidas saame kaarte kasutada BPF programmides endis. Me võiksime rääkida sellest raskesti loetavate masinkoodide makrode keeles, kuid tegelikult on kätte jõudnud aeg näidata, kuidas BPF programme kirjutatakse ja hooldatakse — abi läbi libbpf.

(Lugejatele, kes on rahulolematu madala taseme näidete puudumise üle: me arutame üksikasjalikult programme, mis kasutavad kaarte ja abifunktsioone, mis on loodud läbi libbpf ja räägime, mis toimub käsu tasemel. Lugejatele, kes on rahulolematu väga tugevalt, oleme lisanud näide seoses artikli sobivasse kohta.)

Kirjutame BPF-i programme libbpf-kasutades

BPF programmide kirjutamine masinkoodide kaudu võib olla huvitav ainult esialgu, seejärel muutub see tüütuks. Sel hetkel tuleks oma pilk pöörata llvm, mis sisaldab tagakülge BPF arhitektuurile koodi genereerimiseks, ja ka raamatukogu libbpf, mis võimaldab kirjutada BPF rakenduste kasutajapoolset osa ja laadida BPF programmide koodi, mis on genereeritud läbi llvm/clang.

Tegelikult, nagu näeme selles ja järgnevates artiklites, libbpf teeb üsna palju tööd ja ilma selleta (või sarnaste tööriistadeta — iproute2, libbcc, libbpf-go, jne.) ei saa elada. Üks projekti killer-funktsioone libbpf on BPF CO-RE (Compile Once, Run Everywhere) — projekt, mis võimaldab kirjutada BPF programe, mis on ülekandmiseks erinevate tuumade vahel ja töötamine erinevate API-dega (näiteks, kui tuuma struktuur muutub erinevate versioonide vahel). Selleks, et CO-RE-ga töötada, peab teie tuum olema BTF toega kompileeritud (kuidas seda teha, räägime jaotises Arendustooted. Kontrollida, kas teie tuum on BTF toega kompileeritud, on väga lihtne — olemasoleva faili järgi:

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

See fail sisaldab teavet kõigi andmetüüpide kohta, mida tuumas kasutatakse, ja seda kasutatakse kõigis meie näidetes, mis kasutavad libbpf. Räägime CO-RE-st põhjalikult järgnevates artiklites, aga sel korral — lihtsalt koostage oma tuum CONFIG_DEBUG_INFO_BTF.

Raamatukogu libbpf elab otse kataloogis tools/lib/bpf tuuma ja selle arendamist juhitakse postiloendi kaudu bpf@vger.kernel.org. Kuid rakenduste jaoks, mis elavad kestast väljaspool, toetatakse eraldi hoidlat https://github.com/libbpf/libbpf , kus kernelirakenduse teek peegeldub lugemiseks enam-vähem nii nagu on.

Selles osas vaatame, kuidas luua projekt, mis kasutab libbpf, kirjutame mõned (enam-vähem mõttetud) testprogrammid ja vaatame, kuidas see kõik töötab. See võimaldab meil järgnevates osades lihtsamalt selgitada, kuidas just BPF programmid interakteeruvad maps, kernel helpers, BTF jne.

Tavaliselt lisavad projektid, mis kasutavad libbpf , GitHubi hoidla git submodulina, teeme seda ka meie:

$ 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.

Kogumine libbpf on väga lihtne:

$ 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

Meie edasine plaan selles osas on järgmine: kirjutame BPF tüüpi programmi BPF_PROG_TYPE_XDP, sama, mis eelnevas näites, aga C keeles, kompileerime selle kasutades clang, ja kirjutame abiprogrammi, mis laadib selle kernelisse. Järgnevates osades laiendame nii BPF programmi kui ka abiprogrammi funktsioone.

Näide: loome täisfunktsionaalse rakenduse libbpf abil

Alustuseks kasutame ülalpool mainitud faili /sys/kernel/btf/vmlinux, ja loome selle ekvivalent pea failina:

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

Selles failis hoitakse kõiki andmestruktuure, mis meie kernelis eksisteerivad, näiteks määratletakse siin IPv4 päis nii:

$ 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;
};

Nüüd kirjutame oma BPF programmi C keeles:

$ cat xdp-simple.bpf.c
#include "vmlinux.h"
#include 

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

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

Kuigi meie programm on väga lihtne, peame siiski tähelepanu pöörama mitmetele detailidele. Esiteks on esimene päisfail, mida me kaasame, vmlinux.h, mille me just genereerisime abiga bpftool btf dump — nüüd ei pea me enam installima kernel-headers paketti, et teada saada, kuidas tuumstruktuurid välja näevad. Järgmine päisfail tuleb meile raamatukogust libbpf. Praegu on see meile vajalik ainult selleks, et makro SEC, mis saadab sümboli ELF objektifaili vastavasse sektsiooni, määratletaks. Meie programm on sektsioonis xdp/simple, kus enne kaldkriipsu määrame BPF programmi tüübi — see on kokkulepe, mida kasutatakse libbpf, mis põhineb sektsiooni nimele, sisestab õige tüübi käivitamisel bpf(2). BPF programm ise on C — väga lihtne ja koosneb ühisest reast return XDP_PASS. Lõpuks sisaldab eraldi sektsioon "license" litsentsi nime.

Saame meie programmi kompileerida llvm/clang abil, versiooniga >= 10.0.0, veel parem — uuema (vt jaotist Arendustooted):

$ 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

Huvitavad omadused: me määrame sihtarhitektuuri -target bpf ja teed päisfailideni libbpf, mille me hiljuti installisime. Samuti ärge unustage -O2, ilma selle valikuta võivad teid oodata edaspidi üllatused. Vaatame meie koodi, kas suutsime kirjutada programmi, mida soovisime?

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

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

Sektsiooni xdp/simple dekoodeerimine:

0000000000000000 :
       0:       r0 = 2
       1:       exit

Jah, see õnnestus! Nüüd on meil binaarfail programmiga ja tahame luua rakenduse, mis laadib selle tuuma. Selleks pakub raamatukogu meile kahte võimalust — kasutada madalama taseme API-d või kõrgema taseme API-d. Me valime teise tee, kuna tahame õppida, kuidas kirjutada, laadida ja ühendada BPF programme minimaalse vaevaga nende edasise uurimise jaoks. libbpf Esiteks peame genereerima meie programmi "skelett" sellest binaarfailist sama utiliidi abil

Alustuseks peame meie programmi „skeleti“ genereerima selle binaarfailist, kasutades sama utiliiti. bpftool — šveitsi armee noa BPF (mida saab mõista ka otseselt, sest Daniel Borkman on üks BPF loojatest ja hoidlaseisunditest — šveitslane):

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

Failis xdp-simple.skel.h Sisaldab meie programmi binaarkoodi ja funktsioone haldamiseks — laadimiseks, ühendamiseks, meie objekti eemaldamiseks. Meie lihtsal juhul näeb see välja ülemäärasena, kuid see töötab ka olukordades, kus objektifail sisaldab palju BPF programme ja kaarte, ning selle tohutu ELF laadimiseks piisab, kui genereerida skelett ja kutsuda ühe või kahe funktsiooni kasutajarakendusest, mille kirjutamise juurde me nüüd jõuame.

Tegelikult on meie laadimisprogramm triviaalne:

#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);
}

Siin struct xdp_simple_bpf määratakse failis xdp-simple.skel.h ja kirjeldab meie objektifaili:

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;
};

Siit võib märgata madalamal tasemel API jälgi: struktuur struct bpf_program *simple ja struct bpf_link *simple. Esimene struktuur kirjeldab konkreetselt meie programmi, mis on salvestatud sektsiooni xdp/simple, ja teine kirjeldab seda, kuidas programm on ühendatud sündmuste allikaga.

Funktsioon xdp_simple_bpf__open_and_load, avab ELF objekti, parsib selle, loob kõik struktuurid ja alastruktuurid (kuna ELF-is on programme ja teisi sektsioone — andmed, ainult lugemiseks mõeldud andmed, silumisinfo, litsents jne), ja laadib siis südamikku süsteemikõne kaudu bpf, mille võime kontrollida, kompileerides ja käivitades programmi:

$ 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

Vaatame nüüd oma programmi läbi bpftool. Leiame selle ID:

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

ja teeme dumpimise (kasutame käskluse lühendatud vormi bpftool prog dump xlated):

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

Midagi uut! Programm printis meie allika faili osad C keeles. Seda tegi teek libbpf, mis leidis binaaris silumissektsiooni, kompileeris selle BTF objektiks, laadis selle südamikku käsku BPF_BTF_LOAD, ja seejärel kasutas saadud failide descriptorit programmi laadimiseks käsu BPG_PROG_LOAD.

Kernel Helpers

BPF-i programmid võivad käivitada 'välist' funktsioone — kernel helpers. Need abifunktsioonid võimaldavad BPF-i programmidel pääseda ligi kernelistruktuuridele, hallata maps'e ning suhelda 'reaalse maailmaga' — luua perf events, hallata riistvara (nt suunata pakette) jne.

Näide: bpf_get_smp_processor_id

Konteksti 'õpime näidete kaudu' raames vaatame ühte abifunktsiooni, bpf_get_smp_processor_id(), konkreetne failis kernel/bpf/helpers.c. See tagastab protsessori numbri, millel käivitub seda kutsuv BPF-i programm. Kuid meid huvitab rohkem mitte selle semantika, vaid see, et selle rakendamine võtab ühe rea:

BPF_CALL_0(bpf_get_smp_processor_id)
{
    return smp_processor_id();
}

BPF-i abifunktsioonide määratlemine sarnaneb Linuxi süsteemikõnede määratlemisega. Siin määratletakse näiteks argumentideta funktsioon. (Funktsioon, mis võtab näiteks kolm argumenti, määratletakse makroga BPF_CALL_3. Maksimaalne argumentide arv on viis.) Kuid see on ainult määratlemise esmane osa. Teine osa seisneb tüübi määratlemises struct bpf_func_proto, mis sisaldab abifunktsiooni kirjeldust, mis on verifikaatorile arusaadav:

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

Abifunktsioonide registreerimine

Selleks, et teatud tüüpi BPF-i programmid saaksid seda funktsiooni kasutada, peavad nad selle registreerima, näiteks tüübi jaoks BPF_PROG_TYPE_XDP kernelis määratletakse funktsioon xdp_func_proto, mis funktsiooni ID kaudu määrab, kas XDP toetab seda funktsiooni või mitte. Meie funktsiooni toetab:

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;
    ...
    }
}

Uued BPF-i programmide tüübid 'määratakse' failis include/linux/bpf_types.h makro abil BPF_PROG_TYPE. 'Määratlemine' on jutumärkides, kuna see on ratsionaalne määratlemine, kuid C keele kontekstis määratakse konkreetsete struktuuride kogum teistes kohtades. Eriti failis kernel/bpf/verifier.c kõik määratlused failist bpf_types.h kasutatakse struktuuride massiivi loomiseks 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 
#undef BPF_PROG_TYPE
};

See, for each type of BPF program, a pointer to a data type structure is defined struct bpf_verifier_ops, which is initialized with the value _name ## _verifier_ops, i.e., xdp_verifier_ops jaoks xdp. The structure xdp_verifier_ops is defined failis net/core/filter.c järgmiselt:

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,
};

Here we see our familiar function xdp_func_proto, which will be invoked by the verifier every time it encounters a call of some function inside the BPF program, see verifier.c.

Let's look at how a hypothetical BPF program uses the function bpf_get_smp_processor_id. To do this, we will rewrite the program from our previous section as follows:

#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";

Symbol bpf_get_smp_processor_id is defined ja <bpf/bpf_helper_defs.h> teeki libbpf kuidas

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

that is, bpf_get_smp_processor_id — this is a pointer to a function, the value of which is 8, where 8 is the value BPF_FUNC_get_smp_processor_id tüüpi enum bpf_fun_id, which is defined for us in the file vmlinux.h (the file bpf_helper_defs.h is generated by a script in the kernel, so ‘magic’ numbers are ok). This function takes no arguments and returns a value of type __u32. When we run it in our program, clang it generates an instruction BPF_CALL of the ‘correct form’. Let's compile the program and look at the section 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 :
       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
       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 
       6:       b7 00 00 00 01 00 00 00 r0 = 1

0000000000000038 :
       7:       95 00 00 00 00 00 00 00 exit

In the very first line, we see the instruction call, parameeter IMM which equals 8, and SRC_REG — zero. According to the ABI convention used by the verifier, this is indeed a call to the helper function number eight. After it is executed, the logic is straightforward. The returned value from the register r0 is copied into r1 and on lines 2,3 converted to the type u32 — the upper 32 bits are zeroed. In lines 4,5,6,7 we return 2 (XDP_PASS) or 1 (XDP_DROP) depending on whether the helper function from line 0 returned zero or non-zero.

Let's check ourselves: load the program and look at the output 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
   4: (b7) r0 = 2
; }
   5: (15) if r1 == 0x0 goto pc+1
   6: (b7) r0 = 1
   7: (95) exit

Hästi, verifikaator leidis õige kernel-helperi.

Näide: edastame argumendid ja lõpuks käivitame programmi!

Kõik jooksutamise abifunktsioonid omavad prototüüpe

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

Abifunktsioonide parameetrid edastatakse registrites r1—r5, ja tagastatav väärtus on registris r0. Funktsioone, mis võtavad rohkem kui viis argumenti, ei ole ja nende toetamine ei ole tulevikus plaanis.

Vaadakem uut kernel helperit ja seda, kuidas BPF edastab parameetreid. Kirjutame ümber xdp-simple.bpf.c järgmiste sõnadega (muud read ei muutunud):

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

Meie programm prindib CPU numbri, millel see töötab. Kompileerime selle ja vaatame koodi:

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

0000000000000000 :
       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

Ridade 0-7 salvestame kuhja rea running on CPU%un, ja siis real 8 käivitame tuttava bpf_get_smp_processor_id. Ridades 9-12 valmistame ette abifunktsiooni bpf_printk — registrid r1, r2, r3. Miks neid on kolm, mitte kaks? Sest bpf_printk — see on makro, mis ümbritseb tõelist abifunktsiooni bpf_trace_printk, millele tuleb edastada formaadi stringi suurus.

Nüüd lisame paar rida xdp-simple.c, et meie programm ühenduks liidesega lo ja töötaks tõeliselt!

$ cat xdp-simple.c
#include 
#include 
#include 
#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);
}

Siin kasutame funktsiooni bpf_set_link_xdp_fd, mis ühendab BPF XDP tüüpi programmid võrguliidestega. Oleme kõva koodiga määranud liidese numbri lo, mis on alati 1. Käivitame funktsiooni kaks korda, et esmalt katkestada vana programm, kui see on ühendatud. Pange tähele, et nüüd ei ole meil enam vaja kutsuda pause või lõpmatust tsüklit: meie laadimisprogramm lõpetab töö, kuid BPF-programm ei hävine, kuna see on ühendatud sündmuste allikaga. Pärast eduka laadimise ja ühendamise korral käivitatakse programm iga võrkpaketi jaoks, mis jõuab lo.

Laadime programmi ja vaatame liidest lo:

$ sudo ./xdp-simple
$ sudo bpftool p | grep simple
669: xdp name simple tag 4fca62e77ccb43d6 gpl
$ ip l show dev lo
1: lo:  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

Laaditud programm on ID-ga 669 ja sama ID on näha liideses lo. Saatame paar paketti aadressile 127.0.0.1 (päring + vastus):

$ ping -c1 localhost

ja nüüd vaatame silumine virtuaalsesse faili /sys/kernel/debug/tracing/trace_pipe, kuhu bpf_printk kirjutab oma sõnumid:

# 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

Kaks paketti tuvastati lo ja töödeldi CPU0-l — meie esimene täielik mõtetu BPF-programm töötas!

Tuleb märkida, et bpf_printk ei kirjuta asjata silumise faili: see ei ole parim abivahend tootmiskeskkonnas kasutamiseks, kuid meie eesmärk oli näidata midagi lihtsat.

Juurdepääs BPF-programmidest maps

Näide: kasutame mappi BPF-programmist

Eelmistes lõikudes õppisime looma ja kasutama mappe kasutaja ruumis, nüüd vaatame tuuma osa. Alustame, nagu tavaliselt, näitest. Kirjutame oma programmi ümber xdp-simple.bpf.c järgmiselt:

#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";

Programmi alguses lisasime mapi defineerimise woo: see on 8 elemendi massiiv, kuhu salvestatakse andmed, mille tüüp on u64 (C-s defineeriksime sellise massiivi kui u64 woo[8]). Programmis "xdp/simple" saame käimasoleva protsessori numbri muutuja key ja seejärel helper-funktsiooni abil bpf_map_lookup_element saame vastava kirje massiivist ja suurendame seda ühe võrra. Venekeelsena: loeme statistikat selle kohta, millisel CPU-l on töödeldud sissetulevad paketid. Proovime programmi käivitada:

$ 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

Kontrollime, et see on ühendatud lo ja saadame natuke pakette:

$ ip l show dev lo
1: lo:  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

Nüüd vaatame massiivi sisu:

$ 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 }
]

Peaaegu kõik protsessid töötati CPU7 peal. Meie jaoks pole see oluline, peamine on, et programm töötab ja me mõistsime, kuidas pääseda BPF-i kaartidele — kasutades abiainete bpf_mp_*.

Müstiline näitaja

Nii saame me BPF-programmist kaardile juurdepääsu, kasutades kõnesid nagu

val = bpf_map_lookup_elem(&woo, &key);

kus abifunktsioon näeb välja nagu

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

aga me edastame näitaja &woo nimetule struktuurile struct { ... }…

Kui vaatame programmi assemblerit, siis näeme, et väärtus &woo ei ole tegelikult määratletud (rida 4):

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

xdp-simple.bpf.o:       faili formaat elf64-bpf

XRP lihtsate sektsioonide väljavõte:

0000000000000000 :
       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
...

ja sisaldub relegatsioonides:

$ 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

Aga kui vaatame juba laaditud programmi, siis näeme viit õigesse kaardile (rida 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]
...

Nii saame järeldada, et meie ühenduslikus programmi käivitamise hetkel viidatakse &woo oli asendatud midagi raamatukoguga libbpf. Esmalt vaatame väljundit 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

Me näeme, et libbpf loomine kaardina woo ja seejärel laadis meie programmi simple. Vaatame lähemalt, kuidas me programmi laadime:

• kutsume xdp_simple_bpf__open_and_load failist xdp-simple.skel.h
• mis kutsub esile xdp_simple_bpf__load failist xdp-simple.skel.h
• mis kutsub esile bpf_object__load_skeleton failist libbpf/src/libbpf.c
• mis kutsub esile bpf_object__load_xattr API-s libbpf/src/libbpf.c

Viimane funktsioon kutsub muuhulgas esile bpf_object__create_maps, mis loob või avab olemasolevaid kaarte, muutes need failikirjeldajateks. (Siin me näeme BPF_MAP_CREATE väljastuses strace.) Edasi kutsutakse funktsioon bpf_object__relocate , ja just see meid huvitab, kuna me mäletame, et nägime woo ülejäänud tabelis. Seda uurides jõuame lõpuks funktsiooni bpf_program__relocate, mis tegeleb kaartide relokatsioonidega:

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

Nii et me võtame meie käsu

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

ja asendame selles allika registri BPF_PSEUDO_MAP_FD, ja esimese IMM failikirjeldajaga meie kaardist. Ja kui see on näiteks 0xdeadbeef, siis tulemuseks saame käsu

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

Nii edastatakse teave kaartide kohta konkreetsele laaditud BPF programmile. Samal ajal võib kaart olla loodud BPF_MAP_CREATE, või avatud ID-ga, kasutades BPF_MAP_GET_FD_BY_ID.

Seega, kasutades libbpf on algoritm järgmine:

• kompileerimise ajal luuakse viidete jaoks kaartidele relokatsiooni tabelis kirjed
• libbpf ava ELF objekt, leidke kõik kasutatud kaardid ja looge neile failikirjeldajad
• failikirjeldajad laetakse tuuma osana käskudest LD64

Nagu aru saate, see pole veel kõik ja meil tuleb vaadata tuuma. Õnneks on meil vihje — oleme määranud väärtuse BPF_PSEUDO_MAP_FD allika registrisse ja saame seda otsida, mis viib meid kõigi pühamate pühade — kernel/bpf/verifier.c, kus funktsioon, millel on iseloomulik nimi, asendab failikirjeldaja struktuuri aadressiga 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;

(täielik kood on saadaval linki pidi). Nii et saame täiendada meie algoritmi:

• programmi laadimise ajal kontrollib verifier kaardi õiget kasutamist ja määrab vastava struktuuri aadressi struct bpf_map

Eesti ELF binaari laadimisel libbpf juhtuda veel palju sündmusi, kuid me arutame seda teiste artiklite raames.

Laadime programme ja kaarte ilma libbpf-ita

Nagu lubatud, siin on näide lugejatele, kes soovivad teada, kuidas luua ja laadida programmi, mis kasutab kaarte, ilma abita. libbpf. See võib olla kasulik, kui töötate keskkonnas, kus te ei saa sõltuvusi kokku koguda, või säästate iga bitti või kirjutate sarnast programmi ply, mis genereerib BPF binaarkoodi lennult.

Kergemaks järgimiseks kirjutame meie näite ümber xdp-simple. Täieliku ja veidi laiendatud programmi koodi, mida selles näites käsitleme, leiate siit gist.

Meie rakenduse loogika on järgmine:

• luua kaarditüüp BPF_MAP_TYPE_ARRAY käskluse abil BPF_MAP_CREATE,
• luua programm, mis kasutab seda kaarti,
• ühendada programm liidesega lo,

mis tõlgib inimkeelde kui

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);
}

Siin map_create loob kaardi täpselt nii, nagu me seda tegime esimeses näites süsteemikõnest bpf — "tuum, palun tee mulle uus kaart massiivi kujul, kus on 8 elementi tüüpi __u64 ja naita mulle failide deskriptor":

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));
}

Programm laaditakse samuti lihtsalt:

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));
}

Raske osa prog_load — see on meie BPF programmi määratlemine struktuuride massiivina struct bpf_insn insns[]. Kuid kuna me kasutame programmi, mis meil on C-s, saame natuke pettuse kasutada:

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

0000000000000000 :
       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 
       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 :
      13:       bf 10 00 00 00 00 00 00 r0 = r1
      14:       95 00 00 00 00 00 00 00 exit

Kokkuvõttes peame kirjutama 14 käsku struktuuride tüüpidena struct bpf_insn (nõuanne: võtke ülevaade, lugege uuesti juhendit, avage linux/bpf.h ja linux/bpf_common.h ja proovige tuvastada struct bpf_insn insns[] iseselt):

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
    },
};

Harjutus neile, kes seda ise ei kirjutanud — leidke map_fd.

Meie programmis on veel üks avaldamata osa — xdp_attach. Kahjuks ei saa XDP tüüpi programme süsteemi kutse kaudu ühenduda bpf. Inimesed, kes lõid BPF-i ja XDP-d, olid Linuxi võrgu kogukonnast, seega kasutasid nad kõige tuttavamat neile (aga mitte tavalistele inimestele) suhtlemisliidest tuumaga: netlink sockets, vt ka RFC3549. Lihtsaim viis rakendamiseks xdp_attach — on koodi kopeerimine libbpf, nimelt failist netlink.c, mida me just tegime, seda veidi lühendades:

Tere tulemast netlink socketite maailma

Avame netlink socketi tüübi 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;
}

Loeme sellisest soketist:

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 nlmsg_pid != nl_pid)
                errx(1, "vale 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); liiga palju koodi, mida kopeerida...
                    goto done;
                case NLMSG_DONE:
                    return 0;
                default:
                    break;
            }
        }
    }
    ret = 0;
done:
    return ret;
}

Lõpuks, siin on meie funktsioon, mis avab soketi ja saadab sellesse spetsiaalse sõnumi, mis sisaldab failihalduri descriptorit:

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 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;
}

Nii, kõik on testimiseks valmis:

$ 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 +++

Vaadakem, kas meie programm on ühendatud lo:

$ ip l show dev lo
1: lo:  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

Saadame ping-sõnumeid ja vaatame kaarti:

$ 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
Leidsime 8 elementi

Hästi, kõik töötab. Märkige, et meie kaart kuvatakse jälle baitidena. See tuleneb sellest, et erinevalt libbpf ei ole me tüübinfot (BTF) laadinud. Kuid sellest räägime järgmine kord.

Arendustooted

Selles osas vaatame põhitehniliste tööriistade komplekti BPF arendajatele.

Üldiselt ei ole BPF programmide arendamiseks midagi erilist vaja — BPF töötab igas korralikus jaotuse tõukes ja programmid koostatakse clang, mille saab paketi kaudu installida. Ent kuna BPF on arenduses, muutuvad tuum ja tööriistad pidevalt. Kui te ei soovi kirjutada BPF programme eelmise sajandi meetoditega, peate selle koguma.

• llvm/clang
• pahole
• oma tuum
• bpftool

(Teabe jaoks: see ja kõik näidised artiklis jooksutati Debian 10-l.)

llvm/clang

BPF töötab koos LLVM-iga ja kuigi hiljutistel aegadel saab BPF programme kompileerida ka gcc abil, toimub kogu praegune arendus LLVM-i jaoks. Seega kogume kõigepealt praeguse versiooni clang git-ist:

$ 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
... palju aega hiljem
$

Nüüd saame kontrollida, kas kõik on õigesti kokku pandud:

$ ./bin/llc --version
LLVM (http://llvm.org/):
  LLVM versioon 11.0.0git
  Optimeeritud versioon.
  Vaikimisi sihtmärk: x86_64-unknown-linux-gnu
  Host CPU: znver1

  Registreeritud sihtmärkide
    bpf    - BPF (host endian)
    bpfeb  - BPF (big endian)
    bpfel  - BPF (little endian)
    x86    - 32-bit X86: Pentium-Pro ja kõrgem
    x86-64 - 64-bit X86: EM64T ja AMD64

(Kogumise juhised clang on mulle saadud bpf_devel_QA.)

Me ei paigalda alles kogutud programme, vaid lisame need lihtsalt PATH, näiteks:

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

(Selle saab lisada .bashrc või eraldi faili. Isiklikult lisan sellised asjad ~/.bin/activate-llvm.sh ja kui on vaja, teen . activate-llvm.sh.)

Pahole ja BTF

Utiliit pahole kasutatakse tuuma kogumise ajal BTF formaadis silumisinfote loobmiseks. Me ei käsitle selle artikli raames BTF tehnoloogia üksikasju, välja arvatud see, et see on mugav ja me tahame seda kasutada. Seega, kui kavatsete koguda oma tuuma, koguge esmalt pahole (ilma pahole te ei saa tuuma koguda, kui valik 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

Tuuma BPF-iga eksperimenteerimiseks

BPF võimaluste uurimisel tasub kokku panna oma kerneli. Üldiselt ei ole see kohustuslik, kuna saate kokku panna ja laadida BPF programme ka jaotuse kernelil, kuid oma kernel võimaldab kasutada kõige uuemaid BPF võimalusi, mis jõuavad teie jaotusse parimal juhul alles pärast mitut kuud või, nagu mõnedate silumisriistade puhul, ei panda neid üldse lähitulevikus kokku. Samuti võimaldab oma kernel tunda end olulisena, katsetades koodi.

Kernel’i ehitamiseks vajate kõigepealt ise kernelit ja teiseks kernelikonfiguratsiooni faili. BPF eksperimentide jaoks saame kasutada tavapärast puhast kernelit või üht arenduskernelit. Ajalooliselt toimub BPF arendamine Linuxi võrgukogukonna raames ja seega lähevad kõik muudatused varem või hiljem läbi David Milleri (David Miller) — Linuxi võrguosa hooldaja. sõltuvalt oma iseloomust — parandused või uued funktsioonid — jõuavad võrgu muudatused ühte kahest kernelist — net või net-next. BPF muudatused jaotatakse samuti bpf ja bpf-next, mis hiljem jõuavad vastavalt net-i ja net-next-i. Lisainfot vt bpf_devel_QA ja netdev-FAQ. Valige seega kernel oma maitse ja süsteemi stabiilsuse vajaduste põhjal, millel testite (*-next kerneli on kõige ebastabiilsemad kõikidest loetletud).

Käesoleva artikli raames ei ole juttu kernelikonfiguratsiooni failide haldamisest — eeldatakse, et oskate seda juba teha või olete valmis ise õppima. Siiski, järgmised juhised peaksid olema enam-vähem piisavad, et teil oleks toimiv süsteem BPF toe saavutamiseks.

Laadige alla üks ülalmainitud kernelitest:

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

Küpsetage minimaalne töötav kernelikonfiguratsioon:

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

Aktiveerige BPF valikud failis .config oma valiku järgi (tõenäoliselt on CONFIG_BPF juba aktiveeritud, kuna seda kasutab systemd). Siin on valikuvõimaluste loetelu kernelist, mida selle artikli jaoks kasutati:

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

Järgmiseks saame kergesti koguda ja installida mooduleid ja kerneli (muide, kerneli saab koguda just värskelt koostatud) clang, lisades CC=clang):

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

ja taaskäivitades uue kerneliga (kasutan selleks kexec paketist kexec-tools):

v=5.8.0-rc6+ # kui uuendate olemasolevat kernelit, siis saate teha v=`uname -r`
sudo kexec -l -t bzImage /boot/vmlinuz-$v --initrd=/boot/initrd.img-$v --reuse-cmdline &&
sudo kexec -e

bpftool

Artiklis kõige sagedamini kasutatav utiliit on utiliit bpftool, mis on tarnitud Linuxi kerneli koosseisus. Selle on kirjutanud ja hooldanud BPF arendajad BPF arendajatele ning selle abil saab hallata kõiki BPF objekte — laadida programme, luua ja muuta kaarte, uurida BPF ökosüsteemi elu jne. Dokumentatsiooni man pages'i allikaid saab leida kernelis või juba kompileerituna, internetis.

Artikli kirjutamise hetkeks bpftool tarnitakse valmis kujul ainult RHELile, Federale ja Ubuntule (vt näiteks, see teema, kus räägitakse lõpetamata loost pakendamisest bpftool Debianis). Kuid kui olete juba oma kernelit kogunud, siis on selle kogumine imelihtne: bpftool $ cd ${linux}/tools/bpf/bpftool # ... kirjuta viimase clang'i teed nagu eespool kirjeldatud $ make -sSüsteemi omaduste automaatne tuvastamine: ... libbfd: [ on ] ... disassembler-four-args: [ on ] ... zlib: [ on ] ... libcap: [ on ] ... clang-bpf-co-re: [ on ]Süsteemi omaduste automaatne tuvastamine: ... libelf: [ on ] ... zlib: [ on ] ... bpf: [ on ]$

(siin

${linux} — see on teie kerneli kataloog.) Pärast nende käskude täitmist kolitakse katalooge bpftool ${linux}/tools/bpf/bpftool ja seda saab kirja panna teele (esimesele kasutajale ) või lihtsalt kopeerida rootKogumine /usr/local/sbin.

on kõige parem läbi viia viimasel bpftool , nagu eespool kirjeldatud, ning kontrollida, kas see on õigesti koostatud — näiteks järgmise käsu abil clang$ sudo bpftool feature probe kernel Süsteemi konfiguratsiooni skaneerimine... bpf() syscall mittenõutud kasutajatele on lubatud JIT kompilaator on lubatud JIT kompilaatorite kõvade seadistuste muutmine on keelatud JIT kompilaatori kallasymlsi ekspordid on juurte jaoks lubatud ...

mis näitab, millised BPF omadused on teil kernelis lubatud.

Muide, eelmist käsku saab käivitada nagu

See on sarnane utiliitide tööriistade pakettidest

# bpftool f p k

See on tehtud sarnaselt paketi utiliitidele. iproute2, kus me saame näiteks öelda ip a s eth0 asemel ip addr show dev eth0.

Kokkuvõte

BPF võimaldab tõhusalt hiire suurust mõõta ja süsteemi tuuma funktsionaalsust reaalajas muuta. Süsteem on osutunud väga edukaks, järgides parimaid UNIX-i traditsioone: lihtne mehhanism, mis võimaldab tuuma (uuesti)programmeerida, on võimaldanud tohutul hulgal inimesi ja organisatsioone eksperimenteerida. Ja kuigi eksperimentide, nagu ka BPF infrastruktuuri arendamise, lõpp on veel kaugel, on süsteemil juba stabiilne ABI, mis võimaldab luua usaldusväärset ja mis kõige tähtsam, efektiivset äriloogikat.

Tahaksin märkida, et minu arvates on tehnoloogia saamas nii populaarseks, kuna selle kaudu saab mängida (masina arhitektuuri võib enam-vähem mõista ühe õhtu jooksul), ning samas lahendada ülesandeid, mis enne selle ilmumist ei olnud (ilusasti) lahendatavad. Need kaks komponenti koos panevad inimesi eksperimenteerima ja unistama, mis viib uute ja uute uuenduste tekkimiseni.

See artikkel, kuigi ei osutunud eriti lühikeseks, on vaid sissejuhatus BPF maailma ning ei käsitle „edasiarendatud“ võimalusi ja olulisi arhitektuuri osi. Edasi-plaan on ligikaudu järgmine: järgmine artikkel käsitleb BPF programmide tüüpide ülevaadet (kernel 5.8 toetab 30 programmi tüüpi), seejärel vaatame lõpuks, kuidas kirjutada tõelisi rakendusi BPF, kasutades tuuma jälgimise programme, seejärel saab aeg süvitsi minekuks BPF arhitektuuri juurde ja seejärel tulevad näited võrgurakendustest ja BPF turbarakendustest.

Selles tsüklis eelnevad artiklid

1. BPF kõige väiksematele, osa null: klassikaline BPF

Lingid

1. BPF ja XDP Viidatud Juhend — BPF dokumentatsioon ciliumilt, täpsemalt Daniel Borkmanilt, ühelt BPF looja ja hooldaja poolt. See on üks esimesi tõsiseid kirjeldusi, mis eristub ülejäänutest, kuna Daniel teab täpselt, millest ta kirjutab ja vigu seal ei leidu. Eelkõige käsitletakse selles dokumendis, kuidas töötada BPF programmidega, mille tüübid on XDP ja TC tuntud utiliidi abil ip paketist iproute2.

2. Dokumentatsioon/networking/filter.txt — originaaldokument klassikalise, ja seejärel laiendatud BPF kohta. Kasulik lugeda, kui soovite süveneda assemblerisse ja arhitektuuri tehnilistesse detailidesse.

3. BPF blogi facebookist. Uuendatakse harva, kuid täpselt, kuna kirjutavad Alexei Starovoitov (eBPF autor) ja Andrii Nakryiko — (hooldaja libbpf).

4. bpftooli saladused. Huvitav Twitteri teema Quentin Monnetilt näidete ja bpftooli kasutamise saladustega.

5. Sukeldu BPF-i: lugemisvõimaluste loend. Üks suurimaid (ja jätkuvalt toetatavaid) linkide loetelusid BPF-i dokumentatsioonile Quentin Monnetilt.

Allikas: habr.com