BPF за најмалите, дел нула: класичен BPF

Беркли пакетни филтри (BPF) е технологија на кернелот на Линукс која е на насловните страници на технолошките публикации на англиски јазик веќе неколку години. Конференциите се полни со извештаи за употребата и развојот на BPF. Дејвид Милер, одржувач на мрежен потсистем Линукс, го повикува својот говор на Linux Plumbers 2018 „Овој разговор не е за XDP“ (XDP е еден случај за употреба за BPF). Брендан Грег дава говори со наслов Линукс BPF суперсили. Токе Хојланд-Јоргенсен се смеедека јадрото сега е микрокернел. Томас Граф ја промовира идејата дека BPF е javascript за кернелот.

Сè уште нема систематски опис на BPF на Habré, и затоа во серија написи ќе се обидам да зборувам за историјата на технологијата, да ја опишам архитектурата и алатките за развој и да ги наведам областите на примена и практика на користење на BPF. Оваа статија, нула, во серијата, ја раскажува историјата и архитектурата на класичниот BPF, а исто така ги открива тајните на неговите принципи на работа. tcpdump, seccomp, strace, и уште повеќе.

Развојот на BPF е контролиран од мрежна заедница на Linux, главните постоечки апликации на BPF се поврзани со мрежи и затоа, со дозвола @eucariot, ја нареков серијата „БПФ за најмалите“, во чест на одличната серија „Мрежи за најмалите“.

Краток курс во историјата на BPF (c)

Модерната BPF технологија е подобрена и проширена верзија на старата технологија со истото име, сега наречена класична BPF за да се избегне забуна. Беше создадена добро позната алатка врз основа на класичниот BPF tcpdump, механизам seccomp, како и помалку познати модули xt_bpf за iptables и класификатор cls_bpf. Во современиот Linux, класичните BPF програми автоматски се преведуваат во новата форма, меѓутоа, од корисничка гледна точка, API остана на место и нови употреби за класичниот BPF, како што ќе видиме во оваа статија, сè уште се наоѓаат. Поради оваа причина, а исто така и затоа што следејќи ја историјата на развојот на класичниот BPF во Linux, ќе стане појасно како и зошто еволуирал во неговата модерна форма, решив да започнам со статија за класичниот BPF.

Кон крајот на осумдесеттите години на минатиот век, инженерите од познатата лабораторија Лоренс Беркли се заинтересираа за прашањето како правилно да се филтрираат мрежните пакети на хардвер кој беше модерен во доцните осумдесетти години на минатиот век. Основната идеја за филтрирање, првично имплементирана во технологијата CSPF (CMU/Stanford Packet Filter), беше да се филтрираат непотребните пакети што е можно порано, т.е. во просторот на јадрото, бидејќи со тоа се избегнува копирање на непотребни податоци во корисничкиот простор. За да се обезбеди безбедност за време на траење за извршување на кориснички код во просторот на јадрото, се користеше виртуелна машина со песок.

Сепак, виртуелните машини за постоечките филтри беа дизајнирани да работат на машини базирани на оџак и не работеа толку ефикасно на поновите RISC машини. Како резултат на тоа, преку напорите на инженерите од Berkeley Labs, беше развиена нова технологија BPF (Berkeley Packet Filters), чија архитектура на виртуелната машина беше дизајнирана врз основа на процесорот Motorola 6502 - работниот коњ на такви добро познати производи како што се Apple II или НСВ. Новата виртуелна машина ги зголеми перформансите на филтерот десетици пати во споредба со постоечките решенија.

Архитектура на машината BPF

Со архитектурата ќе се запознаеме на работен начин, анализирајќи примери. Сепак, за почеток, да речеме дека машината имаше два 32-битни регистри достапни за корисникот, акумулатор A и индексен регистар X, 64 бајти меморија (16 зборови), достапни за пишување и последователно читање и мал систем на команди за работа со овие објекти. Инструкциите за прескокнување за имплементација на условни изрази беа исто така достапни во програмите, но за да се гарантира навремено завршување на програмата, скоковите можеа да се направат само напред, односно, особено, беше забрането да се создаваат јамки.

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

Горенаведеното ќе ни биде доволно за да почнеме да гледаме примери: ќе се запознаеме со системот и форматот на командата по потреба. Ако сакате веднаш да го проучите командниот систем на виртуелната машина и да дознаете за сите негови способности, тогаш можете да ја прочитате оригиналната статија Филтер за пакети BSD и/или првата половина од датотеката Документација/вмрежување/филтер.txt од документацијата на јадрото. Покрај тоа, можете да ја проучувате презентацијата libpcap: Архитектура и методологија за оптимизација за фаќање пакети, во која McCanne, еден од авторите на BPF, зборува за историјата на создавањето libpcap.

Сега продолжуваме да ги разгледуваме сите значајни примери за користење на класичен BPF на Linux: tcpdump (libpcap), секкомп, xt_bpf, cls_bpf.

tcpdump

Развојот на BPF беше спроведен паралелно со развојот на предниот дел за филтрирање пакети - добро позната алатка tcpdump. И, бидејќи ова е најстариот и најпознатиот пример за користење на класичен BPF, достапен на многу оперативни системи, ќе започнеме со проучување на технологијата со него.

