Книга «BPF за наблюдение на Linux»

Здравейте, Хаброжители! Виртуалната машина BPF е един от най-важните компоненти на ядрото на Linux. Правилното й приложение ще позволи на системните инженери да откриват грешки и да решават дори най-сложните проблеми. Вие ще научите как да създавате програми, които следят и модифицират поведението на ядрото, ще можете безопасно да внедрявате код за наблюдение на събития в ядрото и много други. Дейвид Калавера и Лоренцо Фонтана ще ви помогнат да разкриете възможностите на BPF. Разширете знанията си за оптимизация на производителността, мрежи и сигурност. — Използвайте BPF за проследяване и модификация на поведението на ядрото на Linux. — Внедрявайте код за безопасно наблюдение на събития в ядрото — без необходимост от повторна компилация на ядрото или рестартиране на системата. — Ползвайте удобни примери на код на C, Go или Python. — Управлявайте ситуацията, владеейки жизнения цикъл на програмата BPF.

Сигурността на ядрото на Linux, неговите възможности и Seccomp

BPF предоставя мощен начин за разширяване на ядрото без компромис с неговата стабилност, сигурност и бързина. Поради тази причина разработчиците на ядрото сметнали, че би било добре да използват универсалността му, за да подобрят изолацията на процесите в Seccomp чрез реализиране на филтри Seccomp, поддържани от програми BPF, известни също като Seccomp BPF. В тази глава ще разкажем какво представлява Seccomp и как се прилага. След това ще научите как да пишете филтри Seccomp с помощта на програми BPF. След това ще разгледаме вградените капани BPF, които са налични в ядрото за модули за сигурност на Linux.

Модулите за сигурност на Linux (LSM) са платформа, която предоставя набор от функции, които могат да се прилагат за стандартизирана реализация на различни модели на сигурност. LSM може да се използва директно в дървото на изходния код на ядрото, например Apparmor, SELinux и Tomoyo.

Да започнем с дискусия за възможностите на Linux.

Възможности

Същността на възможностите на Linux е в това, че трябва да предоставите разрешение на непривилегирован процес да изпълни конкретна задача, но без да използвате suid за тази цел или по друг начин да направите процеса привилегирован, като намалите възможността за атаки и осигурите на процеса възможността да изпълнява определени задачи. Например, ако приложението ви трябва да отвори привилегирован порт, да кажем 80, вместо да стартирате процеса с права на root, можете просто да му предоставите правото CAP_NET_BIND_SERVICE.

Нека разгледаме програма на Go с име main.go:

package main
import (
            "net/http"
            "log"
)
func main() {
     log.Fatalf("%v", http.ListenAndServe(":80", nil))
}

Тази програма обслужва HTTP сървър на порт 80 (това е привилегирован порт). Обикновено я стартираме веднага след компилация:

$ go build -o capabilities main.go
$ ./capabilities

Въпреки това, тъй като не предоставяме привилегии на root, този код ще издаде грешка при свързване на порта:

2019/04/25 23:17:06 listen tcp :80: bind: permission denied
exit status 1

capsh (инструмент за управление на обвивка) е инструмент, който стартира обвивка с определен набор от възможности.

В този случай, както вече споменахме, вместо да предоставим пълни права на root, можем да разрешим свързването на привилегировани портове, предоставяйки правото cap_net_bind_service, наред с всички останали, които вече са налични в програмата. За целта можем да завием програмата си в capsh:

# capsh --caps='cap_net_bind_service+eip cap_setpcap,cap_setuid,cap_setgid+ep' 
   --keep=1 --user="nobody" 
   --addamb=cap_net_bind_service -- -c "./capabilities"

Нека разгледаме малко по-подробно тази команда.

• capsh — използваме capsh като обвивка.
• —caps='cap_net_bind_service+eip cap_setpcap,cap_setuid,cap_setgid+ep' — тъй като трябва да сменим потребителя (не искаме да стартираме с права на root), ще посочим cap_net_bind_service и способността действително да променим идентификатора на потребителя от root на nobody, а именно cap_setuid и cap_setgid.
• —keep=1 — искаме да запазим зададените възможности, когато се извършва смяна от акаунта на root.
• —user='nobody' — крайният потребител, който стартира програмата, ще бъде nobody.
• —addamb=cap_net_bind_service — задаваме почистване на свързаните възможности след смяна от режим root.
• — -c "./capabilities" — просто стартираме програмата.

