eBPF nima va nega muhim?

eBPF — Linux yadrosi ichida kichik dasturlarni xavfsiz tarzda ishga tushirish imkonini beruvchi kuchli texnologiyadir. Odatda yadroga yangi xususiyat qo'shish juda xavfli va qiyin ish hisoblanadi. eBPF esa tarmoq paketlarini kuzatish, tizim chaqiruvlarini kuzatib borish, unumdorlikni o'lchash yoki xavfsizlik siyosatini qo'llash kabi vazifalarda yadroga kichik dasturlar yuklashga ruxsat beradi.

Bugungi kunda eBPF bulut infratuzilmasida, xavfsizlik monitoring tizimlarida, tarmoq unumdorligi o'lchovlarida va kuzatuvchanlik vositalarida keng qo'llaniladi. Shuning uchun eBPF dasturlarining xavfsizligi nafaqat dasturchilarni, balki server infratuzilmasini, ma'lumot markazlarini va xavfsizlik jamoalarini ham qiziqtiradi.

Biroq eBPF dasturlari odatda past darajadagi C kodi bilan yoziladi. C tili kuchli va tez; ammo xotira xavfsizligi, tur aralashuvi va xato nazorati kabi sohalarda dasturchiga juda ko'p mas'uliyat yuklaydi.

Linux eBPF Verifier hamma narsani nazorat qilmaydimi?

eBPF dasturlari yadroga yuklanishidan oldin Linux eBPF verifier tomonidan tekshiriladi. Verifier dasturning cheksiz tsiklga kirmasligini, ba'zi xotira xavfsizligi qoidalariga rioya qilishini va yadro ichida qabul qilinadigan tarzda ishlashini nazorat qiladi.

Bu juda muhim; chunki yadroda ishlaydigan dasturning nazoratsiz harakat qilishi butun tizimga ta'sir qilishi mumkin.

Ammo maqolaning ta'kidlagan nuqtasi shuki:

Verifier har bir manba kodi darajasidagi xatolarni ushlash uchun mo'ljallanmagan.

Verifier ko'proq kompilyatsiya qilingan bytecode ustida ishlaydi. Dasturchining manba kodda nimani maqsad qilganini, qaysi struct maydonini tashqariga yubormoqchi ekanini, qaysi xato qaytishini tekshirish kerakligini yoki qaysi map sxemasi mantiqan to'g'ri ekanini har doim tushuna olmaydi.

Shuning uchun ba'zi xatolar kompilyatsiya qilinishi, verifierdan o'tishi va ish vaqtida jimjit noto'g'ri natija berishi mumkin.

Maqolada qanday xato sinflari muhokama qilingan?

Tadqiqotchilar eBPF verifier qamrovidan tashqarida qolishi mumkin bo'lgan olti xato sinfi haqida gapirishadi.

Bular soddalashtirilganda quyidagicha tushuntirilishi mumkin:

1. Boshlanmagan ma'lumotlardan foydalanish
Ma'lumot tuzilmasining ba'zi maydonlari to'ldirilmasdan foydalanuvchi maydoniga yuborilishi mumkin. Bu holatda eski xotira qoldiqlari tashqariga sizib chiqishi mumkin.

2. Yordamchi funksiya qaytish qiymatlarini tekshirmaslik
Ba'zi eBPF yordamchi funksiyalari muvaffaqiyatsiz bo'lishi mumkin. Agar qaytish qiymati tekshirilmasa, dastur muvaffaqiyatsiz o'qishdan keyin ham ma'lumot yuborishda davom etishi mumkin.

3. Buffer / o'lcham nomuvofiqligi
Dasturchi faqat kichik maydonni yubormoqchi bo'lsa ham, noto'g'ri ravishda kattaroq struct o'lchamini berishi mumkin. Bu ortiqcha maxfiy maydonlarning tashqariga chiqishiga olib kelishi mumkin.

4. Hook / context nomuvofiqligi
Dastur ma'lum eBPF hook turi uchun yozilganga o'xshasa ham, noto'g'ri context tuzilmasidan foydalanishi mumkin. Bu kuzatilayotgan ma'lumotlarning noto'g'ri talqin qilinishiga olib kelishi mumkin.

