BPF សម្រាប់កូនតូច ផ្នែកសូន្យ៖ BPF បុរាណ

Berkeley Packet Filters (BPF) គឺជាបច្ចេកវិទ្យាខឺណែលលីនុច ដែលមាននៅលើទំព័រមុខនៃការបោះពុម្ពផ្សាយបច្ចេកវិទ្យាជាភាសាអង់គ្លេសអស់រយៈពេលជាច្រើនឆ្នាំមកហើយ។ សន្និសីទត្រូវបានបំពេញដោយរបាយការណ៍ស្តីពីការប្រើប្រាស់ និងការអភិវឌ្ឍន៍ BPF ។ David Miller អ្នកថែទាំប្រព័ន្ធរងបណ្តាញលីនុច ហៅការពិភាក្សារបស់គាត់នៅ Linux Plumbers 2018 "ការនិយាយនេះមិនមែននិយាយអំពី XDP ទេ" (XDP គឺជាករណីប្រើប្រាស់មួយសម្រាប់ BPF) ។ Brendan Gregg ផ្តល់ការពិភាក្សាដែលមានចំណងជើង លីនុច BPF មហាអំណាច. Toke Høiland-Jørgensen សើចថាខឺណែលឥឡូវនេះគឺជាមីក្រូខឺណែល។ Thomas Graf ផ្សព្វផ្សាយគំនិតនោះ។ BPF គឺជា javascript សម្រាប់ខឺណែល.

នៅតែមិនមានការពិពណ៌នាជាប្រព័ន្ធនៃ BPF លើHabre ទេ ដូច្នេះហើយនៅក្នុងអត្ថបទជាបន្តបន្ទាប់ ខ្ញុំនឹងព្យាយាមនិយាយអំពីប្រវត្តិនៃបច្ចេកវិទ្យា ពិពណ៌នាអំពីឧបករណ៍ស្ថាបត្យកម្ម និងការអភិវឌ្ឍន៍ ហើយរៀបរាប់ពីផ្នែកនៃការអនុវត្ត និងការអនុវត្តការប្រើប្រាស់ BPF ។ អត្ថបទនេះសូន្យនៅក្នុងស៊េរីប្រាប់ពីប្រវត្តិ និងស្ថាបត្យកម្មនៃ BPF បុរាណ ហើយក៏បង្ហាញពីអាថ៌កំបាំងនៃគោលការណ៍ប្រតិបត្តិការរបស់វាផងដែរ។ tcpdump, seccomp, strace, និងច្រើនទៀត។

ការអភិវឌ្ឍន៍ BPF ត្រូវបានគ្រប់គ្រងដោយសហគមន៍បណ្តាញលីនុច កម្មវិធីដែលមានស្រាប់សំខាន់ៗរបស់ BPF គឺទាក់ទងទៅនឹងបណ្តាញ ដូច្នេះហើយដោយមានការអនុញ្ញាត។ @eucariotខ្ញុំបានហៅស៊េរី "BPF សម្រាប់កូនតូច" ជាកិត្តិយសនៃស៊េរីដ៏អស្ចារ្យ "បណ្តាញសម្រាប់ក្មេងតូច".

វគ្គខ្លីមួយក្នុងប្រវត្តិសាស្រ្តនៃ BPF (c)

បច្ចេកវិជ្ជា BPF ទំនើបគឺជាកំណែដែលបានកែលម្អ និងពង្រីកនៃបច្ចេកវិទ្យាចាស់ដែលមានឈ្មោះដូចគ្នា ដែលឥឡូវនេះហៅថា BPF បុរាណ ដើម្បីជៀសវាងការភាន់ច្រឡំ។ ឧបករណ៍ប្រើប្រាស់ល្បីមួយត្រូវបានបង្កើតឡើងដោយផ្អែកលើ BPF បុរាណ tcpdump, យន្តការ seccompក៏ដូចជាម៉ូឌុលដែលមិនសូវស្គាល់ xt_bpf សម្រាប់ iptables និងអ្នកចាត់ថ្នាក់ cls_bpf. នៅក្នុងលីនុចទំនើប កម្មវិធី BPF បុរាណត្រូវបានបកប្រែដោយស្វ័យប្រវត្តិទៅជាទម្រង់ថ្មី ទោះបីជាយ៉ាងណាក៏ដោយ តាមទស្សនៈរបស់អ្នកប្រើ API នៅតែមាននៅនឹងកន្លែង ហើយការប្រើប្រាស់ថ្មីសម្រាប់ BPF បុរាណ ដូចដែលយើងនឹងឃើញនៅក្នុងអត្ថបទនេះនៅតែត្រូវបានរកឃើញ។ សម្រាប់ហេតុផលនេះ ហើយក៏ដោយសារតែបន្ទាប់ពីប្រវត្តិនៃការអភិវឌ្ឍន៍ BPF បុរាណនៅក្នុងលីនុច វានឹងកាន់តែច្បាស់អំពីរបៀប និងមូលហេតុដែលវាវិវត្តទៅជាទម្រង់ទំនើបរបស់វា ខ្ញុំបានសម្រេចចិត្តចាប់ផ្តើមជាមួយនឹងអត្ថបទអំពី BPF បុរាណ។

នៅចុងបញ្ចប់នៃទសវត្សរ៍ទី XNUMX នៃសតវត្សចុងក្រោយនេះ វិស្វករមកពីមន្ទីរពិសោធន៍ Lawrence Berkeley ដ៏ល្បីល្បាញបានចាប់អារម្មណ៍លើសំណួរអំពីរបៀបត្រងកញ្ចប់បណ្តាញឱ្យបានត្រឹមត្រូវនៅលើផ្នែករឹងដែលទំនើបនៅចុងទសវត្សរ៍ទី XNUMX នៃសតវត្សទីចុងក្រោយ។ គំនិតជាមូលដ្ឋាននៃការត្រងដែលត្រូវបានអនុវត្តដំបូងនៅក្នុងបច្ចេកវិទ្យា CSPF (CMU/Stanford Packet Filter) គឺដើម្បីត្រងកញ្ចប់ព័ត៌មានដែលមិនចាំបាច់ឱ្យបានឆាប់តាមដែលអាចធ្វើទៅបាន ពោលគឺឧ។ នៅក្នុងចន្លោះខឺណែល ព្រោះវាជៀសវាងការចម្លងទិន្នន័យដែលមិនចាំបាច់ទៅក្នុងទំហំអ្នកប្រើប្រាស់។ ដើម្បីផ្តល់សុវត្ថិភាពពេលដំណើរការសម្រាប់ការដំណើរការកូដអ្នកប្រើប្រាស់ក្នុងចន្លោះខឺណែល ម៉ាស៊ីននិម្មិត Sandbox ត្រូវបានប្រើប្រាស់។

