BPF და eBPF-ის მოკლე შესავალი

ჰეი ჰაბრ! გაცნობებთ, რომ ვემზადებით წიგნის გამოსაცემად"Linux-ის დაკვირვება BPF-ით".

ვინაიდან BPF ვირტუალური მანქანა აგრძელებს განვითარებას და აქტიურად გამოიყენება პრაქტიკაში, ჩვენ თქვენთვის ვთარგმნეთ სტატია, სადაც აღწერილია მისი ძირითადი მახასიათებლები და მიმდინარე მდგომარეობა.

ბოლო წლების განმავლობაში, პროგრამირების ინსტრუმენტებმა და ტექნიკამ მოიპოვა პოპულარობა Linux-ის ბირთვის შეზღუდვების კომპენსაციისთვის იმ შემთხვევებში, როდესაც საჭიროა მაღალი ხარისხის პაკეტის დამუშავება. ამ ტიპის ერთ-ერთ ყველაზე პოპულარულ მეთოდს ე.წ ძირითადი შემოვლითი (კერნელი შემოვლითი) და საშუალებას იძლევა, გამოტოვოთ ბირთვის ქსელური ფენა, შეასრულოს ყველა პაკეტის დამუშავება მომხმარებლის სივრციდან. ბირთვის გვერდის ავლით ასევე ხდება ქსელის ბარათის მართვა მომხმარებლის სივრცე. სხვა სიტყვებით რომ ვთქვათ, ქსელის ბარათთან მუშაობისას ჩვენ ვენდობით დრაივერს მომხმარებლის სივრცე.

ქსელის ბარათის სრული კონტროლის მომხმარებლის სივრცის პროგრამაზე გადაცემით, ჩვენ ვამცირებთ ბირთვის ზედნადებს (კონტექსტის გადამრთველები, ქსელის ფენის დამუშავება, შეფერხებები და ა.შ.), რაც საკმაოდ მნიშვნელოვანია 10 გბ/წმ სიჩქარით მუშაობისას. უფრო მაღალი. ბირთვის გვერდის ავლით, პლუს სხვა ფუნქციების კომბინაცია (პარტიული დამუშავება) და შესრულების ფრთხილად რეგულირება (NUMA ბუღალტერია, CPU იზოლაციადა ა.შ.) შეესაბამება მომხმარებლის სივრცის მაღალი ხარისხის ქსელის საფუძვლებს. შესაძლოა პაკეტების დამუშავების ამ ახალი მიდგომის სამაგალითო მაგალითია DPDK ინტელისგან (მონაცემთა თვითმფრინავის განვითარების ნაკრები), თუმცა არსებობს სხვა ცნობილი ინსტრუმენტები და ტექნიკა, მათ შორის VPP Cisco-დან (Vector Packet Processing), Netmap და, რა თქმა უნდა, სნაბი.

მომხმარებლის სივრცეში ქსელური ურთიერთქმედების ორგანიზებას აქვს მთელი რიგი უარყოფითი მხარეები:

• OS ბირთვი არის აბსტრაქციის ფენა ტექნიკის რესურსებისთვის. იმის გამო, რომ მომხმარებლის სივრცის პროგრამებმა უშუალოდ უნდა მართონ თავიანთი რესურსები, მათ ასევე უნდა მართონ საკუთარი აპარატურა. ეს ხშირად ნიშნავს საკუთარი დრაივერების დაპროგრამებას.
• მას შემდეგ, რაც ჩვენ მთლიანად ვუთმობთ ბირთვის სივრცეს, ჩვენ ასევე უარს ვამბობთ ბირთვის მიერ მოწოდებულ ქსელის ყველა ფუნქციაზე. მომხმარებელთა სივრცის პროგრამებმა ხელახლა უნდა განახორციელონ ფუნქციები, რომლებიც შეიძლება უკვე უზრუნველყოფილი იყოს ბირთვის ან ოპერაციული სისტემის მიერ.
• პროგრამები მუშაობს sandbox რეჟიმში, რაც სერიოზულად ზღუდავს მათ ურთიერთქმედებას და ხელს უშლის მათ ინტეგრირებას ოპერაციული სისტემის სხვა ნაწილებთან.

