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

Хей Хабр! Информираме ви, че подготвяме издаването на книга "Наблюдаемост на Linux с BPF".

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

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

Чрез прехвърляне на пълния контрол на мрежовата карта към програма за потребителско пространство, ние намаляваме режийните разходи, причинени от ядрото (превключване на контекста, обработка на мрежовия слой, прекъсвания и т.н.), което е много важно при работа със скорости от 10Gb/s или по-висок. Заобикаляне на ядрото плюс комбинация от други функции (пакетна обработка) и внимателна настройка на производителността (NUMA счетоводство, Изолация на процесора, и т.н.) отговарят на основите на високопроизводителната мрежа в потребителското пространство. Може би примерен пример за този нов подход към обработката на пакети е DPDK от Intel (Комплект за разработка на Data Plane), въпреки че има други добре известни инструменти и техники, включително VPP от Cisco (Vector Packet Processing), Netmap и, разбира се, хапам.

Организацията на мрежовите взаимодействия в потребителското пространство има редица недостатъци:

• Ядрото на ОС е абстракционен слой за хардуерни ресурси. Тъй като програмите за потребителско пространство трябва да управляват своите ресурси директно, те също трябва да управляват собствения си хардуер. Това често означава програмиране на вашите собствени драйвери.
• Тъй като напълно се отказваме от пространството на ядрото, ние се отказваме и от цялата мрежова функционалност, предоставена от ядрото. Програмите за потребителско пространство трябва да внедрят отново функции, които може вече да са предоставени от ядрото или операционната система.
• Програмите работят в режим sandbox, което сериозно ограничава тяхното взаимодействие и им пречи да се интегрират с други части на операционната система.

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

BPF и eBPF

Въпреки не съвсем ясното име, BPF (Packet Filtering, Berkeley) всъщност е модел на виртуална машина. Тази виртуална машина първоначално е проектирана да обработва филтриране на пакети, откъдето идва и името.

Един от най-известните инструменти, използващи 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 съответства на ethertype на пакета.
• Инструкция (001): сравнява стойността в акумулатора с 0x86dd, т.е. със стойността на ethertype за IPv6. Ако резултатът е верен, тогава програмният брояч отива към инструкция (002), а ако не, тогава към (006).
• Инструкция (006): сравнява стойността с 0x800 (стойност на ethertype за IPv4). Ако отговорът е верен, тогава програмата отива на (007), ако не, тогава на (015).

И така нататък, докато програмата за филтриране на пакети върне резултат. Обикновено е булево. Връщането на ненулева стойност (инструкция (014)) означава, че пакетът е съвпаднал, а връщането на нула (инструкция (015)) означава, че пакетът не е съвпаднал.

Виртуалната машина BPF и нейният байт код бяха предложени от Стив Маккан и Ван Джейкъбсън в края на 1992 г., когато излезе тяхната статия. BSD пакетен филтър: Нова архитектура за улавяне на пакети на ниво потребител, за първи път тази технология беше представена на конференцията на Usenix през зимата на 1993 г.

Тъй като BPF е виртуална машина, той определя средата, в която се изпълняват програмите. В допълнение към байт кода, той също така дефинира модел на памет за пакети (инструкциите за зареждане се прилагат имплицитно към пакет), регистри (A и X; акумулаторни и индексни регистри), памет за памет и скрит програмен брояч. Интересното е, че байт кодът на BPF е моделиран след Motorola 6502 ISA. Както Стив Маккан си спомня в своя пленарен доклад на Sharkfest '11 той беше запознат с компилация 6502 от гимназията, когато програмираше на Apple II, и това знание повлия на работата му по проектиране на байт кода на BPF.

Поддръжката на BPF е внедрена в ядрото на Linux във версия v2.5 и по-нова, добавена главно от Jay Schullist. BPF кодът остана непроменен до 2011 г., когато Ерик Дюмасет преработи BPF интерпретатора, за да работи в JIT режим (Източник: JIT за пакетни филтри). След това, вместо да интерпретира байт кода на BPF, ядрото може директно да конвертира BPF програми в целевата архитектура: x86, ARM, MIPS и т.н.

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

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

• Разчита на модерни 64-битови архитектури. eBPF използва 64-битови регистри и увеличава броя на наличните регистри от 2 (акумулатор и X) на 10. eBPF предоставя и допълнителни кодове за операции (BPF_MOV, BPF_JNE, BPF_CALL…).
• Отделен от подсистемата на мрежовия слой. BPF беше свързан с модела на партидните данни. Тъй като беше използван за филтриране на пакети, неговият код беше в подсистемата, която осигуряваше мрежови взаимодействия. Виртуалната машина eBPF обаче вече не е обвързана с модел на данни и може да се използва за всякакви цели. И така, сега програмата eBPF може да бъде свързана към tracepoint или kprobe. Това отваря вратата към eBPF инструменти, анализ на производителността и много други случаи на употреба в контекста на други подсистеми на ядрото. Сега кодът на eBPF се намира в собствен път: kernel/bpf.
• Глобални хранилища за данни, наречени Карти. Картите са хранилища на ключ-стойност, които осигуряват обмен на данни между потребителското пространство и пространството на ядрото. eBPF предоставя няколко вида карти.
• Вторични функции. По-специално, за презаписване на пакет, изчисляване на контролна сума или клониране на пакет. Тези функции се изпълняват вътре в ядрото и не принадлежат към програмите в потребителското пространство. В допълнение, системни повиквания могат да се правят от програми на eBPF.
• Край на разговорите. Размерът на програмата в eBPF е ограничен до 4096 байта. Функцията за край на повикване позволява на eBPF програма да прехвърли управлението на нова eBPF програма и по този начин да заобиколи това ограничение (до 32 програми могат да бъдат свързани по този начин).

пример за eBPF

Има няколко примера за eBPF в изходните кодове на ядрото на Linux. Налични са на samples/bpf/. За да компилирате тези примери, просто напишете:

$ sudo make samples/bpf/

Няма да пиша сам нов пример за eBPF, а ще използвам един от примерите, налични в samples/bpf/. Ще разгледам някои части от кода и ще обясня как работи. Като пример избрах програмата tracex4.

Като цяло всеки от примерите в samples/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

Всички други програми в sample/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: Минало, настояще и бъдеще Ферис Елис. Longread с продължениено си струва да се прочете. Една от най-добрите статии за eBPF, на които съм попадал.

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