ទោះយ៉ាងណាក៏ដោយ ម៉ាស៊ីននិម្មិតសម្រាប់តម្រងដែលមានស្រាប់ត្រូវបានរចនាឡើងដើម្បីដំណើរការលើម៉ាស៊ីនដែលមានមូលដ្ឋានលើជង់ ហើយមិនដំណើរការប្រកបដោយប្រសិទ្ធភាពដូចម៉ាស៊ីន RISC ថ្មីជាងនេះទេ។ ជាលទ្ធផល តាមរយៈការខិតខំប្រឹងប្រែងរបស់វិស្វករមកពី Berkeley Labs បច្ចេកវិទ្យា BPF (Berkeley Packet Filters) ថ្មីត្រូវបានបង្កើតឡើង ស្ថាបត្យកម្មម៉ាស៊ីននិម្មិតដែលត្រូវបានរចនាឡើងដោយផ្អែកលើប្រព័ន្ធដំណើរការ Motorola 6502 ដែលជាកម្លាំងពលកម្មនៃផលិតផលល្បីដូចជា Apple II ឬ អិន។ អេ. ម៉ាស៊ីននិម្មិតថ្មីបានបង្កើនដំណើរការតម្រងរាប់សិបដងបើប្រៀបធៀបទៅនឹងដំណោះស្រាយដែលមានស្រាប់។

ស្ថាបត្យកម្មម៉ាស៊ីន BPF

យើងនឹងស្គាល់ស្ថាបត្យកម្មតាមរបៀបធ្វើការដោយវិភាគឧទាហរណ៍។ ទោះយ៉ាងណាក៏ដោយ ដើម្បីចាប់ផ្តើម ឧបមាថាម៉ាស៊ីនមានការចុះឈ្មោះ 32-bit ចំនួនពីរដែលអាចចូលប្រើបានសម្រាប់អ្នកប្រើប្រាស់ ដែលជាឧបករណ៍ប្រមូលផ្តុំ A និងការចុះឈ្មោះសន្ទស្សន៍ X, 64 បៃនៃអង្គចងចាំ (16 ពាក្យ) មានសម្រាប់ការសរសេរ និងការអានជាបន្តបន្ទាប់ និងប្រព័ន្ធតូចមួយនៃពាក្យបញ្ជាសម្រាប់ធ្វើការជាមួយវត្ថុទាំងនេះ។ ការណែនាំលោតសម្រាប់ការអនុវត្តកន្សោមតាមលក្ខខណ្ឌក៏មាននៅក្នុងកម្មវិធីដែរ ប៉ុន្តែដើម្បីធានាការបញ្ចប់កម្មវិធីទាន់ពេលវេលា ការលោតអាចត្រូវបានធ្វើឡើងទៅមុខតែប៉ុណ្ណោះ ពោលគឺ ជាពិសេសវាត្រូវបានហាមឃាត់មិនឱ្យបង្កើតរង្វិលជុំ។

គ្រោងការណ៍ទូទៅសម្រាប់ការចាប់ផ្តើមម៉ាស៊ីនមានដូចខាងក្រោម។ អ្នកប្រើប្រាស់បង្កើតកម្មវិធីសម្រាប់ស្ថាបត្យកម្ម BPF និងដោយប្រើ ខ្លះ យន្តការខឺណែល (ដូចជាការហៅប្រព័ន្ធ) ផ្ទុក និងភ្ជាប់កម្មវិធីទៅ ទៅខ្លះ ទៅម៉ាស៊ីនបង្កើតព្រឹត្តិការណ៍នៅក្នុងខឺណែល (ឧទាហរណ៍ ព្រឹត្តិការណ៍មួយគឺជាការមកដល់នៃកញ្ចប់ព័ត៌មានបន្ទាប់នៅលើកាតបណ្តាញ)។ នៅពេលដែលព្រឹត្តិការណ៍មួយកើតឡើង ខឺណែលដំណើរការកម្មវិធី (ឧទាហរណ៍ ក្នុងកម្មវិធីបកប្រែ) ហើយអង្គចងចាំម៉ាស៊ីនត្រូវនឹង ទៅខ្លះ តំបន់អង្គចងចាំខឺណែល (ឧទាហរណ៍ ទិន្នន័យនៃកញ្ចប់ព័ត៌មានចូល)។

ខាងលើនឹងគ្រប់គ្រាន់សម្រាប់យើងដើម្បីចាប់ផ្តើមមើលឧទាហរណ៍៖ យើងនឹងស្គាល់ប្រព័ន្ធ និងទម្រង់ពាក្យបញ្ជាតាមការចាំបាច់។ ប្រសិនបើអ្នកចង់សិក្សាភ្លាមៗនូវប្រព័ន្ធបញ្ជារបស់ម៉ាស៊ីននិម្មិត និងស្វែងយល់អំពីសមត្ថភាពរបស់វាទាំងអស់នោះ អ្នកអាចអានអត្ថបទដើម តម្រងកញ្ចប់ BSD និង/ឬពាក់កណ្តាលដំបូងនៃឯកសារ ឯកសារ/បណ្តាញ/filter.txt ពីឯកសារខឺណែល។ លើសពីនេះទៀតអ្នកអាចសិក្សាបទបង្ហាញ libpcap៖ វិធីសាស្ត្រស្ថាបត្យកម្ម និងបង្កើនប្រសិទ្ធភាពសម្រាប់ការចាប់យកកញ្ចប់ដែលក្នុងនោះ McCanne ដែលជាអ្នកនិពន្ធម្នាក់នៃ BPF និយាយអំពីប្រវត្តិនៃការបង្កើត libpcap.

