BPF პატარებისთვის, ნაწილი პირველი: გაფართოებული BPF

თავიდან იყო ტექნოლოგია და მას ერქვა BPF. ჩვენ მას ვუყურებდით წინა, ამ სერიის ძველი აღთქმის სტატია. 2013 წელს, ალექსეი სტაროვოიტოვისა და დანიელ ბორკმანის ძალისხმევით, შეიქმნა მისი გაუმჯობესებული ვერსია, რომელიც ოპტიმიზირებულია თანამედროვე 64-ბიტიანი მანქანებისთვის და ჩართული იყო Linux-ის ბირთვში. ამ ახალ ტექნოლოგიას მოკლედ ეწოდა Internal BPF, შემდეგ დაარქვეს Extended BPF და ახლა, რამდენიმე წლის შემდეგ, ყველა მას უბრალოდ BPF-ს უწოდებს.

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

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

სტატიის რეზიუმე

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

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

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

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

Пишем программы BPF с помощью libbpf. რა თქმა უნდა, შეგიძლიათ დაწეროთ პროგრამები სისტემური ზარის გამოყენებით. მაგრამ ძნელია. უფრო რეალისტური სცენარისთვის, ბირთვულმა პროგრამისტებმა შეიმუშავეს ბიბლიოთეკა libbpf. ჩვენ შევქმნით BPF აპლიკაციის ძირითად ჩონჩხს, რომელსაც გამოვიყენებთ შემდგომ მაგალითებში.

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

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

განვითარების ინსტრუმენტები. დახმარების განყოფილება, თუ როგორ უნდა შეიკრიბოთ საჭირო კომუნალური პროგრამები და ბირთვი ექსპერიმენტებისთვის.

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

შესავალი BPF არქიტექტურაში

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

ახალი BPF შეიქმნა, როგორც პასუხი 64-ბიტიანი მანქანების, ღრუბლოვანი სერვისების და SDN-ის შესაქმნელად ხელსაწყოების გაზრდილი საჭიროების პასუხად.Sპროგრამული უზრუნველყოფა-dეფინა nდამუშავება). ბირთვის ქსელის ინჟინრების მიერ შემუშავებული, როგორც კლასიკური BPF-ის გაუმჯობესებული შემცვლელი, ახალი BPF ფაქტიურად ექვსი თვის შემდეგ იპოვა აპლიკაციები Linux სისტემების თვალყურის დევნების რთულ ამოცანაში და ახლა, მისი გამოჩენიდან ექვსი წლის შემდეგ, ჩვენ დაგვჭირდება მთელი შემდეგი სტატია. ჩამოთვალეთ სხვადასხვა ტიპის პროგრამები.

Სასაცილო სურათები

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

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

BPF არქიტექტურა ნაწილობრივ შექმნილია თანამედროვე მანქანებზე ეფექტურად მუშაობისთვის. იმისათვის, რომ ეს პრაქტიკაში იმუშაოს, BPF ბაიტიკოდი, რომელიც ჩაიტვირთება ბირთვში, ითარგმნება ადგილობრივ კოდში, კომპონენტის გამოყენებით, რომელსაც ეწოდება JIT შემდგენელი (Just In Tდრო). შემდეგი, თუ გახსოვთ, კლასიკურ BPF-ში პროგრამა ჩაიტვირთა ბირთვში და მიმაგრებული იყო მოვლენის წყაროზე ატომურად - ერთი სისტემური ზარის კონტექსტში. ახალ არქიტექტურაში ეს ხდება ორ ეტაპად - პირველი, კოდი იტვირთება ბირთვში სისტემური ზარის გამოყენებით. bpf(2)და შემდეგ, მოგვიანებით, სხვა მექანიზმების მეშვეობით, რომლებიც განსხვავდება პროგრამის ტიპის მიხედვით, პროგრამა მიმაგრებულია მოვლენის წყაროზე.

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

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

მაშ რა ვისწავლეთ აქამდე? მომხმარებელი წერს პროგრამას C-ზე, იტვირთება მას ბირთვში სისტემური ზარის გამოყენებით bpf(2), სადაც ის მოწმდება ვერიფიკატორის მიერ და ითარგმნება მშობლიურ ბაიტეკოდში. შემდეგ იგივე ან სხვა მომხმარებელი აკავშირებს პროგრამას მოვლენის წყაროსთან და ის იწყებს შესრულებას. ჩატვირთვისა და კავშირის გამიჯვნა აუცილებელია რამდენიმე მიზეზის გამო. ჯერ ერთი, ვერიფიკატორის გაშვება შედარებით ძვირია და ერთი და იგივე პროგრამის რამდენჯერმე გადმოტვირთვით კომპიუტერის დროს ვკარგავთ. მეორეც, ზუსტად როგორ არის დაკავშირებული პროგრამა, დამოკიდებულია მის ტიპზე და ერთი წლის წინ შემუშავებული ერთი "უნივერსალური" ინტერფეისი შეიძლება არ იყოს შესაფერისი ახალი ტიპის პროგრამებისთვის. (თუმცა ახლა, როდესაც არქიტექტურა უფრო მომწიფებულია, არსებობს იდეა ამ ინტერფეისის დონეზე გაერთიანების libbpf.)

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

რუკებზე წვდომა ხდება მომხმარებლის პროცესებიდან სისტემური ზარის გამოყენებით bpf(2), და ბირთვში გაშვებული BPF პროგრამებიდან დამხმარე ფუნქციების გამოყენებით. უფრო მეტიც, დამხმარეები არსებობენ არა მხოლოდ რუკებთან მუშაობისთვის, არამედ ბირთვის სხვა შესაძლებლობებზე წვდომისთვის. მაგალითად, BPF პროგრამებს შეუძლიათ გამოიყენონ დამხმარე ფუნქციები პაკეტების სხვა ინტერფეისებზე გადასატანად, perf მოვლენების გენერირებისთვის, ბირთვის სტრუქტურებზე წვდომისთვის და ა.შ.

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

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

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

მოდით დავასრულოთ სტატიის მიმოხილვის ნაწილი და უფრო დეტალურად გადავხედოთ ვირტუალურ მანქანას და BPF ეკოსისტემას.

დიგრესია: კომუნალური

იმისათვის, რომ შეძლოთ მაგალითების გაშვება შემდეგ განყოფილებებში, შეიძლება დაგჭირდეთ რამდენიმე კომუნალური პროგრამა, სულ მცირე llvm/clang bpf-ის მხარდაჭერით და bpftool... თავში განვითარების ინსტრუმენტები თქვენ შეგიძლიათ წაიკითხოთ ინსტრუქციები უტილიტების აწყობის შესახებ, ისევე როგორც თქვენი ბირთვი. ეს განყოფილება მოთავსებულია ქვემოთ ისე, რომ არ დაირღვეს ჩვენი პრეზენტაციის ჰარმონია.

BPF ვირტუალური მანქანების რეგისტრებისა და ინსტრუქციის სისტემა

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

BPF-ს აქვს თერთმეტი მომხმარებლისთვის ხელმისაწვდომი 64-ბიტიანი რეგისტრი r0-r10 და პროგრამის მრიცხველი. რეგისტრაცია r10 შეიცავს ჩარჩოს მაჩვენებელს და არის მხოლოდ წაკითხვადი. პროგრამებს აქვთ წვდომა 512 ბაიტიან დასტაზე მუშაობის დროს და შეუზღუდავი რაოდენობის საერთო მეხსიერება რუქების სახით.

BPF პროგრამებს უფლება აქვთ განახორციელონ პროგრამის ტიპის ბირთვის დამხმარეების კონკრეტული ნაკრები და, ახლახან, რეგულარული ფუნქციები. თითოეულ გამოძახებულ ფუნქციას შეუძლია მიიღოს ხუთამდე არგუმენტი, რომლებიც გადაცემულია რეესტრებში r1-r5და დაბრუნებული მნიშვნელობა გადაეცემა r0. გარანტირებულია, რომ ფუნქციიდან დაბრუნების შემდეგ რეგისტრების შინაარსი r6-r9 არ შეიცვლება.

პროგრამის ეფექტური თარგმნისთვის, რეგისტრაცია r0-r11 ყველა მხარდაჭერილი არქიტექტურისთვის ცალსახად არის შედგენილი რეალურ რეგისტრებთან, მიმდინარე არქიტექტურის ABI მახასიათებლების გათვალისწინებით. მაგალითად, ამისთვის x86_64 რეგისტრები r1-r5, რომელიც გამოიყენება ფუნქციის პარამეტრების გადასაცემად, ნაჩვენებია rdi, rsi, rdx, rcx, r8, რომლებიც გამოიყენება ფუნქციებზე პარამეტრების გადასაცემად x86_64. მაგალითად, კოდი მარცხნივ ითარგმნება, როგორც მარჯვენა კოდი ასე:

1:  (b7) r1 = 1                    mov    $0x1,%rdi
2:  (b7) r2 = 2                    mov    $0x2,%rsi
3:  (b7) r3 = 3                    mov    $0x3,%rdx
4:  (b7) r4 = 4                    mov    $0x4,%rcx
5:  (b7) r5 = 5                    mov    $0x5,%r8
6:  (85) call pc+1                 callq  0x0000000000001ee8

დარეგისტრირება r0 ასევე გამოიყენება პროგრამის შესრულების შედეგის დასაბრუნებლად და რეესტრში r1 პროგრამას გადაეცემა კონტექსტის მაჩვენებელი - პროგრამის ტიპის მიხედვით, ეს შეიძლება იყოს, მაგალითად, სტრუქტურა struct xdp_md (XDP-სთვის) ან სტრუქტურა struct __sk_buff (სხვადასხვა ქსელური პროგრამებისთვის) ან სტრუქტურა struct pt_regs (სხვადასხვა ტიპის ტრასინგის პროგრამებისთვის) და ა.შ.

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

გავაგრძელოთ აღწერა და ვისაუბროთ ამ ობიექტებთან მუშაობის ბრძანების სისტემაზე. ყველა (თითქმის ყველა) BPF ინსტრუქციებს აქვს ფიქსირებული 64 ბიტიანი ზომა. თუ გადახედავთ ერთ ინსტრუქციას 64-ბიტიანი Big Endian მანქანაზე, ნახავთ

აქ Code - ეს არის ინსტრუქციის კოდირება, Dst/Src არის მიმღების და წყაროს კოდირება, შესაბამისად, Off - 16-ბიტიანი ხელმოწერილი შეწევა და Imm არის 32-ბიტიანი ხელმოწერილი მთელი რიცხვი, რომელიც გამოიყენება ზოგიერთ ინსტრუქციაში (cBPF მუდმივის K-ის მსგავსი). კოდირება Code აქვს ერთი ორი ტიპი:

ინსტრუქციის კლასები 0, 1, 2, 3 განსაზღვრავს ბრძანებებს მეხსიერებასთან მუშაობისთვის. მათ ჰქვია, BPF_LD, BPF_LDX, BPF_ST, BPF_STX, შესაბამისად. კლასები 4, 7 (BPF_ALU, BPF_ALU64) წარმოადგენს ALU ინსტრუქციების ერთობლიობას. კლასები 5, 6 (BPF_JMP, BPF_JMP32) შეიცავს ნახტომის ინსტრუქციებს.

BPF ინსტრუქციის სისტემის შესწავლის შემდგომი გეგმა ასეთია: იმის ნაცვლად, რომ ზედმიწევნით ჩამოვთვალოთ ყველა ინსტრუქცია და მათი პარამეტრი, ჩვენ გადავხედავთ რამდენიმე მაგალითს ამ განყოფილებაში და მათგან გაირკვევა, თუ როგორ მუშაობს ინსტრუქციები რეალურად და როგორ. ხელით დაშალეთ ნებისმიერი ბინარული ფაილი BPF-ისთვის. მასალის შემდგომ სტატიაში გასამყარებლად, ჩვენ ასევე შევხვდებით ინდივიდუალურ ინსტრუქციებს განყოფილებებში Verifier-ის, JIT შემდგენელის, კლასიკური BPF-ის თარგმანის შესახებ, ასევე რუკების შესწავლისას, ფუნქციების დარეკვისას და ა.შ.

როდესაც ვსაუბრობთ ინდივიდუალურ ინსტრუქციებზე, ჩვენ მივმართავთ ძირითად ფაილებს bpf.h и bpf_common.h, რომელიც განსაზღვრავს BPF ინსტრუქციების ციფრულ კოდებს. არქიტექტურის დამოუკიდებლად შესწავლისას და/ან ბინარების ანალიზისას, შეგიძლიათ იპოვოთ სემანტიკა შემდეგ წყაროებში, დალაგებული სირთულის მიხედვით: არაოფიციალური eBPF სპეციფიკაცია, BPF და XDP საცნობარო გზამკვლევი, ინსტრუქციების ნაკრები, Documentation/networking/filter.txt და, რა თქმა უნდა, Linux-ის საწყის კოდში - ვერიფიკატორი, JIT, BPF თარჯიმანი.

მაგალითი: BPF-ის დაშლა თქვენს თავში

მოდით შევხედოთ მაგალითს, რომელშიც ჩვენ ვადგენთ პროგრამას readelf-example.c და შეხედეთ შედეგად ორობითს. ჩვენ გამოვაქვეყნებთ ორიგინალურ შინაარსს readelf-example.c ქვემოთ, მას შემდეგ, რაც ჩვენ აღვადგენთ მის ლოგიკას ორობითი კოდებიდან:

$ clang -target bpf -c readelf-example.c -o readelf-example.o -O2
$ llvm-readelf -x .text readelf-example.o
Hex dump of section '.text':
0x00000000 b7000000 01000000 15010100 00000000 ................
0x00000010 b7000000 02000000 95000000 00000000 ................

გამომავალი პირველი სვეტი readelf არის ჩაღრმავება და, შესაბამისად, ჩვენი პროგრამა შედგება ოთხი ბრძანებისგან:

Code Dst Src Off  Imm
b7   0   0   0000 01000000
15   0   1   0100 00000000
b7   0   0   0000 02000000
95   0   0   0000 00000000