5. Map turi yoki sxema aralashuvi
Map ichida kutilgan ma'lumot turi bilan yozilgan yoki o'qilgan ma'lumot turi mos kelmasligi mumkin.

6. Imzoli / imzosiz son aralashuvi
Salbiy xato kodlari imzosiz songa aylantirilsa, juda katta musbat qiymatlar kabi ko'rinishi va noto'g'ri map kalitlari yoki noto'g'ri natijalar hosil qilishi mumkin.

Ushbu xato sinflarining umumiy nuqtasi shuki: dastur texnik jihatdan ishlashi mumkin; lekin xavfsizlik yoki to'g'rilik nuqtai nazaridan noto'g'ri harakat qilishi mumkin.

Nega Rust va Aya?

Rust — xotira xavfsizligi va tur xavfsizligi bo'yicha C tiliga qaraganda kuchliroq himoya beradigan zamonaviy tizim dasturlash tilidir. Rust o'zgaruvchi ishlatilishidan oldin boshlanganmi, turlar mos keladimi, xato natijasi e'tiborsiz qoldirilganmi kabi ko'plab masalalarda dasturchini kompilyatsiya bosqichida majbur qiladi.

Aya esa eBPF dasturlarini Rust bilan yozish uchun mo'ljallangan ekotizimdir. C/libbpf asosidagi yondashuvga alternativa sifatida yanada tur xavfsiz va Rustga mos interfeys taqdim etadi.

Maqoladagi asosiy g'oya quyidagicha:

Eski C eBPF dasturlarini qo'lda qayta yozish juda mehnat talab qilishi mumkin.
Katta til modellari tarjimani tezlashtirishi mumkin.
Ammo tarjima faqat «kompilyatsiya qilinadi» deb ishonchli hisoblanmasligi kerak.
Shuning uchun kuchli tarjimadan keyingi tekshiruv talab qilinadi.

Heimdall nima?

Heimdall — C tilida yozilgan eBPF dasturlarini Rust/Ayaga avtomatik ko'chirish uchun taklif qilingan ko'p bosqichli tizimdir.

Tizimning maqsadi faqat C kodini Rust kodiga aylantirish emas. Asosiy maqsad tarjima qilingan Rust dasturining:

• Kompilyatsiya qilinishi
• Kernel verifierdan o'tishi
• Xavfsiz Aya foydalanishiga mos kelishi
• Asl C dasturi bilan kuzatiladigan xatti-harakat nuqtai nazaridan teng bo'lishi
• Xato topilganda LLMga fikr-mulohaza berib tarjimani tuzatishi

Shuning uchun Heimdall klassik «AI kod tarjima qildi» yondashuvidan ilgariroq model taklif etadi. Bu yerda sun'iy intellekt yolg'iz qaror qabul qilmaydi; kompilyator, verifier, statik tahlil, simvolik ijro va Z3 kabi vositalar bilan nazorat qilinadi.

1-rasm nima haqida gapiradi?

Maqoladagi 1-rasm Heimdallning beshta bosqichli ishlov berish liniyasini ko'rsatadi.

1-bosqich: LLM tarjimasi
C/libbpf eBPF dasturi katta til modeli tomonidan Rust/Aya kodiga tarjima qilinadi.

2-bosqich: Kompilyatsiya va kernel verifier tekshiruvi
Rust kodi eBPF bytecodega kompilyatsiya qilinadi. Keyin Linux kernel verifier bu dasturni qabul qiladimi yoki yo'qmi tekshiriladi.

3-bosqich: Statik xavfsizlik tahlili
Tarjima xavfsiz Aya foydalanishiga zid naqshlar jihatidan tekshiriladi. Masalan, keraksiz unsafe foydalanishi, tekshirilmagan helper natijalari yoki boshlanmagan output buffer foydalanishi oldini olishga harakat qilinadi.

4-bosqich: Simvolik ijro
Ham asl C dan kelgan eBPF bytecode, ham Rust dan kelgan eBPF bytecode simvolik tarzda ishga tushiriladi. Ya'ni ma'lum test kiritmalari bilan emas, balki barcha mumkin bo'lgan yo'llarni ifodalovchi mantiqiy formulalar bilan o'rganiladi.

