Краток вовед во BPF и eBPF

Здраво, Хабр! Ве известуваме дека подготвуваме книга за издавање“.Набљудливост на Linux со BPF".

Бидејќи виртуелната машина BPF продолжува да се развива и активно се користи во пракса, ние ви преведовме статија во која се опишуваат нејзините главни способности и моменталната состојба.

Во последниве години, програмските алатки и техники станаа сè попопуларни за да се компензираат ограничувањата на кернелот на Linux во случаи кога е потребна обработка на пакети со високи перформанси. Една од најпопуларните техники од овој вид се нарекува бајпас на јадрото (бајпас на кернелот) и овозможува, заобиколувајќи го мрежниот слој на јадрото, да се изврши целата обработка на пакети од корисничкиот простор. Заобиколувањето на кернелот вклучува и контрола на мрежната картичка од кориснички простор. Со други зборови, кога работиме со мрежна картичка, се потпираме на возачот кориснички простор.

Пренесувајќи ја целосната контрола на мрежната картичка на програма за кориснички простор, ги намалуваме трошоците на кернелот (префрлување на контекст, обработка на мрежниот слој, прекини итн.), што е доста важно кога работи со брзини од 10 Gb/s или повисоки. Бајпас на кернелот плус комбинација од други карактеристики (сериска обработка) и внимателно подесување на изведбата (НУМА сметководство, Изолација на процесорот, итн.) одговараат на основите на мрежна обработка со високи перформанси во корисничкиот простор. Можеби примерен пример за овој нов пристап за обработка на пакети е ДПДК од Интел (Комплет за развој на податоци за рамнина), иако има и други добро познати алатки и техники, вклучувајќи го Cisco's VPP (Vector Packet Processing), Netmap и, се разбира, шипка.

Организирањето на мрежните интеракции во корисничкиот простор има голем број на недостатоци:

• Јадрото на ОС е слој за апстракција за хардверски ресурси. Бидејќи програмите за кориснички простор треба директно да управуваат со нивните ресурси, тие исто така треба да управуваат со сопствениот хардвер. Ова често значи дека треба да програмирате сопствени драјвери.
• Бидејќи целосно се откажуваме од просторот на кернелот, се откажуваме и од сета мрежна функционалност обезбедена од кернелот. Програмите за кориснички простор мора повторно да ги имплементираат функциите што можеби веќе се обезбедени од кернелот или оперативниот систем.
• Програмите работат во режим на песок, што сериозно ја ограничува нивната интеракција и ги спречува да се интегрираат со други делови од оперативниот систем.

Во суштина, при вмрежување во кориснички простор, придобивките од перформансите се постигнуваат со преместување на обработката на пакети од кернелот до корисничкиот простор. XDP го прави токму спротивното: ги преместува мрежните програми од корисничкиот простор (филтри, резолутори, рутирање, итн.) во просторот на јадрото. XDP ни овозможува да извршиме мрежна функција веднаш штом пакетот го погоди мрежниот интерфејс и пред да почне да се движи нагоре во потсистемот на мрежата на јадрото. Како резултат на тоа, брзината на обработка на пакети значително се зголемува. Меѓутоа, како кернелот му дозволува на корисникот да ги извршува своите програми во просторот на јадрото? Пред да одговориме на ова прашање, да погледнеме што е BPF.

BPF и eBPF

И покрај збунувачкото име, BPF (Berkeley Packet Filtering) е всушност модел на виртуелна машина. Оваа виртуелна машина првично беше дизајнирана да се справува со филтрирање на пакети, па оттука и името.

Една од најпознатите алатки кои користат BPF е tcpdump. Кога фаќате пакети користејќи tcpdump корисникот може да наведе израз за филтрирање на пакети. Само пакетите што одговараат на овој израз ќе бидат заробени. На пример, изразот „tcp dst port 80” се однесува на сите TCP пакети кои пристигнуваат на портата 80. Компајлерот може да го скрати овој израз со конвертирање во BPF бајтекод.