ბრძანების კოდები თანაბარია b7, 15, b7 и 95. შეგახსენებთ, რომ ყველაზე ნაკლებად მნიშვნელოვანი სამი ბიტი არის ინსტრუქციის კლასი. ჩვენს შემთხვევაში, ყველა ინსტრუქციის მეოთხე ბიტი ცარიელია, ამიტომ ინსტრუქციის კლასები არის 7, 5, 7, 5, შესაბამისად. კლასი 7 არის BPF_ALU64და 5 არის BPF_JMP. ორივე კლასისთვის, ინსტრუქციის ფორმატი იგივეა (იხ. ზემოთ) და ჩვენ შეგვიძლია გადავიწეროთ ჩვენი პროგრამა ასე (ამავე დროს ჩვენ გადავწერთ დარჩენილ სვეტებს ადამიანის სახით):

Op S  Class   Dst Src Off  Imm
b  0  ALU64   0   0   0    1
1  0  JMP     0   1   1    0
b  0  ALU64   0   0   0    2
9  0  JMP     0   0   0    0

ოპერაცია b კლასი ALU64 - რამდენად BPF_MOV. ის ანიჭებს მნიშვნელობას დანიშნულების რეგისტრს. თუ ბიტი დაყენებულია s (წყარო), მაშინ მნიშვნელობა აღებულია წყაროს რეესტრიდან და თუ, როგორც ჩვენს შემთხვევაში, არ არის მითითებული, მაშინ მნიშვნელობა აღებულია ველიდან. Imm. ასე რომ, პირველ და მესამე ინსტრუქციებში ჩვენ ვასრულებთ ოპერაციას r0 = Imm. გარდა ამისა, JMP კლასი 1 ოპერაცია არის BPF_JEQ (ხტომა თუ თანაბარია). ჩვენს შემთხვევაში, მას შემდეგ, რაც ცოტა S არის ნული, ის ადარებს წყაროს რეგისტრის მნიშვნელობას ველთან Imm. თუ მნიშვნელობები ემთხვევა, მაშინ ხდება გადასვლა PC + Offსად PC, როგორც ყოველთვის, შეიცავს შემდეგი ინსტრუქციის მისამართს. და ბოლოს, JMP კლასი 9 ოპერაცია არის BPF_EXIT. ეს ინსტრუქცია წყვეტს პროგრამას, ბრუნდება ბირთვში r0. მოდით დავამატოთ ახალი სვეტი ჩვენს ცხრილს:

Op    S  Class   Dst Src Off  Imm    Disassm
MOV   0  ALU64   0   0   0    1      r0 = 1
JEQ   0  JMP     0   1   1    0      if (r1 == 0) goto pc+1
MOV   0  ALU64   0   0   0    2      r0 = 2
EXIT  0  JMP     0   0   0    0      exit

ჩვენ შეგვიძლია გადავიწეროთ ეს უფრო მოსახერხებელი ფორმით:

     r0 = 1
     if (r1 == 0) goto END
     r0 = 2
END:
     exit

თუ გავიხსენებთ რა არის რეესტრში r1 პროგრამას გადაეცემა კონტექსტის მაჩვენებელი ბირთვიდან და რეესტრში r0 მნიშვნელობა უბრუნდება ბირთვს, მაშინ ჩვენ ვხედავთ, რომ თუ კონტექსტის მაჩვენებელი ნულია, მაშინ ვაბრუნებთ 1-ს, წინააღმდეგ შემთხვევაში - 2-ს. მოდით შევამოწმოთ, რომ ჩვენ მართალი ვართ წყაროს დათვალიერებით:

$ cat readelf-example.c
int foo(void *ctx)
{
        return ctx ? 2 : 1;
}

დიახ, ეს უაზრო პროგრამაა, მაგრამ ის ითარგმნება მხოლოდ ოთხ მარტივ ინსტრუქციაში.

გამონაკლისი მაგალითი: 16 ბაიტიანი ინსტრუქცია

ადრე აღვნიშნეთ, რომ ზოგიერთი ინსტრუქცია 64 ბიტზე მეტს იღებს. ეს ეხება, მაგალითად, ინსტრუქციებს lddw (კოდი = 0x18 = BPF_LD | BPF_DW | BPF_IMM) — ჩატვირთეთ ორმაგი სიტყვა ველებიდან რეესტრში Imm. ფაქტია, რომ Imm აქვს ზომა 32, ხოლო ორმაგი სიტყვა არის 64 ბიტი, ასე რომ, 64-ბიტიანი უშუალო მნიშვნელობის ჩატვირთვა რეესტრში ერთ 64-ბიტიან ინსტრუქციაში არ იმუშავებს. ამისათვის გამოიყენება ორი მიმდებარე ინსტრუქცია ველში 64-ბიტიანი მნიშვნელობის მეორე ნაწილის შესანახად Imm... მაგალითი:

$ cat x64.c
long foo(void *ctx)
{
        return 0x11223344aabbccdd;
}
$ clang -target bpf -c x64.c -o x64.o -O2
$ llvm-readelf -x .text x64.o
Hex dump of section '.text':
0x00000000 18000000 ddccbbaa 00000000 44332211 ............D3".
0x00000010 95000000 00000000                   ........

ბინარულ პროგრამაში მხოლოდ ორი ინსტრუქციაა:

Binary                                 Disassm
18000000 ddccbbaa 00000000 44332211    r0 = Imm[0]|Imm[1]
95000000 00000000                      exit

ჩვენ კვლავ შევხვდებით ინსტრუქციებით lddw, როცა ვსაუბრობთ გადაადგილებაზე და რუკებთან მუშაობაზე.

მაგალითი: BPF-ის დაშლა სტანდარტული ხელსაწყოების გამოყენებით

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

$ llvm-objdump -d x64.o

Disassembly of section .text:

0000000000000000 <foo>:
 0: 18 00 00 00 dd cc bb aa 00 00 00 00 44 33 22 11 r0 = 1234605617868164317 ll
 2: 95 00 00 00 00 00 00 00 exit

BPF ობიექტების სიცოცხლის ციკლი, bpffs ფაილური სისტემა

(პირველად ვისწავლე ამ ქვეთავში აღწერილი ზოგიერთი დეტალი პოსტი ალექსეი სტაროვოიტოვი BPF ბლოგი.)

BPF ობიექტები - პროგრამები და რუქები - იქმნება მომხმარებლის სივრციდან ბრძანებების გამოყენებით BPF_PROG_LOAD и BPF_MAP_CREATE სისტემური ზარი bpf(2), ჩვენ ვისაუბრებთ ზუსტად იმაზე, თუ როგორ ხდება ეს შემდეგ განყოფილებაში. ეს ქმნის ბირთვის მონაცემთა სტრუქტურებს და თითოეული მათგანისთვის refcount (მინიშნებების რაოდენობა) დაყენებულია ერთზე და ფაილის აღწერილობა, რომელიც მიუთითებს ობიექტზე, უბრუნდება მომხმარებელს. სახელურის დახურვის შემდეგ refcount ობიექტი მცირდება ერთით და როდესაც ის მიაღწევს ნულს, ობიექტი ნადგურდება.

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

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

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

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

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

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

BPF ფაილური სისტემა ჩვეულებრივ დამონტაჟებულია /sys/fs/bpf, მაგრამ ის ასევე შეიძლება დამონტაჟდეს ადგილობრივად, მაგალითად, ასე:

$ mkdir bpf-mountpoint
$ sudo mount -t bpf none bpf-mountpoint

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

$ cat test.c
__attribute__((section("xdp"), used))
int test(void *ctx)
{
        return 0;
}

char _license[] __attribute__((section("license"), used)) = "GPL";

მოდით შევადგინოთ ეს პროგრამა და შევქმნათ ფაილური სისტემის ლოკალური ასლი bpffs:

$ clang -target bpf -c test.c -o test.o
$ mkdir bpf-mountpoint
$ sudo mount -t bpf none bpf-mountpoint

ახლა გადმოვწეროთ ჩვენი პროგრამა უტილიტის გამოყენებით bpftool და გადახედეთ თანმხლებ სისტემის ზარებს bpf(2) (ზოგიერთი შეუსაბამო სტრიქონი ამოღებულია ზოლის გამომავალიდან):

$ sudo strace -e bpf bpftool prog load ./test.o bpf-mountpoint/test
bpf(BPF_PROG_LOAD, {prog_type=BPF_PROG_TYPE_XDP, prog_name="test", ...}, 120) = 3
bpf(BPF_OBJ_PIN, {pathname="bpf-mountpoint/test", bpf_fd=3}, 120) = 0

აქ ჩვენ ჩატვირთეთ პროგრამა გამოყენებით BPF_PROG_LOAD, მიიღო ფაილის აღმწერი ბირთვიდან 3 და ბრძანების გამოყენებით BPF_OBJ_PIN დაამაგრა ეს ფაილის აღმწერი ფაილად "bpf-mountpoint/test". ამის შემდეგ ჩამტვირთავი პროგრამა bpftool დაასრულა მუშაობა, მაგრამ ჩვენი პროგრამა დარჩა ბირთვში, თუმცა ჩვენ არ მივუმაგრეთ იგი არცერთ ქსელურ ინტერფეისს:

$ sudo bpftool prog | tail -3
783: xdp  name test  tag 5c8ba0cf164cb46c  gpl
        loaded_at 2020-05-05T13:27:08+0000  uid 0
        xlated 24B  jited 41B  memlock 4096B

ჩვენ შეგვიძლია ჩვეულებრივ წავშალოთ ფაილის ობიექტი unlink(2) და ამის შემდეგ წაიშლება შესაბამისი პროგრამა:

$ sudo rm ./bpf-mountpoint/test
$ sudo bpftool prog show id 783
Error: get by id (783): No such file or directory

ობიექტების წაშლა

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

BPF პროგრამების ზოგიერთი ტიპი საშუალებას გაძლევთ შეცვალოთ პროგრამა ფრენაზე, ე.ი. უზრუნველყოს თანმიმდევრობის ატომურობა replace = detach old program, attach new program. ამ შემთხვევაში, პროგრამის ძველი ვერსიის ყველა აქტიური ინსტანცია დაასრულებს თავის მუშაობას და ახალი პროგრამიდან შეიქმნება ახალი ღონისძიების დამმუშავებლები და აქ „ატომურობა“ ნიშნავს, რომ არც ერთი ღონისძიება არ იქნება გამოტოვებული.

პროგრამების მიმაგრება მოვლენის წყაროებზე

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

ობიექტების მანიპულირება bpf სისტემური ზარის გამოყენებით

BPF პროგრამები

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

#include <linux/bpf.h>

int bpf(int cmd, union bpf_attr *attr, unsigned int size);

აი გუნდი cmd არის ტიპის ერთ-ერთი მნიშვნელობა enum bpf_cmd, attr — პარამეტრების მაჩვენებელი კონკრეტული პროგრამისთვის და size - ობიექტის ზომა მაჩვენებელის მიხედვით, ე.ი. ჩვეულებრივ ეს sizeof(*attr). ბირთვში 5.8 სისტემური ზარი bpf მხარს უჭერს 34 სხვადასხვა ბრძანებას და განსაზღვრა union bpf_attr იკავებს 200 ხაზს. მაგრამ ჩვენ ამან არ უნდა შეგვაშინოს, რადგან რამდენიმე სტატიის განმავლობაში გავეცნობით ბრძანებებს და პარამეტრებს.

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

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

r0 = 2
exit

მას შემდეგ რაც გადავწყვიტეთ რომ ჩვენ ავტვირთავთ, შეგვიძლია გითხრათ, როგორ გავაკეთებთ ამას:

#define _GNU_SOURCE
#include <string.h>
#include <unistd.h>
#include <sys/syscall.h>
#include <linux/bpf.h>

static inline __u64 ptr_to_u64(const void *ptr)
{
        return (__u64) (unsigned long) ptr;
}

int main(void)
{
    struct bpf_insn insns[] = {
        {
            .code = BPF_ALU64 | BPF_MOV | BPF_K,
            .dst_reg = BPF_REG_0,
            .imm = XDP_PASS
        },
        {
            .code = BPF_JMP | BPF_EXIT
        },
    };

    union bpf_attr attr = {
        .prog_type = BPF_PROG_TYPE_XDP,
        .insns     = ptr_to_u64(insns),
        .insn_cnt  = sizeof(insns)/sizeof(insns[0]),
        .license   = ptr_to_u64("GPL"),
    };

    strncpy(attr.prog_name, "woo", sizeof(attr.prog_name));
    syscall(__NR_bpf, BPF_PROG_LOAD, &attr, sizeof(attr));

    for ( ;; )
        pause();
}

პროგრამაში საინტერესო მოვლენები იწყება მასივის განსაზღვრით insns - ჩვენი BPF პროგრამა მანქანის კოდში. ამ შემთხვევაში, BPF პროგრამის თითოეული ინსტრუქცია შეფუთულია სტრუქტურაში bpf_insn. პირველი ელემენტი insns შეესაბამება მითითებებს r0 = 2, მეორე - exit.

უკან დახევა. ბირთვი განსაზღვრავს უფრო მოსახერხებელ მაკროებს მანქანების კოდების დასაწერად და ბირთვის სათაურის ფაილის გამოსაყენებლად tools/include/linux/filter.h შეგვეძლო დაწერა

struct bpf_insn insns[] = {
    BPF_MOV64_IMM(BPF_REG_0, XDP_PASS),
    BPF_EXIT_INSN()
};

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

BPF პროგრამის განსაზღვრის შემდეგ გადავდივართ მის ბირთვში ჩატვირთვაზე. ჩვენი მინიმალისტური პარამეტრების ნაკრები attr მოიცავს პროგრამის ტიპს, ინსტრუქციების კომპლექტს და რაოდენობას, საჭირო ლიცენზიას და სახელს "woo", რომელსაც ვიყენებთ ჩამოტვირთვის შემდეგ სისტემაში ჩვენი პროგრამის საპოვნელად. პროგრამა, როგორც დაპირდა, იტვირთება სისტემაში სისტემური ზარის გამოყენებით bpf.

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

