BPF за най-малките, част нула: classic BPF

Berkeley Packet Filters (BPF) е технология на ядрото на Linux, която не слиза от първите страници на англоезичните технически издания вече няколко години. Конференциите са пълни с доклади относно използването и разработката на BPF. Дейвид Милър, поддръжник на мрежовата подсистема на Linux, нарича своя доклад на Linux Plumbers 2018 «Тази лекция не е за XDP» (XDP е един от вариантите за използване на BPF). Брендън Грегг чете доклади с наименования Linux BPF Superpowers. Токе Хьоланд-Йоргенсен се смее, че ядрото сега е микрокернел. Томас Граф популяризира идеята, че BPF е javascript за ядрото.

Все още няма систематично описание на BPF в Хабра, затова в серия от статии ще се опитам да разкажа за историята на технологията, да опиша архитектурата и средствата за разработка, да очертая областите на приложение и практиките за използване на BPF. В тази, нулева, статия от цикъла ще бъде разказана историята и архитектурата на класическия BPF и ще бъдат разкрити тайните на принципите на работа tcpdump, seccomp, strace, и много друго.

Разработката на BPF се контролира от мрежовата общност на Linux, основните съществуващи приложения на BPF са свързани с мрежите и затова, с позволението на @eucariot, нарекох серията "BPF за най-малките", в чест на великата серия "Мрежи за най-малките".

Кратък курс по историята на BPF(c)

Съвременната технология BPF е подобрена и разширена версия на старата технология с същото название, наричана днес, за да се избегне объркване, класически BPF. На базата на класическия BPF са създадени известната утилита tcpdump, механизъм seccomp, както и по-малко известният модул xt_bpf за iptables и класификатор cls_bpf. В съвременния Linux класическите програми BPF автоматично се трансформират в нова форма, но от потребителска гледна точка, API-то остана същото и новите приложения на класическия BPF, както ще видим в тази статия, все още съществуват. Поради тази причина, а също така и защото следвайки историята на развитието на класическия BPF в Linux, ще стане ясно как и защо е еволюирала в съвременна форма, реших да започна именно с статията за класическия BPF.

В края на осемдесетте години на миналия век инженери от известната лаборатория Lawrence Berkeley се заинтересуваха от въпроса как правилно да се филтрират пакетите в мрежата на съвременното за края на осемдесетте години оборудване. Основната идея на филтрация, реализирана първоначално в технологията CSPF (CMU/Stanford Packet Filter), беше да се филтрират ненужните пакети възможно най-рано, т.е. в ядрото, тъй като това позволява да не се копират излишни данни в пространството на потребителя. За да се осигури безопасност на времето за изпълнение при стартиране на потребителски код в ядрото, беше използвана виртуална машина — пясъчник.

Въпреки това, виртуалните машини за съществуващите филтри бяха проектирани за работа на машини с стекова архитектура и на новите RISC машини не работеха толкова ефктивно. В резултат на усилията на инженерите от Berkeley Labs беше разработена нова технология BPF (Berkeley Packet Filters), чиято архитектура на виртуалната машина беше проектирана на основата на процесора Motorola 6502 — работна коня на такива известни продукти като Apple II или NES. Новата виртуална машина увеличаваше производителността на филтрите десетки пъти в сравнение със съществуващите решения.

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

Ще се запознаем с архитектурата практически, разглеждайки примери. Но първо нека кажем, че машината имаше два налични за потребителя 32-битови регистра — акумулатор A и индексен регистър X, 64 байта памет (16 думи), налична за запис и последващо четене, и малка система от команди за работа с тези обекти. В програмите бяха на разположение и инструкции за преход, за да се реализират условни изрази, но за да се гарантира навременното приключване на програмата, можеше да се премества само напред, т.е. по-специално не беше позволено да се създават цикли.

Общата схема на стартиране на машината е следната. Потребителят създава програма за архитектурата BPF и, с помощта на някакъв механизъм на ядрото (например, системен повик), зарежда и свързва програмата с някакъв генератор на събития в ядрото (например, събитие — това е пристигането на нов пакет на мрежовата карта). При възникване на събитие, ядрото стартира програмата (например, в интерпретатор), при което паметта на машината отговаря. някакъв регион на паметта на ядрото (например, данни от получен пакет).

