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

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

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

Разработването на BPF се контролира от мрежовата общност на Linux, основните съществуващи приложения на 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 или NES. Новата виртуална машина увеличи производителността на филтъра десетки пъти в сравнение със съществуващите решения.

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

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

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

Горното ще бъде достатъчно, за да започнем да разглеждаме примери: ще се запознаем със системата и формата на командите, ако е необходимо. Ако искате веднага да изучите командната система на виртуална машина и да научите за всичките й възможности, тогава можете да прочетете оригиналната статия Пакетният филтър BSD и/или първата половина на файла Documentation/networking/filter.txt от документацията на ядрото. Освен това можете да изучавате презентацията libpcap: Методология за архитектура и оптимизация за улавяне на пакети, в който McCanne, един от авторите на 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 (тип опаковка) c 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 пакети. Сравняваме протокола с 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 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 със собствените си ръце.

Класически БНФ и XNUMX век

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

Компилаторът JIT беше първият във веригата от промени: през 2012 г се появи възможност за писане на филтри за seccomp, използвайки 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))

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

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

Разширения за Linux и 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. Пакетът съдържа доста подробна документация, вижте и връзките в края на статията.

seccomp

И така, ние вече знаем как да пишем 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 за това!“ Той обхваща, по-специално, как да добавите черни списъци или бели списъци на системни повиквания за демони, изпълняващи systemd.

След това ще видим как да пишем и зареждаме филтри за seccomp в гол C и използвайки библиотеката libseccomp и какви са плюсовете и минусите на всяка опция, и накрая, нека видим как seccomp се използва от програмата strace.

Писане и зареждане на филтри за seccomp

Вече знаем как да пишем BPF програми, така че нека първо да разгледаме програмния интерфейс на seccomp. Можете да зададете филтър на ниво процес и всички дъщерни процеси ще наследят ограниченията. Това става чрез системно повикване seccomp(2):

seccomp(SECCOMP_SET_MODE_FILTER, flags, &filter)

където &filter - това е указател към вече позната ни структура struct sock_fprog, т.е. Програма на БНФ.

Как се различават програмите за 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() ядки. (Странното е, че в оригиналния комит, който добави функционалността 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 за 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 не е равен 0x29. Няма да навлизам в подробности, тъй като вече е ясно, че писането на такива правила на ръка не е много удобно. В статията BPF - забравеният байт код, има няколко връзки с примери за използване и генериране на правила за 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 атаки. В статията Представяме ви 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 c 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.

Позоваването

Стивън Маккан и Ван Джейкъбсън, „Пакетният филтър BSD: Нова архитектура за улавяне на пакети на ниво потребител“, https://www.tcpdump.org/papers/bpf-usenix93.pdf
Стивън Маккан, „libpcap: Архитектура и методология за оптимизация за улавяне на пакети“, https://sharkfestus.wireshark.org/sharkfest.11/presentations/McCanne-Sharkfest'11_Keynote_Address.pdf
tcpdump, libpcap: https://www.tcpdump.org/
Урок за съвпадение на IPtable U32.
BPF - забравеният байт код: https://blog.cloudflare.com/bpf-the-forgotten-bytecode/
Представяме ви инструмента BPF: https://blog.cloudflare.com/introducing-the-bpf-tools/
bpf_cls: http://man7.org/linux/man-pages/man8/tc-bpf.8.html
Общ преглед на seccomp: https://lwn.net/Articles/656307/
https://github.com/torvalds/linux/blob/master/Documentation/userspace-api/seccomp_filter.rst
habr: Контейнери и сигурност: seccomp
habr: Изолиране на демони със systemd или „нямате нужда от Docker за това!“
Paul Chaignon, „strace --seccomp-bpf: поглед под капака“, https://fosdem.org/2020/schedule/event/debugging_strace_bpf/
netsniff-ng: http://netsniff-ng.org/

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

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