$ sudo tcpdump -d "tcp dst port 80"
(000) ldh [12] (001) jeq #0x86dd jt 2 jf 6
(002) ldb [20] (003) jeq #0x6 jt 4 jf 15
(004) ldh [56] (005) jeq #0x50 jt 14 jf 15
(006) jeq #0x800 jt 7 jf 15
(007) ldb [23] (008) jeq #0x6 jt 9 jf 15
(009) ldh [20] (010) jset #0x1fff jt 15 jf 11
(011) ldxb 4*([14]&0xf)
(012) ldh [x + 16] (013) jeq #0x50 jt 14 jf 15
(014) ret #262144
(015) ret #0

Ова е она што горната програма во основа го прави:

• Упатство (000): Го вчитува пакетот со поместување 12, како 16-битен збор, во акумулаторот. Офсет 12 одговара на етертипот на пакетот.
• Инструкција (001): ја споредува вредноста во акумулаторот со 0x86dd, односно со вредноста на етертипот за IPv6. Ако резултатот е точен, тогаш програмскиот бројач оди на инструкцијата (002), а ако не, тогаш на (006).
• Упатство (006): ја споредува вредноста со 0x800 (етертип вредност за IPv4). Ако одговорот е точен, тогаш програмата оди на (007), ако не, тогаш на (015).

И така натаму додека програмата за филтрирање пакети не врати резултат. Ова е обично Булова. Враќањето не-нулта вредност (инструкција (014)) значи дека пакетот е прифатен, а враќањето нулта вредност (инструкција (015)) значи дека пакетот не бил прифатен.

Виртуелната машина BPF и нејзиниот бајтекод беа предложени од Стив МекКен и Ван Џејкобсон кон крајот на 1992 година кога нивниот труд беше објавен Филтер за пакети BSD: Нова архитектура за фаќање пакети на ниво на корисник, оваа технологија за прв пат беше претставена на конференцијата Usenix во зимата 1993 година.

Бидејќи BPF е виртуелна машина, ја дефинира околината во која работат програмите. Покрај бајтекодот, тој го дефинира и моделот на сериска меморија (инструкциите за вчитување се имплицитно применети на серијата), регистрите (A и X; акумулатори и индексни регистри), складирање на меморија за гребење и имплицитен бројач на програми. Интересно е што BPF бајтекодот беше моделиран по Motorola 6502 ISA. Како што се присети Стив МекКен во неговата пленарен извештај на Sharkfest '11, тој беше запознаен со изградбата 6502 од неговите средношколски денови програмирање на Apple II, и ова знаење влијаеше на неговата работа за дизајнирање на BPF бајтекодот.

Поддршката за BPF е имплементирана во кернелот Линукс во верзии v2.5 и повисоки, додадени главно со напорите на Џеј Шулист. Кодот BPF остана непроменет до 2011 година, кога Ерик Думасет го редизајнираше преведувачот BPF за да работи во JIT режим (Извор: JIT за филтри за пакети). После ова, кернелот, наместо да го толкува BPF бајтекодот, може директно да ги конвертира BPF програмите во целната архитектура: x86, ARM, MIPS итн.

Подоцна, во 2014 година, Алексеј Старовоитов предложи нов JIT механизам за BPF. Всушност, овој нов JIT стана нова архитектура базирана на BPF и беше наречен eBPF. Мислам дека и двете VM коегзистираа некое време, но моментално филтрирањето на пакети се имплементира врз основа на eBPF. Всушност, во многу примери на модерна документација, BPF се подразбира како eBPF, а класичниот BPF денес е познат како cBPF.

eBPF ја проширува класичната виртуелна машина BPF на неколку начини:

• Врз основа на модерни 64-битни архитектури. eBPF користи 64-битни регистри и го зголемува бројот на достапни регистри од 2 (акумулатор и X) на 10. eBPF обезбедува и дополнителни оптички кодови (BPF_MOV, BPF_JNE, BPF_CALL...).
• Одвоено од потсистемот на мрежниот слој. BPF беше поврзан со моделот на сериски податоци. Бидејќи се користеше за филтрирање на пакети, неговиот код се наоѓаше во потсистемот што обезбедува мрежни комуникации. Сепак, виртуелната машина eBPF повеќе не е врзана за моделот на податоци и може да се користи за која било намена. Значи, сега програмата eBPF може да се поврзе со точка за следење или kprobe. Ова го отвора патот до инструментацијата на eBPF, анализата на перформансите и многу други случаи на употреба во контекст на други потсистеми на кернелот. Сега кодот eBPF се наоѓа на сопствената патека: кернел/bpf.
• Глобални складишта за податоци наречени „Карти“. Мапите се складишта со клучни вредности кои овозможуваат размена на податоци помеѓу корисничкиот простор и просторот на јадрото. eBPF обезбедува неколку видови на мапи.
• Секундарни функции. Особено, за да се преработи пакет, пресметајте контролна сума или клонирајте пакет. Овие функции работат во кернелот и не се програми за кориснички простор. Можете исто така да остварувате системски повици од програмите eBPF.
• Заврши повици. Големината на програмата во eBPF е ограничена на 4096 бајти. Функцијата за опасен повик овозможува програма eBPF да ја пренесе контролата на нова програма eBPF и на тој начин да го заобиколи ова ограничување (на овој начин може да се поврзат до 32 програми).

eBPF: пример

Постојат неколку примери за eBPF во изворите на кернелот на Линукс. Тие се достапни на примероци/bpf/. За да ги соберете овие примери, едноставно внесете:

$ sudo make samples/bpf/

Јас самиот нема да напишам нов пример за eBPF, туку ќе користам еден од примероците достапни во примероци/bpf/. Ќе погледнам некои делови од кодот и ќе објаснам како функционира. Како пример, ја избрав програмата tracex4.

Генерално, секој од примерите во примероци/bpf/ се состои од две датотеки. Во овој случај:

• tracex4_kern.c, го содржи изворниот код што треба да се изврши во јадрото како eBPF бајтекод.
• tracex4_user.c, содржи програма од кориснички простор.

Во овој случај, треба да се составиме tracex4_kern.c до eBPF бајтекод. Во моментов во gcc нема заднински за eBPF. За среќа, clang може да емитува eBPF бајтекод. Makefile користи clang за компилација tracex4_kern.c до објектната датотека.

Погоре спомнав дека една од најинтересните карактеристики на eBPF се мапите. tracex4_kern дефинира една карта:

struct pair {
    u64 val;
    u64 ip;
};  

struct bpf_map_def SEC("maps") my_map = {
    .type = BPF_MAP_TYPE_HASH,
    .key_size = sizeof(long),
    .value_size = sizeof(struct pair),
    .max_entries = 1000000,
};

BPF_MAP_TYPE_HASH е еден од многуте видови картички што ги нуди eBPF. Во овој случај, тоа е само хаш. Можеби сте забележале и оглас SEC("maps"). SEC е макро што се користи за создавање нов дел од бинарна датотека. Всушност, во примерот tracex4_kern дефинирани се уште два дела:

SEC("kprobe/kmem_cache_free")
int bpf_prog1(struct pt_regs *ctx)
{   
    long ptr = PT_REGS_PARM2(ctx);

    bpf_map_delete_elem(&my_map, &ptr); 
    return 0;
}
    
SEC("kretprobe/kmem_cache_alloc_node") 
int bpf_prog2(struct pt_regs *ctx)
{
    long ptr = PT_REGS_RC(ctx);
    long ip = 0;

    // получаем ip-адрес вызывающей стороны kmem_cache_alloc_node() 
    BPF_KRETPROBE_READ_RET_IP(ip, ctx);

    struct pair v = {
        .val = bpf_ktime_get_ns(),
        .ip = ip,
    };
    
    bpf_map_update_elem(&my_map, &ptr, &v, BPF_ANY);
    return 0;
}   

Овие две функции ви дозволуваат да избришете запис од картата (kprobe/kmem_cache_free) и додадете нов запис на картата (kretprobe/kmem_cache_alloc_node). Сите имиња на функции напишани со големи букви одговараат на макроа дефинирани во bpf_helpers.h.

Ако ги исфрлам деловите од објектната датотека, треба да видам дека овие нови делови се веќе дефинирани:

$ objdump -h tracex4_kern.o