(Ги истрчав сите примери во оваа статија на Linux 5.6.0-rc6. Излезот на некои команди е уреден за подобра читливост.)

Пример: набљудување на IPv6 пакети

Да замислиме дека сакаме да ги погледнеме сите IPv6 пакети на интерфејс eth0. За да го направите ова, можеме да ја извршиме програмата tcpdump со едноставен филтер ip6:

$ sudo tcpdump -i eth0 ip6

Во овој случај, tcpdump го составува филтерот ip6 во бајтекодот на архитектурата BPF и испратете го до кернелот (видете детали во делот Tcpdump: се вчитува). Вчитаниот филтер ќе се активира за секој пакет што минува низ интерфејсот eth0. Ако филтерот врати вредност што не е нула n, потоа до n бајти од пакетот ќе бидат копирани во корисничкиот простор и ќе го видиме на излезот tcpdump.

Излегува дека лесно можеме да откриеме кој бајтекод е испратен до кернелот tcpdump со помош на tcpdump, ако го извршиме со опцијата -d:

$ sudo tcpdump -i eth0 -d ip6
(000) ldh      [12]
(001) jeq      #0x86dd          jt 2    jf 3
(002) ret      #262144
(003) ret      #0

На линијата нула ја извршуваме командата ldh [12], што значи „вчитување во регистарот A половина збор (16 бита) лоциран на адреса 12“ и единственото прашање е на каква меморија се обраќаме? Одговорот е дека во x започнува (x+1)ти бајт од анализираниот мрежен пакет. Читаме пакети од етернет интерфејсот eth0, и ова значидека пакетот изгледа вака (за едноставност, претпоставуваме дека нема VLAN ознаки во пакетот):

       6              6          2
|Destination MAC|Source MAC|Ether Type|...|

Значи по извршувањето на командата ldh [12] во регистарот A ќе има нива Ether Type — типот на пакетот што се пренесува во оваа етернет рамка. На линија 1 ја споредуваме содржината на регистарот A (тип на пакет) в 0x86dd, и ова и имаат Типот за кој не интересира е IPv6. На линија 1, покрај командата за споредба, има уште две колони - jt 2 и jf 3 — ознаки до кои треба да отидете ако споредбата е успешна (A == 0x86dd) и неуспешни. Значи, во успешен случај (IPv6) одиме на линија 2, а во неуспешен случај - на линија 3. На линијата 3 програмата завршува со кодот 0 (не го копирај пакетот), на линијата 2 програмата завршува со кодот 262144 (копирај ми пакет од максимум 256 килобајти).

Покомплициран пример: ги разгледуваме TCP пакетите по дестинација порта

Ајде да видиме како изгледа филтерот што ги копира сите TCP пакети со одредишната порта 666. Ќе го разгледаме случајот IPv4, бидејќи случајот IPv6 е поедноставен. Откако ќе го проучите овој пример, можете сами да го истражите филтерот IPv6 како вежба (ip6 and tcp dst port 666) и филтер за општиот случај (tcp dst port 666). Значи, филтерот за кој сме заинтересирани изгледа вака:

$ sudo tcpdump -i eth0 -d ip and tcp dst port 666
(000) ldh      [12]
(001) jeq      #0x800           jt 2    jf 10
(002) ldb      [23]
(003) jeq      #0x6             jt 4    jf 10
(004) ldh      [20]
(005) jset     #0x1fff          jt 10   jf 6
(006) ldxb     4*([14]&0xf)
(007) ldh      [x + 16]
(008) jeq      #0x29a           jt 9    jf 10
(009) ret      #262144
(010) ret      #0

Веќе знаеме што прават линиите 0 и 1. На линијата 2 веќе проверивме дали ова е IPv4 пакет (Тип на етер = 0x800) и вчитајте го во регистарот A 24-ти бајт од пакетот. Нашиот пакет изгледа како

       14            8      1     1
|ethernet header|ip fields|ttl|protocol|...|

што значи дека вчитуваме во регистарот A полето Protocol на IP заглавието, што е логично, бидејќи сакаме да копираме само TCP пакети. Ние го споредуваме Протоколот со 0x6 (IPPROTO_TCP) на линија 3.

На линиите 4 и 5 ги вчитуваме полузборовите лоцирани на адресата 20 и ја користиме командата jset проверете дали е поставено едно од трите знамиња - издадена носење маска jset се бришат трите најзначајни бита. Два од трите бита ни кажуваат дали пакетот е дел од фрагментиран IP пакет, и ако е така, дали е последниот фрагмент. Третиот бит е резервиран и мора да биде нула. Не сакаме да проверуваме ниту нецелосни или скршени пакети, па затоа ги проверуваме сите три бита.