5-bosqich: Z3 bilan tenglik tekshiruvi
Z3 yechuvchisi ikki dastur bir xil shartlarda bir xil kuzatiladigan xatti-harakatni hosil qiladimi yoki yo'qmi tekshiradi. Agar farq topilsa, bu qarshi misol LLMga qaytariladi va tarjima tuzatiladi.

Ushbu oqimning eng muhim xabari shuki:

Kompilyatsiya qilinadigan kod ishlab chiqish yetarli emas; xavfsiz va xatti-harakatni saqlovchi kod ishlab chiqilishi kerak.

2-rasm nima ko'rsatadi?

Maqoladagi 2-rasm tadqiqotchilar eBPF bytecode uchun angr nomli simvolik ijro vositasiga qanday qo'llab-quvvatlash qo'shganini ko'rsatadi.

eBPF dasturlarini simvolik tarzda ishga tushirish oson emas. Chunki bu dasturlar yadro context tuzilmalari, map operatsiyalari, helper funksiyalari va turli hook turlari bilan ishlaydi.

Tadqiqotchilar shuning uchun angr ichida eBPF uchun beshta qavatli qo'llab-quvvatlash ishlab chiqqanlarini aytishadi:

• eBPF ELF yuklagich
• eBPF arxitektura ta'rifi
• eBPF instruction lifter
• eBPF helper modellari
• Formula ishlab chiqaruvchi

Bu texnik infratuzilma C va Rust versiyalarini bytecode darajasida solishtirish imkonini beradi. Shunday qilib, C va Rust manba tillarining farqlari o'rniga yadroga boradigan haqiqiy eBPF xatti-harakati solishtiriladi.

Formula nimani anglatadi? Dastur tengligi qanday tekshiriladi?

Maqolaning muhim matematik g'oyasi shuki:

eBPF dasturi kiritmalarni oladi, qaytish qiymati hosil qiladi va map holatini o'zgartirishi mumkin.

Soddalashtirilgan shaklda:

Program = kiritma + boshlang'ich map holati → qaytish qiymati + oxirgi map holati

Heimdall C va Rust dasturlarining faqat bir xil qaytish qiymatini beradimi yoki yo'qmi degan savolga qaramaydi. Shuningdek, map yangilanishlari va tashqariga yuborilgan kuzatiladigan natijalar kabi yon ta'sirlarni ham hisobga oladi.

Tenglik nazorati quyidagi savolga qisqartiriladi:

C dasturi bilan Rust dasturi turli natija hosil qila oladigan har qanday kiritma bormi?

Agar Z3 bunday kiritma topa olmasa, ya'ni qarshi misol bo'lmasa, dasturlar teng deb hisoblanadi.

Bu test qilishdan kuchliroq yondashuvdir. Chunki testlarda faqat tanlangan namunalar sinovdan o'tkaziladi. Simvolik tasdiqlashda esa iloji boricha butun xatti-harakat maydoni mantiqan o'rganishga harakat qilinadi.

Nega «shartli tenglik» ishlatiladi?

Bu yerda juda muhim va o'rgatuvchi nuqta bor.

Agar C dasturida xavfsizlik zaifligi bo'lsa va Rust tarjimasi buni tuzatsa, Rust dasturi ba'zi holatlarda C dasturidan boshqacha harakat qiladi. Bu aslida xohlanadigan farqdir.

Masalan, C dasturi helper muvaffaqiyatsiz bo'lsa ham eski ma'lumotni yuborishi mumkin. Rust tarjimasi esa xato holatida xavfsiz tarzda chiqishi mumkin. Qattiq tenglik tekshiruvi bu holatda «Rust boshqacha harakat qildi» deb xavfsiz tarjimani rad etishi mumkin.

Shuning uchun Heimdall «shartli tenglik» g'oyasidan foydalanadi.

Oddiy ma'nosi quyidagicha:

Rust dasturi C dasturining xavfsiz deb qabul qilingan yo'llarida bir xil xatti-harakat ko'rsatishi kerak.
Lekin C dagi xavfsizlik xatosining ishga tushgan yo'llarida Rustning xavfsizroq harakat qilishiga ruxsat beriladi.

Bu farq muhimdir. Chunki maqsad yomon xatti-harakatni bir-bir nusxalash emas, to'g'ri xatti-harakatni saqlab turar ekan xato xatti-harakatni xavfsiz qilishdir.

Baholash qanday o'tkazilgan?

Izlanishda tadqiqotchilar 119 ta eBPF dasturini to'plagan. Ayoning qo'llab-quvvatlamagan ba'zi xususiyatlari tufayli ularning 102 tasi haqiqiy tarjima va tasdiqlash to'plamiga kiritilgan.

Maqola uchta tarjima yondashuvini solishtiradi:

Baseline:
LLM agentiga C kodi beriladi va Rust/Aya tarjimasi qilish so'raladi. Kompilyatsiya qilinadigan natija hosil qilishi kutiladi.

Heimdall Deterministic:
Beshta bosqichli ishlov berish liniyasi tashqi nazoratchi tomonidan ketma-ket ishga tushiriladi. LLM faqat fikr-mulohaza bilan yangi nomzod tarjima ishlab chiqaradi.

Heimdall Agentic:
Agent xuddi shu Heimdall tamoyillariga amal qiladi, lekin fayl o'qish, qidirish, bytecode o'rganish va yordamchi vositalardan foydalanishda erkinroq harakat qiladi.

Bu farq muhim. Chunki zamonaviy dasturiy ta'minot ishlab chiqish agentlari faqat matn yaratmaydi; fayl qidiradi, buyruq bajaradi, xato chiqishini o'qiydi va qayta urinadi. Maqola ushbu vosita foydalanish bilan keladigan farqni ham o'lchaydi.

Natijalar nimalarni ko'rsatmoqda?

Maqoladagi eng e'tiborga loyiq natijalardan biri shuki:

Barcha 102 ta haqiqiy dastur bo'yicha Heimdall Agentic 96 ta dastur uchun rasmiy tasdiqlangan teng Rust tarjimasi ishlab chiqqan. Bu nisbati 94,1 foiz deb xabar qilinadi.

Qolgan olti dastur uchun tadqiqotchilar ularni to'g'ridan-to'g'ri haqiqiy tarjima xatosi sifatida emas, balki simvolik ijro yoki yechuvchi o'lchamlilik chegarasi sifatida tushuntiradi. Uchta dastur qisman tasdiqlangan, uchta dastur esa yechuvchi chegaralarini oshgani uchun tasdiqlanmagan.

Benchmark jadvali shuningdek faqat kompilyatsiyaning yetarli emasligini ko'rsatadi. Baseline usullarining barchasi 51 ta dasturni kompilyatsiya qila oladi; ammo xavfsizlik va tenglik tekshiruvlari qo'shilganda to'liq muvaffaqiyatli tarjima soni juda past qoladi.

Bu dasturiy ta'minot xavfsizligi nuqtai nazaridan kuchli dars beradi:

Kodning kompilyatsiyasi kodning to'g'ri va xavfsiz ekanligini anglatmaydi.

Qaysi xavfsizlik teshiklari yopilgan?

Maqoladagi ma'lumotlar to'plami ustida o'tkazilgan tahlilda Heimdall uchta kuzatilgan xato sinfini yopgani xabar qilinmoqda:

• Boshlanmagan holat: 10 ta namunadan 10 tasi
• Tekshirilmagan helper qaytishlari: 44 ta namunadan 44 tasi
• Imzoli / imzosiz son aralashuvi: 6 ta namunadan 6 tasi

Bu natijalar Heimdall faqat tarjima qiluvchi vosita emas, balki ma'lum manba kodi darajasidagi xavfsizlik xatolarini kamaytiradigan ko'chirish liniyasi sifatida mo'ljallanganligini ko'rsatadi.

Biroq bu natijalar butun eBPF dunyosi uchun umumiy kafolat emas. Faqat maqolada skanerlangan va tasdiqlangan ma'lumotlar to'plami uchun xabar qilingan topilmalardir.