tracex4_kern.o: file format elf64-little

Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00000000 0000000000000000 0000000000000000 00000040 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 kprobe/kmem_cache_free 00000048 0000000000000000 0000000000000000 00000040 2**3
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
2 kretprobe/kmem_cache_alloc_node 000000c0 0000000000000000 0000000000000000 00000088 2**3
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
3 maps 0000001c 0000000000000000 0000000000000000 00000148 2**2
CONTENTS, ALLOC, LOAD, DATA
4 license 00000004 0000000000000000 0000000000000000 00000164 2**0
CONTENTS, ALLOC, LOAD, DATA
5 version 00000004 0000000000000000 0000000000000000 00000168 2**2
CONTENTS, ALLOC, LOAD, DATA
6 .eh_frame 00000050 0000000000000000 0000000000000000 00000170 2**3
CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA

Исто така постои tracex4_user.c, главна програма. Во основа, оваа програма слуша настани kmem_cache_alloc_node. Кога ќе се случи таков настан, се извршува соодветниот eBPF код. Кодот го зачувува IP атрибутот на објектот во мапа, а објектот потоа се врти низ главната програма. Пример:

$ sudo ./tracex4
obj 0xffff8d6430f60a00 is 2sec old was allocated at ip ffffffff9891ad90
obj 0xffff8d6062ca5e00 is 23sec old was allocated at ip ffffffff98090e8f
obj 0xffff8d5f80161780 is 6sec old was allocated at ip ffffffff98090e8f

Како се поврзани програма за кориснички простор и програма eBPF? На иницијализација tracex4_user.c вчитува објект-датотека tracex4_kern.o користејќи ја функцијата load_bpf_file.

int main(int ac, char **argv)
{
    struct rlimit r = {RLIM_INFINITY, RLIM_INFINITY};
    char filename[256];
    int i;

    snprintf(filename, sizeof(filename), "%s_kern.o", argv[0]);

    if (setrlimit(RLIMIT_MEMLOCK, &r)) {
        perror("setrlimit(RLIMIT_MEMLOCK, RLIM_INFINITY)");
        return 1;
    }

    if (load_bpf_file(filename)) {
        printf("%s", bpf_log_buf);
        return 1;
    }

    for (i = 0; ; i++) {
        print_old_objects(map_fd[1]);
        sleep(1);
    }

    return 0;
}

Со правење load_bpf_file се додаваат сонди дефинирани во датотеката eBPF /sys/kernel/debug/tracing/kprobe_events. Сега ги слушаме овие настани и нашата програма може да направи нешто кога ќе се случат.

$ sudo cat /sys/kernel/debug/tracing/kprobe_events
p:kprobes/kmem_cache_free kmem_cache_free
r:kprobes/kmem_cache_alloc_node kmem_cache_alloc_node

Сите други програми во примерокот/bpf/ се структурирани слично. Тие секогаш содржат две датотеки:

• XXX_kern.c: програма eBPF.
• XXX_user.c: главна програма.

Програмата eBPF ги идентификува мапите и функциите поврзани со дел. Кога кернелот издава настан од одреден тип (на пример, tracepoint), се извршуваат врзаните функции. Картичките обезбедуваат комуникација помеѓу програмата на јадрото и програмата за кориснички простор.

Заклучок

Оваа статија ги дискутираше BPF и eBPF во општи термини. Знам дека денес има многу информации и ресурси за eBPF, па затоа ќе препорачам уште неколку ресурси за понатамошно проучување

Препорачувам да прочитате:

• BPF: универзална виртуелна машина во кернелот Џонатан Корбет. Вовед во BPF и како тој еволуираше во eBPF.
• Темелен вовед во eBPF Брендан Грег. Статија од LWN.net. Брендан често твита за eBPF и одржува листа на ресурси на темата на неговата блог пост.
• Белешки за BPF и eBPF Џулија Еванс. Коментари на презентацијата на Сушакра Шарма „Филтерот за пакети BSD: Нова архитектура за фаќање пакети на ниво на корисник“. Коментарите се добри и навистина ви помагаат да ги разберете слајдовите.
• eBPF, дел 1: Минатото, сегашноста и иднината Ферис Елис. Долго време со продолжение, но вреди да се прочита. Една од најдобрите написи што сум ги сретнал на eBPF.

Извор: www.habr.com