Свързаните възможности са особен вид възможности, които се наследяват от дъщерни програми, когато текущата програма ги изпълнява с помощта на execve(). Могат да се наследяват само възможности, разрешени като свързани, или, с други думи, като възможности на околната среда.

Вероятно, ви е интересно какво означава +eip след указването на възможност в опцията —caps. Тези флагове се използват за определяне на това, че възможността:

-трябва да бъде активирана (p);

-е достъпна за прилагане (e);

-може да бъде наследена от дъщерни процеси (i).

Тъй като искаме да използваме cap_net_bind_service, трябва да направим това с флага e. След това ще стартираме оболката в командата. В резултат на това ще се стартира бинарен файл capabilities, и трябва да го пометим с флага i. Накрая, искаме възможността да бъде активирана (както направихме, без да променяме UID) с помощта на p. Това изглежда като cap_net_bind_service+eip.

Можете да проверите резултата с помощта на ss. Нека малко да съкратим извода, за да се побере на страницата, но той ще покаже свързания порт и идентификатора на потребителя, различен от 0, в този случай 65 534:

# ss -tulpn -e -H | cut -d' ' -f17-
128 *:80 *:*
users:(("capabilities",pid=30040,fd=3)) uid:65534 ino:11311579 sk:2c v6only:0

В този пример използвахме capsh, но можете да напишете оболка с помощта на libcap. За допълнителна информация се свържете с man 3 libcap.

При написването на програми разработчикът доста често не знае предварително всички възможности, необходими на програмата по време на изпълнение; повече от това, в новите версии тези възможности могат да се променят.

За да разберем по-добре възможностите на нашата програма, можем да използваме инструмента BCC capable, който задава kprobe за функцията на ядрото cap_capable:

/usr/share/bcc/tools/capable
TIME      UID  PID   TID   COMM               CAP    NAME           AUDIT
10:12:53 0 424     424     systemd-udevd 12 CAP_NET_ADMIN         1
10:12:57 0 1103   1101   timesync        25 CAP_SYS_TIME         1
10:12:57 0 19545 19545 capabilities       10 CAP_NET_BIND_SERVICE 1

Същото можем да постигнем, използвайки bpftrace с едноредов kprobe в функцията на ядрото cap_capable:

bpftrace -e 
   'kprobe:cap_capable {
      time("%H:%M:%S ");
      printf("%-6d %-6d %-16s %-4d %dn", uid, pid, comm, arg2, arg3);
    }' 
    | grep -i capabilities

Това ще изведе нещо подобно на следното, ако възможностите на нашата програма са активирани след kprobe:

12:01:56 1000 13524 capabilities 21 0
12:01:56 1000 13524 capabilities 21 0
12:01:56 1000 13524 capabilities 21 0
12:01:56 1000 13524 capabilities 12 0
12:01:56 1000 13524 capabilities 12 0
12:01:56 1000 13524 capabilities 12 0
12:01:56 1000 13524 capabilities 12 0
12:01:56 1000 13524 capabilities 10 1

Петият стълбец — това са възможностите, от които се нуждае процесът, и, тъй като тези изходни данни включват също неаудитни събития, виждаме всички неаудитни проверки и, в крайна сметка, изискваната възможност с флага за одит (последният в извода), зададен на 1. Възможността, която ни интересува, е CAP_NET_BIND_SERVICE, тя е определена като константа в изходния код на ядрото в файла include/uapi/linux/ability.h с идентификатор 10:

/* Allows binding to TCP/UDP sockets below 1024 */
/* Allows binding to ATM VCIs below 32 */
#define CAP_NET_BIND_SERVICE 10<source lang="go">

Възможностите често се използват по време на изпълнение на контейнери, като runC или Docker, за да работят в непривилегирован режим, но им се разрешават само онези възможности, които са необходими за стартиране на повечето приложения. Когато на приложението са необходими определени възможности, в Docker може да се осигурят чрез —cap-add:

docker run -it --rm --cap-add=NET_ADMIN ubuntu ip link add dummy0 type dummy