კარგად, ჩვენ მზად ვართ ტესტირებისთვის. მოდით შევიკრიბოთ და გავუშვათ პროგრამა ქვეშ straceიმის შესამოწმებლად, რომ ყველაფერი მუშაობს ისე, როგორც უნდა:

$ clang -g -O2 simple-prog.c -o simple-prog

$ sudo strace ./simple-prog
execve("./simple-prog", ["./simple-prog"], 0x7ffc7b553480 /* 13 vars */) = 0
...
bpf(BPF_PROG_LOAD, {prog_type=BPF_PROG_TYPE_XDP, insn_cnt=2, insns=0x7ffe03c4ed50, license="GPL", log_level=0, log_size=0, log_buf=NULL, kern_version=KERNEL_V
ERSION(0, 0, 0), prog_flags=0, prog_name="woo", prog_ifindex=0, expected_attach_type=BPF_CGROUP_INET_INGRESS}, 72) = 3
pause(

Ყველაფერი კარგადაა, bpf(2) დაგვიბრუნდა სახელური 3 და ჩვენ შევედით უსასრულო მარყუჟში pause(). შევეცადოთ ვიპოვოთ ჩვენი პროგრამა სისტემაში. ამისათვის ჩვენ გადავალთ სხვა ტერმინალში და გამოვიყენებთ კომუნალურ პროგრამას bpftool:

# bpftool prog | grep -A3 woo
390: xdp  name woo  tag 3b185187f1855c4c  gpl
        loaded_at 2020-08-31T24:66:44+0000  uid 0
        xlated 16B  jited 40B  memlock 4096B
        pids simple-prog(10381)

ჩვენ ვხედავთ, რომ სისტემაში არის დატვირთული პროგრამა woo რომლის გლობალური ID არის 390 და ამჟამად მიმდინარეობს simple-prog არის ღია ფაილის აღმწერი, რომელიც მიუთითებს პროგრამაზე (და თუ simple-prog მაშინ დაასრულებს საქმეს woo გაქრება). როგორც მოსალოდნელი იყო, პროგრამა woo იღებს 16 ბაიტს - ორ ინსტრუქციას - ორობითი კოდების BPF არქიტექტურაში, მაგრამ მისი მშობლიური ფორმით (x86_64) ის უკვე 40 ბაიტია. მოდით შევხედოთ ჩვენს პროგრამას მისი ორიგინალური ფორმით:

# bpftool prog dump xlated id 390
   0: (b7) r0 = 2
   1: (95) exit

არავითარი სიურპრიზები. ახლა მოდით გადავხედოთ JIT შემდგენელის მიერ გენერირებულ კოდს:

# bpftool prog dump jited id 390
bpf_prog_3b185187f1855c4c_woo:
   0:   nopl   0x0(%rax,%rax,1)
   5:   push   %rbp
   6:   mov    %rsp,%rbp
   9:   sub    $0x0,%rsp
  10:   push   %rbx
  11:   push   %r13
  13:   push   %r14
  15:   push   %r15
  17:   pushq  $0x0
  19:   mov    $0x2,%eax
  1e:   pop    %rbx
  1f:   pop    %r15
  21:   pop    %r14
  23:   pop    %r13
  25:   pop    %rbx
  26:   leaveq
  27:   retq

არ არის ძალიან ეფექტური exit(2), მაგრამ სამართლიანად რომ ვთქვათ, ჩვენი პროგრამა ძალიან მარტივია და არატრივიალური პროგრამებისთვის JIT შემდგენლის მიერ დამატებული პროლოგი და ეპილოგი, რა თქმა უნდა, საჭიროა.

რუკები

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

დაუყოვნებლივ ვთქვათ, რომ რუქების შესაძლებლობები არ შემოიფარგლება მხოლოდ საერთო მეხსიერებაზე წვდომით. არსებობს სპეციალური დანიშნულების რუქები, რომლებიც შეიცავს, მაგალითად, მითითებებს BPF პროგრამებისკენ ან ქსელის ინტერფეისების მითითებებს, პერფ მოვლენებთან მუშაობის რუქებს და ა.შ. მათზე აქ არ ვისაუბრებთ, რათა მკითხველი არ დავაბნიოთ. გარდა ამისა, ჩვენ უგულებელყოფთ სინქრონიზაციის საკითხებს, რადგან ეს არ არის მნიშვნელოვანი ჩვენი მაგალითებისთვის. ხელმისაწვდომი რუქების ტიპების სრული სია შეგიძლიათ იხილოთ აქ <linux/bpf.h>, და ამ განყოფილებაში მაგალითად ავიღებთ ისტორიულად პირველ ტიპს, ჰეშის ცხრილს BPF_MAP_TYPE_HASH.

თუ შექმნით ჰეშის ცხრილს, ვთქვათ, C++-ში, თქვენ იტყვით unordered_map<int,long> woo, რაც რუსულად ნიშნავს „მაგიდა მჭირდება woo შეუზღუდავი ზომა, რომლის გასაღებები არის ტიპის int, და მნიშვნელობები არის ტიპი long" იმისათვის, რომ შევქმნათ BPF ჰეშის ცხრილი, ჩვენ უნდა გავაკეთოთ დაახლოებით იგივე, გარდა იმისა, რომ ჩვენ უნდა მივუთითოთ ცხრილის მაქსიმალური ზომა და იმის ნაცვლად, რომ მივუთითოთ გასაღებების ტიპები და მნიშვნელობები, ჩვენ უნდა მივუთითოთ მათი ზომები ბაიტებში. . რუქების შესაქმნელად გამოიყენეთ ბრძანება BPF_MAP_CREATE სისტემური ზარი bpf. მოდით შევხედოთ მეტ-ნაკლებად მინიმალურ პროგრამას, რომელიც ქმნის რუკას. წინა პროგრამის შემდეგ, რომელიც იტვირთება BPF პროგრამებს, ეს მარტივი უნდა მოგეჩვენოთ:

$ cat simple-map.c
#define _GNU_SOURCE
#include <string.h>
#include <unistd.h>
#include <sys/syscall.h>
#include <linux/bpf.h>

int main(void)
{
    union bpf_attr attr = {
        .map_type = BPF_MAP_TYPE_HASH,
        .key_size = sizeof(int),
        .value_size = sizeof(int),
        .max_entries = 4,
    };
    strncpy(attr.map_name, "woo", sizeof(attr.map_name));
    syscall(__NR_bpf, BPF_MAP_CREATE, &attr, sizeof(attr));

    for ( ;; )
        pause();
}

აქ ჩვენ განვსაზღვრავთ პარამეტრების კომპლექტს attr, რომელშიც ჩვენ ვამბობთ „მე მჭირდება ჰეშის ცხრილი გასაღებებით და ზომის მნიშვნელობებით sizeof(int), რომელშიც მაქსიმუმ ოთხი ელემენტის ჩასმა შემიძლია." BPF რუქების შექმნისას შეგიძლიათ მიუთითოთ სხვა პარამეტრები, მაგალითად, ისევე, როგორც პროგრამის მაგალითში, ჩვენ დავაზუსტეთ ობიექტის სახელი, როგორც "woo".

მოდით შევადგინოთ და გავუშვათ პროგრამა:

$ clang -g -O2 simple-map.c -o simple-map
$ sudo strace ./simple-map
execve("./simple-map", ["./simple-map"], 0x7ffd40a27070 /* 14 vars */) = 0
...
bpf(BPF_MAP_CREATE, {map_type=BPF_MAP_TYPE_HASH, key_size=4, value_size=4, max_entries=4, map_name="woo", ...}, 72) = 3
pause(

აი სისტემური ზარი bpf(2) დაგვიბრუნა აღწერის რუკის ნომერი 3 და შემდეგ პროგრამა, როგორც მოსალოდნელი იყო, ელოდება შემდგომ ინსტრუქციებს სისტემურ ზარში pause(2).

ახლა მოდით გავაგზავნოთ ჩვენი პროგრამა ფონზე ან გავხსნათ სხვა ტერმინალი და შევხედოთ ჩვენს ობიექტს უტილიტის გამოყენებით bpftool (ჩვენ შეგვიძლია განვასხვავოთ ჩვენი რუკა სხვებისგან თავისი სახელით):

$ sudo bpftool map
...
114: hash  name woo  flags 0x0
        key 4B  value 4B  max_entries 4  memlock 4096B
...

ნომერი 114 არის ჩვენი ობიექტის გლობალური ID. სისტემის ნებისმიერ პროგრამას შეუძლია გამოიყენოს ეს ID ბრძანების გამოყენებით არსებული რუკის გასახსნელად BPF_MAP_GET_FD_BY_ID სისტემური ზარი bpf.

ახლა ჩვენ შეგვიძლია ვითამაშოთ ჰეშის მაგიდასთან. მოდით შევხედოთ მის შინაარსს:

$ sudo bpftool map dump id 114
Found 0 elements

ცარიელი. მოდით დავაყენოთ მასში ღირებულება hash[1] = 1:

$ sudo bpftool map update id 114 key 1 0 0 0 value 1 0 0 0

კიდევ ერთხელ გადავხედოთ ცხრილს:

$ sudo bpftool map dump id 114
key: 01 00 00 00  value: 01 00 00 00
Found 1 element

ჰოო! ჩვენ მოვახერხეთ ერთი ელემენტის დამატება. გაითვალისწინეთ, რომ ამისათვის ჩვენ უნდა ვიმუშაოთ ბაიტის დონეზე, რადგან bptftool არ იცის რა ტიპის მნიშვნელობებია ჰეშის ცხრილში. (ეს ცოდნა შეიძლება გადაეცეს მას BTF-ის გამოყენებით, მაგრამ ამაზე მეტი ახლა.)

ზუსტად როგორ კითხულობს და ამატებს ელემენტებს bpftool? მოდით შევხედოთ კაპოტის ქვეშ:

$ sudo strace -e bpf bpftool map dump id 114
bpf(BPF_MAP_GET_FD_BY_ID, {map_id=114, next_id=0, open_flags=0}, 120) = 3
bpf(BPF_MAP_GET_NEXT_KEY, {map_fd=3, key=NULL, next_key=0x55856ab65280}, 120) = 0
bpf(BPF_MAP_LOOKUP_ELEM, {map_fd=3, key=0x55856ab65280, value=0x55856ab652a0}, 120) = 0
key: 01 00 00 00  value: 01 00 00 00
bpf(BPF_MAP_GET_NEXT_KEY, {map_fd=3, key=0x55856ab65280, next_key=0x55856ab65280}, 120) = -1 ENOENT

ჯერ გავხსენით რუკა მისი გლობალური ID-ით ბრძანების გამოყენებით BPF_MAP_GET_FD_BY_ID и bpf(2) დაგვიბრუნა აღმწერი 3. ბრძანების შემდგომი გამოყენებით BPF_MAP_GET_NEXT_KEY ცხრილის პირველი გასაღები ვიპოვეთ გავლის გზით NULL როგორც "წინა" გასაღების მაჩვენებელი. თუ ჩვენ გვაქვს გასაღები, შეგვიძლია გავაკეთოთ BPF_MAP_LOOKUP_ELEMრომელიც უბრუნებს მნიშვნელობას მაჩვენებელს value. შემდეგი ნაბიჯი არის ჩვენ ვცდილობთ ვიპოვოთ შემდეგი ელემენტი მიმდინარე კლავიშზე მაჩვენებლის გადაცემით, მაგრამ ჩვენი ცხრილი შეიცავს მხოლოდ ერთ ელემენტს და ბრძანებას BPF_MAP_GET_NEXT_KEY ბრუნდება ENOENT.

კარგი, მოდით შევცვალოთ მნიშვნელობა 1-ით, ვთქვათ, ჩვენი ბიზნეს ლოგიკა მოითხოვს რეგისტრაციას hash[1] = 2:

$ sudo strace -e bpf bpftool map update id 114 key 1 0 0 0 value 2 0 0 0
bpf(BPF_MAP_GET_FD_BY_ID, {map_id=114, next_id=0, open_flags=0}, 120) = 3
bpf(BPF_MAP_UPDATE_ELEM, {map_fd=3, key=0x55dcd72be260, value=0x55dcd72be280, flags=BPF_ANY}, 120) = 0

როგორც მოსალოდნელი იყო, ეს ძალიან მარტივია: ბრძანება BPF_MAP_GET_FD_BY_ID ხსნის ჩვენს რუკას ID-ით და ბრძანებით BPF_MAP_UPDATE_ELEM გადაწერს ელემენტს.

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

• BPF_MAP_LOOKUP_ELEM: იპოვნეთ მნიშვნელობა გასაღებით
• BPF_MAP_UPDATE_ELEM: განახლება/შექმნა ღირებულება
• BPF_MAP_DELETE_ELEM: გასაღების ამოღება
• BPF_MAP_GET_NEXT_KEY: იპოვნეთ შემდეგი (ან პირველი) გასაღები
• BPF_MAP_GET_NEXT_ID: გაძლევთ საშუალებას გაიაროთ ყველა არსებული რუკა, ასე მუშაობს bpftool map
• BPF_MAP_GET_FD_BY_ID: გახსენით არსებული რუკა მისი გლობალური ID-ით
• BPF_MAP_LOOKUP_AND_DELETE_ELEM: ატომურად განაახლეთ ობიექტის მნიშვნელობა და დააბრუნეთ ძველი
• BPF_MAP_FREEZE: გახადეთ რუკა შეუცვლელი მომხმარებლის სივრციდან (ამ ოპერაციის გაუქმება შეუძლებელია)
• BPF_MAP_LOOKUP_BATCH, BPF_MAP_LOOKUP_AND_DELETE_BATCH, BPF_MAP_UPDATE_BATCH, BPF_MAP_DELETE_BATCH: მასობრივი ოპერაციები. Მაგალითად, BPF_MAP_LOOKUP_AND_DELETE_BATCH - ეს არის ერთადერთი საიმედო გზა რუქიდან ყველა მნიშვნელობის წაკითხვისა და გადატვირთვისთვის

ყველა ეს ბრძანება არ მუშაობს ყველა ტიპის რუქისთვის, მაგრამ ზოგადად სხვა ტიპის რუქებთან მუშაობა მომხმარებლის სივრციდან ზუსტად ისე გამოიყურება, როგორც ჰეშ ცხრილებთან მუშაობა.

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

$ sudo bpftool map update id 114 key 2 0 0 0 value 1 0 0 0
$ sudo bpftool map update id 114 key 3 0 0 0 value 1 0 0 0
$ sudo bpftool map update id 114 key 4 0 0 0 value 1 0 0 0

ჯერჯერობით კარგია:

$ sudo bpftool map dump id 114
key: 01 00 00 00  value: 01 00 00 00
key: 02 00 00 00  value: 01 00 00 00
key: 04 00 00 00  value: 01 00 00 00
key: 03 00 00 00  value: 01 00 00 00
Found 4 elements

შევეცადოთ დავამატოთ კიდევ ერთი:

$ sudo bpftool map update id 114 key 5 0 0 0 value 1 0 0 0
Error: update failed: Argument list too long

როგორც მოსალოდნელი იყო, წარმატებას ვერ მივაღწიეთ. მოდით შევხედოთ შეცდომას უფრო დეტალურად:

$ sudo strace -e bpf bpftool map update id 114 key 5 0 0 0 value 1 0 0 0
bpf(BPF_MAP_GET_FD_BY_ID, {map_id=114, next_id=0, open_flags=0}, 120) = 3
bpf(BPF_OBJ_GET_INFO_BY_FD, {info={bpf_fd=3, info_len=80, info=0x7ffe6c626da0}}, 120) = 0
bpf(BPF_MAP_UPDATE_ELEM, {map_fd=3, key=0x56049ded5260, value=0x56049ded5280, flags=BPF_ANY}, 120) = -1 E2BIG (Argument list too long)
Error: update failed: Argument list too long
+++ exited with 255 +++

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

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

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

BPF პროგრამების წერა libbpf-ის გამოყენებით

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

სინამდვილეში, როგორც ამ და შემდგომ სტატიებში დავინახავთ, libbpf აკეთებს საკმაოდ ბევრ სამუშაოს მის გარეშე (ან მსგავსი ხელსაწყოები - iproute2, libbcc, libbpf-goდა ა.შ.) შეუძლებელია ცხოვრება. პროექტის ერთ-ერთი მკვლელი თვისება libbpf არის BPF CO-RE (შედგენა ერთხელ, გაუშვით ყველგან) - პროექტი, რომელიც საშუალებას გაძლევთ დაწეროთ BPF პროგრამები, რომლებიც პორტატულია ერთი ბირთვიდან მეორეზე, სხვადასხვა API-ზე გაშვების შესაძლებლობით (მაგალითად, როდესაც ბირთვის სტრუქტურა იცვლება ვერსიიდან. ვერსიამდე). იმისათვის, რომ შეძლოთ CO-RE-სთან მუშაობა, თქვენი ბირთვი უნდა იყოს შედგენილი BTF მხარდაჭერით (ჩვენ აღვწერთ, თუ როგორ უნდა გავაკეთოთ ეს განყოფილებაში განვითარების ინსტრუმენტები. თქვენ შეგიძლიათ შეამოწმოთ არის თუ არა თქვენი ბირთვი BTF-ით აშენებული თუ არა ძალიან მარტივად - შემდეგი ფაილის არსებობით:

$ ls -lh /sys/kernel/btf/vmlinux
-r--r--r-- 1 root root 2.6M Jul 29 15:30 /sys/kernel/btf/vmlinux

ეს ფაილი ინახავს ინფორმაციას ბირთვში გამოყენებული ყველა ტიპის მონაცემთა შესახებ და გამოიყენება ჩვენს ყველა მაგალითში libbpf. CO-RE-ზე დეტალურად ვისაუბრებთ შემდეგ სტატიაში, მაგრამ ამ სტატიაში - უბრალოდ შექმენით ბირთვი CONFIG_DEBUG_INFO_BTF.

ბიბლიოთეკა libbpf ცხოვრობს პირდაპირ დირექტორიაში tools/lib/bpf ბირთვი და მისი განვითარება ხდება საფოსტო სიის მეშვეობით [email protected]. თუმცა, ცალკე საცავი ინახება ბირთვის გარეთ მცხოვრები აპლიკაციების საჭიროებებისთვის https://github.com/libbpf/libbpf რომელშიც ბირთვის ბიბლიოთეკა ასახულია წაკითხვის წვდომისთვის მეტ-ნაკლებად ისე, როგორც არის.

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

როგორც წესი, პროექტების გამოყენებით libbpf დაამატეთ GitHub საცავი, როგორც git ქვემოდული, ჩვენ იგივეს გავაკეთებთ:

$ mkdir /tmp/libbpf-example
$ cd /tmp/libbpf-example/
$ git init-db
Initialized empty Git repository in /tmp/libbpf-example/.git/
$ git submodule add https://github.com/libbpf/libbpf.git
Cloning into '/tmp/libbpf-example/libbpf'...
remote: Enumerating objects: 200, done.
remote: Counting objects: 100% (200/200), done.
remote: Compressing objects: 100% (103/103), done.
remote: Total 3354 (delta 101), reused 118 (delta 79), pack-reused 3154
Receiving objects: 100% (3354/3354), 2.05 MiB | 10.22 MiB/s, done.
Resolving deltas: 100% (2176/2176), done.

მიდის libbpf ძალიან მარტივია:

$ cd libbpf/src
$ mkdir build
$ OBJDIR=build DESTDIR=root make -s install
$ find root
root
root/usr
root/usr/include
root/usr/include/bpf
root/usr/include/bpf/bpf_tracing.h
root/usr/include/bpf/xsk.h
root/usr/include/bpf/libbpf_common.h
root/usr/include/bpf/bpf_endian.h
root/usr/include/bpf/bpf_helpers.h
root/usr/include/bpf/btf.h
root/usr/include/bpf/bpf_helper_defs.h
root/usr/include/bpf/bpf.h
root/usr/include/bpf/libbpf_util.h
root/usr/include/bpf/libbpf.h
root/usr/include/bpf/bpf_core_read.h
root/usr/lib64
root/usr/lib64/libbpf.so.0.1.0
root/usr/lib64/libbpf.so.0
root/usr/lib64/libbpf.a
root/usr/lib64/libbpf.so
root/usr/lib64/pkgconfig
root/usr/lib64/pkgconfig/libbpf.pc

ჩვენი შემდეგი გეგმა ამ განყოფილებაში ასეთია: ჩვენ დავწერთ BPF პროგრამას, როგორიცაა BPF_PROG_TYPE_XDP, იგივე, რაც წინა მაგალითში, მაგრამ C-ში, ჩვენ ვადგენთ მას გამოყენებით clangდა დაწერეთ დამხმარე პროგრამა, რომელიც ჩატვირთავს მას ბირთვში. შემდეგ განყოფილებებში ჩვენ გავაფართოვებთ როგორც BPF პროგრამის, ასევე ასისტენტის პროგრამის შესაძლებლობებს.

მაგალითი: სრულფასოვანი აპლიკაციის შექმნა libbpf-ის გამოყენებით

დასაწყისისთვის, ჩვენ ვიყენებთ ფაილს /sys/kernel/btf/vmlinux, რომელიც ზემოთ იყო ნახსენები და შექმენით მისი ეკვივალენტი სათაურის ფაილის სახით:

$ bpftool btf dump file /sys/kernel/btf/vmlinux format c > vmlinux.h

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

$ grep -A 12 'struct iphdr {' vmlinux.h
struct iphdr {
    __u8 ihl: 4;
    __u8 version: 4;
    __u8 tos;
    __be16 tot_len;
    __be16 id;
    __be16 frag_off;
    __u8 ttl;
    __u8 protocol;
    __sum16 check;
    __be32 saddr;
    __be32 daddr;
};

ახლა ჩვენ დავწერთ ჩვენს BPF პროგრამას C-ში:

$ cat xdp-simple.bpf.c
#include "vmlinux.h"
#include <bpf/bpf_helpers.h>

SEC("xdp/simple")
int simple(void *ctx)
{
        return XDP_PASS;
}

char LICENSE[] SEC("license") = "GPL";

მიუხედავად იმისა, რომ ჩვენი პროგრამა ძალიან მარტივი აღმოჩნდა, ჩვენ მაინც უნდა მივაქციოთ ყურადღება ბევრ დეტალს. პირველი, პირველი სათაურის ფაილი, რომელიც ჩვენ შევიტანთ არის vmlinux.h, რომელიც ჩვენ ახლახან შევქმენით გამოყენებით bpftool btf dump - ახლა ჩვენ არ გვჭირდება kernel-headers პაკეტის დაყენება, რათა გავიგოთ, როგორ გამოიყურება ბირთვის სტრუქტურები. შემდეგი სათაურის ფაილი ჩვენთან მოდის ბიბლიოთეკიდან libbpf. ახლა ის მხოლოდ მაკროს განსაზღვრისთვის გვჭირდება SEC, რომელიც აგზავნის სიმბოლოს ELF ობიექტის ფაილის შესაბამის განყოფილებაში. ჩვენი პროგრამა მოცემულია განყოფილებაში xdp/simple, სადაც ხაზამდე ჩვენ განვსაზღვრავთ პროგრამის ტიპს BPF - ეს არის კონვენცია, რომელიც გამოიყენება libbpf, განყოფილების სახელზე დაყრდნობით, ის ჩაანაცვლებს სწორ ტიპს გაშვებისას bpf(2). თავად BPF პროგრამაა C - ძალიან მარტივი და შედგება ერთი ხაზისგან return XDP_PASS. და ბოლოს, ცალკე განყოფილება "license" შეიცავს ლიცენზიის სახელს.

ჩვენ შეგვიძლია შევადგინოთ ჩვენი პროგრამა llvm/clang-ის გამოყენებით, ვერსია >= 10.0.0, ან კიდევ უკეთესი, უფრო დიდი (იხილეთ სექცია განვითარების ინსტრუმენტები):

$ clang --version
clang version 11.0.0 (https://github.com/llvm/llvm-project.git afc287e0abec710398465ee1f86237513f2b5091)
...

$ clang -O2 -g -c -target bpf -I libbpf/src/root/usr/include xdp-simple.bpf.c -o xdp-simple.bpf.o

საინტერესო მახასიათებლებს შორის: ჩვენ მივუთითებთ სამიზნე არქიტექტურას -target bpf და გზა სათაურებისკენ libbpf, რომელიც ჩვენ ახლახან დავაინსტალირეთ. ასევე, არ დაივიწყოთ -O2, ამ პარამეტრის გარეშე მომავალში შესაძლოა სიურპრიზები გქონდეთ. მოდით გადავხედოთ ჩვენს კოდს, მოვახერხეთ თუ არა სასურველი პროგრამის დაწერა?

$ llvm-objdump --section=xdp/simple --no-show-raw-insn -D xdp-simple.bpf.o

xdp-simple.bpf.o:       file format elf64-bpf

Disassembly of section xdp/simple:

0000000000000000 <simple>:
       0:       r0 = 2
       1:       exit

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

პირველ რიგში, ჩვენ უნდა შევქმნათ ჩვენი პროგრამის „ჩონჩხი“ მისი ბინარიდან იმავე პროგრამის გამოყენებით bpftool - BPF სამყაროს შვეიცარიული დანა (რაც შეიძლება სიტყვასიტყვით იქნას აღქმული, რადგან დანიელ ბორკმანი, BPF-ის ერთ-ერთი შემქმნელი და შემსრულებელი, შვეიცარიელია):

$ bpftool gen skeleton xdp-simple.bpf.o > xdp-simple.skel.h

ფაილში xdp-simple.skel.h შეიცავს ჩვენი პროგრამის ორობით კოდს და ფუნქციებს მართვისთვის - ჩვენი ობიექტის ჩატვირთვა, მიმაგრება, წაშლა. ჩვენს მარტივ შემთხვევაში, ეს ზედმეტად გამოიყურება, მაგრამ ის ასევე მუშაობს იმ შემთხვევაში, როდესაც ობიექტის ფაილი შეიცავს ბევრ BPF პროგრამას და რუქას და ამ გიგანტური ELF-ის ჩასატვირთად, ჩვენ უბრალოდ გვჭირდება ჩონჩხის გენერირება და ერთი ან ორი ფუნქციის გამოძახება მორგებული აპლიკაციიდან. წერენ ახლავე გავაგრძელოთ.

მკაცრად რომ ვთქვათ, ჩვენი ჩამტვირთავი პროგრამა ტრივიალურია:

#include <err.h>
#include <unistd.h>
#include "xdp-simple.skel.h"

int main(int argc, char **argv)
{
    struct xdp_simple_bpf *obj;

    obj = xdp_simple_bpf__open_and_load();
    if (!obj)
        err(1, "failed to open and/or load BPF objectn");

    pause();

    xdp_simple_bpf__destroy(obj);
}

აქ struct xdp_simple_bpf ფაილში განსაზღვრული xdp-simple.skel.h და აღწერს ჩვენს ობიექტის ფაილს:

struct xdp_simple_bpf {
    struct bpf_object_skeleton *skeleton;
    struct bpf_object *obj;
    struct {
        struct bpf_program *simple;
    } progs;
    struct {
        struct bpf_link *simple;
    } links;
};

ჩვენ შეგვიძლია დავინახოთ დაბალი დონის API-ს კვალი აქ: სტრუქტურა struct bpf_program *simple и struct bpf_link *simple. პირველი სტრუქტურა კონკრეტულად აღწერს ჩვენს პროგრამას, რომელიც დაწერილია განყოფილებაში xdp/simpleდა მეორე აღწერს, თუ როგორ უკავშირდება პროგრამა მოვლენის წყაროს.

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

$ clang -O2 -I ./libbpf/src/root/usr/include/ xdp-simple.c -o xdp-simple ./libbpf/src/root/usr/lib64/libbpf.a -lelf -lz

$ sudo strace -e bpf ./xdp-simple
...
bpf(BPF_BTF_LOAD, 0x7ffdb8fd9670, 120)  = 3
bpf(BPF_PROG_LOAD, {prog_type=BPF_PROG_TYPE_XDP, insn_cnt=2, insns=0xdfd580, license="GPL", log_level=0, log_size=0, log_buf=NULL, kern_version=KERNEL_VERSION(5, 8, 0), prog_flags=0, prog_name="simple", prog_ifindex=0, expected_attach_type=0x25 /* BPF_??? */, ...}, 120) = 4

მოდით ახლა გადავხედოთ ჩვენს პროგრამას bpftool. მოდი ვიპოვოთ მისი ID:

# bpftool p | grep -A4 simple
463: xdp  name simple  tag 3b185187f1855c4c  gpl
        loaded_at 2020-08-01T01:59:49+0000  uid 0
        xlated 16B  jited 40B  memlock 4096B
        btf_id 185
        pids xdp-simple(16498)

და dump (ჩვენ ვიყენებთ ბრძანების შემოკლებულ ფორმას bpftool prog dump xlated):

# bpftool p d x id 463
int simple(void *ctx):
; return XDP_PASS;
   0: (b7) r0 = 2
   1: (95) exit

რაღაც ახალი! პროგრამამ დაბეჭდა ჩვენი C წყაროს ფაილის ნაწილაკები. ეს გაკეთდა ბიბლიოთეკის მიერ libbpf, რომელმაც იპოვა გამართვის განყოფილება ბინარში, შეადგინა იგი BTF ობიექტში და ჩატვირთა ბირთვში გამოყენებით BPF_BTF_LOAD, და შემდეგ მიუთითეთ მიღებული ფაილის აღმწერი პროგრამის ბრძანებით ჩატვირთვისას BPG_PROG_LOAD.

ბირთვის დამხმარეები

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

მაგალითი: bpf_get_smp_processor_id

„მაგალითით სწავლის“ პარადიგმის ფარგლებში განვიხილოთ დამხმარე ერთ-ერთი ფუნქცია. bpf_get_smp_processor_id(), გარკვეული ფაილში kernel/bpf/helpers.c. ის აბრუნებს პროცესორის ნომერს, რომელზედაც მუშაობს BPF პროგრამა, რომელმაც მას დაურეკა. მაგრამ ჩვენ არ გვაინტერესებს მისი სემანტიკა, როგორც ის, რომ მისი განხორციელება ერთ ხაზს იღებს:

BPF_CALL_0(bpf_get_smp_processor_id)
{
    return smp_processor_id();
}

BPF დამხმარე ფუნქციის განმარტებები მსგავსია Linux სისტემის ზარის განმარტებების. აქ, მაგალითად, განსაზღვრულია ფუნქცია, რომელსაც არ აქვს არგუმენტები. (ფუნქცია, რომელიც იღებს, ვთქვათ, სამ არგუმენტს, განისაზღვრება მაკროს გამოყენებით BPF_CALL_3. არგუმენტების მაქსიმალური რაოდენობა არის ხუთი.) თუმცა, ეს განმარტების მხოლოდ პირველი ნაწილია. მეორე ნაწილი არის ტიპის სტრუქტურის განსაზღვრა struct bpf_func_proto, რომელიც შეიცავს დამხმარე ფუნქციის აღწერას, რომელსაც ვერიფიკატორი ესმის:

const struct bpf_func_proto bpf_get_smp_processor_id_proto = {
    .func     = bpf_get_smp_processor_id,
    .gpl_only = false,
    .ret_type = RET_INTEGER,
};

დამხმარე ფუნქციების რეგისტრაცია

იმისათვის, რომ კონკრეტული ტიპის BPF პროგრამებმა გამოიყენონ ეს ფუნქცია, მათ უნდა დაარეგისტრირონ ის, მაგალითად, ტიპისთვის BPF_PROG_TYPE_XDP ფუნქცია განისაზღვრება ბირთვში xdp_func_proto, რომელიც დამხმარე ფუნქციის ID-დან განსაზღვრავს, მხარს უჭერს თუ არა XDP ამ ფუნქციას. ჩვენი ფუნქციაა მხარს უჭერს:

static const struct bpf_func_proto *
xdp_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog)
{
    switch (func_id) {
    ...
    case BPF_FUNC_get_smp_processor_id:
        return &bpf_get_smp_processor_id_proto;
    ...
    }
}

BPF პროგრამის ახალი ტიპები "განსაზღვრულია" ფაილში include/linux/bpf_types.h მაკროს გამოყენებით BPF_PROG_TYPE. განსაზღვრულია ბრჭყალებში, რადგან ეს არის ლოგიკური განმარტება, ხოლო C ენის ტერმინებში ბეტონის სტრუქტურების მთელი ნაკრების განმარტება ხდება სხვა ადგილებში. კერძოდ, ფაილში kernel/bpf/verifier.c ყველა განმარტება ფაილიდან bpf_types.h გამოიყენება სტრუქტურების მასივის შესაქმნელად bpf_verifier_ops[]:

static const struct bpf_verifier_ops *const bpf_verifier_ops[] = {
#define BPF_PROG_TYPE(_id, _name, prog_ctx_type, kern_ctx_type) 
    [_id] = & _name ## _verifier_ops,
#include <linux/bpf_types.h>
#undef BPF_PROG_TYPE
};

ანუ, თითოეული ტიპის BPF პროგრამისთვის, მითითებულია მონაცემთა სტრუქტურის მითითება struct bpf_verifier_ops, რომელიც ინიციალიზებულია მნიშვნელობით _name ## _verifier_ops, ე.ი. xdp_verifier_ops ამისთვის xdp... სტრუქტურა xdp_verifier_ops განსაზღვრული ფაილში net/core/filter.c შემდეგნაირად:

const struct bpf_verifier_ops xdp_verifier_ops = {
    .get_func_proto     = xdp_func_proto,
    .is_valid_access    = xdp_is_valid_access,
    .convert_ctx_access = xdp_convert_ctx_access,
    .gen_prologue       = bpf_noop_prologue,
};

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

მოდით შევხედოთ, თუ როგორ იყენებს ჰიპოთეტური BPF პროგრამა ფუნქციას bpf_get_smp_processor_id. ამისათვის ჩვენ გადავიწერთ პროგრამას ჩვენი წინა განყოფილებიდან შემდეგნაირად:

#include "vmlinux.h"
#include <bpf/bpf_helpers.h>

SEC("xdp/simple")
int simple(void *ctx)
{
    if (bpf_get_smp_processor_id() != 0)
        return XDP_DROP;
    return XDP_PASS;
}

char LICENSE[] SEC("license") = "GPL";

სტრატეგია bpf_get_smp_processor_id განსაზღვრული в <bpf/bpf_helper_defs.h> ბიბლიოთეკები libbpf როგორც

static u32 (*bpf_get_smp_processor_id)(void) = (void *) 8;

ანუ bpf_get_smp_processor_id არის ფუნქციის მაჩვენებელი, რომლის მნიშვნელობა არის 8, სადაც 8 არის მნიშვნელობა BPF_FUNC_get_smp_processor_id ტიპი enum bpf_fun_id, რომელიც ჩვენთვის არის განსაზღვრული ფაილში vmlinux.h (ფაილი bpf_helper_defs.h ბირთვში გენერირდება სკრიპტი, ამიტომ "ჯადოსნური" ნომრები კარგია). ეს ფუნქცია არ იღებს არგუმენტებს და აბრუნებს ტიპის მნიშვნელობას __u32. როდესაც ჩვენ ვატარებთ მას ჩვენს პროგრამაში, clang ქმნის ინსტრუქციას BPF_CALL "სწორი ტიპი" მოდით შევადგინოთ პროგრამა და გადავხედოთ განყოფილებას xdp/simple:

$ clang -O2 -g -c -target bpf -I libbpf/src/root/usr/include xdp-simple.bpf.c -o xdp-simple.bpf.o
$ llvm-objdump -D --section=xdp/simple xdp-simple.bpf.o

xdp-simple.bpf.o:       file format elf64-bpf

Disassembly of section xdp/simple:

0000000000000000 <simple>:
       0:       85 00 00 00 08 00 00 00 call 8
       1:       bf 01 00 00 00 00 00 00 r1 = r0
       2:       67 01 00 00 20 00 00 00 r1 <<= 32
       3:       77 01 00 00 20 00 00 00 r1 >>= 32
       4:       b7 00 00 00 02 00 00 00 r0 = 2
       5:       15 01 01 00 00 00 00 00 if r1 == 0 goto +1 <LBB0_2>
       6:       b7 00 00 00 01 00 00 00 r0 = 1

0000000000000038 <LBB0_2>:
       7:       95 00 00 00 00 00 00 00 exit

პირველ სტრიქონში ჩვენ ვხედავთ ინსტრუქციებს call, პარამეტრი IMM რომელიც უდრის 8-ს და SRC_REG - ნული. ვერიფიკატორის მიერ გამოყენებული ABI შეთანხმების თანახმად, ეს არის ზარი დამხმარე ფუნქციის ნომერი რვაზე. მისი გაშვების შემდეგ, ლოგიკა მარტივია. დააბრუნეთ ღირებულება რეესტრიდან r0 გადაწერა r1 ხოლო 2,3 სტრიქონზე ის გარდაიქმნება ტიპად u32 — ზედა 32 ბიტი გასუფთავებულია. 4,5,6,7 ხაზებზე ვაბრუნებთ 2 (XDP_PASS) ან 1 (XDP_DROP) იმისდა მიხედვით, დამხმარე ფუნქციამ 0 ხაზიდან დააბრუნა ნულოვანი თუ არა-ნულოვანი მნიშვნელობა.

მოდით გამოვცადოთ საკუთარი თავი: ჩატვირთეთ პროგრამა და შეხედეთ გამომავალს bpftool prog dump xlated:

$ bpftool gen skeleton xdp-simple.bpf.o > xdp-simple.skel.h
$ clang -O2 -g -I ./libbpf/src/root/usr/include/ -o xdp-simple xdp-simple.c ./libbpf/src/root/usr/lib64/libbpf.a -lelf -lz
$ sudo ./xdp-simple &
[2] 10914

$ sudo bpftool p | grep simple
523: xdp  name simple  tag 44c38a10c657e1b0  gpl
        pids xdp-simple(10915)

$ sudo bpftool p d x id 523
int simple(void *ctx):
; if (bpf_get_smp_processor_id() != 0)
   0: (85) call bpf_get_smp_processor_id#114128
   1: (bf) r1 = r0
   2: (67) r1 <<= 32
   3: (77) r1 >>= 32
   4: (b7) r0 = 2
; }
   5: (15) if r1 == 0x0 goto pc+1
   6: (b7) r0 = 1
   7: (95) exit

კარგი, ვერიფიკატორმა იპოვა სწორი ბირთვის დამხმარე.

მაგალითი: არგუმენტების გაცემა და ბოლოს პროგრამის გაშვება!

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

u64 fn(u64 r1, u64 r2, u64 r3, u64 r4, u64 r5)

დამხმარე ფუნქციების პარამეტრები გადაეცემა რეესტრებში r1-r5, და მნიშვნელობა დაბრუნდება რეესტრში r0. არ არსებობს ფუნქციები, რომლებიც იღებენ ხუთზე მეტ არგუმენტს და მათი მხარდაჭერა არ არის მოსალოდნელი მომავალში.

მოდით შევხედოთ ბირთვის ახალ დამხმარეს და როგორ გადასცემს BPF პარამეტრებს. გადავიწეროთ xdp-simple.bpf.c შემდეგნაირად (დანარჩენი სტრიქონები არ შეცვლილა):

SEC("xdp/simple")
int simple(void *ctx)
{
    bpf_printk("running on CPU%un", bpf_get_smp_processor_id());
    return XDP_PASS;
}

ჩვენი პროგრამა ბეჭდავს CPU-ს ნომერს, რომელზეც ის მუშაობს. მოდით შევადგინოთ და შევხედოთ კოდს:

$ llvm-objdump -D --section=xdp/simple --no-show-raw-insn xdp-simple.bpf.o

0000000000000000 <simple>:
       0:       r1 = 10
       1:       *(u16 *)(r10 - 8) = r1
       2:       r1 = 8441246879787806319 ll
       4:       *(u64 *)(r10 - 16) = r1
       5:       r1 = 2334956330918245746 ll
       7:       *(u64 *)(r10 - 24) = r1
       8:       call 8
       9:       r1 = r10
      10:       r1 += -24
      11:       r2 = 18
      12:       r3 = r0
      13:       call 6
      14:       r0 = 2
      15:       exit

0-7 სტრიქონებში ვწერთ სტრიქონს running on CPU%un, შემდეგ კი მე-8 სტრიქონზე ვაწარმოებთ ნაცნობს bpf_get_smp_processor_id. 9-12 სტრიქონებზე ვამზადებთ დამხმარე არგუმენტებს bpf_printk - რეგისტრები r1, r2, r3. რატომ არის სამი მათგანი და არა ორი? იმიტომ რომ bpf_printk - ეს არის მაკრო შეფუთვა ნამდვილი დამხმარის ირგვლივ bpf_trace_printk, რომელიც უნდა გაიაროს ფორმატის სტრიქონის ზომა.

ახლა დავამატოთ რამდენიმე სტრიქონი xdp-simple.cრათა ჩვენი პროგრამა დაუკავშირდეს ინტერფეისს lo და მართლა დაიწყო!

$ cat xdp-simple.c
#include <linux/if_link.h>
#include <err.h>
#include <unistd.h>
#include "xdp-simple.skel.h"

int main(int argc, char **argv)
{
    __u32 flags = XDP_FLAGS_SKB_MODE;
    struct xdp_simple_bpf *obj;

    obj = xdp_simple_bpf__open_and_load();
    if (!obj)
        err(1, "failed to open and/or load BPF objectn");

    bpf_set_link_xdp_fd(1, -1, flags);
    bpf_set_link_xdp_fd(1, bpf_program__fd(obj->progs.simple), flags);

cleanup:
    xdp_simple_bpf__destroy(obj);
}

აქ ჩვენ ვიყენებთ ფუნქციას bpf_set_link_xdp_fd, რომელიც აკავშირებს BPF პროგრამებს, როგორიცაა XDP, ქსელურ ინტერფეისებთან. ჩვენ დავაფიქსირეთ ინტერფეისის ნომერი lo, რომელიც ყოველთვის არის 1. ჩვენ ორჯერ ვასრულებთ ფუნქციას, რომ ჯერ დავშორდეთ ძველი პროგრამას, თუ ის იყო მიმაგრებული. გაითვალისწინეთ, რომ ახლა ჩვენ არ გვჭირდება გამოწვევა pause ან უსასრულო მარყუჟი: ჩვენი ჩამტვირთავი პროგრამა გამოვა, მაგრამ BPF პროგრამა არ დაიკარგება, რადგან ის დაკავშირებულია მოვლენის წყაროსთან. წარმატებული ჩამოტვირთვისა და დაკავშირების შემდეგ, პროგრამა ამოქმედდება თითოეული ქსელის პაკეტისთვის, რომელიც შემოდის lo.

გადმოვწეროთ პროგრამა და გადავხედოთ ინტერფეისს lo:

$ sudo ./xdp-simple
$ sudo bpftool p | grep simple
669: xdp  name simple  tag 4fca62e77ccb43d6  gpl
$ ip l show dev lo
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 xdpgeneric qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    prog/xdp id 669

ჩვენ მიერ გადმოწერილი პროგრამა აქვს ID 669 და იგივე ID-ს ვხედავთ ინტერფეისზე lo. ჩვენ გამოგიგზავნით რამდენიმე პაკეტს 127.0.0.1 (მოთხოვნა + პასუხი):

$ ping -c1 localhost

და ახლა მოდით შევხედოთ გამართვის ვირტუალური ფაილის შინაარსს /sys/kernel/debug/tracing/trace_pipe, რომელშიც bpf_printk წერს თავის მესიჯებს:

# cat /sys/kernel/debug/tracing/trace_pipe
ping-13937 [000] d.s1 442015.377014: bpf_trace_printk: running on CPU0
ping-13937 [000] d.s1 442015.377027: bpf_trace_printk: running on CPU0

ორი პაკეტი დაფიქსირდა lo და დამუშავდა CPU0-ზე - ჩვენი პირველი სრულფასოვანი უაზრო BPF პროგრამა მუშაობდა!

აღსანიშნავია, რომ bpf_printk ტყუილად არ წერს გამართვის ფაილში: ეს არ არის ყველაზე წარმატებული დამხმარე წარმოებაში გამოსაყენებლად, მაგრამ ჩვენი მიზანი იყო რაღაც მარტივის ჩვენება.

რუკებზე წვდომა BPF პროგრამებიდან

მაგალითი: რუკის გამოყენება BPF პროგრამიდან

წინა განყოფილებებში ვისწავლეთ რუქების შექმნა და გამოყენება მომხმარებლის სივრციდან, ახლა კი მოდით გადავხედოთ ბირთვის ნაწილს. დავიწყოთ, როგორც ყოველთვის, მაგალითით. მოდით გადავიწეროთ ჩვენი პროგრამა xdp-simple.bpf.c შემდეგნაირად:

#include "vmlinux.h"
#include <bpf/bpf_helpers.h>

struct {
    __uint(type, BPF_MAP_TYPE_ARRAY);
    __uint(max_entries, 8);
    __type(key, u32);
    __type(value, u64);
} woo SEC(".maps");

SEC("xdp/simple")
int simple(void *ctx)
{
    u32 key = bpf_get_smp_processor_id();
    u32 *val;

    val = bpf_map_lookup_elem(&woo, &key);
    if (!val)
        return XDP_ABORTED;

    *val += 1;

    return XDP_PASS;
}

char LICENSE[] SEC("license") = "GPL";

პროგრამის დასაწყისში ჩვენ დავამატეთ რუკის განმარტება woo: ეს არის 8 ელემენტიანი მასივი, რომელიც ინახავს მსგავს მნიშვნელობებს u64 (C-ში ჩვენ განვსაზღვრავთ ისეთ მასივს, როგორც u64 woo[8]). პროგრამაში "xdp/simple" ჩვენ ვიღებთ მიმდინარე პროცესორის ნომერს ცვლადში key შემდეგ კი დამხმარე ფუნქციის გამოყენებით bpf_map_lookup_element ვიღებთ მაჩვენებელს მასივის შესაბამის ჩანაწერზე, რომელსაც ვზრდით ერთით. რუსულად ნათარგმნი: ჩვენ ვიანგარიშებთ სტატისტიკას, რომელზედაც CPU ამუშავებს შემომავალ პაკეტებს. ვცადოთ პროგრამის გაშვება:

$ clang -O2 -g -c -target bpf -I libbpf/src/root/usr/include xdp-simple.bpf.c -o xdp-simple.bpf.o
$ bpftool gen skeleton xdp-simple.bpf.o > xdp-simple.skel.h
$ clang -O2 -g -I ./libbpf/src/root/usr/include/ -o xdp-simple xdp-simple.c ./libbpf/src/root/usr/lib64/libbpf.a -lelf -lz
$ sudo ./xdp-simple

მოდით შევამოწმოთ, რომ ის დაკავშირებულია lo და გაგზავნეთ რამდენიმე პაკეტი:

$ ip l show dev lo
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 xdpgeneric qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    prog/xdp id 108

$ for s in `seq 234`; do sudo ping -f -c 100 127.0.0.1 >/dev/null 2>&1; done

ახლა მოდით შევხედოთ მასივის შინაარსს:

$ sudo bpftool map dump name woo
[
    { "key": 0, "value": 0 },
    { "key": 1, "value": 400 },
    { "key": 2, "value": 0 },
    { "key": 3, "value": 0 },
    { "key": 4, "value": 0 },
    { "key": 5, "value": 0 },
    { "key": 6, "value": 0 },
    { "key": 7, "value": 46400 }
]

თითქმის ყველა პროცესი დამუშავდა CPU7-ზე. ჩვენთვის ეს არ არის მნიშვნელოვანი, მთავარია, რომ პროგრამა მუშაობს და ჩვენ გვესმის, როგორ მივიღოთ რუქები BPF პროგრამებიდან - გამოყენებით хелперов bpf_mp_*.

მისტიკური ინდექსი

ასე რომ, რუკაზე წვდომა შეგვიძლია BPF პროგრამიდან მსგავსი ზარების გამოყენებით

val = bpf_map_lookup_elem(&woo, &key);

სადაც დამხმარე ფუნქცია გამოიყურება

void *bpf_map_lookup_elem(struct bpf_map *map, const void *key)

მაგრამ ჩვენ ვატარებთ მაჩვენებელს &woo უსახელო სტრუქტურას struct { ... }...

თუ გადავხედავთ პროგრამის ასამბლერს, ჩვენ ვხედავთ, რომ მნიშვნელობა &woo რეალურად არ არის განსაზღვრული (სტრიქონი 4):

llvm-objdump -D --section xdp/simple xdp-simple.bpf.o

xdp-simple.bpf.o:       file format elf64-bpf

Disassembly of section xdp/simple:

0000000000000000 <simple>:
       0:       85 00 00 00 08 00 00 00 call 8
       1:       63 0a fc ff 00 00 00 00 *(u32 *)(r10 - 4) = r0
       2:       bf a2 00 00 00 00 00 00 r2 = r10
       3:       07 02 00 00 fc ff ff ff r2 += -4
       4:       18 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 r1 = 0 ll
       6:       85 00 00 00 01 00 00 00 call 1
...

და შედის გადაადგილებებში:

$ llvm-readelf -r xdp-simple.bpf.o | head -4

Relocation section '.relxdp/simple' at offset 0xe18 contains 1 entries:
    Offset             Info             Type               Symbol's Value  Symbol's Name
0000000000000020  0000002700000001 R_BPF_64_64            0000000000000000 woo

მაგრამ თუ გადავხედავთ უკვე დატვირთულ პროგრამას, ჩვენ ვხედავთ მაჩვენებელს სწორი რუკისკენ (სტრიქონი 4):

$ sudo bpftool prog dump x name simple
int simple(void *ctx):
   0: (85) call bpf_get_smp_processor_id#114128
   1: (63) *(u32 *)(r10 -4) = r0
   2: (bf) r2 = r10
   3: (07) r2 += -4
   4: (18) r1 = map[id:64]
...

ამრიგად, შეგვიძლია დავასკვნათ, რომ ჩვენი ჩამტვირთავი პროგრამის გაშვების დროს, ბმული &woo შეიცვალა რაღაც ბიბლიოთეკით libbpf. პირველ რიგში, ჩვენ შევხედავთ გამოსავალს strace:

$ sudo strace -e bpf ./xdp-simple
...
bpf(BPF_MAP_CREATE, {map_type=BPF_MAP_TYPE_ARRAY, key_size=4, value_size=8, max_entries=8, map_name="woo", ...}, 120) = 4
bpf(BPF_PROG_LOAD, {prog_type=BPF_PROG_TYPE_XDP, prog_name="simple", ...}, 120) = 5

ჩვენ ამას ვხედავთ libbpf შექმნა რუკა woo და შემდეგ გადმოვწერე ჩვენი პროგრამა simple. მოდით უფრო დეტალურად განვიხილოთ, თუ როგორ ვტვირთავთ პროგრამას:

• ზარი xdp_simple_bpf__open_and_load ფაილიდან xdp-simple.skel.h
• რაც იწვევს xdp_simple_bpf__load ფაილიდან xdp-simple.skel.h
• რაც იწვევს bpf_object__load_skeleton ფაილიდან libbpf/src/libbpf.c
• რაც იწვევს bpf_object__load_xattr საქართველოს libbpf/src/libbpf.c

ბოლო ფუნქცია, სხვა საკითხებთან ერთად, დარეკავს bpf_object__create_maps, რომელიც ქმნის ან ხსნის არსებულ რუკებს, აქცევს მათ ფაილის აღწერად. (ეს არის სადაც ჩვენ ვხედავთ BPF_MAP_CREATE გამომავალში strace.) შემდეგ ფუნქცია გამოიძახება bpf_object__relocate და ის არის ის, ვინც გვაინტერესებს, რადგან გვახსოვს ის, რაც ვნახეთ woo გადაადგილების ცხრილში. მისი შესწავლით, ჩვენ საბოლოოდ აღმოვჩნდებით ფუნქციაში bpf_program__relocate, რომელიც ეხება რუკის გადაადგილებას:

case RELO_LD64:
    insn[0].src_reg = BPF_PSEUDO_MAP_FD;
    insn[0].imm = obj->maps[relo->map_idx].fd;
    break;

ასე რომ, ჩვენ ვიღებთ ჩვენს მითითებებს

18 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 r1 = 0 ll

და შეცვალეთ მასში არსებული წყაროს რეგისტრი BPF_PSEUDO_MAP_FDდა პირველი IMM ჩვენი რუქის ფაილის აღწერისთვის და, თუ ის უდრის, მაგალითად, 0xdeadbeef, შემდეგ ჩვენ მივიღებთ ინსტრუქციას

18 11 00 00 ef eb ad de 00 00 00 00 00 00 00 00 r1 = 0 ll

ასე გადადის რუქის ინფორმაცია კონკრეტულ დატვირთულ BPF პროგრამაში. ამ შემთხვევაში, რუკა შეიძლება შეიქმნას გამოყენებით BPF_MAP_CREATEდა გაიხსნა ID-ის გამოყენებით BPF_MAP_GET_FD_BY_ID.

სულ, გამოყენებისას libbpf ალგორითმი ასეთია:

• შედგენის დროს, ჩანაწერები იქმნება გადატანის ცხრილში რუკების ბმულებისთვის
• libbpf ხსნის ELF ობიექტების წიგნს, პოულობს ყველა გამოყენებულ რუქას და ქმნის მათთვის ფაილის აღწერებს
• ფაილის აღწერები იტვირთება ბირთვში, როგორც ინსტრუქციის ნაწილი LD64

როგორც თქვენ წარმოიდგინეთ, წინ კიდევ ბევრია და ჩვენ უნდა ჩავიხედოთ ბირთვში. საბედნიეროდ, ჩვენ გვაქვს მინიშნება - ჩავწერეთ მნიშვნელობა BPF_PSEUDO_MAP_FD წყაროს რეგისტრში და ჩვენ შეგვიძლია დავმარხოთ იგი, რაც მიგვიყვანს ყველა წმინდანის წმიდამდე - kernel/bpf/verifier.c, სადაც განმასხვავებელი სახელის მქონე ფუნქცია ცვლის ფაილის აღწერს ტიპის სტრუქტურის მისამართით struct bpf_map:

static int replace_map_fd_with_map_ptr(struct bpf_verifier_env *env) {
    ...

    f = fdget(insn[0].imm);
    map = __bpf_map_get(f);
    if (insn->src_reg == BPF_PSEUDO_MAP_FD) {
        addr = (unsigned long)map;
    }
    insn[0].imm = (u32)addr;
    insn[1].imm = addr >> 32;

(სრული კოდი შეგიძლიათ იხილოთ по ссылке). ასე რომ, ჩვენ შეგვიძლია გავაფართოვოთ ჩვენი ალგორითმი:

• პროგრამის ჩატვირთვისას ვერიფიკატორი ამოწმებს რუკის სწორად გამოყენებას და წერს შესაბამისი სტრუქტურის მისამართს struct bpf_map

ELF ბინარის ჩამოტვირთვისას გამოყენებით libbpf კიდევ ბევრი რამ ხდება, მაგრამ ამას სხვა სტატიებში განვიხილავთ.

პროგრამებისა და რუქების ჩატვირთვა libbpf-ის გარეშე

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

ლოგიკის გასაადვილებლად, ჩვენ გადავწერთ ჩვენს მაგალითს ამ მიზნებისთვის xdp-simple. ამ მაგალითში განხილული პროგრამის სრული და ოდნავ გაფართოებული კოდი შეგიძლიათ იხილოთ აქ გისტა.

ჩვენი განაცხადის ლოგიკა ასეთია:

• შექმენით ტიპის რუკა BPF_MAP_TYPE_ARRAY ბრძანების გამოყენებით BPF_MAP_CREATE,
• შექმენით პროგრამა, რომელიც იყენებს ამ რუკას,
• დააკავშირეთ პროგრამა ინტერფეისთან lo,

რაც ადამიანურად ითარგმნება როგორც

int main(void)
{
    int map_fd, prog_fd;

    map_fd = map_create();
    if (map_fd < 0)
        err(1, "bpf: BPF_MAP_CREATE");

    prog_fd = prog_load(map_fd);
    if (prog_fd < 0)
        err(1, "bpf: BPF_PROG_LOAD");

    xdp_attach(1, prog_fd);
}

აქ map_create ქმნის რუკას ისევე, როგორც ჩვენ გავაკეთეთ პირველ მაგალითში სისტემური ზარის შესახებ bpf - „ბირთვი, გთხოვთ დამიმზადეთ ახალი რუკა 8 ელემენტისგან შემდგარი მასივის სახით, როგორიცაა __u64 და დამიბრუნე ფაილის აღმწერი":

static int map_create()
{
    union bpf_attr attr;

    memset(&attr, 0, sizeof(attr));
    attr.map_type = BPF_MAP_TYPE_ARRAY,
    attr.key_size = sizeof(__u32),
    attr.value_size = sizeof(__u64),
    attr.max_entries = 8,
    strncpy(attr.map_name, "woo", sizeof(attr.map_name));
    return syscall(__NR_bpf, BPF_MAP_CREATE, &attr, sizeof(attr));
}

პროგრამა ასევე ადვილად იტვირთება:

static int prog_load(int map_fd)
{
    union bpf_attr attr;
    struct bpf_insn insns[] = {
        ...
    };

    memset(&attr, 0, sizeof(attr));
    attr.prog_type = BPF_PROG_TYPE_XDP;
    attr.insns     = ptr_to_u64(insns);
    attr.insn_cnt  = sizeof(insns)/sizeof(insns[0]);
    attr.license   = ptr_to_u64("GPL");
    strncpy(attr.prog_name, "woo", sizeof(attr.prog_name));
    return syscall(__NR_bpf, BPF_PROG_LOAD, &attr, sizeof(attr));
}

რთული ნაწილი prog_load არის ჩვენი BPF პროგრამის განმარტება, როგორც სტრუქტურების მასივი struct bpf_insn insns[]. მაგრამ რადგან ჩვენ ვიყენებთ პროგრამას, რომელიც გვაქვს C-ში, შეგვიძლია ცოტა მოვიტყუოთ:

$ llvm-objdump -D --section xdp/simple xdp-simple.bpf.o

0000000000000000 <simple>:
       0:       85 00 00 00 08 00 00 00 call 8
       1:       63 0a fc ff 00 00 00 00 *(u32 *)(r10 - 4) = r0
       2:       bf a2 00 00 00 00 00 00 r2 = r10
       3:       07 02 00 00 fc ff ff ff r2 += -4
       4:       18 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 r1 = 0 ll
       6:       85 00 00 00 01 00 00 00 call 1
       7:       b7 01 00 00 00 00 00 00 r1 = 0
       8:       15 00 04 00 00 00 00 00 if r0 == 0 goto +4 <LBB0_2>
       9:       61 01 00 00 00 00 00 00 r1 = *(u32 *)(r0 + 0)
      10:       07 01 00 00 01 00 00 00 r1 += 1
      11:       63 10 00 00 00 00 00 00 *(u32 *)(r0 + 0) = r1
      12:       b7 01 00 00 02 00 00 00 r1 = 2

0000000000000068 <LBB0_2>:
      13:       bf 10 00 00 00 00 00 00 r0 = r1
      14:       95 00 00 00 00 00 00 00 exit

საერთო ჯამში, ჩვენ უნდა დავწეროთ 14 ინსტრუქცია მსგავსი სტრუქტურების სახით struct bpf_insn (რჩევა: აიღეთ ნაგავსაყრელი ზემოდან, ხელახლა წაიკითხეთ ინსტრუქციების განყოფილება, გახსენით linux/bpf.h и linux/bpf_common.h და შეეცადეთ დაადგინოთ struct bpf_insn insns[] ერთი საკუთარი):

struct bpf_insn insns[] = {
    /* 85 00 00 00 08 00 00 00 call 8 */
    {
        .code = BPF_JMP | BPF_CALL,
        .imm = 8,
    },

    /* 63 0a fc ff 00 00 00 00 *(u32 *)(r10 - 4) = r0 */
    {
        .code = BPF_MEM | BPF_STX,
        .off = -4,
        .src_reg = BPF_REG_0,
        .dst_reg = BPF_REG_10,
    },

    /* bf a2 00 00 00 00 00 00 r2 = r10 */
    {
        .code = BPF_ALU64 | BPF_MOV | BPF_X,
        .src_reg = BPF_REG_10,
        .dst_reg = BPF_REG_2,
    },

    /* 07 02 00 00 fc ff ff ff r2 += -4 */
    {
        .code = BPF_ALU64 | BPF_ADD | BPF_K,
        .dst_reg = BPF_REG_2,
        .imm = -4,
    },

    /* 18 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 r1 = 0 ll */
    {
        .code = BPF_LD | BPF_DW | BPF_IMM,
        .src_reg = BPF_PSEUDO_MAP_FD,
        .dst_reg = BPF_REG_1,
        .imm = map_fd,
    },
    { }, /* placeholder */

    /* 85 00 00 00 01 00 00 00 call 1 */
    {
        .code = BPF_JMP | BPF_CALL,
        .imm = 1,
    },

    /* b7 01 00 00 00 00 00 00 r1 = 0 */
    {
        .code = BPF_ALU64 | BPF_MOV | BPF_K,
        .dst_reg = BPF_REG_1,
        .imm = 0,
    },

    /* 15 00 04 00 00 00 00 00 if r0 == 0 goto +4 <LBB0_2> */
    {
        .code = BPF_JMP | BPF_JEQ | BPF_K,
        .off = 4,
        .src_reg = BPF_REG_0,
        .imm = 0,
    },

    /* 61 01 00 00 00 00 00 00 r1 = *(u32 *)(r0 + 0) */
    {
        .code = BPF_MEM | BPF_LDX,
        .off = 0,
        .src_reg = BPF_REG_0,
        .dst_reg = BPF_REG_1,
    },

    /* 07 01 00 00 01 00 00 00 r1 += 1 */
    {
        .code = BPF_ALU64 | BPF_ADD | BPF_K,
        .dst_reg = BPF_REG_1,
        .imm = 1,
    },

    /* 63 10 00 00 00 00 00 00 *(u32 *)(r0 + 0) = r1 */
    {
        .code = BPF_MEM | BPF_STX,
        .src_reg = BPF_REG_1,
        .dst_reg = BPF_REG_0,
    },

    /* b7 01 00 00 02 00 00 00 r1 = 2 */
    {
        .code = BPF_ALU64 | BPF_MOV | BPF_K,
        .dst_reg = BPF_REG_1,
        .imm = 2,
    },

    /* <LBB0_2>: bf 10 00 00 00 00 00 00 r0 = r1 */
    {
        .code = BPF_ALU64 | BPF_MOV | BPF_X,
        .src_reg = BPF_REG_1,
        .dst_reg = BPF_REG_0,
    },

    /* 95 00 00 00 00 00 00 00 exit */
    {
        .code = BPF_JMP | BPF_EXIT
    },
};

სავარჯიშო მათთვის, ვინც თვითონ არ დაწერა ეს - იპოვნეთ map_fd.

ჩვენს პროგრამაში დარჩა კიდევ ერთი გაურკვეველი ნაწილი - xdp_attach. სამწუხაროდ, ისეთი პროგრამები, როგორიცაა XDP, შეუძლებელია სისტემური ზარის გამოყენებით bpf. ადამიანები, რომლებმაც შექმნეს BPF და XDP, იყვნენ ონლაინ Linux საზოგადოებისგან, რაც ნიშნავს, რომ მათ იყენებდნენ მათთვის ყველაზე ნაცნობს (მაგრამ არა ნორმალური ხალხი) ინტერფეისი ბირთვთან ურთიერთობისთვის: netlink სოკეტები, იხილეთ ასევე RFC3549. განხორციელების უმარტივესი გზა xdp_attach კოპირებს კოდს libbpf, კერძოდ, ფაილიდან netlink.c, რაც ჩვენ გავაკეთეთ, ცოტა შევამოკლეთ:

კეთილი იყოს თქვენი მობრძანება netlink სოკეტების სამყაროში

გახსენით netlink სოკეტის ტიპი NETLINK_ROUTE:

int netlink_open(__u32 *nl_pid)
{
    struct sockaddr_nl sa;
    socklen_t addrlen;
    int one = 1, ret;
    int sock;

    memset(&sa, 0, sizeof(sa));
    sa.nl_family = AF_NETLINK;

    sock = socket(AF_NETLINK, SOCK_RAW, NETLINK_ROUTE);
    if (sock < 0)
        err(1, "socket");

    if (setsockopt(sock, SOL_NETLINK, NETLINK_EXT_ACK, &one, sizeof(one)) < 0)
        warnx("netlink error reporting not supported");

    if (bind(sock, (struct sockaddr *)&sa, sizeof(sa)) < 0)
        err(1, "bind");

    addrlen = sizeof(sa);
    if (getsockname(sock, (struct sockaddr *)&sa, &addrlen) < 0)
        err(1, "getsockname");

    *nl_pid = sa.nl_pid;
    return sock;
}

ამ სოკეტიდან ვკითხულობთ:

static int bpf_netlink_recv(int sock, __u32 nl_pid, int seq)
{
    bool multipart = true;
    struct nlmsgerr *errm;
    struct nlmsghdr *nh;
    char buf[4096];
    int len, ret;

    while (multipart) {
        multipart = false;
        len = recv(sock, buf, sizeof(buf), 0);
        if (len < 0)
            err(1, "recv");

        if (len == 0)
            break;

        for (nh = (struct nlmsghdr *)buf; NLMSG_OK(nh, len);
                nh = NLMSG_NEXT(nh, len)) {
            if (nh->nlmsg_pid != nl_pid)
                errx(1, "wrong pid");
            if (nh->nlmsg_seq != seq)
                errx(1, "INVSEQ");
            if (nh->nlmsg_flags & NLM_F_MULTI)
                multipart = true;
            switch (nh->nlmsg_type) {
                case NLMSG_ERROR:
                    errm = (struct nlmsgerr *)NLMSG_DATA(nh);
                    if (!errm->error)
                        continue;
                    ret = errm->error;
                    // libbpf_nla_dump_errormsg(nh); too many code to copy...
                    goto done;
                case NLMSG_DONE:
                    return 0;
                default:
                    break;
            }
        }
    }
    ret = 0;
done:
    return ret;
}

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

static int xdp_attach(int ifindex, int prog_fd)
{
    int sock, seq = 0, ret;
    struct nlattr *nla, *nla_xdp;
    struct {
        struct nlmsghdr  nh;
        struct ifinfomsg ifinfo;
        char             attrbuf[64];
    } req;
    __u32 nl_pid = 0;

    sock = netlink_open(&nl_pid);
    if (sock < 0)
        return sock;

    memset(&req, 0, sizeof(req));
    req.nh.nlmsg_len = NLMSG_LENGTH(sizeof(struct ifinfomsg));
    req.nh.nlmsg_flags = NLM_F_REQUEST | NLM_F_ACK;
    req.nh.nlmsg_type = RTM_SETLINK;
    req.nh.nlmsg_pid = 0;
    req.nh.nlmsg_seq = ++seq;
    req.ifinfo.ifi_family = AF_UNSPEC;
    req.ifinfo.ifi_index = ifindex;

    /* started nested attribute for XDP */
    nla = (struct nlattr *)(((char *)&req)
            + NLMSG_ALIGN(req.nh.nlmsg_len));
    nla->nla_type = NLA_F_NESTED | IFLA_XDP;
    nla->nla_len = NLA_HDRLEN;

    /* add XDP fd */
    nla_xdp = (struct nlattr *)((char *)nla + nla->nla_len);
    nla_xdp->nla_type = IFLA_XDP_FD;
    nla_xdp->nla_len = NLA_HDRLEN + sizeof(int);
    memcpy((char *)nla_xdp + NLA_HDRLEN, &prog_fd, sizeof(prog_fd));
    nla->nla_len += nla_xdp->nla_len;

    /* if user passed in any flags, add those too */
    __u32 flags = XDP_FLAGS_SKB_MODE;
    nla_xdp = (struct nlattr *)((char *)nla + nla->nla_len);
    nla_xdp->nla_type = IFLA_XDP_FLAGS;
    nla_xdp->nla_len = NLA_HDRLEN + sizeof(flags);
    memcpy((char *)nla_xdp + NLA_HDRLEN, &flags, sizeof(flags));
    nla->nla_len += nla_xdp->nla_len;

    req.nh.nlmsg_len += NLA_ALIGN(nla->nla_len);

    if (send(sock, &req, req.nh.nlmsg_len, 0) < 0)
        err(1, "send");
    ret = bpf_netlink_recv(sock, nl_pid, seq);

cleanup:
    close(sock);
    return ret;
}

ასე რომ, ყველაფერი მზად არის ტესტირებისთვის:

$ cc nolibbpf.c -o nolibbpf
$ sudo strace -e bpf ./nolibbpf
bpf(BPF_MAP_CREATE, {map_type=BPF_MAP_TYPE_ARRAY, map_name="woo", ...}, 72) = 3
bpf(BPF_PROG_LOAD, {prog_type=BPF_PROG_TYPE_XDP, insn_cnt=15, prog_name="woo", ...}, 72) = 4
+++ exited with 0 +++

ვნახოთ, უკავშირდება თუ არა ჩვენი პროგრამა lo:

$ ip l show dev lo
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 xdpgeneric qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    prog/xdp id 160

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

$ for s in `seq 234`; do sudo ping -f -c 100 127.0.0.1 >/dev/null 2>&1; done
$ sudo bpftool m dump name woo
key: 00 00 00 00  value: 90 01 00 00 00 00 00 00
key: 01 00 00 00  value: 00 00 00 00 00 00 00 00
key: 02 00 00 00  value: 00 00 00 00 00 00 00 00
key: 03 00 00 00  value: 00 00 00 00 00 00 00 00
key: 04 00 00 00  value: 00 00 00 00 00 00 00 00
key: 05 00 00 00  value: 00 00 00 00 00 00 00 00
key: 06 00 00 00  value: 40 b5 00 00 00 00 00 00
key: 07 00 00 00  value: 00 00 00 00 00 00 00 00
Found 8 elements

რა, ყველაფერი მუშაობს. სხვათა შორის, გაითვალისწინეთ, რომ ჩვენი რუკა კვლავ ნაჩვენებია ბაიტების სახით. ეს გამოწვეულია იმით, რომ განსხვავებით libbpf ჩვენ არ ჩავტვირთეთ ტიპის ინფორმაცია (BTF). მაგრამ ამაზე მეტს შემდეგ ჯერზე ვისაუბრებთ.

განვითარების ინსტრუმენტები

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

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

• llvm/clang
• pahole
• მისი ბირთვი
• bpftool

(ცნობისთვის, ეს განყოფილება და სტატიის ყველა მაგალითი გაშვებულია Debian 10-ზე.)

llvm/clang

BPF მეგობრულია LLVM-თან და, მიუხედავად იმისა, რომ ბოლო დროს BPF-ის პროგრამების შედგენა შესაძლებელია gcc-ის გამოყენებით, ყველა მიმდინარე განვითარება ხორციელდება LLVM-სთვის. ამიტომ, პირველ რიგში, ჩვენ ავაშენებთ მიმდინარე ვერსიას clang git-დან:

$ sudo apt install ninja-build
$ git clone --depth 1 https://github.com/llvm/llvm-project.git
$ mkdir -p llvm-project/llvm/build/install
$ cd llvm-project/llvm/build
$ cmake .. -G "Ninja" -DLLVM_TARGETS_TO_BUILD="BPF;X86" 
                      -DLLVM_ENABLE_PROJECTS="clang" 
                      -DBUILD_SHARED_LIBS=OFF 
                      -DCMAKE_BUILD_TYPE=Release 
                      -DLLVM_BUILD_RUNTIME=OFF
$ time ninja
... много времени спустя
$

ახლა ჩვენ შეგვიძლია შევამოწმოთ თუ არა ყველაფერი სწორად:

$ ./bin/llc --version
LLVM (http://llvm.org/):
  LLVM version 11.0.0git
  Optimized build.
  Default target: x86_64-unknown-linux-gnu
  Host CPU: znver1

  Registered Targets:
    bpf    - BPF (host endian)
    bpfeb  - BPF (big endian)
    bpfel  - BPF (little endian)
    x86    - 32-bit X86: Pentium-Pro and above
    x86-64 - 64-bit X86: EM64T and AMD64

(შეკრების ინსტრუქცია clang ჩემ მიერ აღებული bpf_devel_QA.)

ჩვენ არ დავაინსტალირებთ პროგრამებს, რომლებიც ახლახან შევქმენით, არამედ უბრალოდ დავამატებთ მათ PATH, მაგალითად:

export PATH="`pwd`/bin:$PATH"

(ეს შეიძლება დაემატოს .bashrc ან ცალკე ფაილში. პირადად მე ვამატებ მსგავს რაღაცეებს ~/bin/activate-llvm.sh და როცა საჭიროა ვაკეთებ . activate-llvm.sh.)

პაჰოლი და BTF

კომუნალური pahole გამოიყენება ბირთვის აგებისას BTF ფორმატში გამართვის ინფორმაციის შესაქმნელად. BTF ტექნოლოგიის დეტალების შესახებ ამ სტატიაში არ განვიხილავთ, გარდა იმისა, რომ ის მოსახერხებელია და გვინდა გამოვიყენოთ. ასე რომ, თუ თქვენი ბირთვის შექმნას აპირებთ, ჯერ ააშენეთ pahole (გარეშე pahole თქვენ ვერ შეძლებთ ბირთვის აშენებას პარამეტრით CONFIG_DEBUG_INFO_BTF:

$ git clone https://git.kernel.org/pub/scm/devel/pahole/pahole.git
$ cd pahole/
$ sudo apt install cmake
$ mkdir build
$ cd build/
$ cmake -D__LIB=lib ..
$ make
$ sudo make install
$ which pahole
/usr/local/bin/pahole

ბირთვები BPF-ის ექსპერიმენტებისთვის

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

ბირთვის ასაშენებლად, პირველ რიგში, საჭიროა თავად ბირთვი და მეორეც, ბირთვის კონფიგურაციის ფაილი. BPF-ზე ექსპერიმენტისთვის შეგვიძლია გამოვიყენოთ ჩვეულებრივი ვანილი ბირთვი ან განვითარების ერთ-ერთი ბირთვი. ისტორიულად, BPF განვითარება ხდება Linux ქსელის საზოგადოებაში და, შესაბამისად, ყველა ცვლილება ადრე თუ გვიან გადადის დევიდ მილერზე, Linux ქსელის შემქმნელზე. მათი ბუნებიდან გამომდინარე - რედაქტირება ან ახალი ფუნქციები - ქსელის ცვლილებები იყოფა ორ ბირთვში - net ან net-next. BPF-ის ცვლილებები ნაწილდება ერთნაირად bpf и bpf-next, რომლებიც შემდეგ გაერთიანებულია net და net-next, შესაბამისად. დაწვრილებით იხ bpf_devel_QA и netdev-FAQ. ასე რომ, შეარჩიეთ ბირთვი თქვენი გემოვნებისა და სისტემის სტაბილურობის საჭიროებებზე დაყრდნობით, რომელზედაც ამოწმებთ (*-next ბირთვები ჩამოთვლილთაგან ყველაზე არასტაბილურია).

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

ჩამოტვირთეთ ერთ-ერთი ზემოთ მოცემული ბირთვი:

$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git
$ cd bpf-next

შექმენით მინიმალური სამუშაო ბირთვის კონფიგურაცია:

$ cp /boot/config-`uname -r` .config
$ make localmodconfig

ჩართეთ BPF პარამეტრები ფაილში .config თქვენი არჩევანით (სავარაუდოდ CONFIG_BPF უკვე ჩართული იქნება, რადგან systemd იყენებს მას). აქ მოცემულია ამ სტატიისთვის გამოყენებული ბირთვის ვარიანტების სია:

CONFIG_CGROUP_BPF=y
CONFIG_BPF=y
CONFIG_BPF_LSM=y
CONFIG_BPF_SYSCALL=y
CONFIG_ARCH_WANT_DEFAULT_BPF_JIT=y
CONFIG_BPF_JIT_ALWAYS_ON=y
CONFIG_BPF_JIT_DEFAULT_ON=y
CONFIG_IPV6_SEG6_BPF=y
# CONFIG_NETFILTER_XT_MATCH_BPF is not set
# CONFIG_BPFILTER is not set
CONFIG_NET_CLS_BPF=y
CONFIG_NET_ACT_BPF=y
CONFIG_BPF_JIT=y
CONFIG_BPF_STREAM_PARSER=y
CONFIG_LWTUNNEL_BPF=y
CONFIG_HAVE_EBPF_JIT=y
CONFIG_BPF_EVENTS=y
CONFIG_BPF_KPROBE_OVERRIDE=y
CONFIG_DEBUG_INFO_BTF=y

შემდეგ ჩვენ შეგვიძლია მარტივად ავაწყოთ და დავაინსტალიროთ მოდულები და ბირთვი (სხვათა შორის, ბირთვის აწყობა შეგიძლიათ ახლად აწყობილის გამოყენებით clangდამატებით CC=clang):

$ make -s -j $(getconf _NPROCESSORS_ONLN)
$ sudo make modules_install
$ sudo make install

და გადატვირთეთ ახალი ბირთვით (ამისთვის ვიყენებ kexec პაკეტიდან kexec-tools):

v=5.8.0-rc6+ # если вы пересобираете текущее ядро, то можно делать v=`uname -r`
sudo kexec -l -t bzImage /boot/vmlinuz-$v --initrd=/boot/initrd.img-$v --reuse-cmdline &&
sudo kexec -e

bpftool

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

ამ წერის დროს bpftool მზადდება მხოლოდ RHEL, Fedora და Ubuntu-სთვის (იხილეთ, მაგალითად, ეს თემა, რომელიც შეფუთვის დაუმთავრებელ ისტორიას მოგვითხრობს bpftool Debian-ში). მაგრამ თუ უკვე შექმენით თქვენი ბირთვი, მაშინ ააშენეთ bpftool ტორტივით მარტივი:

$ cd ${linux}/tools/bpf/bpftool
# ... пропишите пути к последнему clang, как рассказано выше
$ make -s

Auto-detecting system features:
...                        libbfd: [ on  ]
...        disassembler-four-args: [ on  ]
...                          zlib: [ on  ]
...                        libcap: [ on  ]
...               clang-bpf-co-re: [ on  ]

Auto-detecting system features:
...                        libelf: [ on  ]
...                          zlib: [ on  ]
...                           bpf: [ on  ]

$

(აქ ${linux} - ეს არის თქვენი ბირთვის დირექტორია.) ამ ბრძანებების შესრულების შემდეგ bpftool შეგროვდება დირექტორიაში ${linux}/tools/bpf/bpftool და ის შეიძლება დაემატოს ბილიკს (პირველ რიგში მომხმარებლისთვის root) ან უბრალოდ დააკოპირეთ /usr/local/sbin.

Შეგროვება bpftool უმჯობესია გამოიყენოთ ეს უკანასკნელი clang, აწყობილია როგორც ზემოთ აღწერილი და შეამოწმეთ სწორად არის თუ არა აწყობილი - მაგალითად, ბრძანების გამოყენებით

$ sudo bpftool feature probe kernel
Scanning system configuration...
bpf() syscall for unprivileged users is enabled
JIT compiler is enabled
JIT compiler hardening is disabled
JIT compiler kallsyms exports are enabled for root
...

რომელიც აჩვენებს, რომელი BPF ფუნქციებია ჩართული თქვენს ბირთვში.

სხვათა შორის, წინა ბრძანება შეიძლება შესრულდეს როგორც

# bpftool f p k

ეს კეთდება პაკეტიდან კომუნალური საშუალებების ანალოგიით iproute2, სადაც შეგვიძლია, მაგალითად, ვთქვათ ip a s eth0 ნაცვლად ip addr show dev eth0.

დასკვნა

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

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

ეს სტატია, თუმცა არც თუ ისე მოკლეა, არის მხოლოდ შესავალი BPF-ის სამყაროში და არ აღწერს „მოწინავე“ მახასიათებლებს და არქიტექტურის მნიშვნელოვან ნაწილებს. მომავალი გეგმა დაახლოებით ასეთია: შემდეგი სტატია იქნება BPF პროგრამის ტიპების მიმოხილვა (5.8 ბირთვში მხარდაჭერილია პროგრამის 30 ტიპი), შემდეგ ჩვენ საბოლოოდ გადავხედავთ, თუ როგორ დავწეროთ რეალური BPF აპლიკაციები ბირთვის მიკვლევის პროგრამების გამოყენებით. მაგალითად, დროა ჩავიტაროთ უფრო სიღრმისეული კურსი BPF არქიტექტურაზე, რასაც მოჰყვება BPF ქსელის და უსაფრთხოების აპლიკაციების მაგალითები.

წინა სტატიები ამ სერიის

1. BPF პატარებისთვის, ნაწილი ნულოვანი: კლასიკური BPF

ბმულები

1. BPF და XDP საცნობარო გზამკვლევი - დოკუმენტაცია BPF-ის შესახებ cilium-დან, უფრო სწორედ დანიელ ბორკმენისგან, BPF-ის ერთ-ერთი შემქმნელისა და შემსრულებლისგან. ეს არის ერთ-ერთი პირველი სერიოზული აღწერილობა, რომელიც განსხვავდება სხვებისგან იმით, რომ დანიელმა ზუსტად იცის, რაზე წერს და იქ შეცდომები არ არის. კერძოდ, ეს დოკუმენტი აღწერს, თუ როგორ უნდა იმუშაოთ XDP და TC ტიპის BPF პროგრამებთან ცნობილი უტილიტის გამოყენებით. ip პაკეტიდან iproute2.

2. Documentation/networking/filter.txt — ორიგინალური ფაილი კლასიკური და შემდეგ გაფართოებული BPF-ის დოკუმენტაციით. კარგი წასაკითხია, თუ გსურთ ასამბლეის ენისა და ტექნიკური არქიტექტურული დეტალების შესწავლა.

3. ბლოგი BPF-ის შესახებ ფეისბუქიდან. იგი განახლებულია იშვიათად, მაგრამ მართებულად, როგორც წერენ იქ ალექსეი სტაროვოიტოვი (eBPF-ის ავტორი) და ანდრიი ნაკრიიკო - (შემსრულებელი). libbpf).

4. bpftool-ის საიდუმლოებები. გასართობი ტვიტერის თემა კვენტინ მონესგან bpftool-ის გამოყენების მაგალითებითა და საიდუმლოებით.

5. ჩაყვინთეთ BPF-ში: საკითხავი მასალის სია. გიგანტური (და ჯერ კიდევ შენარჩუნებული) სია BPF დოკუმენტაციის ბმულების კვენტინ მონედან.

წყარო: www.habr.com