ឥឡូវនេះយើងបន្តទៅពិចារណាឧទាហរណ៍សំខាន់ៗទាំងអស់នៃការប្រើប្រាស់ BPF បុរាណនៅលើលីនុច៖ tcpdump (libpcap), seccomp, xt_bpf, cls_bpf.

tcpdump

ការអភិវឌ្ឍន៍ BPF ត្រូវបានអនុវត្តស្របជាមួយនឹងការអភិវឌ្ឍន៍ផ្នែកខាងមុខសម្រាប់ការត្រងកញ្ចប់ព័ត៌មាន - ឧបករណ៍ប្រើប្រាស់ល្បី tcpdump. ហើយដោយសារនេះគឺជាឧទាហរណ៍ចាស់បំផុត និងល្បីល្បាញបំផុតនៃការប្រើប្រាស់ BPF បុរាណដែលមាននៅលើប្រព័ន្ធប្រតិបត្តិការជាច្រើន យើងនឹងចាប់ផ្តើមការសិក្សារបស់យើងអំពីបច្ចេកវិទ្យាជាមួយវា។

(ខ្ញុំបានរត់ឧទាហរណ៍ទាំងអស់នៅក្នុងអត្ថបទនេះនៅលើលីនុច 5.6.0-rc6. លទ្ធផលនៃពាក្យបញ្ជាមួយចំនួនត្រូវបានកែសម្រួលសម្រាប់ការអានកាន់តែប្រសើរ។ )

ឧទាហរណ៍៖ ការសង្កេតកញ្ចប់ព័ត៌មាន IPv6

សូមស្រមៃថាយើងចង់មើលកញ្ចប់ IPv6 ទាំងអស់នៅលើចំណុចប្រទាក់មួយ។ eth0. ដើម្បីធ្វើដូចនេះយើងអាចដំណើរការកម្មវិធី tcpdump ជាមួយនឹងតម្រងសាមញ្ញ ip6:

$ sudo tcpdump -i eth0 ip6

ដូច្នេះ tcpdump ចងក្រងតម្រង ip6 ចូលទៅក្នុង BPF architecture bytecode ហើយផ្ញើវាទៅខឺណែល (សូមមើលព័ត៌មានលម្អិតនៅក្នុងផ្នែក 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)th byte នៃកញ្ចប់បណ្តាញដែលបានវិភាគ។ យើងអានកញ្ចប់ព័ត៌មានពីចំណុចប្រទាក់អ៊ីសឺរណិត eth0, ហើយ​នេះ មធ្យោបាយថាកញ្ចប់ព័ត៌មានមើលទៅដូចនេះ (សម្រាប់ភាពសាមញ្ញ យើងសន្មត់ថាមិនមានស្លាក VLAN នៅក្នុងកញ្ចប់ព័ត៌មានទេ)៖

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

ដូច្នេះបន្ទាប់ពីប្រតិបត្តិពាក្យបញ្ជា ldh [12] នៅក្នុងការចុះឈ្មោះ A វានឹងមានវាលមួយ។ Ether Type - ប្រភេទនៃកញ្ចប់ព័ត៌មានដែលបានបញ្ជូននៅក្នុងស៊ុមអ៊ីសឺរណិតនេះ។ នៅលើបន្ទាត់ទី 1 យើងប្រៀបធៀបមាតិកានៃការចុះឈ្មោះ A (ប្រភេទកញ្ចប់) គ 0x86dd, ហើយ​នេះ និងមាន។ ប្រភេទដែលយើងចាប់អារម្មណ៍គឺ IPv6 ។ នៅលើបន្ទាត់ទី 1 បន្ថែមពីលើពាក្យបញ្ជាប្រៀបធៀបមានជួរឈរពីរបន្ថែមទៀត - jt 2 и jf 3 - សញ្ញាដែលអ្នកត្រូវទៅ ប្រសិនបើការប្រៀបធៀបជោគជ័យ (A == 0x86dd) និងមិនជោគជ័យ។ ដូច្នេះក្នុងករណីជោគជ័យ (IPv6) យើងទៅជួរទី 2 ហើយក្នុងករណីដែលមិនជោគជ័យ - ទៅជួរទី 3 ។ នៅលើបន្ទាត់ទី 3 កម្មវិធីបញ្ចប់ដោយលេខកូដ 0 (កុំចម្លងកញ្ចប់ព័ត៌មាន) នៅបន្ទាត់ទី 2 កម្មវិធីបញ្ចប់ដោយលេខកូដ 262144 (ចម្លងខ្ញុំកញ្ចប់អតិបរមា 256 គីឡូបៃ) ។

ឧទាហរណ៍ស្មុគស្មាញជាងនេះ៖ យើងមើលកញ្ចប់ TCP តាមច្រកគោលដៅ

សូមមើលអ្វីដែលតម្រងមើលទៅដូចដែលចម្លងកញ្ចប់ TCP ទាំងអស់ដែលមានច្រកទិសដៅ 666។ យើងនឹងពិចារណាករណី IPv4 ព្រោះករណី IPv6 គឺសាមញ្ញជាង។ បន្ទាប់ពីសិក្សាឧទាហរណ៍នេះ អ្នកអាចស្វែងយល់ពីតម្រង IPv6 ដោយខ្លួនឯងជាលំហាត់មួយ (ip6 and tcp dst port 666) និងតម្រងសម្រាប់ករណីទូទៅ (tcp dst port 666) ដូច្នេះតម្រងដែលយើងចាប់អារម្មណ៍មើលទៅដូចនេះ៖

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

យើងដឹងរួចហើយថា បន្ទាត់ 0 និង 1 ធ្វើអ្វី។ នៅលើបន្ទាត់ទី 2 យើងបានពិនិត្យរួចហើយថានេះគឺជាកញ្ចប់ IPv4 (ប្រភេទ Ether = 0x800) ហើយផ្ទុកវាទៅក្នុងបញ្ជី A 24 បៃនៃកញ្ចប់ព័ត៌មាន។ កញ្ចប់របស់យើងមើលទៅដូចជា

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

