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

Berkeley Packet Filters (BPF) არის Linux-ის ბირთვის ტექნოლოგია, რომელიც უკვე რამდენიმე წელია ინგლისურენოვანი ტექნიკური გამოცემების პირველ გვერდებზეა. კონფერენციები ივსება ანგარიშებით BPF-ის გამოყენებისა და განვითარების შესახებ. დევიდ მილერი, Linux ქსელის ქვესისტემის შემსრულებელი, უწოდებს თავის გამოსვლას Linux Plumbers 2018-ზე "ეს საუბარი არ არის XDP-ზე" (XDP არის BPF-ის გამოყენების ერთ-ერთი შემთხვევა). ბრენდან გრეგი ატარებს მოლაპარაკებებს სათაურით Linux BPF სუპერ ძალები. ტოკე ჰოილანდი-იორგენსენი იცინისრომ ბირთვი ახლა მიკროკერნელია. თომას გრაფი ხელს უწყობს იმ აზრს, რომ BPF არის javascript ბირთვისთვის.

ჯერ კიდევ არ არის BPF-ის სისტემური აღწერა Habré-ზე და ამიტომ სტატიების სერიაში შევეცდები ვისაუბრო ტექნოლოგიის ისტორიაზე, აღვწერო არქიტექტურისა და განვითარების ინსტრუმენტები და გამოვყო BPF გამოყენების გამოყენების სფეროები და პრაქტიკა. ეს სტატია, ნულოვანი, სერიაში, მოგვითხრობს კლასიკური BPF-ის ისტორიასა და არქიტექტურას და ასევე ავლენს მისი მოქმედების პრინციპების საიდუმლოებებს. tcpdump, seccomp, strace, და უფრო მეტი.

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

მოკლე კურსი BPF-ის ისტორიაში (c)

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

გასული საუკუნის ოთხმოციანი წლების ბოლოს, ცნობილი ლოურენს ბერკლის ლაბორატორიის ინჟინრები დაინტერესდნენ კითხვაზე, თუ როგორ სწორად გაფილტრონ ქსელის პაკეტები აპარატურაზე, რომელიც თანამედროვე იყო გასული საუკუნის ოთხმოციანი წლების ბოლოს. ფილტრაციის ძირითადი იდეა, რომელიც თავდაპირველად განხორციელდა CSPF (CMU/Stanford Packet Filter) ტექნოლოგიაში, იყო არასაჭირო პაკეტების რაც შეიძლება ადრე გაფილტვრა, ე.ი. ბირთვის სივრცეში, რადგან ეს თავიდან აიცილებს არასაჭირო მონაცემების მომხმარებლის სივრცეში კოპირებას. ბირთვის სივრცეში მომხმარებლის კოდის გაშვების უსაფრთხოების უზრუნველსაყოფად, გამოყენებული იქნა sandboxed ვირტუალური მანქანა.

თუმცა, არსებული ფილტრების ვირტუალური მანქანები შექმნილია სტეკზე დაფუძნებულ მანქანებზე მუშაობისთვის და არ მუშაობდნენ ისე ეფექტურად ახალ RISC აპარატებზე. შედეგად, Berkeley Labs-ის ინჟინრების ძალისხმევით, შეიქმნა ახალი BPF (Berkeley Packet Filters) ტექნოლოგია, რომლის ვირტუალური მანქანის არქიტექტურა შეიქმნა Motorola 6502 პროცესორის საფუძველზე - ისეთი ცნობილი პროდუქტების მუშა. Apple II ან NES. ახალმა ვირტუალურმა მანქანამ ათჯერ გაზარდა ფილტრის მოქმედება არსებულ გადაწყვეტილებებთან შედარებით.

BPF მანქანების არქიტექტურა

არქიტექტურას სამუშაო გზით, მაგალითების ანალიზით გავეცნობით. თუმცა, დასაწყისისთვის, ვთქვათ, რომ აპარატს ჰქონდა მომხმარებლისთვის ხელმისაწვდომი ორი 32-ბიტიანი რეგისტრი, აკუმულატორი. A და ინდექსის რეესტრი X, 64 ბაიტი მეხსიერება (16 სიტყვა), ხელმისაწვდომია ჩასაწერად და შემდგომ წასაკითხად და ბრძანებების მცირე სისტემა ამ ობიექტებთან მუშაობისთვის. პირობითი გამონათქვამების განხორციელების ნახტომის ინსტრუქციები ასევე ხელმისაწვდომი იყო პროგრამებში, მაგრამ პროგრამის დროულად დასრულების გარანტირებისთვის, ნახტომები მხოლოდ წინ იყო შესაძლებელი, ანუ, კერძოდ, აკრძალული იყო მარყუჟების შექმნა.

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

ზემოთ ჩამოთვლილი საკმარისი იქნება იმისათვის, რომ დავიწყოთ მაგალითების ყურება: საჭიროებისამებრ გავეცნობით სისტემას და ბრძანების ფორმატს. თუ გსურთ დაუყოვნებლივ შეისწავლოთ ვირტუალური მანქანის ბრძანების სისტემა და გაეცნოთ მის ყველა შესაძლებლობებს, მაშინ შეგიძლიათ წაიკითხოთ ორიგინალური სტატია BSD პაკეტის ფილტრი ან/და ფაილის პირველი ნახევარი Documentation/networking/filter.txt ბირთვის დოკუმენტაციიდან. გარდა ამისა, შეგიძლიათ შეისწავლოთ პრეზენტაცია libpcap: არქიტექტურა და ოპტიმიზაციის მეთოდოლოგია პაკეტის დაჭერისთვის, რომელშიც მაკკანი, BPF-ის ერთ-ერთი ავტორი, შექმნის ისტორიაზე საუბრობს libpcap.