Тази команда ще предостави на контейнера способността CAP_NET_ADMIN, което ще му позволи да конфигурира мрежова връзка за добавяне на интерфейса dummy0.

В следващия раздел е показано използването на такива възможности, като фильтриране, но с друг метод, който ще ни позволи програмно да реализираме собствени филтри.

Seccomp

Seccomp означава Secure Computing, това е ниво на сигурност, реализирано в ядрото на Linux, което позволява на разработчиците да филтрират определени системни повиквания. Докато Seccomp е съпоставим с възможностите на Linux, способността му да управлява определени системни повиквания го прави много по-гъвкав в сравнение с тях.

Seccomp и възможностите на Linux не се изключват взаимно, често се използват заедно, за да се извлекат ползи от двата подхода. Например, можете да искате да предоставите на процеса възможността CAP_NET_ADMIN, но да не му позволите да приема връзки чрез сокет, блокирайки системните повиквания accept и accept4.

Метода на филтриране в Seccomp е базиран на BPF филтри, работещи в режим SECCOMP_MODE_FILTER, а филтрирането на системни повиквания се извършва по същия начин, както и за пакетите.

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

Ето как изглежда структурата seccomp_data от изходния код на ядрото в файла linux/seccomp.h:

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

Както може да се види от тази структура, можем да филтрираме по системно повикване, неговите аргументи или тяхната комбинация.

След като получи всеки пакет, Seccomp филтърът трябва да извърши обработка, за да вземе окончателно решение и да уведоми ядрото какво да прави по-нататък. Окончателното решение се изразява с един от върнатите стойности (кодове за статус).

— SECCOMP_RET_KILL_PROCESS — незабавно прекратяване на целия процес след филтриране на системния повик, който поради това не се изпълнява.

— SECCOMP_RET_KILL_THREAD — незабавно прекратяване на текущия поток след филтриране на системния повик, който поради това не се изпълнява.

— SECCOMP_RET_KILL — алиас за SECCOMP_RET_KILL_THREAD, оставен за обратна съвместимост.

— SECCOMP_RET_TRAP — системният повик е забранен и сигналът SIGSYS (Лош системен повик) се изпраща на задачата, извикала го.

— SECCOMP_RET_ERRNO — системният повик не се изпълнява и част от върнатата стойност на филтъра SECCOMP_RET_DATA се предава в потребителското пространство като стойност errno. В зависимост от причината за грешката, се връщат различни стойности errno. Списъкът с номера на грешките е предоставен в следващия раздел.

— SECCOMP_RET_TRACE — използва се за уведомяване на трасировчика ptrace с PTRACE_O_TRACESECCOMP, за да се прихване, когато се изпълнява системният повик, за да се види и контролира този процес. Ако трасировчикът не е свързан, се връща грешка, errno се задава на -ENOSYS, а системният повик не се изпълнява.

— SECCOMP_RET_LOG — системният повик е разрешен и регистриран в журнала.

— SECCOMP_RET_ALLOW — системният повик просто е разрешен.

ptrace е системен повик за реализация на механизми за трасировка в процес, наречен tracee, с възможност за наблюдение и контрол на изпълнението на процеса. Програмата за трасировка може ефективно да влияе на изпълнението и да променя регистрите на паметта на tracee. В контекста на Seccomp ptrace се използва, когато се стартира с код на статус SECCOMP_RET_TRACE, следователно, трасировчикът може да предотврати изпълнението на системния повик и да реализира собствена логика.

Грешки на Seccomp

От време на време, работейки с Seccomp, ще се сблъсквате с различни грешки, които се идентифицират от върнатата стойност от типа SECCOMP_RET_ERRNO. За да докладва за грешка, системният повик seccomp ще върне -1 вместо 0.

Възможни са следните грешки:

— EACCESS — на повикващата страна не ѝ е разрешено да извърши системен вик. Обикновено това се случва, защото няма привилегии CAP_SYS_ADMIN или no_new_privs не е зададен с prctl (за това ще говорим по-късно);

— EFAULT — предадените аргументи (args в структурата seccomp_data) нямат валиден адрес;

— EINVAL — тук могат да бъдат четири причини:

- поисканата операция е неизвестна или не се поддържа от ядрото в текущата конфигурация;

- зададените флагове са невалидни за исканата операция;