ដែលមានន័យថាយើងផ្ទុកទៅក្នុងបញ្ជី A វាល Protocol នៃបឋមកថា 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, i.e. យើងក៏មិនអាចនិយាយបានដែរ។ 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 bytecode ទៅក្នុងខឺណែលសម្រាប់ការត្រងកញ្ចប់ព័ត៌មាននោះទេ។ និយាយជាទូទៅ, tcpdump បញ្ជូនទៅកាន់ប្រព័ន្ធជាច្រើន និងសម្រាប់ធ្វើការជាមួយតម្រង tcpdump ប្រើបណ្ណាល័យ libpcap. ដោយសង្ខេប ដើម្បីដាក់តម្រងលើចំណុចប្រទាក់ដោយប្រើ libpcapអ្នកត្រូវធ្វើដូចខាងក្រោមៈ

• បង្កើតអ្នកពិពណ៌នាប្រភេទ pcap_t ពីឈ្មោះចំណុចប្រទាក់៖ pcap_create,
• ធ្វើឱ្យចំណុចប្រទាក់សកម្ម៖ pcap_activate,
• ចងក្រងតម្រង៖ pcap_compile,
• ភ្ជាប់តម្រង៖ pcap_setfilter.

ដើម្បីមើលមុខងារ pcap_setfilter អនុវត្តនៅក្នុងលីនុច យើងប្រើ 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
...

នៅលើបន្ទាត់ទិន្នផលពីរដំបូងយើងបង្កើត រន្ធឆៅ ដើម្បីអានស៊ុមអ៊ីសឺរណិតទាំងអស់ ហើយភ្ជាប់វាទៅចំណុចប្រទាក់ eth0... ពី ឧទាហរណ៍ដំបូងរបស់យើង។ យើងដឹងថាតម្រង ip នឹងមានការណែនាំ BPF ចំនួនបួន ហើយនៅលើបន្ទាត់ទីបី យើងឃើញពីរបៀបប្រើជម្រើស SO_ATTACH_FILTER ការហៅប្រព័ន្ធ setsockopt យើងផ្ទុកនិងភ្ជាប់តម្រងប្រវែង 4. នេះគឺជាតម្រងរបស់យើង។

វាគួរឱ្យកត់សម្គាល់ថានៅក្នុង BPF បុរាណការផ្ទុកនិងភ្ជាប់តម្រងតែងតែកើតឡើងជាប្រតិបត្តិការអាតូមិកហើយនៅក្នុងកំណែថ្មីនៃ BPF ការផ្ទុកកម្មវិធីនិងចងវាទៅម៉ាស៊ីនបង្កើតព្រឹត្តិការណ៍ត្រូវបានបំបែកតាមពេលវេលា។

ការពិតដែលលាក់

កំណែពេញលេញជាងបន្តិចនៃលទ្ធផលមើលទៅដូចនេះ៖

$ sudo strace -f -e trace=%network tcpdump -p -i eth0 ip
socket(AF_PACKET, SOCK_RAW, 768)        = 3
bind(3, {sa_family=AF_PACKET, sll_protocol=htons(ETH_P_ALL), sll_ifindex=if_nametoindex("eth0"), sll_hatype=ARPHRD_NETROM, sll_pkttype=PACKET_HOST, sll_halen=0}, 20) = 0
setsockopt(3, SOL_SOCKET, SO_ATTACH_FILTER, {len=1, filter=0xbeefbeefbeef}, 16) = 0
recvfrom(3, 0x7ffcad394257, 1, MSG_TRUNC, NULL, NULL) = -1 EAGAIN (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 និងសតវត្សទី XNUMX

BPF ត្រូវបានរួមបញ្ចូលនៅក្នុងលីនុចក្នុងឆ្នាំ 1997 ហើយនៅតែជាអ្នកធ្វើការអស់រយៈពេលជាយូរមកហើយ libpcap ដោយគ្មានការផ្លាស់ប្តូរពិសេសណាមួយ (ជាការពិតណាស់ការផ្លាស់ប្តូរជាក់លាក់លីនុច, វាគឺជាការប៉ុន្តែពួកគេមិនបានផ្លាស់ប្តូររូបភាពសកលទេ)។ សញ្ញាធ្ងន់ធ្ងរដំបូងដែល BPF នឹងវិវឌ្ឍកើតឡើងនៅឆ្នាំ 2011 នៅពេលដែល Eric Dumazet បានស្នើឡើង។ បំណះដែលបន្ថែម Just In Time Compiler ទៅខឺណែល - អ្នកបកប្រែសម្រាប់បំប្លែង BPF bytecode ទៅដើម 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))

ការសរសេរកម្មវិធីក្នុងទម្រង់ជាកូដម៉ាស៊ីនមិនងាយស្រួលទេ ប៉ុន្តែពេលខ្លះវាចាំបាច់ (ឧទាហរណ៍ សម្រាប់ការកែកំហុស ការបង្កើតការធ្វើតេស្តឯកតា ការសរសេរអត្ថបទនៅលើHabre ។ល។)។ ដើម្បីភាពងាយស្រួលនៅក្នុងឯកសារ <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),
}

ទោះយ៉ាងណាក៏ដោយជម្រើសនេះមិនងាយស្រួលទេ។ នេះជាអ្វីដែលអ្នកសរសេរកម្មវិធីខឺណែលលីនុចបានវែកញែក ហេតុដូច្នេះហើយនៅក្នុងថត 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ដូចដែលយើងបានធ្វើនៅដើមផ្នែកនេះ។

ផ្នែកបន្ថែមលីនុច និង netsniff-ng