Това, което казахме по-горе, е достатъчно, за да започнем да разглеждаме примера: ще се запознаем със системата и формата на командите, ако е необходимо. Ако искате да проучите системата на командите на виртуалната машина веднага и да научите за всичките й възможности, може да прочетете оригиналната статия. Индекс на пакетите BSD и/или първата половина на файла Documentation/networking/filter.txt от документацията на ядрото. Освен това, можете да изследвате презентацията libpcap: Архитектура и методология за оптимизация за улавяне на пакети, в която МакКан, един от авторите на BPF, разказва за историята на създаването libpcap.

Сега преминаваме към разглеждане на всички съществени примери за прилагането на класическия BPF в Linux: tcpdump (libpcap), seccomp, 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)-ят байт на анализирания мрежови пакет. Читаме пакети от Ethernet интерфейса eth0, а това означава, което пакетът изглежда по следния начин (за улеснение приемаме, че пакетът няма VLAN тагове):

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

Следователно, след изпълнение на командата ldh [12] в регистъра A ще се окаже поле Ether Type — типът на предавания пакет в този Ethernet фрейм. На ред 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 пакет (Ether Type = 0x800) и зареждаме в регистра A 24-ия байт на пакета. Нашият пакет изглежда като

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

а значи зареждаме в регистра A полето Protocol на IP заглавието, което е логично, тъй като искаме да копираме само TCP пакети. Сравняваме Protocol с 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 байта заема заглавието на Ethernet, а X съдържа дължината на заглавието на IPv4, разбираме, че в A се зарежда портът на целта TCP:

       14           X           2             2
|заглавие на ethernet|заглавие на ip|изходен порт|целеви порт|

Накрая, в ред 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
...

В първите два реда на изхода създаваме raw сокет за четене на всички 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.

Интересно е, че филтърът може да бъде свързван към всеки сокет, не само към raw. Ето пример програма, която отрязва всичко, освен първите два байта на всичките входящи UDP датаграми. (Коментарите добавих в кода, за да не пренасочват текста на статията.)

Повече информация за използването на setsockopt за свързване на филтри, вижте в socket(7), а за написването на собствени филтри от типа struct sock_fprog без помощта на tcpdump ще говорим в раздел Програмиране на BPF с помощта на собствените ръце.

Класически BPF и XXI век

BPF бе включен в Linux през 1997 година и дълго време остана работна коня libpcap без особени промени (разбира се, има специфични за Linux промени, имаше, но те не промениха глобалната картина). Първите сериозни признаци, че BPF ще еволюира, се появиха през 2011 година, когато Ерик Дюмазе предложи пач, добавящ в ядрото Just In Time Compiler — транслятор за превод на байткод на BPF в нативен x86_64 код.

JIT компилаторът беше първият в редицата промени: през 2012 година се появи възможност за писане на филтри за seccomp, използвайки BPF, през януари 2013 беше е добавен модул xt_bpf, което позволяваше писането на правила за iptables чрез BPF, а през октомври 2013 имаше е добавен още и модул cls_bpf, позволяващ да пишем трафикови класификатори с BPF.

Скоро ще разгледаме всичките тези примери по-подробно, но първо ще бъде полезно да научим как да пишем и компилираме произволни програми за BPF, тъй като възможностите, предоставени от библиотеката libpcap са ограничени (прост пример: филтър, сгенериран libpcap може да върне само две стойности — 0 или 0x40000) или изобщо, както в случая seccomp, невалидни.

Програмиране на BPF с помощта на собствените ръце

Нека да се запознаем с бинарния формат на BPF инструкции, който е много прост:

   16    8    8     32
| код | jt | jf |  k  |

Всяка инструкция заема 64 бита, в които първите 16 бита — това е кода на командата, следвани от две осем битови отстъпи, jt и jf, и 32 бита за аргумента, K, чиято роля се променя в зависимост от командата. Например, командата ret, която завършва изпълнението на програмата, има код 6, а връщаната стойност се взима от константата K. В езика C една инструкция BPF се представя в вида на структура

struct sock_filter {
        __u16   код;
        __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),
}

Обаче, и този вариант не е особено удобен. По същия начин мислиха и програмистите на ядрото на Linux и затова в директорията 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

По подразбиране асемблерът генерира код в формат , ,..., за нашия пример с 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, както направихме в началото на този раздел.

Разширения на Linux и netsniff-ng

Освен стандартните инструкции BPF, Linux и tools/bpf/bpf_asm поддържат и нестандартен набор. Главно, инструкциите служат за достъп до полета на структурата struct sk_buff, описваща мрежов пакет в ядрото. Въпреки това, има и помощни инструкции от друг тип, например ldw cpu ще зареди в регистъра A резултата от функцията на ядрото raw_smp_processor_id(). (В новата версия на BPF тези нестандартни разширения били разширени с предоставяне на kernel helpers на програмите за достъп до памет, структури и генериране на събития.) Ето интересен пример за филтър, при който копираме в пространството на потребителя само заглавията на пакетите, използвайки разширението poff, payload offset:

ld poff
ret a

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

seccomp

Така че вече знаем как да пишем BPF програми с произволна сложност и сме готови да разгледаме нови примери, първият от които е технологията seccomp, която позволява с помощта на BPF филтри да управлявате множеството и набор от аргументи на системните повиквания, достъпни на този процес и неговите потомци.

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

Забележете, че на Хабър вече имаше статии за използването на seccomp, може би на някого ще му се иска да ги прочете преди (или вместо) следващите подраздели. В статията Контейнери и сигурност: seccomp са дадени примери за използване на seccomp, както от версията от 2007 г., така и от версията с използване на BPF (филтрите се генерират с помощта на libseccomp), обсъжда се връзката между seccomp и Docker, а също така са предоставени много полезни връзки. В статията Изолираме демони с systemd или 'не ви трябва Docker за това!' се разказва, по-специално, как да добавяте черни или бели списъци със системни повиквания за демоните, управлявани от systemd.

По-нататък ще погледнем как да пишем и зареждаме филтри за 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, на тази функция забравиха да добавят разрешение за използване на инструкция мод (остатък от деление) и сега тя не е достъпна за 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
Лошо системно повикване

Използваме 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} ---
+++ убит от SIGSYS (core dumped) +++
Лошо системно повикване

откъдето можем да разберем, че програмата е била завършена поради използването на забранено системно повикване 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 за netfilter. Той беше написан аналогично на още по-древния трафик класфикатор 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 Sequence Number 0x29е равен на 0. Няма да задълбочавам темата, тъй като вече е ясно, че ръчното написване на такива правила не е много удобно. В статията BPF — forgotten bytecode, има няколко линка с примери за използване и генериране на правила за xt_u32. Вижте също линковете в края на тази статия.

Започвайки от 2013 година, вместо модула xt_u32 може да се използва модул, базиран на BPF. xt_bpfНа всички, които достигнаха дотук, трябва вече да е ясен принципът на работа: изпълнение на BPF байт код като правила на 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 атаки. В статията Introducing the BPF Tools те разказват как (и защо) генерират 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. В статията Introducing the p0f BPF compiler те разказват какво е 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 Mitigations.

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, в началото на 2000-те години настъпи преходът от 32-битови към 64-битови машини и класическият BPF започна да остарява. Освен това, възможностите на класическия BPF са значително ограничени, тъй като, освен остарялата архитектура, нямаме възможност да запазваме състояние между повикванията на BPF програмите, нямаме възможност за директна връзка с потребителя, и нямаме възможност за взаимодействие с ядрото, освен за четене на ограничен брой полета от структурата. sk_buff и изпълнение на най-простите помощни функции, не е възможно да се променя съдържанието на пакетите и да се пренасочват.

Всъщност, в момента от класическия BPF в Linux остана само API интерфейс, а вътре в ядрото всички класически програми, било то филтри на сокети или филтри seccomp, автоматично се транслират в новия формат, Extended BPF. (Ще разкажем как именно това се случва в следващата статия.)

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

Следващите статии в тази серия ще разкажат за архитектурата и приложенията на новата технология, първоначално известна като internal BPF, след това extended BPF, а сега просто BPF.

Връзки

1. Steven McCanne and Van Jacobson, "The BSD Packet Filter: A New Architecture for User-level Packet Capture", https://www.tcpdump.org/papers/bpf-usenix93.pdf
2. Steven McCanne, "libpcap: An Architecture and Optimization Methodology for Packet Capture", https://sharkfestus.wireshark.org/sharkfest.11/presentations/McCanne-Sharkfest'11_Keynote_Address.pdf
3. tcpdump, libpcap: https://www.tcpdump.org/
4. IPtable U32 Match Tutorial.
5. BPF — забравеният байт-код: https://blog.cloudflare.com/bpf-the-forgotten-bytecode/
6. Представяне на BPF Tool: https://blog.cloudflare.com/introducing-the-bpf-tools/
7. bpf_cls: http://man7.org/linux/man-pages/man8/tc-bpf.8.html
8. Обзор на seccomp: 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. Paul Chaignon, "strace —seccomp-bpf: поглед под капака", https://fosdem.org/2020/schedule/event/debugging_strace_bpf/
13. netsniff-ng: http://netsniff-ng.org/

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