- операцията включва BPF_ABS, но има проблеми с посоченото изместване, което може да надвишава размера на структурата seccomp_data;

- броят на инструкциите, предадени на филтъра, надвишава максималния;

— ENOMEM — недостатъчна памет за изпълнение на програмата;

— EOPNOTSUPP — операцията е посочила, че с SECCOMP_GET_ACTION_AVAIL действието е било достъпно, но ядрото не поддържа връщането в аргументите;

— ESRCH — възникна проблем при синхронизацията на друг поток;

— ENOSYS — няма трасировач, прикрепен към действието SECCOMP_RET_TRACE.

prctl е системен вик, който позволява на програмата в потребителското пространство да управлява (заделя и получава) конкретни аспекти на процеса, като порядков номер на байтове, имена на потоци, режим на защитени изчисления (Seccomp), привилегии, събития Perf и др.

Seccomp може да ви изглежда като технология за пясъчна кутия, но не е така. Seccomp е инструмент, който позволява на потребителите да проектират механизъм на пясъчната кутия. Сега ще разгледаме как се създават програми за потребителски взаимодействия с помощта на филтър, извикван директно чрез системния вик Seccomp.

Пример за филтър BPF Seccomp

Тук ще покажем как да комбинираме двете разгледани по-рано действия, а именно:

— ще напишем програма Seccomp BPF, която ще се прилага като филтър с различни кодове за връщане в зависимост от получените решения;

— ще заредим филтъра, използвайки prctl.

Първо, нужни са заглавия от стандартната библиотека и ядрото на Linux:

#include <errno.h>
#include <linux/audit.h>
#include <linux/bpf.h>
#include <linux/filter.h>
#include <linux/seccomp.h>
#include <linux/unistd.h>
#include <stddef.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/prctl.h>
#include <unistd.h>

Преди да се опитаме да изпълним този пример, трябва да се уверим, че ядрото е компилирано с CONFIG_SECCOMP и CONFIG_SECCOMP_FILTER, зададени на y. На работната машина това може да се провери така:

cat /proc/config.gz | zcat | grep -i CONFIG_SECCOMP

Останалата част от кода представлява функция install_filter, състояща се от две части. Първата част съдържа нашия списък с инструкции за филтриране BPF:

static int install_filter(int nr, int arch, int error) {
  struct sock_filter filter[] = {
    BPF_STMT(BPF_LD + BPF_W + BPF_ABS, (offsetof(struct seccomp_data, arch))),
    BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, arch, 0, 3),
    BPF_STMT(BPF_LD + BPF_W + BPF_ABS, (offsetof(struct seccomp_data, nr))),
    BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, nr, 0, 1),
    BPF_STMT(BPF_RET + BPF_K, SECCOMP_RET_ERRNO | (error & SECCOMP_RET_DATA)),
    BPF_STMT(BPF_RET + BPF_K, SECCOMP_RET_ALLOW),
  };

Инструкциите се задават с помощта на макросите BPF_STMT и BPF_JUMP, дефинирани в файла linux/filter.h.
Нека прегледаме инструкциите.

— BPF_STMT(BPF_LD + BPF_W + BPF_ABS (offsetof(struct seccomp_data, arch))) — системата зарежда и натрупва с BPF_LD под формата на дума BPF_W, пакетните данни се намират с фиксимирано отместване BPF_ABS.

— BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, arch, 0, 3) — проверява с помощта на BPF_JEQ, дали стойността на архитектурата в константния акумулатор BPF_K е равна на arch. Ако е така, преминава с отместване 0 към следващата инструкция, в противен случай, за да издаде грешка, скача с отместване 3 (в този случай), тъй като arch не съвпада.

— BPF_STMT(BPF_LD + BPF_W + BPF_ABS (offsetof(struct seccomp_data, nr))) — зарежда и натрупва с BPF_LD под формата на дума BPF_W, която е номерът на системния повик, съдържащ се в фиксирано отместване BPF_ABS.

— BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, nr, 0, 1) — сравнява номера на системния повик със стойността на променливата nr. Ако са равни, преминава към следващата инструкция и забранява системния повик, в противен случай разрешава системния повик с SECCOMP_RET_ALLOW.