បន្ថែមពីលើស្តង់ដារ BPF, Linux និង tools/bpf/bpf_asm គាំទ្រ និង សំណុំមិនស្តង់ដារ. ជាទូទៅ ការណែនាំត្រូវបានប្រើដើម្បីចូលទៅកាន់វាលនៃរចនាសម្ព័ន្ធមួយ។ struct sk_buffដែលពិពណ៌នាអំពីកញ្ចប់ព័ត៌មានបណ្តាញនៅក្នុងខឺណែល។ ទោះយ៉ាងណាក៏ដោយ ក៏មានប្រភេទផ្សេងទៀតនៃការណែនាំជំនួយផងដែរ ឧទាហរណ៍ ldw cpu នឹងផ្ទុកទៅក្នុងបញ្ជី A លទ្ធផលនៃការដំណើរការមុខងារខឺណែល raw_smp_processor_id(). (នៅក្នុងកំណែថ្មីនៃ BPF ផ្នែកបន្ថែមដែលមិនមែនជាស្តង់ដារទាំងនេះត្រូវបានពង្រីកដើម្បីផ្តល់កម្មវិធីជាមួយនឹងសំណុំនៃកម្មវិធីជំនួយខឺណែលសម្រាប់ការចូលប្រើអង្គចងចាំ រចនាសម្ព័ន្ធ និងការបង្កើតព្រឹត្តិការណ៍។) នេះគឺជាឧទាហរណ៍គួរឱ្យចាប់អារម្មណ៍នៃតម្រងដែលយើងចម្លងតែផ្នែក បឋមកថា packet ចូលទៅក្នុងទំហំអ្នកប្រើប្រាស់ ដោយប្រើផ្នែកបន្ថែម poff, payload offset:

ld poff
ret a

ផ្នែកបន្ថែម BPF មិនអាចប្រើបានទេ។ tcpdumpប៉ុន្តែនេះគឺជាហេតុផលដ៏ល្អដើម្បីស្គាល់កញ្ចប់ឧបករណ៍ប្រើប្រាស់ netsniff-ngដែលក្នុងចំណោមរបស់ផ្សេងទៀត មានកម្មវិធីកម្រិតខ្ពស់ netsniff-ngដែលបន្ថែមពីលើការត្រងដោយប្រើ BPF ក៏មានម៉ាស៊ីនភ្លើងចរាចរដ៏មានប្រសិទ្ធភាព និងកម្រិតខ្ពស់ជាង tools/bpf/bpf_asmអ្នកដំឡើង BPF បានហៅ bpfc. កញ្ចប់មានឯកសារលម្អិត សូមមើលផងដែរនូវតំណភ្ជាប់នៅចុងបញ្ចប់នៃអត្ថបទ។

ស៊ីមខម

ដូច្នេះ យើងដឹងពីរបៀបសរសេរកម្មវិធី BPF នៃភាពស្មុគស្មាញតាមអំពើចិត្ត ហើយត្រៀមខ្លួនរួចជាស្រេចដើម្បីមើលឧទាហរណ៍ថ្មី ដែលទីមួយគឺបច្ចេកវិទ្យា seccomp ដែលអនុញ្ញាតឱ្យប្រើប្រាស់ BPF filters ដើម្បីគ្រប់គ្រងសំណុំ និងសំណុំនៃអាគុយម៉ង់ការហៅប្រព័ន្ធដែលមានសម្រាប់ ដំណើរការដែលបានផ្តល់ឱ្យ និងកូនចៅរបស់វា។

កំណែដំបូងនៃ seccomp ត្រូវបានបន្ថែមទៅខឺណែលក្នុងឆ្នាំ 2005 ហើយមិនមានប្រជាប្រិយភាពខ្លាំងទេព្រោះវាផ្តល់ជម្រើសតែមួយ - ដើម្បីកំណត់សំណុំនៃការហៅប្រព័ន្ធដែលមានសម្រាប់ដំណើរការដូចខាងក្រោម: read, write, exit и sigreturnហើយដំណើរការដែលបំពានច្បាប់ត្រូវបានសម្លាប់ដោយប្រើ SIGKILL. ទោះយ៉ាងណាក៏ដោយក្នុងឆ្នាំ 2012 seccomp បានបន្ថែមសមត្ថភាពក្នុងការប្រើតម្រង BPF ដែលអនុញ្ញាតឱ្យអ្នកកំណត់សំណុំនៃការហៅប្រព័ន្ធដែលបានអនុញ្ញាតហើយថែមទាំងធ្វើការត្រួតពិនិត្យលើអាគុយម៉ង់របស់ពួកគេ។ (គួរឱ្យចាប់អារម្មណ៍ Chrome គឺជាអ្នកប្រើប្រាស់ដំបូងគេនៃមុខងារនេះ ហើយមនុស្ស Chrome បច្ចុប្បន្នកំពុងបង្កើតយន្តការ KRSI ដោយផ្អែកលើកំណែថ្មីនៃ BPF និងអនុញ្ញាតឱ្យប្ដូរតាមបំណងនៃម៉ូឌុលសុវត្ថិភាពលីនុច។) តំណភ្ជាប់ទៅឯកសារបន្ថែមអាចរកបាននៅចុងបញ្ចប់។ នៃអត្ថបទ។

ចំណាំថាមានអត្ថបទរួចហើយនៅលើមជ្ឈមណ្ឌលអំពីការប្រើ seccomp ប្រហែលជាមាននរណាម្នាក់ចង់អានវាមុន (ឬជំនួសឱ្យ) អានផ្នែករងខាងក្រោម។ នៅក្នុងអត្ថបទ កុងតឺន័រ និងសុវត្ថិភាព៖ seccomp ផ្តល់នូវឧទាហរណ៍នៃការប្រើប្រាស់ seccomp ទាំងកំណែ 2007 និងកំណែដែលប្រើ BPF (តម្រងត្រូវបានបង្កើតដោយប្រើ libseccomp) និយាយអំពីការភ្ជាប់ seccomp ជាមួយ Docker ហើយក៏ផ្តល់នូវតំណភ្ជាប់មានប្រយោជន៍ជាច្រើនផងដែរ។ នៅក្នុងអត្ថបទ ការញែកដេមិនដោយប្រព័ន្ធ ឬ "អ្នកមិនត្រូវការ Docker សម្រាប់រឿងនេះទេ!" វាគ្របដណ្តប់ជាពិសេស របៀបបន្ថែមបញ្ជីខ្មៅ ឬបញ្ជីសនៃការហៅប្រព័ន្ធសម្រាប់ដេមិនដែលកំពុងដំណើរការ systemd ។

បន្ទាប់យើងនឹងឃើញពីរបៀបសរសេរ និងផ្ទុកតម្រងសម្រាប់ seccomp នៅទទេ C និងប្រើបណ្ណាល័យ libseccomp ហើយតើអ្វីជាគុណសម្បត្តិ និងគុណវិបត្តិនៃជម្រើសនីមួយៗ ហើយចុងក្រោយ សូមមើលពីរបៀបដែលកម្មវិធី seccomp ត្រូវបានប្រើប្រាស់ដោយកម្មវិធី strace.