Runtime tajribalari nima haqida gapiradi?

Tadqiqotchilar rasmiy tasdiqlangan ba'zi Rust tarjimalarining ish vaqtida ham o'xshash xatti-harakat qiladimi yoki yo'qmi tekshirish uchun 10 ta dastur bo'yicha tajriba o'tkazadi.

C va Rust versiyalari bir xil nazorat qilingan ish yuklari ostida ishga tushiriladi. 5-jadvalda bu dasturlarning har biri uchun 100 ta urinishda 100 ta muvaffaqiyatli o'tish xabar qilinadi. Runtime overhead qiymatlari dasturdan dasturga farq qiladi. Ba'zilarida Rust versiyasi sekinroq ko'rinadi, ba'zi misollarda tezroq yoki yaqin natijalar xabar qilingan.

Ushbu bo'limning oddiy xabari shuki:

Rasmiy tasdiqlash kuchli vositadir; ammo ish vaqtida nazorat qilish ham amaliy xatti-harakatni ko'rish uchun qadrli.

Tadqiqot nima deymoqda?

Ishning asosiy xabari bir nechta nuqtaga jamlanishi mumkin.

Birinchisi, eBPF verifier juda qimmatli xavfsizlik qatlami bo'lsa ham, yolg'iz manba kodi darajasidagi barcha xatolarni ushlamaydi.

Ikkinchisi, Rust va Aya kabi yanada tur xavfsiz vositalar eBPF dasturlarida ba'zi xato sinflarini kompilyatsiya yoki API darajasida oldini olishi mumkin.

Uchinchisi, katta til modellari eski C kodlarini Rustga ko'chirishda foydali bo'lishi mumkin; ammo bu tarjimalar faqat LLM chiqishiga ishonib qabul qilinmasligi kerak.

To'rtinchisi, simvolik ijro va Z3 asosidagi tenglik nazorati tarjima haqiqatan ham xatti-harakatni saqlaydimi yoki yo'qmi kuchliroq tekshirishi mumkin.

Beshinchisi, xavfsizlikni yaxshilaydigan tarjimalar uchun shartli tenglik kabi ehtiyotkor tasdiqlash ta'riflari kerak. Chunki xavfsiz Rust tarjimasi C dagi xato xatti-harakatni bir-bir nusxalammasligi kerak.

Bu nima uchun muhim?

Bu ish sun'iy intellekt yordamida dasturiy ta'minot transformatsiyasining kelajagi nuqtai nazaridan muhim dars beradi.

Eski tizim kodlarini zamonaviy va xavfsizroq tillarga ko'chirish dasturiy ta'minot dunyosining katta muammolaridan biridir. Moliya, bulut, operatsion tizim, tarmoq infratuzilmasi va xavfsizlik vositalarida yillar davomida to'plangan C kod mavjud. Bu kodlarni qo'lda qayta yozish qimmat va xavfli.

LLMlar bu jarayonni tezlashtirishi mumkin. Biroq tizim darajasidagi xavfsizlik kodlarida «AI tarjima qildi, kompilyatsiya qildi, tayyor» yondashuvi xavfli bo'lishi mumkin. Chunki kichik tur xatosi, noto'g'ri map yangilanishi yoki yetishmayotgan xato nazorati jiddiy oqibatlarga olib kelishi mumkin.

Heimdallning ahamiyati shu yerda namoyon bo'ladi. Ushbu ish AI kod tarjimasi faqat kuchli vositalar bilan nazorat qilinganda ishonchli bo'lishi mumkinligini ko'rsatadigan tadqiqot misolini taqdim etadi.

Ya'ni kelajakda xavfsiz dasturiy ta'minotni modernizatsiya qilish faqat sun'iy intellekt matn ishlab chiqarish bilan emas; kompilyator, statik tahlil, simvolik ijro, yechuvchi va qarshi misolli tuzatish tsikllarining birgalikda ishlatilishi bilan rivojlanishi mumkin.

E'tibor berish kerak bo'lgan nuqtalar

Bu ish kuchli natijalar taqdim etsa ham, ba'zi cheklovlarga ega.