არსებითად, მომხმარებლის სივრცეში ქსელში ჩართვისას, შესრულების გაუმჯობესება მიიღწევა პაკეტის დამუშავების ბირთვიდან მომხმარებლის სივრცეში გადაადგილებით. XDP აკეთებს ზუსტად საპირისპიროს: ის გადააქვს ქსელის პროგრამებს მომხმარებლის სივრციდან (ფილტრები, გადამყვანები, მარშრუტიზაცია და ა.შ.) ბირთვის ზონაში. XDP საშუალებას გვაძლევს შევასრულოთ ქსელის ფუნქცია, როგორც კი პაკეტი მოხვდება ქსელის ინტერფეისში და სანამ დაიწყებს მოგზაურობას ბირთვის ქსელის ქვესისტემამდე. შედეგად, პაკეტის დამუშავების სიჩქარე მნიშვნელოვნად გაიზარდა. თუმცა, როგორ აძლევს ბირთვი მომხმარებელს საშუალებას გაუშვას თავისი პროგრამები ბირთვის სივრცეში? ამ კითხვაზე პასუხის გაცემამდე მოდით შევხედოთ რა არის BPF.

BPF და eBPF

მთლად მკაფიო სახელის მიუხედავად, BPF (Packet Filtering, Berkeley) არის, ფაქტობრივად, ვირტუალური მანქანის მოდელი. ეს ვირტუალური მანქანა თავდაპირველად შექმნილი იყო პაკეტების ფილტრაციისთვის, აქედან მომდინარეობს სახელი.

BPF-ის გამოყენებით ერთ-ერთი ყველაზე ცნობილი ინსტრუმენტია tcpdump. პაკეტების აღებისას tcpdump მომხმარებელს შეუძლია მიუთითოს გამოხატულება პაკეტის ფილტრაციისთვის. მხოლოდ პაკეტები, რომლებიც ემთხვევა ამ გამონათქვამს, იქნება აღბეჭდილი. მაგალითად, გამოთქმა "tcp dst port 80” ეხება ყველა TCP პაკეტს, რომელიც ჩამოდის პორტში 80. შემდგენელს შეუძლია შეამციროს ეს გამოხატულება BPF ბაიტიკოდად გადაქცევით.

$ sudo tcpdump -d "tcp dst port 80"
(000) ldh [12] (001) jeq #0x86dd jt 2 jf 6
(002) ldb [20] (003) jeq #0x6 jt 4 jf 15
(004) ldh [56] (005) jeq #0x50 jt 14 jf 15
(006) jeq #0x800 jt 7 jf 15
(007) ldb [23] (008) jeq #0x6 jt 9 jf 15
(009) ldh [20] (010) jset #0x1fff jt 15 jf 11
(011) ldxb 4*([14]&0xf)
(012) ldh [x + 16] (013) jeq #0x50 jt 14 jf 15
(014) ret #262144
(015) ret #0

ეს ძირითადად აკეთებს ზემოხსენებულ პროგრამას:

• ინსტრუქცია (000): ატვირთავს პაკეტს ოფსეტური 12, როგორც 16-ბიტიანი სიტყვა, აკუმულატორში. ოფსეტი 12 შეესაბამება პაკეტის ეთერტიპს.
• ინსტრუქცია (001): ადარებს აკუმულატორში არსებულ მნიშვნელობას 0x86dd-ს, ანუ IPv6-ის ეთერტიპის მნიშვნელობას. თუ შედეგი მართალია, მაშინ პროგრამის მრიცხველი მიდის ინსტრუქციაზე (002), ხოლო თუ არა, მაშინ (006).
• ინსტრუქცია (006): ადარებს მნიშვნელობას 0x800-თან (ეთერტიპის მნიშვნელობა IPv4-ისთვის). თუ პასუხი მართალია, მაშინ პროგრამა მიდის (007), თუ არა, მაშინ (015).