ការសរសេរ និងផ្ទុកតម្រងសម្រាប់ seccomp

យើងដឹងពីរបៀបសរសេរកម្មវិធី BPF រួចហើយ ដូច្នេះសូមក្រឡេកមើលចំណុចប្រទាក់សរសេរកម្មវិធី seccomp ជាមុនសិន។ អ្នកអាចកំណត់តម្រងនៅកម្រិតដំណើរការ ហើយដំណើរការកុមារទាំងអស់នឹងទទួលការរឹតបន្តឹង។ នេះត្រូវបានធ្វើដោយប្រើការហៅតាមប្រព័ន្ធ seccomp(2):

seccomp(SECCOMP_SET_MODE_FILTER, flags, &filter)

ដែលជាកន្លែងដែល &filter - នេះគឺជាចង្អុលទៅរចនាសម្ព័ន្ធដែលធ្លាប់ស្គាល់យើងរួចហើយ struct sock_fprog, i.e. កម្មវិធី BPF ។

តើកម្មវិធីសម្រាប់ seccomp ខុសពីកម្មវិធីសម្រាប់ socket យ៉ាងដូចម្តេច? បរិបទឆ្លង។ នៅក្នុងករណីនៃរន្ធ យើងត្រូវបានគេផ្តល់កន្លែងចងចាំដែលមានកញ្ចប់ព័ត៌មាន ហើយក្នុងករណី 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 ។ តើការហៅតាមប្រព័ន្ធទាំងនេះជាអ្វី? យើង​មិន​អាច​និយាយ​ឲ្យ​ប្រាកដ​បាន​ទេ ព្រោះ​យើង​មិន​ដឹង​ថា​កម្មវិធី​មួយ​ណា​ត្រូវ​បាន​សរសេរ។ ដូច្នេះអ្នកនិពន្ធនៃ seccomp ផ្តល់ជូន ចាប់ផ្តើមកម្មវិធីទាំងអស់ដោយការត្រួតពិនិត្យស្ថាបត្យកម្ម (ស្ថាបត្យកម្មបច្ចុប្បន្នត្រូវបានចង្អុលបង្ហាញនៅក្នុងបរិបទជាវាលមួយ។ arch រចនាសម្ព័ន្ធ struct seccomp_data) ជាមួយនឹងការគូសធីកស្ថាបត្យកម្ម ការចាប់ផ្តើមនៃឧទាហរណ៍នឹងមើលទៅដូច៖

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

ហើយបន្ទាប់មកលេខហៅតាមប្រព័ន្ធរបស់យើងនឹងទទួលបានតម្លៃជាក់លាក់។

យើងសរសេរ និងផ្ទុកតម្រងសម្រាប់ seccomp ដោយប្រើ libseccomp

ការសរសេរតម្រងនៅក្នុងកូដដើម ឬនៅក្នុងការជួបប្រជុំ BPF អនុញ្ញាតឱ្យអ្នកមានការគ្រប់គ្រងពេញលេញលើលទ្ធផល ប៉ុន្តែនៅពេលជាមួយគ្នានេះ ពេលខ្លះវាជាការប្រសើរក្នុងការមានកូដចល័ត និង/ឬអាចអានបាន។ បណ្ណាល័យនឹងជួយយើងក្នុងរឿងនេះ libseccompដែលផ្តល់នូវចំណុចប្រទាក់ស្តង់ដារសម្រាប់ការសរសេរតម្រងពណ៌ខ្មៅ ឬស។

ជាឧទាហរណ៍ ចូរយើងសរសេរកម្មវិធីដែលដំណើរការឯកសារគោលពីរនៃការជ្រើសរើសរបស់អ្នកប្រើ ដោយបានដំឡើងបញ្ជីខ្មៅនៃការហៅប្រព័ន្ធពីមុនពី អត្ថបទខាងលើ (កម្មវិធីត្រូវបានធ្វើឱ្យសាមញ្ញសម្រាប់អានកាន់តែច្រើន កំណែពេញលេញអាចរកបាន នៅទីនេះ):

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

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

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

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

        seccomp_load(ctx);

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

ដំបូងយើងកំណត់អារេ sys_numbers នៃ 40+ លេខការហៅតាមប្រព័ន្ធដែលត្រូវទប់ស្កាត់។ បន្ទាប់មកចាប់ផ្តើមបរិបទ ctx ហើយប្រាប់បណ្ណាល័យនូវអ្វីដែលយើងចង់អនុញ្ញាត (SCMP_ACT_ALLOW) ការហៅតាមប្រព័ន្ធទាំងអស់តាមលំនាំដើម (វាកាន់តែងាយស្រួលក្នុងការបង្កើតបញ្ជីខ្មៅ)។ បន្ទាប់មក ម្តងមួយៗ យើងបន្ថែមការហៅប្រព័ន្ធទាំងអស់ចេញពីបញ្ជីខ្មៅ។ ជាការឆ្លើយតបទៅនឹងការហៅតាមប្រព័ន្ធពីបញ្ជី យើងស្នើសុំ SCMP_ACT_TRAPក្នុងករណីនេះ seccomp នឹងបញ្ជូនសញ្ញាទៅដំណើរការ SIGSYS ជាមួយនឹងការពិពណ៌នាអំពីការហៅប្រព័ន្ធណាដែលបំពានច្បាប់។ ទីបំផុតយើងផ្ទុកកម្មវិធីទៅក្នុងខឺណែលដោយប្រើ seccomp_loadដែលនឹងចងក្រងកម្មវិធី និងភ្ជាប់វាទៅដំណើរការដោយប្រើការហៅតាមប្រព័ន្ធ seccomp(2).

សម្រាប់ការចងក្រងដោយជោគជ័យ កម្មវិធីត្រូវតែភ្ជាប់ជាមួយបណ្ណាល័យ libseccompឧទាហរណ៍:

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

ឧទាហរណ៍នៃការចាប់ផ្តើមជោគជ័យ៖

$ ./seccomp_lib echo ok
ok