Avvalo, ish preprintdir. Natijalar mustaqil akademik baholash va turli tizimlarda takrorlanishi kerak.

Ikkinchisi, Heimdallning muvaffaqiyati sinovdan o'tkazilgan eBPF dasturlari va Ayaning qo'llab-quvvatlaydigan xususiyatlari bilan cheklangan. Ayaning qo'llab-quvvatlamagan ba'zi map turlari, USDT argumentlari yoki eski socket-filter buyruqlari qamrovdan tashqarida qoldirilgan.

Uchinchisi, 96 ta dasturning tasdiqlanishi juda kuchli natija bo'lsa ham, qolgan dasturlarda yechuvchi va simvolik ijroning o'lchamlilik chegaralari ko'rinmoqda. Bu rasmiy tasdiqlash amalda hali ham qimmatga tushishi mumkinligini ko'rsatadi.

To'rtinchisi, Rust xavfsizroq til bo'lsa ham Rust eBPF dasturlarida to'liq unsafe siz ishlash har doim mumkin emas. Maqola ham ishlab chiqilgan tarjimalarda o'rtacha unsafe operatsiyalar borligini xabar qiladi. Muhimi bu unsafe hududlarni toraytirish va nazorat qilishdir.

Beshinchisi, maqoladagi xavfsizlik topilmalari ma'lum ochiq manba dasturlar va test sharoitlari orqali xabar qilingan. Ushbu topilmalarni umumlashtirishda ehtiyot bo'lish kerak, ayblovchi yoki qat'iy hukm tilidan foydalanmaslik lozim.

Oxir-oqibat, rasmiy tenglik ma'lum modellashgan xatti-harakatlarga asoslanadi. Modelga kirmagan yadro xatti-harakatlari, apparat ta'sirlari yoki qo'llab-quvvatlanmaydigan yordamchi funksiyalar ham alohida baholanishi kerak.

Natija

Bu tadqiqot sun'iy intellekt yordamida kodni o'zgartirishning jiddiy tizim dasturlarida qanday qilib yanada xavfsiz bo'lishi mumkinligini ko'rsatadigan muhim bir misol taqdim etadi.

Heimdall eski C eBPF dasturlarini Rust/Ayaga tarjima qilish uchun katta til modellaridan foydalanadi; ammo tarjimani faqat LLMga qoldirmaydi. Kompilyatsiya, kernel verifier, statik xavfsizlik siyosati, simvolik ijro va Z3 asosidagi tenglik nazoratini bir liniyada birlashtiradi.

Ishning eng muhim xabari shuki:

Xavfsiz dasturiy ta'minotni modernizatsiya qilishda sun'iy intellekt tezlashtirishi mumkin; ammo ishonch tasdiqlash vositalari bilan qozoniladi.

eBPF kabi yadro darajasiga yaqin ishlaydigan tizimlarda bu yondashuv ayniqsa qadrli. Chunki bu yerda kichik manba kodi xatosi ham ma'lumot sizib chiqishi, noto'g'ri xavfsizlik qarori yoki tizim kuzatuvi xatosi kabi oqibatlarga olib kelishi mumkin.

Heimdall bu muammolarga yakuniy yechim emas; ammo AI yordamidagi tarjima bilan rasmiy tasdiqlashni birlashtiradigan kuchli tadqiqot yo'nalishini ifodalaydi.

Manba va usul eslatmasi

Bu kontent Vishnu Asutosh Dasu, Monika Santra, Md Rafi Ur Rashid, Ashish Kumar, Saeid Tizpaz-Niari va Gang Tan tomonidan tayyorlangan "Heimdall: Formally Verified Automated Migration of Legacy eBPF Programs to Rust" nomli akademik ish asosida Verianla tahririy formatida mustaqil tayyorlangan.

Ish arXivda nashr etilgan preprint sifatidadir. Kontent ma'lumot berish va ta'lim maqsadida. Kiberxavfsizlik, Linux yadrosi ishlab chiqish, eBPF dasturlash, korporativ tizim xavfsizligi yoki professional dasturiy ta'minot tasdiqlash maslahati o'rnini bosa olmaydi.