Линијата 6 е најинтересна во оваа листа. Изразување ldxb 4*([14]&0xf) значи дека вчитуваме во регистарот X најмалку значајните четири бита од петнаесеттиот бајт од пакетот помножени со 4. Најмалку значајните четири бита од петнаесеттиот бајт е полето Должина на заглавието на Интернет Заглавие IPv4, кое ја складира должината на заглавието со зборови, па потоа треба да се помножите со 4. Интересно, изразот 4*([14]&0xf) е ознака за специјална адресна шема која може да се користи само во оваа форма и само за регистар X, т.е. не можеме ни да кажеме ldb 4*([14]&0xf) ниту пак ldxb 5*([14]&0xf) (можеме само да наведеме различно поместување, на пример, ldxb 4*([16]&0xf)). Јасно е дека оваа шема за адресирање е додадена на BPF токму со цел да се добие X (индексен регистар) Должина на заглавието IPv4.

Така, на линијата 7 се обидуваме да вчитаме половина збор на (X+16). Запомнувајќи дека 14 бајти се окупирани од заглавието на Етернет, и X ја содржи должината на заглавието IPv4, ние разбираме дека во A Одредишната порта TCP е вчитана:

       14           X           2             2
|ethernet header|ip header|source port|destination port|

Конечно, на линијата 8 ја споредуваме дестинациската порта со саканата вредност и на линиите 9 или 10 го враќаме резултатот - дали да се копира пакетот или не.

Tcpdump: се вчитува

Во претходните примери, ние конкретно не зборувавме детално за тоа како точно го вчитуваме BPF бајтекодот во кернелот за филтрирање на пакети. Општо земено, tcpdump пренесен на многу системи и за работа со филтри tcpdump ја користи библиотеката libpcap. Накратко, да поставите филтер на интерфејс користејќи libpcap, треба да го направите следново:

• креирајте дескриптор на типот pcap_t од името на интерфејсот: pcap_create,
• активирај интерфејс: pcap_activate,
• компајлира филтер: pcap_compile,
• филтер за поврзување: pcap_setfilter.

За да видите како функционира pcap_setfilter имплементиран во Linux, ние користиме strace (некои линии се отстранети):

$ sudo strace -f -e trace=%network tcpdump -p -i eth0 ip
socket(AF_PACKET, SOCK_RAW, 768)        = 3
bind(3, {sa_family=AF_PACKET, sll_protocol=htons(ETH_P_ALL), sll_ifindex=if_nametoindex("eth0"), sll_hatype=ARPHRD_NETROM, sll_pkttype=PACKET_HOST, sll_halen=0}, 20) = 0
setsockopt(3, SOL_SOCKET, SO_ATTACH_FILTER, {len=4, filter=0xb00bb00bb00b}, 16) = 0
...

На првите две линии на излез што ги создаваме суров штекер да ги прочитате сите Ethernet рамки и да го поврзете со интерфејсот eth0. Од нашиот прв пример знаеме дека филтерот ip ќе се состои од четири BPF инструкции, а на третата линија гледаме како се користи опцијата SO_ATTACH_FILTER системски повик setsockopt вчитуваме и поврзуваме филтер со должина 4. Ова е нашиот филтер.

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

Скриена вистина

Малку поцелосна верзија на излезот изгледа вака:

$ sudo strace -f -e trace=%network tcpdump -p -i eth0 ip
socket(AF_PACKET, SOCK_RAW, 768)        = 3
bind(3, {sa_family=AF_PACKET, sll_protocol=htons(ETH_P_ALL), sll_ifindex=if_nametoindex("eth0"), sll_hatype=ARPHRD_NETROM, sll_pkttype=PACKET_HOST, sll_halen=0}, 20) = 0
setsockopt(3, SOL_SOCKET, SO_ATTACH_FILTER, {len=1, filter=0xbeefbeefbeef}, 16) = 0
recvfrom(3, 0x7ffcad394257, 1, MSG_TRUNC, NULL, NULL) = -1 EAGAIN (Resource temporarily unavailable)
setsockopt(3, SOL_SOCKET, SO_ATTACH_FILTER, {len=4, filter=0xb00bb00bb00b}, 16) = 0
...

Како што споменавме погоре, го вчитуваме и го поврзуваме нашиот филтер со штекерот на линијата 5, но што се случува на линиите 3 и 4? Излегува дека ова libpcap се грижи за нас - така што излезот од нашиот филтер не вклучува пакети што не го задоволуваат, библиотеката поврзува кукла филтер ret #0 (отфрли ги сите пакети), го префрла штекерот во режим на неблокирање и се обидува да ги одземе сите пакети што би можеле да останат од претходните филтри.

Севкупно, за да ги филтрирате пакетите на Linux користејќи класичен BPF, треба да имате филтер во форма на структура како struct sock_fprog и отворен штекер, по што филтерот може да се прикачи на штекерот користејќи системски повик setsockopt.

Интересно е што филтерот може да се прикачи на кој било штекер, а не само суров. Еве пример програма која ги отсекува сите освен првите два бајта од сите дојдовни UDP датаграми. (Додадов коментари во кодот за да не ја натрупувам статијата.)

Повеќе детали за употребата setsockopt за поврзување на филтри, видете приклучок (7), но за пишување сопствени филтри како struct sock_fprog без помош tcpdump ќе разговараме во делот Програмирање на BPF со свои раце.

Класичен BPF и 21 век