ឧទាហរណ៍នៃការហៅតាមប្រព័ន្ធដែលត្រូវបានរារាំង៖

$ sudo ./seccomp_lib mount -t bpf bpf /tmp
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 assembler ដោយចុចលេខការហៅតាមប្រព័ន្ធ ឧទាហរណ៍៖

$ 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 គឺជាឧបករណ៍ដែលមិនអាចខ្វះបានសម្រាប់សិក្សាពីឥរិយាបថនៃដំណើរការនៅលើលីនុច។ ទោះ​ជា​យ៉ាង​ណា​ក៏​មាន​មនុស្ស​ជា​ច្រើន​បាន​ឮ​អំពី បញ្ហាការអនុវត្ត នៅពេលប្រើឧបករណ៍ប្រើប្រាស់នេះ។ ការពិតគឺថា 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

ឥឡូវនេះ ចូរយើងត្រលប់ទៅពិភពនៃបណ្តាញវិញ។

ប្រវត្តិ៖ កាលពីយូរយារណាស់មកហើយ ក្នុងឆ្នាំ ២០០៧ ស្នូលគឺ បានបន្ថែម ម៉ូឌុល xt_u32 សម្រាប់ netfilter ។ វា​ត្រូវ​បាន​សរសេរ​ដោយ​ការ​ប្ៀបប្ដូច​ជា​មួយ​នឹង​ការ​ចាត់​ថ្នាក់​ចរាចរណ៍​បុរាណ​កាន់​តែ​ច្រើន​ cls_u32 និងអនុញ្ញាតឱ្យអ្នកសរសេរក្បួនប្រព័ន្ធគោលពីរតាមអំពើចិត្តសម្រាប់ iptables ដោយប្រើប្រតិបត្តិការសាមញ្ញខាងក្រោម៖ ផ្ទុក 32 ប៊ីតពីកញ្ចប់មួយ ហើយអនុវត្តសំណុំនៃប្រតិបត្តិការនព្វន្ធលើពួកវា។ ឧទាហរណ៍,

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

ផ្ទុក 32 ប៊ីតនៃបឋមកថា IP ដោយចាប់ផ្តើមពី padding 6 ហើយអនុវត្តរបាំងមួយទៅពួកវា 0xFF (យកបៃទាប) ។ វាលនេះ។ protocol បឋមកថា IP ហើយយើងប្រៀបធៀបវាជាមួយ 1 (ICMP) ។ អ្នកអាចបញ្ចូលគ្នានូវការត្រួតពិនិត្យជាច្រើននៅក្នុងច្បាប់មួយ ហើយអ្នកក៏អាចប្រតិបត្តិប្រតិបត្តិករផងដែរ។ @ - ផ្លាស់ទី X bytes ទៅខាងស្តាំ។ ឧទាហរណ៍ច្បាប់

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

ពិនិត្យមើលថាតើលេខលំដាប់ TCP មិនស្មើគ្នា 0x29. ខ្ញុំ​នឹង​មិន​និយាយ​លម្អិត​បន្ថែម​ទៀត​ទេ ព្រោះ​វា​ច្បាស់​ហើយ​ថា​ការ​សរសេរ​ច្បាប់​បែប​នេះ​ដោយ​ដៃ​មិន​សូវ​ស្រួល​ទេ។ នៅក្នុងអត្ថបទ BPF - លេខកូដបៃដែលភ្លេចមានតំណភ្ជាប់ជាច្រើនជាមួយនឹងឧទាហរណ៍នៃការប្រើប្រាស់ និងការបង្កើតច្បាប់សម្រាប់ xt_u32. សូមមើលផងដែរនូវតំណភ្ជាប់នៅចុងបញ្ចប់នៃអត្ថបទនេះ។

ចាប់តាំងពីឆ្នាំ 2013 ម៉ូឌុលជំនួសឱ្យម៉ូឌុល xt_u32 អ្នកអាចប្រើម៉ូឌុលដែលមានមូលដ្ឋានលើ BPF xt_bpf. នរណាម្នាក់ដែលបានអានឆ្ងាយនេះគួរតែច្បាស់រួចហើយអំពីគោលការណ៍នៃប្រតិបត្តិការរបស់វា: ដំណើរការ BPF bytecode ជាច្បាប់ iptables ។ អ្នកអាចបង្កើតច្បាប់ថ្មីឧទាហរណ៍ដូចនេះ៖

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

នៅទីនេះ <байткод> - នេះគឺជាកូដនៅក្នុងទម្រង់លទ្ធផលរបស់ assembler 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 datagram ហើយបន្ទាប់មកពិនិត្យមើលសំណើ៖ 0x04686162 <-> "x04hab" ហើយដូច្នេះនៅលើ។

បន្តិចក្រោយមក Cloudfare បានបោះពុម្ពកូដ p0f -> BPF compiler code។ នៅក្នុងអត្ថបទ ការណែនាំ p0f BPF compiler ពួកគេនិយាយអំពីអ្វីដែល 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 សម្រាប់ប្រព័ន្ធរងគ្រប់គ្រងចរាចរណ៍នៅក្នុងលីនុច បន្ថែមទៅលីនុចនៅចុងឆ្នាំ 2013 និងជំនួសដោយគំនិតបុរាណ។ cls_u32.

ទោះជាយ៉ាងណាក៏ដោយឥឡូវនេះយើងនឹងមិនពិពណ៌នាអំពីការងារនោះទេ។ cls_bpfចាប់តាំងពីទស្សនៈនៃចំណេះដឹងអំពី BPF បុរាណនេះនឹងមិនផ្តល់ឱ្យយើងនូវអ្វីនោះទេ - យើងបានស្គាល់មុខងារទាំងអស់រួចហើយ។ លើសពីនេះទៀតនៅក្នុងអត្ថបទជាបន្តបន្ទាប់ដែលនិយាយអំពី Extended BPF យើងនឹងជួបអ្នកចាត់ថ្នាក់នេះច្រើនជាងម្តង។