ახლა ჩვენ განვიხილავთ Linux-ზე კლასიკური BPF-ის გამოყენების ყველა მნიშვნელოვან მაგალითს: tcpdump (libpcap), სეკკომი, xt_bpf, cls_bpf.

tcpdump

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

(ამ სტატიაში ყველა მაგალითი გავატარე Linux-ზე 5.6.0-rc6. ზოგიერთი ბრძანების გამომავალი რედაქტირებულია უკეთესი წაკითხვისთვის.)

მაგალითი: IPv6 პაკეტებზე დაკვირვება

წარმოვიდგინოთ, რომ ჩვენ გვინდა შევხედოთ ყველა IPv6 პაკეტს ინტერფეისზე eth0. ამისათვის ჩვენ შეგვიძლია გავუშვათ პროგრამა tcpdump მარტივი ფილტრით ip6:

$ sudo tcpdump -i eth0 ip6

ამ შემთხვევაში, tcpdump ადგენს ფილტრს ip6 BPF არქიტექტურის ბაიტეკოდში და გაგზავნეთ ის ბირთვში (იხილეთ დეტალები განყოფილებაში Tcpdump: იტვირთება). დატვირთული ფილტრი იმუშავებს ყველა პაკეტისთვის, რომელიც გადის ინტერფეისში eth0. თუ ფილტრი აბრუნებს არანულოვან მნიშვნელობას n, შემდეგ მდე n პაკეტის ბაიტი კოპირდება მომხმარებლის სივრცეში და ჩვენ ვიხილავთ მას გამოსავალში tcpdump.

გამოდის, რომ ჩვენ მარტივად შეგვიძლია გავარკვიოთ, რომელი ბაიტიკოდი იყო გაგზავნილი ბირთვში tcpdump -ის დახმარებით tcpdump, თუ გავუშვით ოფციით -d:

$ sudo tcpdump -i eth0 -d ip6
(000) ldh      [12]
(001) jeq      #0x86dd          jt 2    jf 3
(002) ret      #262144
(003) ret      #0

ნულ ხაზში ჩვენ ვასრულებთ ბრძანებას ldh [12], რაც ნიშნავს „ჩატვირთვა რეგისტრში A ნახევარი სიტყვა (16 ბიტი) მდებარეობს მისამართზე 12” და ერთადერთი კითხვაა, რა სახის მეხსიერებას მივმართავთ? პასუხი არის ის, რომ ზე x იწყება (x+1)გაანალიზებული ქსელის პაკეტის ე ბაიტი. ჩვენ ვკითხულობთ პაკეტებს Ethernet ინტერფეისიდან eth0, და ეს ნიშნავსრომ პაკეტი ასე გამოიყურება (სიმარტივისთვის, ჩვენ ვვარაუდობთ, რომ პაკეტში არ არის VLAN ტეგები):

       6              6          2
|Destination MAC|Source MAC|Ether Type|...|

ასე რომ, ბრძანების შესრულების შემდეგ ldh [12] რეესტრში A იქნება ველი Ether Type - ამ Ethernet ჩარჩოში გადაცემული პაკეტის ტიპი. 1 სტრიქონზე ჩვენ ვადარებთ რეესტრის შინაარსს A (პაკეტის ტიპი) გ 0x86dd, და ეს და არსებობს ტიპი, რომელიც ჩვენ გვაინტერესებს არის IPv6. 1 ხაზზე, შედარების ბრძანების გარდა, არის კიდევ ორი ​​სვეტი - jt 2 и jf 3 - ნიშნები, რომლებზეც უნდა მიხვიდეთ, თუ შედარება წარმატებულია (A == 0x86dd) და წარუმატებელი. ასე რომ, წარმატებულ შემთხვევაში (IPv6) მივდივართ მე-2 სტრიქონზე, ხოლო წარუმატებელ შემთხვევაში - მე-3 სტრიქონზე. მე-3 სტრიქონზე პროგრამა მთავრდება კოდით 0 (არ დააკოპიროთ პაკეტი), მე-2 ხაზზე პროგრამა მთავრდება კოდით. 262144 (დამიკოპირეთ მაქსიმუმ 256 კილობაიტი პაკეტი).

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

ვნახოთ, როგორ გამოიყურება ფილტრი, რომელიც აკოპირებს ყველა TCP პაკეტს დანიშნულების პორტით 666. ჩვენ განვიხილავთ IPv4 შემთხვევას, რადგან IPv6 შემთხვევა უფრო მარტივია. ამ მაგალითის შესწავლის შემდეგ, შეგიძლიათ თავად შეისწავლოთ IPv6 ფილტრი, როგორც სავარჯიშო (ip6 and tcp dst port 666) და ფილტრი ზოგადი შემთხვევისთვის (tcp dst port 666). ასე რომ, ფილტრი, რომელიც ჩვენ გვაინტერესებს, ასე გამოიყურება:

$ sudo tcpdump -i eth0 -d ip and tcp dst port 666
(000) ldh      [12]
(001) jeq      #0x800           jt 2    jf 10
(002) ldb      [23]
(003) jeq      #0x6             jt 4    jf 10
(004) ldh      [20]
(005) jset     #0x1fff          jt 10   jf 6
(006) ldxb     4*([14]&0xf)
(007) ldh      [x + 16]
(008) jeq      #0x29a           jt 9    jf 10
(009) ret      #262144
(010) ret      #0

ჩვენ უკვე ვიცით რას აკეთებს 0 და 1 ხაზები. მე-2 ხაზზე ჩვენ უკვე შევამოწმეთ, რომ ეს არის IPv4 პაკეტი (ეთერის ტიპი = 0x800) და ჩატვირთეთ ის რეესტრში A პაკეტის 24-ე ბაიტი. ჩვენი პაკეტი ასე გამოიყურება

       14            8      1     1