და ასე შემდეგ, სანამ პაკეტის ფილტრაციის პროგრამა არ დააბრუნებს შედეგს. ჩვეულებრივ, ეს არის ლოგიკური. ნულოვანი მნიშვნელობის დაბრუნება (ინსტრუქცია (014)) ნიშნავს, რომ პაკეტი დაემთხვა, ხოლო ნულის დაბრუნება (ინსტრუქცია (015)) ნიშნავს, რომ პაკეტი არ დაემთხვა.

BPF ვირტუალური მანქანა და მისი ბაიტეკოდი შემოგვთავაზეს სტივ მაკკენმა და ვან ჯეიკობსონმა 1992 წლის ბოლოს, როდესაც მათი ნაშრომი გამოვიდა. BSD პაკეტის ფილტრი: ახალი არქიტექტურა მომხმარებლის დონეზე პაკეტის დაჭერისთვისპირველად ეს ტექნოლოგია წარმოდგენილი იქნა Usenix-ის კონფერენციაზე 1993 წლის ზამთარში.

იმის გამო, რომ BPF არის ვირტუალური მანქანა, ის განსაზღვრავს გარემოს, რომელშიც პროგრამები მუშაობს. გარდა ბაიტეკოდისა, ის ასევე განსაზღვრავს პაკეტის მეხსიერების მოდელს (ჩატვირთვის ინსტრუქციები ირიბად გამოიყენება პაკეტზე), რეგისტრებს (A და X; აკუმულატორი და ინდექსის რეგისტრები), ნაკაწრის მეხსიერების საცავი და იმპლიციტური პროგრამის მრიცხველი. საინტერესოა, რომ BPF ბაიტიკოდი მოდელირებულია Motorola 6502 ISA-ს მიხედვით. როგორც სტივ მაკკენი იხსენებდა თავის პლენარული ანგარიში Sharkfest '11-ზე, ის იცნობდა 6502-ს უმაღლეს სკოლაში Apple II-ზე პროგრამირებისას და ამ ცოდნამ გავლენა მოახდინა მის მუშაობაზე BPF ბაიტიკოდის დიზაინზე.

BPF მხარდაჭერა განხორციელებულია Linux-ის ბირთვში v2.5 და უფრო გვიან ვერსიაში, რომელიც დამატებულია ძირითადად ჯეი შულიტის მიერ. BPF კოდი უცვლელი დარჩა 2011 წლამდე, როდესაც ერიკ დიუმასეტმა გადააფორმა BPF თარჯიმანი JIT რეჟიმში მუშაობისთვის (წყარო: JIT პაკეტის ფილტრებისთვის). ამის შემდეგ, BPF ბაიტიკოდის ინტერპრეტაციის ნაცვლად, ბირთვს შეეძლო პირდაპირ გადაიყვანოს BPF პროგრამები სამიზნე არქიტექტურაში: x86, ARM, MIPS და ა.შ.

მოგვიანებით, 2014 წელს, ალექსეი სტაროვოიტოვმა შესთავაზა ახალი JIT მექანიზმი BPF-სთვის. სინამდვილეში, ეს ახალი JIT გახდა ახალი არქიტექტურა, რომელიც დაფუძნებულია BPF-ზე და ეწოდა eBPF. ვფიქრობ, ორივე VM თანაარსებობდა გარკვეული დროის განმავლობაში, მაგრამ პაკეტის ფილტრაცია ამჟამად დანერგილია eBPF-ის თავზე. სინამდვილეში, ბევრ თანამედროვე დოკუმენტაციის მაგალითში, BPF მოიხსენიება როგორც eBPF, ხოლო კლასიკური BPF დღეს ცნობილია როგორც cBPF.

eBPF აფართოებს კლასიკურ BPF ვირტუალურ მანქანას რამდენიმე გზით:

• ეყრდნობა თანამედროვე 64-ბიტიან არქიტექტურებს. eBPF იყენებს 64-ბიტიან რეგისტრებს და ზრდის ხელმისაწვდომი რეგისტრების რაოდენობას 2-დან (აკუმულატორი და X) 10-მდე. eBPF ასევე უზრუნველყოფს დამატებით ოპკოდებს (BPF_MOV, BPF_JNE, BPF_CALL…).
• მოწყვეტილია ქსელის ფენის ქვესისტემიდან. BPF იყო მიბმული სურათების მონაცემთა მოდელთან. ვინაიდან იგი გამოიყენებოდა პაკეტების გასაფილტრად, მისი კოდი იყო ქვესისტემაში, რომელიც უზრუნველყოფდა ქსელურ ურთიერთქმედებებს. თუმცა, eBPF ვირტუალური მანქანა აღარ არის დაკავშირებული მონაცემთა მოდელთან და შეიძლება გამოყენებულ იქნას ნებისმიერი მიზნისთვის. ასე რომ, ახლა eBPF პროგრამა შეიძლება დაუკავშირდეს tracepoint-ს ან kprobe-ს. ეს ხსნის კარს eBPF ინსტრუმენტაციისთვის, შესრულების ანალიზისა და მრავალი სხვა გამოყენების შემთხვევისთვის სხვა ბირთვის ქვესისტემების კონტექსტში. ახლა eBPF კოდი მდებარეობს საკუთარ გზაზე: kernel/bpf.
• მონაცემთა გლობალური მაღაზიები სახელწოდებით Maps. რუკები არის საკვანძო მნიშვნელობის მაღაზიები, რომლებიც უზრუნველყოფენ მონაცემთა გაცვლას მომხმარებლის სივრცესა და ბირთვის სივრცეს შორის. eBPF გთავაზობთ რამდენიმე სახის ბარათს.
• მეორადი ფუნქციები. კერძოდ, პაკეტის გადასაწერად, საკონტროლო ჯამის გამოთვლა ან პაკეტის კლონირება. ეს ფუნქციები მუშაობს ბირთვის შიგნით და არ მიეკუთვნება მომხმარებლის სივრცის პროგრამებს. გარდა ამისა, სისტემური ზარები შეიძლება განხორციელდეს eBPF პროგრამებიდან.
• დაასრულეთ ზარები. პროგრამის ზომა eBPF-ში შეზღუდულია 4096 ბაიტით. დასასრულის ზარის ფუნქცია საშუალებას აძლევს eBPF პროგრამას გადასცეს კონტროლი ახალ eBPF პროგრამას და ამით გადალახოს ეს შეზღუდვა (ამ გზით შეიძლება 32-მდე პროგრამა იყოს მიბმული).

eBPF მაგალითი

Linux-ის ბირთვის წყაროებში eBPF-ის რამდენიმე მაგალითია. ისინი ხელმისაწვდომია ნიმუშებზე/bpf/. ამ მაგალითების შესადგენად, უბრალოდ ჩაწერეთ:

$ sudo make samples/bpf/

მე არ დავწერ ახალ მაგალითს eBPF-სთვის, მაგრამ გამოვიყენებ ერთ-ერთ ნიმუშს, რომელიც ხელმისაწვდომია samples/bpf/-ში. მე გადავხედავ კოდის ზოგიერთ ნაწილს და ავხსნი როგორ მუშაობს. მაგალითად, მე ავირჩიე პროგრამა tracex4.

ზოგადად, ნიმუშებში/bpf/ თითოეული მაგალითი შედგება ორი ფაილისგან. Ამ შემთხვევაში:

• tracex4_kern.c, შეიცავს წყაროს კოდს, რომელიც უნდა შესრულდეს ბირთვში, როგორც eBPF ბაიტიკოდი.
• tracex4_user.c, შეიცავს პროგრამას მომხმარებლის სივრციდან.

ამ შემთხვევაში, ჩვენ გვჭირდება კომპილაცია tracex4_kern.c eBPF ბაიტიკოდამდე. ამ მომენტში, gcc არ არსებობს სერვერის ნაწილი eBPF-სთვის. საბედნიეროდ, clang შეუძლია აწარმოოს eBPF ბაიტიკოდი. Makefile იყენებს clang შედგენა tracex4_kern.c ობიექტის ფაილზე.