BPF беше вклучен во Линукс во 1997 година и остана работна сила долго време libpcap без никакви посебни промени (промени специфични за Линукс, се разбира, беа, но тие не ја променија глобалната слика). Првите сериозни знаци дека BPF ќе еволуира се појавија во 2011 година, кога Ерик Думазе предложи лепенка, кој додава Just In Time Compiler во кернелот - преведувач за конвертирање на BPF бајтекод во мајчин x86_64 код.

JIT компајлерот беше првиот во синџирот на промени: во 2012 година се појави способност за пишување филтри за секкомп, користејќи BPF, во јануари 2013 година имаше додаде модул xt_bpf, кој ви овозможува да пишувате правила за iptables со помош на БПФ, а во октомври 2013 година беше додаде исто така модул cls_bpf, кој ви овозможува да пишувате класификатори на сообраќај користејќи BPF.

Наскоро ќе ги разгледаме сите овие примери подетално, но прво ќе ни биде корисно да научиме како да пишуваме и составуваме произволни програми за BPF, бидејќи можностите што ги нуди библиотеката libpcap ограничен (едноставен пример: генериран филтер libpcap може да врати само две вредности - 0 или 0x40000) или генерално, како во случајот со seccomp, не се применливи.

Програмирање на BPF со свои раце

Ајде да се запознаеме со бинарниот формат на инструкциите BPF, тоа е многу едноставно:

   16    8    8     32
| code | jt | jf |  k  |

Секоја инструкција зафаќа 64 бита, во кои првите 16 бита се инструкцискиот код, а потоа има две осум-битни алинеја, jt и jf, и 32 бита за аргументот K, чија цел варира од команда до команда. На пример, командата ret, кој ја прекинува програмата го има кодот 6, а повратната вредност се зема од константата K. Во C, една BPF инструкција е претставена како структура

struct sock_filter {
        __u16   code;
        __u8    jt;
        __u8    jf;
        __u32   k;
}

а целата програма е во форма на структура

struct sock_fprog {
        unsigned short len;
        struct sock_filter *filter;
}

Така, веќе можеме да пишуваме програми (на пример, ги знаеме кодовите за инструкции од [1]). Вака ќе изгледа филтерот ip6 на нашиот прв пример:

struct sock_filter code[] = {
        { 0x28, 0, 0, 0x0000000c },
        { 0x15, 0, 1, 0x000086dd },
        { 0x06, 0, 0, 0x00040000 },
        { 0x06, 0, 0, 0x00000000 },
};
struct sock_fprog prog = {
        .len = ARRAY_SIZE(code),
        .filter = code,
};

програма prog законски можеме да користиме во повик

setsockopt(sk, SOL_SOCKET, SO_ATTACH_FILTER, &prog, sizeof(prog))

Пишувањето програми во форма на машински кодови не е многу погодно, но понекогаш е неопходно (на пример, за дебагирање, создавање тестови за единици, пишување написи на Хабре итн.). За погодност, во датотеката <linux/filter.h> се дефинирани помошни макроа - истиот пример како погоре може да се преработи како

struct sock_filter code[] = {
        BPF_STMT(BPF_LD|BPF_H|BPF_ABS, 12),
        BPF_JUMP(BPF_JMP|BPF_JEQ|BPF_K, ETH_P_IPV6, 0, 1),
        BPF_STMT(BPF_RET|BPF_K, 0x00040000),
        BPF_STMT(BPF_RET|BPF_K, 0),
}

Сепак, оваа опција не е многу погодна. Ова е она што програмерите на кернелот на Линукс го образложија, а со тоа и во директориумот tools/bpf кернели можете да најдете асемблер и дебагер за работа со класичен BPF.

Јазикот на собранието е многу сличен на излезот за отстранување грешки tcpdump, но дополнително можеме да наведеме симболични ознаки. На пример, тука е програма што ги испушта сите пакети освен TCP/IPv4:

$ cat /tmp/tcp-over-ipv4.bpf
ldh [12]
jne #0x800, drop
ldb [23]
jneq #6, drop
ret #-1
drop: ret #0

Стандардно, асемблерот генерира код во формат <количество инструкций>,<code1> <jt1> <jf1> <k1>,..., на нашиот пример со TCP ќе биде

$ tools/bpf/bpf_asm /tmp/tcp-over-ipv4.bpf
6,40 0 0 12,21 0 3 2048,48 0 0 23,21 0 1 6,6 0 0 4294967295,6 0 0 0,

За погодност на програмерите C, може да се користи различен излезен формат:

$ tools/bpf/bpf_asm -c /tmp/tcp-over-ipv4.bpf
{ 0x28,  0,  0, 0x0000000c },
{ 0x15,  0,  3, 0x00000800 },
{ 0x30,  0,  0, 0x00000017 },
{ 0x15,  0,  1, 0x00000006 },
{ 0x06,  0,  0, 0xffffffff },
{ 0x06,  0,  0, 0000000000 },

Овој текст може да се копира во дефиницијата на структурата на типот struct sock_filter, како што направивме на почетокот на овој дел.

Линукс и netsniff-ng екстензии

