Gesaan dan konteks
Bagaimanakah anda akan menggunakan program kebolehcerapan eBPF merentasi pengedaran Linux dan versi kernel? Terangkan perkara yang dilindungi oleh verifier, cara anda menyahpepijat kegagalan pemuatan, dan cara anda membina matriks keserasian yang boleh diuji.
Ini sesuai untuk temu duga platform, Linux, SRE, keselamatan, dan sistem. Ia menguji sempadan kernel, pengesahan statik, kitaran hayat pemuat ruang pengguna (user-space loader), dan disiplin pelepasan. Program eBPF melalui verifier sebelum ia dilampirkan (attach) pada cangkuk (hook) kernel. Lulus pengesahan tidak membuktikan ketepatan perniagaan atau keserasian dengan setiap kernel, set kebenaran, helper, map, atau persekitaran BTF.
Perkara yang dinilai oleh penemu duga
- Memisahkan kekangan keselamatan verifier daripada ketepatan hasil perniagaan.
- Memahami jenis daftar (register), sempadan penuding (pointer bounds), tindanan (stack) yang dimulakan, gelung, dan semakan helper.
- Menerangkan kitaran hayat open, load, attach, dan teardown libbpf.
- Menggunakan BTF, CO-RE, pengesanan ciri, dan matriks kernel untuk perbezaan versi.
- Menyediakan laluan penyahpepijatan untuk log verifier, kebenaran, sumber map, dan kegagalan attach.
- Mengetahui bahawa eBPF kekal tertakluk kepada pepijat kernel, semantik helper, dan kos pemerhatian.
Jawapan 30 saat
“Verifier melakukan semakan statik sebelum pelaksanaan: ia membuktikan akses memori yang bersempadan serta keadaan daftar dan penuding yang sah, mengehadkan helper, dan menolak laluan yang tidak dapat dibuktikan selamat. Ia tidak dapat membuktikan bahawa metrik saya membawa maksud yang betul. Saya akan memastikan proses open, load, verify, attach, dan teardown objek boleh dicerap dan menggunakan log verifier untuk menyahpepijat. BTF, CO-RE, pengesanan ciri, dan matriks CI yang meliputi kernel, seni bina, kebenaran, dan cangkuk mewujudkan keserasian. Jika sasaran tidak dapat dimuatkan, perkhidmatan mengekalkan sandaran ruang pengguna atau metrik sedia ada dan bukannya memintas semakan.”
Penyelesaian langkah demi langkah
Langkah 1: Tentukan sempadan keselamatan eBPF
Program eBPF berjalan dalam persekitaran pelaksanaan yang dikawal oleh kernel; ia tidak boleh membaca memori kernel sewenang-wenangnya atau memanggil fungsi yang tidak dibenarkan. Verifier mengikut aliran kawalan sambil menjejaki daftar, tindanan, penuding map, dan penuding paket, menolak laluan yang keselamatannya tidak dapat dibuktikan. Ia adalah pintu keselamatan, bukan bukti formal yang lengkap, dan ia tidak menyemak makna pensampelan, privasi, atau kos sumber.
Mulakan dengan jenis program dan cangkuk: tracepoint, kprobe, cgroup, XDP, dan lain-lain mempunyai input, helper, dan kekangan pemulangan yang berbeza. Kod sumber yang sama boleh gagal apabila dipindahkan ke jenis program lain kerana konteks dan keupayaan telah berubah.
Langkah 2: Kenali kegagalan biasa verifier
Daftar yang tidak dimulakan, akses tindanan di luar batas, penuding boleh batal (nullable) yang tidak disemak, batas paket yang tidak mencukupi, gelung yang tidak dapat dibuktikan, hujah helper yang tidak sah, dan aritmetik penuding yang tidak sah semuanya boleh menyebabkan penolakan. Baca kegagalan keadaan pertama dalam log daripada hanya membetulkan mesej terakhir.
/* Pseudocode: check bounds before reading packet fields */
if (cursor + sizeof(struct header) > data_end)
return DROP;
struct header *h = cursor;
return handle(h->kind);Pastikan laluan mudah, letakkan semakan batas bersebelahan dengan pembacaan, dan bahagikan penghuraian yang kompleks kepada fungsi kecil yang boleh disahkan. Batasi gelung secara eksplisit, semak hasil carian map, dan gunakan penukaran penuding yang dibenarkan oleh konteks semasa.
Langkah 3: Terangkan kitaran hayat libbpf
Pemuat ruang pengguna membuka objek BPF dan menemui program, map, dan pemboleh ubah global. Pemuatan mencipta map, menyelesaikan penempatan semula (relocation), dan meminta verifier kernel menyemak dan memuatkan program. Peringkat attach menyambungkan program ke cangkuk; teardown memutuskan sambungan dan membebaskan sumber. Rekod nama objek, jenis program, versi kernel, kod ralat, dan log verifier pada setiap fasa.
Pemuatan yang berjaya bukan bermakna attach berjaya. Kebenaran, had memori terkunci, BTF yang hilang, cangkuk yang tiada, had map, dan sumber ring-buffer boleh gagal pada fasa yang berbeza. Pelancar harus mendedahkan fasa yang gagal dan menyatakan keupayaan yang kekal apabila hanya beberapa program dimuatkan.
Langkah 4: Reka bentuk map, peristiwa, dan had sumber
Map menyediakan keadaan kongsi utama antara kernel dan ruang pengguna. Pilih map hash, array, per-CPU, atau ring-buffer berdasarkan kunci, nilai, keserentakan kemas kini, kitaran hayat, dan kapasiti. Peristiwa frekuensi tinggi memerlukan pensampelan, pembatretan (batching), dan pembilang kehilangan; pemerhatian tidak boleh menghabiskan sumber kernel.
Minimumkan medan sensitif dalam kernel dan hantar cincangan (hash), kategori, atau kiraan jika boleh. Pengguna ruang pengguna mesti mengendalikan limpahan ring-buffer, mula semula, dan perubahan versi. Peristiwa yang hilang ialah ketidaktentuan eksplisit, bukan sifar pemerhatian.
Langkah 5: Kendalikan BTF, CO-RE, dan keserasian
BTF membekalkan metadata jenis supaya pemuat dan alat boleh memahami program, map, dan simbol kernel. CO-RE menempatkan semula mengikut jenis dan mengurangkan penyusunan semula bagi setiap kernel, tetapi ia tidak menghapuskan setiap perbezaan. Helper, kfuncs, jenis program, seni bina, pengkompil, dan kebenaran masih memerlukan semakan ciri.
Matriks keserasian harus meliputi pengedaran, versi kernel, seni bina, kehadiran BTF, bendera ciri, kebenaran bekas, dan cangkuk sasaran. CI mesti menjalankan kompilasi, pemuatan verifier, attach, main semula peristiwa, dan teardown pada kernel sebenar atau maya. Kompilasi sahaja bukan bukti keserasian.
Langkah 6: Bina penyahpepijatan, sandaran, dan pelepasan
Nyahpepijat mengikut urutan ini: sahkan kernel dan kebenaran; periksa jenis program dan cangkuk; tangkap log verifier penuh; semak BTF dan helper; kemudian semak sumber map dan penggunaan ruang pengguna. Kelaskan kegagalan sebagai keselamatan sumber, keupayaan yang hilang, kebenaran, sumber masa jalanan, atau logik perniagaan supaya pembetulan sepadan dengan puncanya.
Lepaskan dahulu pada nod bayangan (shadow nodes) atau kenari hos kecil. Pantau CPU, memori, peristiwa yang hilang, penolakan verifier, log kernel, dan isyarat sasaran. Jika pemuatan gagal, perkhidmatan ruang pengguna mengekalkan metrik atau log sedia ada. Simpan objek sebelumnya dan operasi putuskan sambungan (detach) supaya pemulihan (rollback) tidak bergantung pada program baharu.
Pertambahan maklumat dan sempadan
Faedah utama eBPF ialah kebolehprograman kernel yang dikekang melalui laluan pemuatan yang boleh disahkan dan boleh dicerap. Verifier membuktikan satu set sifat keselamatan, bukan niat program; CO-RE meningkatkan kebolehportan tetapi tidak menjamin kejayaan merentas versi. Jawapan yang kukuh merangkumi keselamatan, keserasian, sumber, dan ketepatan perniagaan secara bersama.
Jawapan model
“Saya akan mulakan dengan jenis program dan cangkuk kerana konteks menentukan input, nilai pulangan, dan keupayaan helper. Sebelum pelaksanaan, verifier menjejaki daftar, tindanan, map, dan penuding paket serta menolak daftar yang tidak dimulakan, akses di luar batas, null yang tidak disemak, gelung tanpa batas, dan hujah helper yang tidak sah. Lulus membuktikan laluan tersebut selamat untuk dilaksanakan; ia tidak membuktikan bahawa pensampelan atau metrik perniagaan adalah betul.
Pemuat ruang pengguna menggunakan libbpf untuk menjadikan open, load, attach, dan teardown boleh dicerap. Apabila pemuatan gagal, saya mengekalkan log verifier yang lengkap dan membezakan antara keselamatan sumber, helper yang hilang, BTF, kebenaran, dan sumber. BTF dan CO-RE mengurangkan penyusunan semula, tetapi saya masih menguji matriks sebenar bagi pengedaran, kernel, seni bina, cangkuk, kebenaran, dan ciri merentasi fasa compile, load, attach, main semula, dan teardown.
Saya mengehadkan kapasiti map dan kadar peristiwa, merekodkan kehilangan, dan meminimumkan medan sensitif dalam kernel. Pengeluaran bermula dengan nod bayangan dan kenari kecil, memantau CPU, memori, peristiwa yang hilang, dan log kernel. Pemuatan yang gagal mengekalkan metrik atau laluan log sedia ada dan berundur ke objek sebelumnya dengan operasi detach. Ini memanfaatkan eBPF tanpa mengelirukan verifier atau CO-RE dengan keselamatan mutlak atau keserasian penuh.”
Kesilapan biasa
- Menganggap verifier sebagai bukti perniagaan → ia tidak menyemak maksud metrik atau privasi → tambah main semula, pensampelan, dan audit data.
- Hanya menyemak kompilasi → pemuatan, attach, kebenaran, dan BTF masih boleh gagal → uji kitaran hayat penuh pada matriks kernel.
- Membetulkan baris log terakhir sahaja → punca utama selalunya merupakan kegagalan keadaan terdahulu → mulakan pada ralat daftar atau batas yang pertama.
- Menulis map dan peristiwa tanpa had → pemerhatian boleh menghabiskan sumber kernel → hadkan kapasiti, lakukan pensampelan, dan kira kehilangan.
- Menganggap CO-RE menghapuskan perbezaan versi → helper, cangkuk, kebenaran, dan seni bina masih berbeza → kesan ciri dan turunkan fungsi secara terkawal.
- Tiada sandaran ruang pengguna → pemuatan yang gagal boleh menjejaskan perkhidmatan utama → kekalkan metrik, log, dan laluan detach.
Soalan susulan
Bagaimanakah anda membetulkan ralat verifier penuding yang mungkin null?
Semak secara eksplisit pada setiap laluan aliran kawalan sebelum menyahrujuk (dereferencing), dengan mengekalkan semakan berdekatan dengan pembacaan. Jika cabang adalah kompleks, bahagikan fungsi dan periksa semula keadaan verifier dan bukannya menyembunyikan isu dengan pemutus jenis (cast) yang tidak selamat.
Bagaimana jika program yang sama dimuatkan pada satu kernel tetapi gagal pada kernel yang lain?
Bandingkan jenis program, helper, kfuncs, BTF, seni bina, konfigurasi, kebenaran, dan log verifier dan bukannya hanya membandingkan nombor versi. Lakukan pengesanan ciri untuk alternatif dan rekodkan hasilnya dalam matriks keserasian dan gerbang pelepasan.
Bagaimanakah anda mengelakkan peristiwa yang hilang daripada kelihatan sihat?
Kira kehilangan, limpahan ring-buffer, dan pemulaan semula pengguna dalam kedua-dua kernel dan ruang pengguna. Terbitkan kadar sampel, kadar kehilangan, dan liputan. Papan pemuka harus menunjukkan ketidaktentuan apabila peristiwa tidak lengkap, bukan sifar.
Adakah semakan keselamatan masih diperlukan selepas kelulusan verifier?
Ya. Semak kebenaran program, peminimuman data, pemuat ruang pengguna, peningkatan dan pemulihan, pendedahan kernel, dan had sumber. Verifier adalah perlu, tetapi ia tidak menggantikan pemodelan ancaman atau pemantauan masa jalanan.