|ethernet header|ip fields|ttl|protocol|...|

რაც ნიშნავს, რომ ჩვენ ვტვირთავთ რეესტრში A IP სათაურის პროტოკოლის ველი, რაც ლოგიკურია, რადგან გვინდა მხოლოდ TCP პაკეტების კოპირება. ჩვენ შევადარებთ პროტოკოლს 0x6 (IPPROTO_TCP) მე-3 ხაზზე.

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

მე-6 ხაზი ყველაზე საინტერესოა ამ ჩამონათვალში. გამოხატულება ldxb 4*([14]&0xf) ნიშნავს, რომ ჩავტვირთავთ რეესტრში X პაკეტის მეთხუთმეტე ბაიტის ყველაზე ნაკლებად მნიშვნელოვანი ოთხი ბიტი გამრავლებული 4-ზე. მეთხუთმეტე ბაიტის ყველაზე ნაკლებად მნიშვნელოვანი ოთხი ბიტი არის ველი ინტერნეტის სათაურის სიგრძე IPv4 სათაური, რომელიც ინახავს სათაურის სიგრძეს სიტყვებში, ასე რომ თქვენ უნდა გაამრავლოთ 4-ზე. საინტერესოა, რომ გამოხატულება 4*([14]&0xf) არის აღნიშვნა სპეციალური მისამართის სქემისთვის, რომელიც შეიძლება გამოყენებულ იქნას მხოლოდ ამ ფორმით და მხოლოდ რეესტრისთვის X, ე.ი. ვერც ვიტყვით ldb 4*([14]&0xf) არც ldxb 5*([14]&0xf) (ჩვენ შეგვიძლია მხოლოდ სხვადასხვა ოფსეტის მითითება, მაგალითად, ldxb 4*([16]&0xf)). ნათელია, რომ ეს მისამართის სქემა დაემატა BPF-ს სწორედ მისაღებად X (ინდექსის რეგისტრი) IPv4 სათაურის სიგრძე.

ამიტომ მე-7 სტრიქონზე ვცდილობთ ჩავტვირთოთ ნახევარი სიტყვა (X+16). გახსოვდეთ, რომ 14 ბაიტი იკავებს Ethernet-ის სათაურს და X შეიცავს IPv4 სათაურის სიგრძეს, ჩვენ გვესმის, რომ ში A TCP დანიშნულების პორტი ჩატვირთულია:

       14           X           2             2
|ethernet header|ip header|source port|destination port|

ბოლოს მე-8 სტრიქონზე ვადარებთ დანიშნულების პორტს სასურველ მნიშვნელობას და მე-9 ან მე-10 სტრიქონზე ვაბრუნებთ შედეგს - დავაკოპიროთ თუ არა პაკეტი.

Tcpdump: იტვირთება

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

• შექმენით ტიპის აღმწერი pcap_t ინტერფეისის სახელიდან: pcap_create,
• ინტერფეისის გააქტიურება: pcap_activate,
• კომპილაციის ფილტრი: pcap_compile,
• ფილტრის დაკავშირება: pcap_setfilter.

რომ ნახოთ როგორ ფუნქციონირებს pcap_setfilter დანერგილი Linux-ში, ჩვენ ვიყენებთ strace (ზოგიერთი ხაზი ამოღებულია):

$ sudo strace -f -e trace=%network tcpdump -p -i eth0 ip
socket(AF_PACKET, SOCK_RAW, 768)        = 3
bind(3, {sa_family=AF_PACKET, sll_protocol=htons(ETH_P_ALL), sll_ifindex=if_nametoindex("eth0"), sll_hatype=ARPHRD_NETROM, sll_pkttype=PACKET_HOST, sll_halen=0}, 20) = 0
setsockopt(3, SOL_SOCKET, SO_ATTACH_FILTER, {len=4, filter=0xb00bb00bb00b}, 16) = 0
...

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

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

ფარული სიმართლე

გამომავალი ოდნავ უფრო სრულყოფილი ვერსია ასე გამოიყურება:

$ sudo strace -f -e trace=%network tcpdump -p -i eth0 ip
socket(AF_PACKET, SOCK_RAW, 768)        = 3
bind(3, {sa_family=AF_PACKET, sll_protocol=htons(ETH_P_ALL), sll_ifindex=if_nametoindex("eth0"), sll_hatype=ARPHRD_NETROM, sll_pkttype=PACKET_HOST, sll_halen=0}, 20) = 0
setsockopt(3, SOL_SOCKET, SO_ATTACH_FILTER, {len=1, filter=0xbeefbeefbeef}, 16) = 0
recvfrom(3, 0x7ffcad394257, 1, MSG_TRUNC, NULL, NULL) = -1 EAGAIN (Resource temporarily unavailable)
setsockopt(3, SOL_SOCKET, SO_ATTACH_FILTER, {len=4, filter=0xb00bb00bb00b}, 16) = 0
...

როგორც ზემოთ აღინიშნა, ჩვენ ვტვირთავთ და ვამაგრებთ ჩვენს ფილტრს სოკეტზე მე-5 ხაზზე, მაგრამ რა ხდება მე-3 და მე-4 ხაზებზე? გამოდის, რომ ეს libpcap ზრუნავს ჩვენზე - ისე, რომ ჩვენი ფილტრის გამომავალი არ მოიცავდეს პაკეტებს, რომლებიც მას არ აკმაყოფილებს, ბიბლიოთეკა აკავშირებს მოჩვენებითი ფილტრი ret #0 (ჩააგდეთ ყველა პაკეტი), ცვლის სოკეტს არადაბლოკვის რეჟიმში და ცდილობს გამოაკლოს ყველა პაკეტი, რომელიც შეიძლება დარჩეს წინა ფილტრებიდან.

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

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