Покрај стандардните BPF, Linux и tools/bpf/bpf_asm поддршка и нестандарден сет. Во основа, инструкциите се користат за пристап до полињата на структурата struct sk_buff, кој опишува мрежен пакет во кернелот. Сепак, постојат и други видови помошни инструкции, на пример ldw cpu ќе се вчита во регистарот A резултат на извршување на функцијата на јадрото raw_smp_processor_id(). (Во новата верзија на BPF, овие нестандардни екстензии се проширени за да обезбедат програми со збир на помошници на кернелот за пристап до меморија, структури и генерирање настани.) Еве интересен пример на филтер во кој ги копираме само Заглавија на пакети во корисничкиот простор користејќи ја наставката poff, офсет на носивост:

ld poff
ret a

BPF екстензии не може да се користат во tcpdump, но ова е добра причина да се запознаете со комуналниот пакет netsniff-ng, кој меѓу другото содржи и напредна програма netsniff-ng, кој, покрај филтрирањето со помош на BPF, содржи и ефикасен генератор на сообраќај и понапреден од tools/bpf/bpf_asm, повика асемблерот на BPF bpfc. Пакетот содржи доста детална документација, видете ги и врските на крајот од статијата.

секкомп

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

Првата верзија на seccomp беше додадена во кернелот во 2005 година и не беше многу популарна, бидејќи обезбедуваше само една опција - да се ограничи множеството системски повици достапни за процес на следново: read, write, exit и sigreturn, а процесот што ги прекрши правилата беше убиен користејќи SIGKILL. Сепак, во 2012 година, seccomp додаде можност за користење на BPF филтри, овозможувајќи ви да дефинирате збир на дозволени системски повици, па дури и да извршите проверки на нивните аргументи. (Интересно е што Chrome беше еден од првите корисници на оваа функционалност, а луѓето од Chrome во моментов развиваат механизам KRSI заснован на нова верзија на BPF и дозволуваат прилагодување на безбедносните модули на Linux.) Врски до дополнителна документација може да се најдат на крајот на статијата.

Забележете дека веќе има написи на центарот за користење на seccomp, можеби некој ќе сака да ги прочита пред (или наместо) да ги прочита следните подсекции. Во статијата Контејнери и безбедност: seccomp дава примери за користење на seccomp, и верзијата од 2007 година и верзијата што користи BPF (филтрите се генерираат со употреба на libseccomp), зборува за поврзувањето на seccomp со Docker, а исто така обезбедува многу корисни врски. Во статијата Изолирање на демони со systemd или „не ти треба Docker за ова!“ Тоа опфаќа, особено, како да додадете црни листи или бели листи на системски повици за демони кои работат на системот.

Следно ќе видиме како да пишуваме и вчитаме филтри за seccomp во голо C и користење на библиотеката libseccomp и кои се добрите и лошите страни на секоја опција, и конечно, да видиме како се користи seccomp од програмата strace.

Филтри за пишување и вчитување за seccomp

Ние веќе знаеме како да пишуваме BPF програми, па ајде прво да го погледнеме програмскиот интерфејс seccomp. Може да поставите филтер на ниво на процес и сите детски процеси ќе ги наследат ограничувањата. Ова се прави со помош на системски повик seccomp(2):

seccomp(SECCOMP_SET_MODE_FILTER, flags, &filter)

каде што &filter - ова е покажувач на структура која веќе ни е позната struct sock_fprog, т.е. BPF програма.

Како програмите за seccomp се разликуваат од програмите за сокети? Пренесен контекст. Во случај на сокети, ни беше дадена мемориска област што го содржи пакетот, а во случајот на seccomp ни беше дадена структура како

struct seccomp_data {
    int   nr;
    __u32 arch;
    __u64 instruction_pointer;
    __u64 args[6];
};

Тука nr е бројот на системскиот повик што треба да се активира, arch - актуелна архитектура (повеќе за ова подолу), args - до шест аргументи за системски повик и instruction_pointer е покажувач на инструкцијата за кориснички простор што го направи системскиот повик. Така, на пример, да го вчитате бројот на системскиот повик во регистарот A мораме да кажеме

ldw [0]

Постојат и други функции за seccomp програмите, на пример, до контекстот може да се пристапи само со 32-битно порамнување и не можете да вчитате половина збор или бајт - кога се обидувате да вчитате филтер ldh [0] системски повик seccomp ќе се врати EINVAL. Функцијата ги проверува вчитаните филтри seccomp_check_filter() кернели. (Смешна работа е што во оригиналниот commit што ја додаде функционалноста seccomp, тие заборавија да додадат дозвола за користење на инструкцијата на оваа функција mod (остаток од поделба) и сега е недостапен за seccomp BPF програмите, од неговото додавање ќе се скрши ABI.)

Во основа, ние веќе знаеме сè за пишување и читање на seccomp програми. Обично програмската логика е распоредена како бела или црна листа на системски повици, на пример програмата

ld [0]
jeq #304, bad
jeq #176, bad
jeq #239, bad
jeq #279, bad
good: ret #0x7fff0000 /* SECCOMP_RET_ALLOW */
bad: ret #0

проверува црна листа од четири системски повици нумерирани 304, 176, 239, 279. Кои се овие системски повици? Не можеме да кажеме со сигурност, бидејќи не знаеме за која архитектура е напишана програмата. Затоа, авторите на seccomp понуда стартувајте ги сите програми со проверка на архитектурата (тековната архитектура е означена во контекст како поле arch структурата struct seccomp_data). Со проверена архитектура, почетокот на примерот би изгледал вака:

