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

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

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

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

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

Съвременната технология 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 Packet Filter и/или първата половина на файла 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 (тип на пакета) с 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 проверяваме, дали не е зададен един от трите флага — в маската са изчистени трите най-стари бита. Два от трите бита ни подсказват, дали пакетът е част от фрагментиран IP пакет, и ако да, дали е последният фрагмент. Третият бит е резервиран и трябва да бъде нула. Не искаме да проверяваме нито нецелите, нито повредените пакети, затова проверяваме всички три бита. jset са очистени трите старши бита. Два бита от трите ни дават информация дали пакетът е част от фрагментиран IP пакет, а ако да, дали е последният фрагмент. Третият бит е резервиран и трябва да бъде равен на нула. Не искаме да проверяваме и нецелеви, и повредени пакети, затова проверяваме всички три бита.

Ред 6 е най-интересна в този листинг. Израз ldxb 4*([14]&0xf) означава, че зареждаме в регистъра X четирите най-ниски битове на петнадесетия байт на пакета, умножени по 4. Четирите най-ниски битове на петнадесетия байт са поле Internet Header Length на заглавката IPv4, в която се съхранява дължината на заглавката в думи, за това е необходимо после да се умножи по 4. Интересно е, че изразът 4*([14]&0xf) е обозначение на специалната адресна схема, която може да се използва само по този начин и само за регистъра X, т.е. не можем да кажем нито ldb 4*([14]&0xf) нито ldxb 5*([14]&0xf) (можем само да укажем друг offset, например, ldxb 4*([16]&0xf)). Ясно е, че тази адресна схема е добавена в BPF точно за да получим в X (индексен регистър) дължината на заглавката IPv4.

Така на ред 7 се опитваме да заредим половин дума по адрес (X+16). Припомняйки си, че 14 байта заемат заглавката Ethernet, а X съдържа дължината на заглавката IPv4, разбираме, че в A се зарежда IP на определяне на 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
...

На първите два реда от извода създаваме 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 (Ресурсът временно е недостъпен)
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 година, когато Eric Dumazet предложи, добавяйки Just In Time Compiler в ядрото — транслационния механизм за превод на байткода BPF в нативен патчx86_64 код. JIT компилаторът беше първият в поредицата от промени: през 2012 година

възможността да пишете филтри за е добавена , използвайки BPF, бе добавена през януари 2013. seccompдобавена. добавен модул 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   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),
}

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

Използваме 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 (ядро дъмпнато) +++
Лошо системно повикване

откъдето можем да видим, че програмата е завършена поради използването на забранено системно повикване 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. Няма да се задълбочавам по-нататък, тъй като вече е ясно, че ръчното писане на такива правила не е много удобно. В статията BPF — the 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 програмата булева, където неверно означава, че пакетът не съвпада.

Разбира се, модулът xt_bpf поддържа по-сложни филтри от тези в примера по-горе. Нека да разгледаме реални примери от компанията Cloudflare. До скоро те използваха модула 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" и т.н.

Няколко дни по-късно Cloudflare публикува кода на компилатора 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,
...

В момента Cloudflare вече не използва xt_bpf, тъй като преминаха на XDP — един от вариантите за използване на новата версия BPF, виж. L4Drop: XDP DDoS Mitigирания.

cls_bpf

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

Но ние в момента няма да описваме работата cls_bpf, тъй като що се отнася до знанията за класическия BPF, това не ни дава нищо — вече сме се запознали с цялата функционалност. Освен това, в следващите статии, които разказват за Разширения BPF, ние още няколко пъти ще се сблъскаме с този класификатор.

Още една причина да не разказваме за използването на класически BPF с cls_bpf е, че в сравнение с Разширения BPF в този случай значително се стеснява областта на приложение: класическите програми не могат да променят съдържанието на пакетите и не могат да запазват състояние между повикванията.

Така че дойде време да се сбогуваме с класическия BPF и да погледнем в бъдещето.

Сбогом на класическия BPF

Ние разгледахме как технологията BPF, разработена в началото на деветдесетте години, успешно премина четвърт век и продължава да намира нови приложения. Въпреки това, подобно на прехода от стекови машини към RISC, който послужи за тласък за разработването на класическия BPF, през две хиляди години се случи преход от 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 и 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 инструмента: 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