დამატებითი დეტალები გამოყენების შესახებ setsockopt ფილტრების დასაკავშირებლად იხ სოკეტი (7), მაგრამ საკუთარი ფილტრების დაწერის შესახებ, როგორიცაა struct sock_fprog დახმარების გარეშე tcpdump ჩვენ ვისაუბრებთ განყოფილებაში BPF-ის დაპროგრამება საკუთარი ხელით.

კლასიკური BPF და 21-ე საუკუნე

BPF შევიდა Linux-ში 1997 წელს და კარგა ხანს დარჩა სამუშაო ძალად libpcap რაიმე განსაკუთრებული ცვლილებების გარეშე (რა თქმა უნდა, ლინუქსის სპეციფიკური ცვლილებები, ჩვენ, მაგრამ მათ არ შეცვალეს გლობალური სურათი). პირველი სერიოზული ნიშნები იმისა, რომ BPF განვითარდებოდა, გამოჩნდა 2011 წელს, როდესაც ერიკ დუმაზეტმა შესთავაზა პატჩი, რომელიც ამატებს Just In Time Compiler-ს ბირთვს - თარჯიმანი BPF ბაიტიკოდის მშობლიურად კონვერტაციისთვის x86_64 კოდი.

JIT შემდგენელი იყო პირველი ცვლილებების ჯაჭვში: 2012 წელს გამოჩნდა ფილტრების დაწერის უნარი წამიBPF-ის გამოყენებით, 2013 წლის იანვარში იყო დაემატა მოდული xt_bpf, რომელიც საშუალებას გაძლევთ დაწეროთ წესები iptables BPF-ის დახმარებით და 2013 წლის ოქტომბერში იყო დაემატა ასევე მოდული cls_bpf, რომელიც საშუალებას გაძლევთ დაწეროთ ტრაფიკის კლასიფიკატორები BPF გამოყენებით.

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

BPF-ის დაპროგრამება საკუთარი ხელით

მოდით გავეცნოთ BPF ინსტრუქციების ორობით ფორმატს, ეს ძალიან მარტივია:

   16    8    8     32
| code | jt | jf |  k  |

თითოეული ინსტრუქცია იკავებს 64 ბიტს, რომელშიც პირველი 16 ბიტი არის ინსტრუქციის კოდი, შემდეგ არის ორი რვა ბიტიანი შეწევა, jt и jf, და 32 ბიტი არგუმენტისთვის K, რომლის დანიშნულებაც განსხვავდება ბრძანებიდან ბრძანებამდე. მაგალითად, ბრძანება ret, რომელიც წყვეტს პროგრამას აქვს კოდი 6და დაბრუნების მნიშვნელობა აღებულია მუდმივიდან K. C-ში ერთი BPF ინსტრუქცია წარმოდგენილია როგორც სტრუქტურა

struct sock_filter {
        __u16   code;
        __u8    jt;
        __u8    jf;
        __u32   k;
}

და მთელი პროგრამა არის სტრუქტურის სახით

struct sock_fprog {
        unsigned short len;
        struct sock_filter *filter;
}

ამრიგად, ჩვენ უკვე შეგვიძლია დავწეროთ პროგრამები (მაგალითად, ჩვენ ვიცით ინსტრუქციის კოდები [1]). ასე გამოიყურება ფილტრი ip6 საქართველოს ჩვენი პირველი მაგალითი:

struct sock_filter code[] = {
        { 0x28, 0, 0, 0x0000000c },
        { 0x15, 0, 1, 0x000086dd },
        { 0x06, 0, 0, 0x00040000 },
        { 0x06, 0, 0, 0x00000000 },
};
struct sock_fprog prog = {
        .len = ARRAY_SIZE(code),
        .filter = code,
};

პროგრამა prog ჩვენ შეგვიძლია ლეგალურად გამოვიყენოთ ზარში

setsockopt(sk, SOL_SOCKET, SO_ATTACH_FILTER, &prog, sizeof(prog))

მანქანების კოდების სახით პროგრამების დაწერა არც თუ ისე მოსახერხებელია, მაგრამ ზოგჯერ აუცილებელია (მაგალითად, გამართვისთვის, ერთეულის ტესტების შესაქმნელად, სტატიების დაწერა Habré-ზე და ა.შ.). მოხერხებულობისთვის, ფაილში <linux/filter.h> დამხმარე მაკრო განსაზღვრულია - იგივე მაგალითი, როგორც ზემოთ, შეიძლება გადაიწეროს როგორც

struct sock_filter code[] = {
        BPF_STMT(BPF_LD|BPF_H|BPF_ABS, 12),
        BPF_JUMP(BPF_JMP|BPF_JEQ|BPF_K, ETH_P_IPV6, 0, 1),
        BPF_STMT(BPF_RET|BPF_K, 0x00040000),
        BPF_STMT(BPF_RET|BPF_K, 0),
}

თუმცა, ეს ვარიანტი არ არის ძალიან მოსახერხებელი. ეს არის ის, რასაც Linux kernel პროგრამისტები ამტკიცებდნენ და, შესაბამისად, დირექტორიაში tools/bpf ბირთვებში შეგიძლიათ იპოვოთ ასამბლერი და გამართვა კლასიკურ BPF-თან მუშაობისთვის.

ასამბლეის ენა ძალიან ჰგავს გამართვის გამომავალს tcpdump, მაგრამ დამატებით შეგვიძლია სიმბოლური ეტიკეტების მითითება. მაგალითად, აქ არის პროგრამა, რომელიც ჩამოაგდებს ყველა პაკეტს TCP/IPv4-ის გარდა:

$ cat /tmp/tcp-over-ipv4.bpf
ldh [12]
jne #0x800, drop
ldb [23]
jneq #6, drop
ret #-1
drop: ret #0

ნაგულისხმევად, ასამბლეერი ქმნის კოდს ფორმატში <количество инструкций>,<code1> <jt1> <jf1> <k1>,..., ჩვენი მაგალითისთვის TCP-ით ეს იქნება

$ tools/bpf/bpf_asm /tmp/tcp-over-ipv4.bpf
6,40 0 0 12,21 0 3 2048,48 0 0 23,21 0 1 6,6 0 0 4294967295,6 0 0 0,

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

$ tools/bpf/bpf_asm -c /tmp/tcp-over-ipv4.bpf
{ 0x28,  0,  0, 0x0000000c },
{ 0x15,  0,  3, 0x00000800 },
{ 0x30,  0,  0, 0x00000017 },
{ 0x15,  0,  1, 0x00000006 },
{ 0x06,  0,  0, 0xffffffff },
{ 0x06,  0,  0, 0000000000 },

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

Linux და netsniff-ng გაფართოებები

სტანდარტული BPF-ის გარდა, Linux და tools/bpf/bpf_asm მხარდაჭერა და არასტანდარტული ნაკრები. ძირითადად, ინსტრუქციები გამოიყენება სტრუქტურის ველებზე წვდომისთვის struct sk_buff, რომელიც აღწერს ქსელის პაკეტს ბირთვში. თუმცა, ასევე არსებობს სხვა სახის დამხმარე ინსტრუქციები, მაგალითად ldw cpu ჩაიტვირთება რეესტრში A ბირთვის ფუნქციის გაშვების შედეგი raw_smp_processor_id(). (BPF-ის ახალ ვერსიაში, ეს არასტანდარტული გაფართოებები გაფართოვდა, რათა უზრუნველყოს პროგრამები ბირთვის დამხმარეების ნაკრებით მეხსიერებაზე, სტრუქტურებზე და მოვლენების გენერირებისთვის.) აქ არის ფილტრის საინტერესო მაგალითი, რომელშიც ჩვენ ვაკოპირებთ მხოლოდ პაკეტის სათაურები მომხმარებლის სივრცეში გაფართოების გამოყენებით poff, დატვირთვის ოფსეტური:

ld poff
ret a

BPF გაფართოებების გამოყენება შეუძლებელია tcpdump, მაგრამ ეს კარგი მიზეზია კომუნალური პაკეტის გასაცნობად netsniff-ng, რომელიც, სხვა საკითხებთან ერთად, შეიცავს გაფართოებულ პროგრამას netsniff-ng, რომელიც, გარდა BPF-ის გამოყენებით ფილტრაციისა, ასევე შეიცავს ეფექტურ ტრაფიკის გენერატორს და უფრო განვითარებულს, ვიდრე tools/bpf/bpf_asmდარეკა BPF ასამბლერმა bpfc. პაკეტი შეიცავს საკმაოდ დეტალურ დოკუმენტაციას, ასევე იხილეთ ბმულები სტატიის ბოლოს.

წამი

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

seccomp-ის პირველი ვერსია დაემატა ბირთვს 2005 წელს და არც თუ ისე პოპულარული იყო, რადგან ის მხოლოდ ერთ ვარიანტს იძლეოდა - პროცესისთვის ხელმისაწვდომი სისტემური ზარების ნაკრების შეზღუდვა შემდეგზე: read, write, exit и sigreturn, და პროცესი, რომელიც არღვევდა წესებს, მოკლეს გამოყენებით SIGKILL. თუმცა, 2012 წელს seccomp-მა დაამატა BPF ფილტრების გამოყენების შესაძლებლობა, რაც საშუალებას გაძლევთ განსაზღვროთ დაშვებული სისტემური ზარების ნაკრები და შეასრულოთ მათი არგუმენტების შემოწმებაც კი. (საინტერესოა, რომ Chrome იყო ამ ფუნქციის ერთ-ერთი პირველი მომხმარებელი და Chrome-ის ხალხი ამჟამად ავითარებს KRSI მექანიზმს, რომელიც დაფუძნებულია BPF-ის ახალ ვერსიაზე და საშუალებას აძლევს Linux-ის უსაფრთხოების მოდულების პერსონალიზაციას.) დამატებითი დოკუმენტაციის ბმულები შეგიძლიათ ნახოთ ბოლოს. სტატიის.

გაითვალისწინეთ, რომ ჰაბზე უკვე იყო სტატიები seccomp-ის გამოყენების შესახებ, შესაძლოა ვინმეს მოუნდეს მათი წაკითხვა შემდეგ ქვეგანყოფილებების წაკითხვამდე (ან მის ნაცვლად). სტატიაში კონტეინერები და დაცვა: seccomp გთავაზობთ seccomp-ის გამოყენების მაგალითებს, როგორც 2007 წლის ვერსიას, ასევე ვერსიას BPF გამოყენებით (ფილტრები იქმნება libseccomp-ის გამოყენებით), საუბრობს seccomp-ის კავშირზე Docker-თან და ასევე გთავაზობთ ბევრ სასარგებლო ბმულს. სტატიაში დემონების იზოლირება systemd-ით ან „ამისთვის არ გჭირდება Docker!“ ის მოიცავს, კერძოდ, როგორ დავამატოთ სისტემური ზარების შავი სიები ან თეთრი სიები სისტემაში გაშვებული დემონებისთვის.