ld [4]
jne #0xc000003e, bad_arch ; SCMP_ARCH_X86_64

а потоа нашите системски повик броеви ќе добијат одредени вредности.

Ние пишуваме и вчитуваме филтри за seccomp користење libseccomp

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

Ајде, на пример, да напишеме програма која работи бинарна датотека по избор на корисникот, откако претходно има инсталирано црна листа на системски повици од горната статија (програмата е поедноставена за поголема читливост, може да се најде целосната верзија тука):

#include <seccomp.h>
#include <unistd.h>
#include <err.h>

static int sys_numbers[] = {
        __NR_mount,
        __NR_umount2,
       // ... еще 40 системных вызовов ...
        __NR_vmsplice,
        __NR_perf_event_open,
};

int main(int argc, char **argv)
{
        scmp_filter_ctx ctx = seccomp_init(SCMP_ACT_ALLOW);

        for (size_t i = 0; i < sizeof(sys_numbers)/sizeof(sys_numbers[0]); i++)
                seccomp_rule_add(ctx, SCMP_ACT_TRAP, sys_numbers[i], 0);

        seccomp_load(ctx);

        execvp(argv[1], &argv[1]);
        err(1, "execlp: %s", argv[1]);
}

Прво дефинираме низа sys_numbers од 40+ броеви на системски повик за блокирање. Потоа, иницијализирајте го контекстот ctx и кажете ѝ на библиотеката што сакаме да дозволиме (SCMP_ACT_ALLOW) сите системски повици стандардно (полесно е да се градат црни листи). Потоа, еден по еден, ги додаваме сите системски повици од црната листа. Како одговор на системски повик од списокот, бараме SCMP_ACT_TRAP, во овој случај seccomp ќе испрати сигнал до процесот SIGSYS со опис кој системски повик ги прекршил правилата. Конечно, ја вчитуваме програмата во кернелот користејќи seccomp_load, кој ќе ја компајлира програмата и ќе ја прикачи на процесот користејќи системски повик seccomp(2).

За успешна компилација, програмата мора да биде поврзана со библиотеката libseccomp, на пример:

cc -std=c17 -Wall -Wextra -c -o seccomp_lib.o seccomp_lib.c
cc -o seccomp_lib seccomp_lib.o -lseccomp

Пример за успешно лансирање:

$ ./seccomp_lib echo ok
ok

Пример за блокиран системски повик:

$ sudo ./seccomp_lib mount -t bpf bpf /tmp
Bad system call

Ние користиме straceза детали:

$ sudo strace -e seccomp ./seccomp_lib mount -t bpf bpf /tmp
seccomp(SECCOMP_SET_MODE_FILTER, 0, {len=50, filter=0x55d8e78428e0}) = 0
--- SIGSYS {si_signo=SIGSYS, si_code=SYS_SECCOMP, si_call_addr=0xboobdeadbeef, si_syscall=__NR_mount, si_arch=AUDIT_ARCH_X86_64} ---
+++ killed by SIGSYS (core dumped) +++
Bad system call

како можеме да знаеме дека програмата е прекината поради употреба на нелегален системски повик mount(2).

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

Ако сакате да видите како функционираат бинарните филтри за пребарување, погледнете едноставна скрипта, кој генерира такви програми во асемблерот на BPF со бирање на броеви на системски повици, на пример:

$ echo 1 3 6 8 13 | ./generate_bin_search_bpf.py
ld [0]
jeq #6, bad
jgt #6, check8
jeq #1, bad
jeq #3, bad
ret #0x7fff0000
check8:
jeq #8, bad
jeq #13, bad
ret #0x7fff0000
bad: ret #0

Невозможно е да се напише нешто значително побрзо, бидејќи програмите BPF не можат да вршат скокови со вовлекување (не можеме да направиме, на пример, jmp A или jmp [label+X]) и затоа сите транзиции се статични.

seccomp и strace

Сите ја знаат корисноста strace е незаменлива алатка за проучување на однесувањето на процесите на Linux. Сепак, многумина слушнале и за проблеми со перформансите кога ја користите оваа алатка. Факт е дека strace имплементирани со користење ptrace(2), и во овој механизам не можеме да одредиме на кој сет системски повици треба да го запреме процесот, т.е., на пример, команди

$ time strace du /usr/share/ >/dev/null 2>&1

real    0m3.081s
user    0m0.531s
sys     0m2.073s

и

$ time strace -e open du /usr/share/ >/dev/null 2>&1

real    0m2.404s
user    0m0.193s
sys     0m1.800s

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

Нова опција --seccomp-bpf, додадена на strace верзија 5.3, ви овозможува да го забрзате процесот многу пати и времето на стартување под трагата на еден системски повик е веќе споредливо со времето на редовно стартување:

$ time strace --seccomp-bpf -e open du /usr/share/ >/dev/null 2>&1

real    0m0.148s
user    0m0.017s
sys     0m0.131s

$ time du /usr/share/ >/dev/null 2>&1

real    0m0.140s
user    0m0.024s
sys     0m0.116s