ហេតុផលមួយទៀតដែលមិននិយាយអំពីការប្រើប្រាស់ BPF បុរាណ c cls_bpf បញ្ហាគឺថា បើប្រៀបធៀបទៅនឹង Extended BPF វិសាលភាពនៃការអនុវត្តក្នុងករណីនេះត្រូវបានរួមតូចយ៉ាងខ្លាំង៖ កម្មវិធីបុរាណមិនអាចផ្លាស់ប្តូរខ្លឹមសារនៃកញ្ចប់ និងមិនអាចរក្សាទុកស្ថានភាពរវាងការហៅទូរសព្ទបានទេ។

ដូច្នេះវាដល់ពេលដែលត្រូវនិយាយលាទៅ BPF បុរាណ ហើយមើលទៅអនាគត។

លាទៅ BPF បុរាណ

យើងបានមើលពីរបៀបដែលបច្ចេកវិទ្យា BPF ដែលត្រូវបានបង្កើតឡើងនៅដើមទសវត្សរ៍ទី 32 រស់នៅដោយជោគជ័យក្នុងរយៈពេលមួយភាគបួននៃសតវត្ស ហើយរហូតដល់ចុងបញ្ចប់បានរកឃើញកម្មវិធីថ្មី។ ទោះយ៉ាងណាក៏ដោយ ស្រដៀងគ្នាទៅនឹងការផ្លាស់ប្តូរពីម៉ាស៊ីនជង់ទៅ RISC ដែលបានបម្រើជាកម្លាំងរុញច្រានសម្រាប់ការអភិវឌ្ឍ BPF បុរាណនៅក្នុងទសវត្សរ៍ឆ្នាំ 64 មានការផ្លាស់ប្តូរពីម៉ាស៊ីន XNUMX ប៊ីតទៅ XNUMX ប៊ីត ហើយ BPF បុរាណបានចាប់ផ្តើមលែងប្រើ។ លើសពីនេះទៀតសមត្ថភាពរបស់ BPF បុរាណមានកម្រិតខ្លាំងណាស់ ហើយបន្ថែមពីលើស្ថាបត្យកម្មហួសសម័យ - យើងមិនមានសមត្ថភាពក្នុងការរក្សាទុកស្ថានភាពរវាងការហៅទៅកាន់កម្មវិធី BPF មិនមានលទ្ធភាពនៃអន្តរកម្មរបស់អ្នកប្រើដោយផ្ទាល់ទេវាមិនមានលទ្ធភាពធ្វើអន្តរកម្មទេ។ ជាមួយខឺណែល លើកលែងតែការអានចំនួនកំណត់នៃវាលរចនាសម្ព័ន្ធ sk_buff និងការបើកដំណើរការមុខងារជំនួយការដ៏សាមញ្ញបំផុត អ្នកមិនអាចផ្លាស់ប្តូរខ្លឹមសារនៃកញ្ចប់ព័ត៌មាន និងបញ្ជូនបន្តពួកវាបានទេ។

តាមពិតទៅ បច្ចុប្បន្ននេះ អ្វីទាំងអស់ដែលនៅសេសសល់នៃ BPF បុរាណនៅក្នុងលីនុច គឺជាចំណុចប្រទាក់ API ហើយនៅខាងក្នុងខឺណែលកម្មវិធីបុរាណទាំងអស់ មិនថាវាជាតម្រងរន្ធ ឬតម្រង seccomp ត្រូវបានបកប្រែដោយស្វ័យប្រវត្តិទៅជាទម្រង់ថ្មី Extended BPF ។ (យើងនឹងនិយាយអំពីរបៀបដែលវាកើតឡើងនៅក្នុងអត្ថបទបន្ទាប់។ )

ការផ្លាស់ប្តូរទៅកាន់ស្ថាបត្យកម្មថ្មីបានចាប់ផ្តើមនៅក្នុងឆ្នាំ 2013 នៅពេលដែល Alexey Starovoitov បានស្នើគម្រោងធ្វើបច្ចុប្បន្នភាព BPF ។ នៅឆ្នាំ 2014 បំណះដែលត្រូវគ្នា។ បានចាប់ផ្តើមលេចឡើង នៅក្នុងស្នូល។ តាមដែលខ្ញុំយល់ ផែនការដើមគឺគ្រាន់តែបង្កើនប្រសិទ្ធភាពស្ថាបត្យកម្ម និងកម្មវិធីចងក្រង JIT ឱ្យដំណើរការកាន់តែមានប្រសិទ្ធភាពលើម៉ាស៊ីន 64 ប៊ីតប៉ុណ្ណោះ ប៉ុន្តែផ្ទុយទៅវិញការបង្កើនប្រសិទ្ធភាពទាំងនេះបានសម្គាល់ការចាប់ផ្តើមនៃជំពូកថ្មីក្នុងការអភិវឌ្ឍន៍លីនុច។

អត្ថបទបន្ថែមទៀតនៅក្នុងស៊េរីនេះនឹងគ្របដណ្តប់លើស្ថាបត្យកម្ម និងកម្មវិធីនៃបច្ចេកវិទ្យាថ្មី ដែលដំបូងគេស្គាល់ថាជា BPF ខាងក្នុង បន្ទាប់មកពង្រីក BPF ហើយឥឡូវនេះជាធម្មតា BPF ។

សេចក្តីយោង

1. Steven McCanne និង Van Jacobson, "The BSD Packet Filter: A New Architecture for User-level Packet Capture", https://www.tcpdump.org/papers/bpf-usenix93.pdf
2. Steven McCanne, "libpcap: ស្ថាបត្យកម្ម និងវិធីសាស្រ្តបង្កើនប្រសិទ្ធភាពសម្រាប់ការចាប់យកកញ្ចប់", https://sharkfestus.wireshark.org/sharkfest.11/presentations/McCanne-Sharkfest'11_Keynote_Address.pdf
3. tcpdump, libpcap: https://www.tcpdump.org/
4. ការបង្រៀនអំពីការប្រកួត IPtable U32.
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: ញែកដេមិនជាមួយប្រព័ន្ធឬ "អ្នកមិនត្រូវការ Docker សម្រាប់រឿងនេះទេ!"
12. Paul Chaignon, "strace --seccomp-bpf: a look under the hood", https://fosdem.org/2020/schedule/event/debugging_strace_bpf/
13. netsniff-ng: http://netsniff-ng.org/

ប្រភព: www.habr.com