ზემოთ აღვნიშნე, რომ eBPF-ის ერთ-ერთი ყველაზე საინტერესო მახასიათებელია რუკები. tracex4_kern განსაზღვრავს ერთ რუკას:

struct pair {
    u64 val;
    u64 ip;
};  

struct bpf_map_def SEC("maps") my_map = {
    .type = BPF_MAP_TYPE_HASH,
    .key_size = sizeof(long),
    .value_size = sizeof(struct pair),
    .max_entries = 1000000,
};

BPF_MAP_TYPE_HASH არის eBPF-ის მიერ შემოთავაზებული ბარათის ერთ-ერთი სახეობა. ამ შემთხვევაში, ეს მხოლოდ ჰაშია. თქვენ ასევე შენიშნეთ რეკლამა SEC("maps"). SEC არის მაკრო, რომელიც გამოიყენება ბინარული ფაილის ახალი განყოფილების შესაქმნელად. სინამდვილეში, მაგალითში tracex4_kern განსაზღვრულია კიდევ ორი ​​სექცია:

SEC("kprobe/kmem_cache_free")
int bpf_prog1(struct pt_regs *ctx)
{   
    long ptr = PT_REGS_PARM2(ctx);

    bpf_map_delete_elem(&my_map, &ptr); 
    return 0;
}
    
SEC("kretprobe/kmem_cache_alloc_node") 
int bpf_prog2(struct pt_regs *ctx)
{
    long ptr = PT_REGS_RC(ctx);
    long ip = 0;

    // получаем ip-адрес вызывающей стороны kmem_cache_alloc_node() 
    BPF_KRETPROBE_READ_RET_IP(ip, ctx);

    struct pair v = {
        .val = bpf_ktime_get_ns(),
        .ip = ip,
    };
    
    bpf_map_update_elem(&my_map, &ptr, &v, BPF_ANY);
    return 0;
}   

ეს ორი ფუნქცია საშუალებას გაძლევთ წაშალოთ ჩანაწერი რუკიდან (kprobe/kmem_cache_free) და დაამატეთ ახალი ჩანაწერი რუკაზე (kretprobe/kmem_cache_alloc_node). მთავრული ასოებით დაწერილი ყველა ფუნქციის სახელი შეესაბამება განსაზღვრულ მაკროს bpf_helpers.h.

თუ ობიექტის ფაილის სექციებს გადავყრი, უნდა დავინახო, რომ ეს ახალი სექციები უკვე განსაზღვრულია:

$ objdump -h tracex4_kern.o

tracex4_kern.o: file format elf64-little

Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00000000 0000000000000000 0000000000000000 00000040 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 kprobe/kmem_cache_free 00000048 0000000000000000 0000000000000000 00000040 2**3
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
2 kretprobe/kmem_cache_alloc_node 000000c0 0000000000000000 0000000000000000 00000088 2**3
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
3 maps 0000001c 0000000000000000 0000000000000000 00000148 2**2
CONTENTS, ALLOC, LOAD, DATA
4 license 00000004 0000000000000000 0000000000000000 00000164 2**0
CONTENTS, ALLOC, LOAD, DATA
5 version 00000004 0000000000000000 0000000000000000 00000168 2**2
CONTENTS, ALLOC, LOAD, DATA
6 .eh_frame 00000050 0000000000000000 0000000000000000 00000170 2**3
CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA

Არსებობს ასევე tracex4_user.c, მთავარი პროგრამა. ძირითადად, ეს პროგრამა უსმენს მოვლენებს kmem_cache_alloc_node. როდესაც ასეთი მოვლენა ხდება, შესაბამისი eBPF კოდი სრულდება. კოდი ინახავს ობიექტის IP ატრიბუტს რუკაზე და შემდეგ ობიექტის ციკლი ხდება მთავარი პროგრამის მეშვეობით. მაგალითი:

$ sudo ./tracex4
obj 0xffff8d6430f60a00 is 2sec old was allocated at ip ffffffff9891ad90
obj 0xffff8d6062ca5e00 is 23sec old was allocated at ip ffffffff98090e8f
obj 0xffff8d5f80161780 is 6sec old was allocated at ip ffffffff98090e8f

როგორ არის დაკავშირებული მომხმარებლის კოსმოსური პროგრამა და eBPF პროგრამა? ინიციალიზაციისას tracex4_user.c იტვირთება ობიექტის ფაილი tracex4_kern.o ფუნქციის გამოყენებით load_bpf_file.

int main(int ac, char **argv)
{
    struct rlimit r = {RLIM_INFINITY, RLIM_INFINITY};
    char filename[256];
    int i;

    snprintf(filename, sizeof(filename), "%s_kern.o", argv[0]);

    if (setrlimit(RLIMIT_MEMLOCK, &r)) {
        perror("setrlimit(RLIMIT_MEMLOCK, RLIM_INFINITY)");
        return 1;
    }

    if (load_bpf_file(filename)) {
        printf("%s", bpf_log_buf);
        return 1;
    }

    for (i = 0; ; i++) {
        print_old_objects(map_fd[1]);
        sleep(1);
    }

    return 0;
}

კეთების დროს load_bpf_file ემატება eBPF ფაილში განსაზღვრული ზონდები /sys/kernel/debug/tracing/kprobe_events. ახლა ჩვენ ვუსმენთ ამ მოვლენებს და ჩვენს პროგრამას შეუძლია რაიმე გააკეთოს, როცა ისინი მოხდება.

$ sudo cat /sys/kernel/debug/tracing/kprobe_events
p:kprobes/kmem_cache_free kmem_cache_free
r:kprobes/kmem_cache_alloc_node kmem_cache_alloc_node

ყველა სხვა პროგრამა ნიმუშში/bpf/ სტრუქტურირებულია ანალოგიურად. ისინი ყოველთვის შეიცავს ორ ფაილს:

• XXX_kern.c: eBPF პროგრამა.
• XXX_user.c: მთავარი პროგრამა.

eBPF პროგრამა განსაზღვრავს განყოფილებასთან დაკავშირებულ რუკებს და ფუნქციებს. როდესაც ბირთვი ასხივებს გარკვეული ტიპის მოვლენას (მაგალითად, tracepoint), შეკრული ფუნქციები შესრულებულია. რუკები უზრუნველყოფს კომუნიკაციას ბირთვის პროგრამასა და მომხმარებლის სივრცის პროგრამას შორის.

დასკვნა

ამ სტატიაში BPF და eBPF განიხილეს ზოგადი თვალსაზრისით. ვიცი, რომ დღეს eBPF-ის შესახებ ბევრი ინფორმაცია და რესურსი არსებობს, ამიტომ შემდგომი შესწავლისთვის კიდევ რამდენიმე მასალას გირჩევთ.

გირჩევთ წაიკითხოთ:

• BPF: უნივერსალური ბირთვის ვირტუალური მანქანა ჯონათან კორბეტი. შესავალი BPF-ში და როგორ გადაიქცა ის eBPF-ში.
• საფუძვლიანი შესავალი eBPF ბრენდან გრეგი. სტატია LWN.net-დან. ბრენდანი ხშირად წერს ტვიტერს eBPF-ის შესახებ და ინახავს ამ თემაზე რესურსების სიას თავის ვებსაიტზე. ბლოგის პოსტი.
• შენიშვნები BPF და eBPF-ის შესახებ ჯულია ევანსი. კომენტარები Suchakra Sharma-ს პრეზენტაციაზე „BSD Packet Filter: A New Architecture for User-level Packet Capture“. კომენტარები კარგია და ნამდვილად გვეხმარება სლაიდების გაგებაში.
• eBPF, ნაწილი 1: წარსული, აწმყო და მომავალი ფერის ელისი. დიდი ხნის განმავლობაში გაგრძელებამაგრამ ღირს წაკითხვა. ერთ-ერთი საუკეთესო eBPF სტატია, რომელიც მე შემხვედრია.

წყარო: www.habr.com