(Тука, се разбира, постои мала измама во тоа што не го следиме главниот системски повик на оваа команда. Ако следевме, на пример, newfsstat, Потоа strace би кочел исто толку силно како без --seccomp-bpf.)

Како функционира оваа опција? Без неа strace се поврзува со процесот и започнува да го користи PTRACE_SYSCALL. Кога управуваниот процес издава (било кој) системски повик, контролата се пренесува на strace, кој ги разгледува аргументите на системскиот повик и го извршува користејќи го PTRACE_SYSCALL. По некое време, процесот го комплетира системскиот повик и при излегување од него, контролата повторно се пренесува strace, кој ги гледа повратните вредности и го започнува процесот со користење PTRACE_SYSCALL, и така натаму.

Меѓутоа, со seccomp, овој процес може да се оптимизира токму онака како што би сакале. Имено, ако сакаме да гледаме само на системскиот повик X, тогаш можеме да напишеме BPF филтер што за X враќа вредност SECCOMP_RET_TRACE, и за повици кои не се од интерес за нас - SECCOMP_RET_ALLOW:

ld [0]
jneq #X, ignore
trace: ret #0x7ff00000
ignore: ret #0x7fff0000

Во овој случај strace првично го започнува процесот како PTRACE_CONT, нашиот филтер се обработува за секој системски повик, ако системскиот повик не е X, тогаш процесот продолжува да работи, но ако ова X, тогаш seccomp ќе ја пренесе контролата straceкој ќе ги погледне аргументите и ќе го започне процесот како PTRACE_SYSCALL (бидејќи seccomp нема можност да работи програма при излез од системски повик). Кога ќе се врати системскиот повик, strace ќе го рестартира процесот користејќи PTRACE_CONT и ќе чека нови пораки од seccomp.

При користење на опцијата --seccomp-bpf има две ограничувања. Прво, нема да биде можно да се приклучите на веќе постоечки процес (опција -p програми strace), бидејќи ова не е поддржано од seccomp. Второ, нема можност Нема погледнете ги детските процеси, бидејќи филтрите seccomp се наследени од сите детски процеси без можност за оневозможување на ова.

Малку повеќе детали за тоа како точно strace работи со seccomp може да се најде од неодамнешен извештај. За нас, најинтересен е фактот дека класичниот BPF претставен со seccomp се користи и денес.

xt_bpf

Сега да се вратиме во светот на мрежите.

Позадина: многу одамна, во 2007 година, јадрото беше додаде модул xt_u32 за нетфилтер. Напишан е по аналогија со уште постар сообраќаен класификатор cls_u32 и ви овозможи да напишете произволни бинарни правила за iptables користејќи ги следните едноставни операции: вчитајте 32 бита од пакетот и изведете збир на аритметички операции на нив. На пример,

sudo iptables -A INPUT -m u32 --u32 "6&0xFF=1" -j LOG --log-prefix "seen-by-xt_u32"

Ги вчитува 32-те бита од заглавието на IP, почнувајќи од пополнувањето 6, и применува маска на нив 0xFF (земете го нискиот бајт). Ова поле protocol Заглавие на IP и го споредуваме со 1 (ICMP). Можете да комбинирате многу проверки во едно правило, а исто така можете да го извршите и операторот @ — поместете X бајти надесно. На пример, правилото

iptables -m u32 --u32 "6&0xFF=0x6 && 0>>22&0x3C@4=0x29"

проверува дали секвенцискиот број на TCP не е еднаков 0x29. Нема да навлегувам понатаму во детали, бидејќи веќе е јасно дека рачно пишувањето такви правила не е многу погодно. Во статијата BPF - заборавениот бајтекод, има неколку врски со примери за употреба и генерирање правила за xt_u32. Видете ги и врските на крајот од оваа статија.

Од 2013 година модул наместо модул xt_u32 можете да користите модул базиран на BPF xt_bpf. Секој што прочитал досега треба веќе да биде јасен за принципот на неговото функционирање: стартувајте го BPF bytecode како што правилата iptables. Можете да креирате ново правило, на пример, вака:

iptables -A INPUT -m bpf --bytecode <байткод> -j LOG

тука <байткод> - ова е кодот во излезен формат на асемблер bpf_asm стандардно, на пример,

$ cat /tmp/test.bpf
ldb [9]
jneq #17, ignore
ret #1
ignore: ret #0

$ bpf_asm /tmp/test.bpf
4,48 0 0 9,21 0 1 17,6 0 0 1,6 0 0 0,

# iptables -A INPUT -m bpf --bytecode "$(bpf_asm /tmp/test.bpf)" -j LOG

Во овој пример ги филтрираме сите UDP пакети. Контекст за BPF програма во модул xt_bpf, се разбира, укажува на податоците за пакетот, во случај на iptables, на почетокот на заглавието IPv4. Повратна вредност од програмата BPF буловикаде false значи дека пакетот не се совпаѓа.

Јасно е дека модулот xt_bpf поддржува посложени филтри од примерот погоре. Ајде да погледнеме вистински примери од Cloudfare. До неодамна го користеа модулот xt_bpf за заштита од DDoS напади. Во статијата Воведување на алатките BPF тие објаснуваат како (и зошто) генерираат BPF филтри и објавуваат линкови до збир на алатки за создавање такви филтри. На пример, користејќи ја алатката bpfgen можете да креирате програма BPF што одговара на барањето DNS за име habr.com:

$ ./bpfgen --assembly dns -- habr.com
ldx 4*([0]&0xf)
ld #20
add x
tax

lb_0:
    ld [x + 0]
    jneq #0x04686162, lb_1
    ld [x + 4]
    jneq #0x7203636f, lb_1
    ldh [x + 8]
    jneq #0x6d00, lb_1
    ret #65535

lb_1:
    ret #0

Во програмата прво се вчитуваме во регистарот X адреса на почеток на линијата x04habrx03comx00 внатре во UDP датаграм и потоа проверете го барањето: 0x04686162 <-> "x04hab" итн

Малку подоцна, Cloudfare го објави кодот на компајлерот p0f -> BPF. Во статијата Ви го претставуваме компајлерот p0f BPF тие зборуваат за тоа што е p0f и како да се претворат потписите на p0f во BPF:

$ ./bpfgen p0f -- 4:64:0:0:*,0::ack+:0
39,0 0 0 0,48 0 0 8,37 35 0 64,37 0 34 29,48 0 0 0,
84 0 0 15,21 0 31 5,48 0 0 9,21 0 29 6,40 0 0 6,
...

Во моментов повеќе не користи Cloudfare xt_bpf, бидејќи се преселиле во XDP - една од опциите за користење на новата верзија на BPF, видете. L4Drop: Ублажување на XDP DDoS.

cls_bpf

Последниот пример за користење на класичен BPF во кернелот е класификаторот cls_bpf за потсистемот за контрола на сообраќајот во Linux, додаден на Linux на крајот на 2013 година и концептуално го замени античкиот cls_u32.

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

Друга причина да не се зборува за користење на класичен BPF в cls_bpf Проблемот е што, во споредба со Extended BPF, опсегот на применливост во овој случај е радикално стеснет: класичните програми не можат да ја променат содржината на пакетите и не можат да зачуваат состојба помеѓу повиците.

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

Збогум со класичниот BPF

Разгледавме како технологијата BPF, развиена во раните деведесетти, успешно живее четвртина век и до крајот најде нови апликации. Сепак, слично како и преминот од магацинот кон RISC, кој служеше како поттик за развој на класичниот BPF, во 32-тите имаше транзиција од 64-битни на XNUMX-битни машини и класичниот BPF почна да застарува. Покрај тоа, можностите на класичниот BPF се многу ограничени, а покрај застарената архитектура - немаме можност да ја зачуваме состојбата помеѓу повиците кон програмите BPF, нема можност за директна интеракција со корисникот, нема можност за интеракција со кернелот, освен за читање ограничен број полиња за структура sk_buff и со лансирање на наједноставните функции за помош, не можете да ја менувате содржината на пакетите и да ги пренасочувате.

Всушност, моментално сè што останува од класичниот BPF во Linux е интерфејсот API, а внатре во кернелот сите класични програми, било да се тоа филтри за приклучоци или филтри за seccomp, автоматски се преведуваат во нов формат, Extended BPF. (Ќе зборуваме за тоа како точно се случува ова во следната статија.)

Транзицијата кон нова архитектура започна во 2013 година, кога Алексеј Старовоитов предложи шема за ажурирање на BPF. Во 2014 година соодветните закрпи почна да се појавува во јадрото. Колку што разбрав, првичниот план беше само да се оптимизира архитектурата и JIT компајлерот за поефикасно да работи на 64-битни машини, но наместо тоа, овие оптимизации го означија почетокот на новото поглавје во развојот на Linux.

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

референци

1. Стивен МекКен и Ван Џејкобсон, „Филтерот за пакети BSD: нова архитектура за фаќање пакети на ниво на корисник“, https://www.tcpdump.org/papers/bpf-usenix93.pdf
2. Стивен МекКен, „libpcap: Архитектура и методологија за оптимизација за снимање на пакети“, https://sharkfestus.wireshark.org/sharkfest.11/presentations/McCanne-Sharkfest'11_Keynote_Address.pdf
3. tcpdump, libpcap: https://www.tcpdump.org/
4. Упатство за натпревар за IPtable U32.
5. BPF - заборавениот бајтекод: https://blog.cloudflare.com/bpf-the-forgotten-bytecode/
6. Ви ја претставуваме алатката BPF: https://blog.cloudflare.com/introducing-the-bpf-tools/
7. bpf_cls: http://man7.org/linux/man-pages/man8/tc-bpf.8.html
8. Втор преглед: https://lwn.net/Articles/656307/
9. https://github.com/torvalds/linux/blob/master/Documentation/userspace-api/seccomp_filter.rst
10. habr: Контејнери и безбедност: seccomp
11. habr: Изолирање демони со systemd или „не ти треба Docker за ова!“
12. Пол Шајњон, „трајс --сецомп-бпф: поглед под хаубата“, https://fosdem.org/2020/schedule/event/debugging_strace_bpf/
13. netsniff-ng: http://netsniff-ng.org/

Извор: www.habr.com