— BPF_STMT(BPF_RET + BPF_K, SECCOMP_RET_ERRNO | (error & SECCOMP_RET_DATA)) — приключва програмата с BPF_RET и в резултат издава грешка SECCOMP_RET_ERRNO с номер от променливата err.

— BPF_STMT(BPF_RET + BPF_K, SECCOMP_RET_ALLOW) — приключва програмата с BPF_RET и разрешава изпълнението на системния повик с SECCOMP_RET_ALLOW.

SECCOMP — ТОВА Е CBPF
Може да ви интересува защо вместо компилиран обект ELF или програма на C, компилирана с JIT, се използва списък с инструкции.

Има две причини за това.

• Първо, Seccomp прилага cBPF (класически BPF), а не eBPF, което означава: няма регистри, а само акумулатор за съхранение на последния резултат от изчисленията, както може да се види в примера.

• На второ място, Seccomp приема указател на масив от инструкции BPF директно и нищо повече. Макросите, които използвахме, просто помагат да се определят тези инструкции в удобна за програмистите форма.

Ако имате нужда от допълнителна помощ, за да разберете тази сборка, разгледайте псевдокода, който прави същото:

if (arch != AUDIT_ARCH_X86_64) {
    return SECCOMP_RET_ALLOW;
}
if (nr == __NR_write) {
    return SECCOMP_RET_ERRNO;
}
return SECCOMP_RET_ALLOW;

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

struct sock_fprog prog = {
   .len = (unsigned short)(sizeof(filter) / sizeof(filter[0])),
   .filter = filter,
};

Остава само едно нещо, което трябва да направим във функцията install_filter – да заредим самата програма! За това използваме prctl, взимайки PR_SET_SECCOMP като опция, за да влезем в режим на защитени изчисления. След това ще укажем на режима да зарежда филтъра с помощта на SECCOMP_MODE_FILTER, който се съдържа в променливата prog от тип sock_fprog:

  if (prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, &prog)) {
    perror("prctl(PR_SET_SECCOMP)");
    return 1;
  }
  return 0;
}

Накрая, можем да използваме нашата функция install_filter, но преди това трябва да активираме prctl, за да зададем PR_SET_NO_NEW_PRIVS за текущото изпълнение и така да избегнем ситуация, в която дъщерните процеси получават по-широки привилегии от родителските. При това можем да правим следните повиквания на prctl във функцията install_filter, без да имаме права root.

Сега можем да извикаме функцията install_filter. Ще блокираме всички системни повиквания write, свързващи се с архитектурата X86-64, и просто ще дадем разрешение, забраняващо всички опити. След установка на филтъра продължаваме изпълнението, използвайки първия аргумент:

int main(int argc, char const *argv[]) {
  if (prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0)) {
   perror("prctl(NO_NEW_PRIVS)");
   return 1;
  }
   install_filter(__NR_write, AUDIT_ARCH_X86_64, EPERM);
  return system(argv[1]);
 }

Да започнем. За компилиране на нашата програма можем да използваме или clang, или gcc; в който и да е случай, това е просто компилиране на файла main.c без специални опции:

clang main.c -o filter-write

Както беше посочено, блокирахме всички записи в програмата. За да проверим това, ни е необходима програма, която нещо извежда – ls изглежда като добър кандидат. Ето как обикновено се държи:

ls -la
total 36
drwxr-xr-x 2 fntlnz users 4096 Апр 28 21:09 .
drwxr-xr-x 4 fntlnz users 4096 Апр 26 13:01 ..
-rwxr-xr-x 1 fntlnz users 16800 Апр 28 21:09 filter-write
-rw-r--r-- 1 fntlnz users 19 Апр 28 21:09 .gitignore
-rw-r--r-- 1 fntlnz users 1282 Апр 28 21:08 main.c

Чудесно! Ето как изглежда използването на нашата програма-оболка: просто предаваме програмата, която искаме да тестваме, като първи аргумент:

.\/filter-write "ls -la"

След изпълнението тази програма дава напълно празен изход. Въпреки това можем да приложим strace, за да видим какво се случва:

strace -f .\/filter-write "ls -la"

Резултатът от изпълнението е силно съкратен, но съответната част показва, че записите се блокират с грешка EPERM — същата, която настроихме. Това означава, че програмата не извежда нищо, тъй като не може да получи достъп до системния повик write:

[pid 25099] write(2, "ls: ", 4) = -1 EPERM (Операцията не е разрешена)
[pid 25099] write(2, "грешка при запис", 11) = -1 EPERM (Операцията не е разрешена)
[pid 25099] write(2, "n", 1) = -1 EPERM (Операцията не е разрешена)

Сега разбирате как работи Seccomp BPF и имате добра представа за това какво може да се направи с него. Но не бихте ли искали да постигнете същото с eBPF вместо cBPF, за да използвате цялата му мощ?

Когато става въпрос за eBPF програми, повечето хора мислят, че просто ги пишат и зареждат с администраторски права. Въпреки че това твърдение е в основни линии вярно, ядрото реализира набор от механизми за защита на обектите eBPF на различни нива. Тези механизми се наричат капани BPF LSM.

Капани BPF LSM

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

Към момента на написване на книгата, ядрото имаше седем капана, свързани с BPF програми, а SELinux беше единственият вграден LSM, който ги реализираше.

Изходният код на капаните е разположен в дървото на ядрото в файла include/linux/security.h:

extern int security_bpf(int cmd, union bpf_attr *attr, unsigned int size);
extern int security_bpf_map(struct bpf_map *map, fmode_t fmode);
extern int security_bpf_prog(struct bpf_prog *prog);
extern int security_bpf_map_alloc(struct bpf_map *map);
extern void security_bpf_map_free(struct bpf_map *map);
extern int security_bpf_prog_alloc(struct bpf_prog_aux *aux);
extern void security_bpf_prog_free(struct bpf_prog_aux *aux);

Всяка от тях ще се извиква на различни етапи от изпълнението:

— security_bpf — извършва първоначална проверка на изпълнените системни повиквания BPF;

— security_bpf_map — проверява, когато ядрото връща файлов дескриптор за картата;

— security_bpf_prog — проверява, когато ядрото връща файлов дескриптор за програмата eBPF;

— security_bpf_map_alloc — проверява, дали полето за безопасност в BPF картите е инициализирано;

— security_bpf_map_free — проверява, дали почистването на полето за безопасност в BPF картите се извършва;

— security_bpf_prog_alloc — проверява, дали полето за безопасност в BPF програмите е инициализирано;

— security_bpf_prog_free — проверява, дали полето за безопасност в BPF програмите се очиства.

Сега, виждайки всичко това, разбираме: идеята на перехватчиците LSM BPF е, че те могат да осигурят защита на всеки обект eBPF, гарантирайки, че само тези, които имат съответните привилегии, могат да извършват операции с картите и програмите.

Резюме

Безопасността не е нещо, което можете да внедрите универсално за всичко, което искате да защитите. Важно е да имате способността да защитавате системите на различни нива и по различни начини. Искате да вярвате или не, най-добрият начин да защитите системата е да организирате различни нива на защита от различни позиции, така че намаляването на безопасността на едно ниво да не позволи достъп до цялата система. Разработчиците на ядрото направиха голяма работа, предоставяйки ни набор от различни слоеве и точки на взаимодействие. Надяваме се, че сме ви дали добра представа за това какво са слоевете и как да използвате BPF програмите, за да работите с тях.

За авторите

Дейвид Калавера е технически директор в Netlify. Той е работил в поддръжката на Docker и е участвал в разработването на инструменти Runc, Go и BCC, както и в други проекти с отворен код. Известен е със своята работа по проектите Docker и развитието на екосистемата от плъгини на Docker. Дейвид е много заинтересован от flame graphs и винаги се стреми към оптимизация на производителността.

Лоренцо Фонтана работи в екипа за разработка на софтуер с отворен код в Sysdig, където основно се занимава с Falco — проект на Cloud Native Computing Foundation, който осигурява сигурността на средата за работа с контейнери и откритие на аномалии чрез модул на ядрото и eBPF. Той е запален по разпределените системи, софтуерно дефинираните мрежи, ядрото на Linux и анализа на производителността.

» По-подробно с книгата може да се запознаете на сайта на издателя
» Съдържание
» Извадка

За Хаброжителите отстъпка от 25% с ваучера — Linux

След извършване на плащането за печатната версия на книгата, електронната книга ще бъде изпратена на имейла ви.

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