შემდეგ ჩვენ ვნახავთ, როგორ დავწეროთ და ჩავტვირთოთ ფილტრები seccomp შიშველ C-ში და ბიბლიოთეკის გამოყენებით libseccomp და რა დადებითი და უარყოფითი მხარეები აქვს თითოეულ ვარიანტს და ბოლოს ვნახოთ, როგორ იყენებს seccomp პროგრამას strace.

ფილტრების ჩაწერა და ჩატვირთვა seccomp-ისთვის

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

seccomp(SECCOMP_SET_MODE_FILTER, flags, &filter)

სადაც &filter - ეს ჩვენთვის უკვე ნაცნობი სტრუქტურის მაჩვენებელია struct sock_fprog, ე.ი. BPF პროგრამა.

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

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

აქ nr არის გასაშვები სისტემური ზარის ნომერი, arch - მიმდინარე არქიტექტურა (დაწვრილებით ამის შესახებ ქვემოთ), args - ექვსამდე სისტემური ზარის არგუმენტი და instruction_pointer არის მითითება მომხმარებლის სივრცის ინსტრუქციებზე, რომლითაც მოხდა სისტემის ზარი. ასე, მაგალითად, სისტემის ზარის ნომრის ჩატვირთვა რეესტრში A უნდა ვთქვათ

ldw [0]

არსებობს სხვა ფუნქციები seccomp პროგრამებისთვის, მაგალითად, კონტექსტში წვდომა შესაძლებელია მხოლოდ 32-ბიტიანი გასწორებით და ვერ იტვირთება ნახევარი სიტყვა ან ბაიტი - ფილტრის ჩატვირთვისას. ldh [0] სისტემური ზარი seccomp დაბრუნდება EINVAL. ფუნქცია ამოწმებს დატვირთულ ფილტრებს seccomp_check_filter() ბირთვები. (სასაცილო ის არის, რომ თავდაპირველ commit-ში, რომელმაც დაამატა seccomp ფუნქცია, მათ დაავიწყდათ ამ ფუნქციაზე ინსტრუქციის გამოყენების ნებართვის დამატება. mod (დაყოფის დარჩენილი ნაწილი) და ახლა მიუწვდომელია seccomp BPF პროგრამებისთვის, მისი დამატების შემდეგ გატყდება ABI.)

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

ld [0]
jeq #304, bad
jeq #176, bad
jeq #239, bad
jeq #279, bad
good: ret #0x7fff0000 /* SECCOMP_RET_ALLOW */
bad: ret #0

ამოწმებს ოთხი სისტემური ზარის შავ სიას ნომრებით 304, 176, 239, 279. რა არის ეს სისტემური ზარები? დანამდვილებით ვერ ვიტყვით, რადგან არ ვიცით, რომელი არქიტექტურისთვის დაიწერა პროგრამა. ამიტომ, სეკკომპ შეთავაზება დაიწყეთ ყველა პროგრამა არქიტექტურის შემოწმებით (მიმდინარე არქიტექტურა მითითებულია კონტექსტში, როგორც ველი arch სტრუქტურები struct seccomp_data). არქიტექტურის შემოწმებისას, მაგალითის დასაწყისი ასე გამოიყურება:

ld [4]
jne #0xc000003e, bad_arch ; SCMP_ARCH_X86_64

და შემდეგ ჩვენი სისტემის ზარის ნომრები მიიღებდა გარკვეულ მნიშვნელობებს.

ჩვენ ვწერთ და ვტვირთავთ ფილტრებს seccomp-ის გამოყენებით libseccomp

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

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

#include <seccomp.h>
#include <unistd.h>
#include <err.h>

static int sys_numbers[] = {
        __NR_mount,
        __NR_umount2,
       // ... еще 40 системных вызовов ...
        __NR_vmsplice,
        __NR_perf_event_open,
};

int main(int argc, char **argv)
{
        scmp_filter_ctx ctx = seccomp_init(SCMP_ACT_ALLOW);

        for (size_t i = 0; i < sizeof(sys_numbers)/sizeof(sys_numbers[0]); i++)
                seccomp_rule_add(ctx, SCMP_ACT_TRAP, sys_numbers[i], 0);

        seccomp_load(ctx);

        execvp(argv[1], &argv[1]);
        err(1, "execlp: %s", argv[1]);
}

ჯერ განვსაზღვრავთ მასივს sys_numbers 40+ სისტემური ზარის ნომრიდან დასაბლოკად. შემდეგ კონტექსტის ინიციალიზაცია ctx და უთხარით ბიბლიოთეკას, რისი დაშვება გვინდა (SCMP_ACT_ALLOW) ყველა სისტემური ზარი ნაგულისხმევად (შავი სიების შექმნა უფრო ადვილია). შემდეგ სათითაოდ ვამატებთ ყველა სისტემურ ზარს შავი სიიდან. სისტემური ზარის საპასუხოდ, ჩვენ ვითხოვთ SCMP_ACT_TRAP, ამ შემთხვევაში seccomp სიგნალს გაუგზავნის პროცესს SIGSYS აღწერით თუ რომელი სისტემური გამოძახებით დაირღვა წესები. და ბოლოს, ჩვენ ვტვირთავთ პროგრამას ბირთვში გამოყენებით seccomp_load, რომელიც შეადგენს პროგრამას და დაურთავს პროცესს სისტემური ზარის გამოყენებით seccomp(2).

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

cc -std=c17 -Wall -Wextra -c -o seccomp_lib.o seccomp_lib.c
cc -o seccomp_lib seccomp_lib.o -lseccomp

წარმატებული გაშვების მაგალითი:

$ ./seccomp_lib echo ok
ok

დაბლოკილი სისტემური ზარის მაგალითი:

$ sudo ./seccomp_lib mount -t bpf bpf /tmp
Bad system call

Ჩვენ ვიყენებთ straceდეტალებისთვის:

$ sudo strace -e seccomp ./seccomp_lib mount -t bpf bpf /tmp
seccomp(SECCOMP_SET_MODE_FILTER, 0, {len=50, filter=0x55d8e78428e0}) = 0
--- SIGSYS {si_signo=SIGSYS, si_code=SYS_SECCOMP, si_call_addr=0xboobdeadbeef, si_syscall=__NR_mount, si_arch=AUDIT_ARCH_X86_64} ---
+++ killed by SIGSYS (core dumped) +++
Bad system call

როგორ გავიგოთ, რომ პროგრამა შეწყდა არალეგალური სისტემური ზარის გამოყენების გამო mount(2).

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

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

$ echo 1 3 6 8 13 | ./generate_bin_search_bpf.py
ld [0]
jeq #6, bad
jgt #6, check8
jeq #1, bad
jeq #3, bad
ret #0x7fff0000
check8:
jeq #8, bad
jeq #13, bad
ret #0x7fff0000
bad: ret #0

შეუძლებელია რაიმეს მნიშვნელოვნად სწრაფად დაწერა, რადგან BPF პროგრამებს არ შეუძლიათ ჩაღრმავების ნახტომები (ჩვენ არ შეგვიძლია ამის გაკეთება, მაგალითად, jmp A ან jmp [label+X]) და ამიტომ ყველა გადასვლა სტატიკურია.

seccomp და strace

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

$ time strace du /usr/share/ >/dev/null 2>&1

real    0m3.081s
user    0m0.531s
sys     0m2.073s

и

$ time strace -e open du /usr/share/ >/dev/null 2>&1

real    0m2.404s
user    0m0.193s
sys     0m1.800s

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

ახალი ვარიანტი --seccomp-bpf, დამატება strace ვერსია 5.3, საშუალებას გაძლევთ რამდენჯერმე დააჩქაროთ პროცესი და ერთი სისტემური ზარის კვალის გაშვების დრო უკვე შედარებულია ჩვეულებრივი გაშვების დროს:

$ time strace --seccomp-bpf -e open du /usr/share/ >/dev/null 2>&1

real    0m0.148s
user    0m0.017s
sys     0m0.131s

$ time du /usr/share/ >/dev/null 2>&1

real    0m0.140s
user    0m0.024s
sys     0m0.116s

(აქ, რა თქმა უნდა, არის მცირე მოტყუება, რომ ჩვენ არ ვაკვირდებით ამ ბრძანების მთავარ სისტემურ ზარს. თუ ჩვენ ვიკვლევდით, მაგალითად, newfsstat, მაშინ strace დაამუხრუჭა ისევე ძლიერად, როგორც გარეშე --seccomp-bpf.)

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

თუმცა, seccomp-ით, ამ პროცესის ოპტიმიზაცია შესაძლებელია ზუსტად ისე, როგორც ჩვენ გვსურს. კერძოდ, თუ გვინდა შევხედოთ მხოლოდ სისტემურ ზარს X, მაშინ ჩვენ შეგვიძლია დავწეროთ BPF ფილტრი ამისთვის X აბრუნებს ღირებულებას SECCOMP_RET_TRACEდა ზარებისთვის, რომლებიც ჩვენთვის არ არის საინტერესო - SECCOMP_RET_ALLOW:

ld [0]
jneq #X, ignore
trace: ret #0x7ff00000
ignore: ret #0x7fff0000

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

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

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

xt_bpf

ახლა დავუბრუნდეთ ქსელების სამყაროს.

ფონი: დიდი ხნის წინ, 2007 წელს, ბირთვი იყო დაემატა მოდული xt_u32 ნეტფილტრისთვის. იგი დაიწერა ტრაფიკის კიდევ უფრო უძველესი კლასიფიკატორის ანალოგიით cls_u32 და საშუალებას მოგცემთ დაწეროთ თვითნებური ორობითი წესები iptable-ებისთვის შემდეგი მარტივი ოპერაციების გამოყენებით: ჩატვირთეთ 32 ბიტი პაკეტიდან და შეასრულეთ მათზე არითმეტიკული მოქმედებების ნაკრები. Მაგალითად,

sudo iptables -A INPUT -m u32 --u32 "6&0xFF=1" -j LOG --log-prefix "seen-by-xt_u32"

იტვირთება IP სათაურის 32 ბიტი, დაწყებული 6-ის ბალიშიდან და იყენებს მათ ნიღაბს 0xFF (აიღეთ დაბალი ბაიტი). ეს სფერო protocol IP სათაური და ვადარებთ 1-ს (ICMP). თქვენ შეგიძლიათ დააკავშიროთ მრავალი შემოწმება ერთ წესში, ასევე შეგიძლიათ შეასრულოთ ოპერატორი @ — გადაიტანეთ X ბაიტი მარჯვნივ. მაგალითად, წესი

iptables -m u32 --u32 "6&0xFF=0x6 && 0>>22&0x3C@4=0x29"

ამოწმებს, თუ TCP Sequence Number არ არის ტოლი 0x29. დეტალებს აღარ გავაგრძელებ, რადგან უკვე ნათელია, რომ ასეთი წესების ხელით დაწერა არც თუ ისე მოსახერხებელია. სტატიაში BPF - დავიწყებული ბაიტიკოდი, არსებობს რამდენიმე ბმული გამოყენებისა და წესების გენერირების მაგალითებით xt_u32. ასევე იხილეთ ბმულები ამ სტატიის ბოლოს.

2013 წლიდან მოდული მოდულის ნაცვლად xt_u32 შეგიძლიათ გამოიყენოთ BPF დაფუძნებული მოდული xt_bpf. ვინც წაიკითხა აქამდე, უკვე უნდა იცოდეს მისი მოქმედების პრინციპი: გაუშვით BPF bytecode, როგორც iptables წესები. თქვენ შეგიძლიათ შექმნათ ახალი წესი, მაგალითად, ასე:

iptables -A INPUT -m bpf --bytecode <байткод> -j LOG

აქ <байткод> - ეს არის კოდი ასამბლერის გამომავალი ფორმატში bpf_asm ნაგულისხმევად, მაგალითად,

$ cat /tmp/test.bpf
ldb [9]
jneq #17, ignore
ret #1
ignore: ret #0

$ bpf_asm /tmp/test.bpf
4,48 0 0 9,21 0 1 17,6 0 0 1,6 0 0 0,

# iptables -A INPUT -m bpf --bytecode "$(bpf_asm /tmp/test.bpf)" -j LOG

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

ნათელია, რომ მოდული xt_bpf მხარს უჭერს უფრო რთულ ფილტრებს, ვიდრე ზემოთ მოყვანილი მაგალითი. მოდით შევხედოთ რეალურ მაგალითებს Cloudfare-დან. ბოლო დრომდე ისინი იყენებდნენ მოდულს xt_bpf DDoS შეტევებისგან დასაცავად. სტატიაში BPF ინსტრუმენტების გაცნობა ისინი განმარტავენ, თუ როგორ (და რატომ) ისინი აწარმოებენ BPF ფილტრებს და აქვეყნებენ ბმულებს ასეთი ფილტრების შესაქმნელად. მაგალითად, კომუნალური პროგრამის გამოყენებით bpfgen შეგიძლიათ შექმნათ BPF პროგრამა, რომელიც ემთხვევა სახელის DNS მოთხოვნას habr.com:

$ ./bpfgen --assembly dns -- habr.com
ldx 4*([0]&0xf)
ld #20
add x
tax

lb_0:
    ld [x + 0]
    jneq #0x04686162, lb_1
    ld [x + 4]
    jneq #0x7203636f, lb_1
    ldh [x + 8]
    jneq #0x6d00, lb_1
    ret #65535

lb_1:
    ret #0

პროგრამაში ჯერ ვტვირთავთ რეესტრში X ხაზის დასაწყისის მისამართი x04habrx03comx00 UDP მონაცემთა გრამის შიგნით და შემდეგ შეამოწმეთ მოთხოვნა: 0x04686162 <-> "x04hab" ა.შ.

ცოტა მოგვიანებით, Cloudfare-მა გამოაქვეყნა p0f -> BPF შემდგენელი კოდი. სტატიაში წარმოგიდგენთ p0f BPF შემდგენელს ისინი საუბრობენ რა არის p0f და როგორ გადაიყვანოთ p0f ხელმოწერები BPF-ად:

$ ./bpfgen p0f -- 4:64:0:0:*,0::ack+:0
39,0 0 0 0,48 0 0 8,37 35 0 64,37 0 34 29,48 0 0 0,
84 0 0 15,21 0 31 5,48 0 0 9,21 0 29 6,40 0 0 6,
...

ამჟამად Cloudfare-ს აღარ იყენებს xt_bpf, ვინაიდან ისინი გადავიდნენ XDP-ზე - BPF-ის ახალი ვერსიის გამოყენების ერთ-ერთი ვარიანტი, იხ. L4Drop: XDP DDoS შერბილებები.

cls_bpf

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

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

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

ასე რომ, დროა დავემშვიდობოთ კლასიკურ BPF-ს და შევხედოთ მომავალს.

დაემშვიდობეთ კლასიკურ BPF-ს

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

ფაქტობრივად, ამჟამად Linux-ში კლასიკური BPF-ისგან რჩება მხოლოდ API ინტერფეისი და ბირთვის შიგნით ყველა კლასიკური პროგრამა, იქნება ეს სოკეტის ფილტრები თუ seccomp ფილტრები, ავტომატურად ითარგმნება ახალ ფორმატში, Extended BPF. (ზუსტად როგორ ხდება ეს შემდეგ სტატიაში ვისაუბრებთ.)

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

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

ლიტერატურა

1. სტივენ მაკკენი და ვან ჯეიკობსონი, "BSD პაკეტის ფილტრი: ახალი არქიტექტურა მომხმარებლის დონის პაკეტების დაჭერისთვის", https://www.tcpdump.org/papers/bpf-usenix93.pdf
2. სტივენ მაკკენი, "libpcap: არქიტექტურა და ოპტიმიზაციის მეთოდოლოგია პაკეტის აღების მიზნით", https://sharkfestus.wireshark.org/sharkfest.11/presentations/McCanne-Sharkfest'11_Keynote_Address.pdf
3. tcpdump, libpcap: https://www.tcpdump.org/
4. IPtable U32 Match Tutorial.
5. BPF - დავიწყებული ბაიტიკოდი: https://blog.cloudflare.com/bpf-the-forgotten-bytecode/
6. BPF ინსტრუმენტის გაცნობა: https://blog.cloudflare.com/introducing-the-bpf-tools/
7. bpf_cls: http://man7.org/linux/man-pages/man8/tc-bpf.8.html
8. მეორე მიმოხილვა: https://lwn.net/Articles/656307/
9. https://github.com/torvalds/linux/blob/master/Documentation/userspace-api/seccomp_filter.rst
10. habr: კონტეინერები და დაცვა: seccomp
11. habr: დემონების იზოლირება სისტემით ან „ამისთვის არ გჭირდებათ დოკერი!“
12. პოლ ჩეინიონი, "strace --seccomp-bpf: გამოხედვა კაპოტის ქვეშ", https://fosdem.org/2020/schedule/event/debugging_strace_bpf/
13. netsniff-ng: http://netsniff-ng.org/

წყარო: www.habr.com