Filter seccomp dapat melakukan lebih dari sekadar langsung mengizinkan atau menolak system call. Dengan user notification, call yang cocok dapat ditahan sementara proses lain menerima request terstruktur melalui listener file descriptor dan menentukan hasil yang diterima thread yang diblokir. Mekanisme ini mengubah keputusan syscall terpilih menjadi interface berbasis broker tanpa memindahkan seluruh implementasi syscall ke user space.
Batasnya presisi, tetapi lebih sempit daripada lapisan interposition umum. Kernel tetap memiliki syscall dispatch, task state, descriptor table, dan validasi yang dilakukan kode kernel. Broker menerima metadata dan dapat mengembalikan nilai, error, atau pada kasus yang didukung meminta eksekusi syscall asli dilanjutkan. Desain yang benar memperhitungkan memory target yang mutable, lifetime notification, serta fakta bahwa keputusan policy tidak otomatis menjadi transaksi atas state proses.
Filter memilih notification sebelum syscall dieksekusi
Proses memasang filter seccomp dengan rule terpilih yang mengembalikan SECCOMP_RET_USER_NOTIF. Saat filter dipasang dengan SECCOMP_FILTER_FLAG_NEW_LISTENER, pemasangan tersebut mengembalikan listener file descriptor. Supervisor yang memegang descriptor itu dapat menerima notification melalui SECCOMP_IOCTL_NOTIF_RECV.
Notification memuat identifier task target, nomor syscall, nilai architecture, instruction pointer, argumen syscall, dan identifier notification. Pada titik ini syscall terpilih belum selesai. Thread target tetap diblokir sampai notification dijawab, diinterupsi, atau menjadi tidak valid akibat event pada lifecycle task.
Susunan ini memisahkan selection dari policy. Logika filter BPF tetap dibatasi dan dieksekusi pada jalur seccomp, sedangkan broker dapat memakai state user space yang lebih kaya untuk menentukan response. Fleksibilitas tersebut juga memperluas permukaan protokol: broker kini ikut menentukan latency dan availability setiap syscall yang diarahkan kepadanya.
Identifier notification mewakili request sementara
Identifier notification numerik bukan handle permanen untuk task atau percobaan syscall. Request dapat menjadi stale sebelum broker selesai memprosesnya, misalnya ketika operasi yang diblokir terinterupsi. SECCOMP_IOCTL_NOTIF_ID_VALID memungkinkan broker memeriksa apakah identifier masih merujuk ke notification yang aktif.
Validasi penting ketika broker melakukan pekerjaan dengan efek eksternal sebelum memberikan response. Identifier yang valid saat diterima dapat menjadi tidak valid kemudian. Pemeriksaan validitas mempersempit race window; pemeriksaan itu tidak mengubah operasi lain di sekitar broker menjadi transaksi atomic dengan target.
Response yang dikirim melalui SECCOMP_IOCTL_NOTIF_SEND harus membawa identifier yang terkait dengan request. Kernel menolak response untuk notification yang sudah tidak valid. State broker karena itu sebaiknya dikaitkan dengan lifetime notification, bukan memperlakukan identifier task saja sebagai identitas request.
Argumen syscall adalah nilai, bukan objek yang dibekukan
Notification mengekspos register argumen syscall yang ditangkap untuk call tersebut. Untuk argumen berupa nilai scalar, nilai register itu dapat cukup bagi keputusan policy. Argumen pointer memiliki batas berbeda.
Alamat pada argumen syscall merujuk ke memory di proses target. Notification tidak menyalin objek yang ditunjuk menjadi payload request immutable. Thread lain pada target dapat mengubah memory tersebut ketika broker sedang memeriksanya. Pathname, socket address, atau argumen terstruktur yang dibaca broker karena itu dapat berbeda dari data yang kemudian dikonsumsi eksekusi kernel jika syscall asli dilanjutkan.
Ini merupakan batas time-of-check/time-of-use. Broker tidak boleh memperlakukan salinan user space dari memory target yang mutable sebagai bukti atas data yang akan dikonsumsi operasi kernel berikutnya. Policy yang memerlukan identitas objek stabil membutuhkan mekanisme dengan kontrak yang mengikat objek yang diperiksa ke operasi akhirnya, bukan hanya mengandalkan snapshot pointer.
Melanjutkan syscall menyerahkan eksekusi kembali ke kernel
Response dapat memakai SECCOMP_USER_NOTIF_FLAG_CONTINUE untuk meminta kernel mengeksekusi syscall yang memicu notification. Mode ini berbeda secara material dari mengembalikan hasil emulasi. Broker mengotorisasi continuation, tetapi implementasi syscall normal kemudian membaca state target sesuai semantik syscall tersebut.
Continuation flag karena itu membawa langsung persoalan pointer race ke desain policy. Jika otorisasi bergantung pada byte yang dibaca dari memory target, byte tersebut dapat berubah sebelum dikonsumsi kernel. Continuation hanya sesuai ketika policy tetap valid terhadap mutabilitas itu atau invariant lain menutup race tersebut.
Broker juga dapat memberikan return value atau error sintetis tanpa mengeksekusi syscall asli. Hal itu dapat merepresentasikan penolakan atau emulasi, tetapi broker bertanggung jawab mempertahankan kontrak observable yang diharapkan target. Mengembalikan success tidak menghasilkan side effect kernel yang seharusnya dibuat syscall asli.
Descriptor injection mengikat objek milik broker ke target
Sebagian pola mediasi perlu mengembalikan file descriptor nyata, bukan sekadar integer yang menyerupainya. SECCOMP_IOCTL_NOTIF_ADDFD memungkinkan broker memasang file descriptor ke descriptor table target untuk notification yang masih aktif. Source descriptor dimiliki broker, sedangkan descriptor yang dipasang menjadi referensi yang tersedia bagi target.
Mekanisme ini berguna untuk operasi seperti file opening melalui broker karena broker dapat memilih dan membuka objek berdasarkan policy miliknya, lalu mentransfer referensi kernel yang dihasilkan. Target menerima descriptor ke objek terpilih tersebut, bukan melakukan resolusi pathname lagi setelah otorisasi.
Descriptor injection memiliki aturan lifecycle tersendiri. Notification harus tetap valid, descriptor flags dan pemilihan target descriptor harus mengikuti kontrak ioctl, dan broker harus menangani kegagalan tanpa menganggap nomor descriptor yang diminta pasti sudah terpasang. Operasi ini menyelesaikan transfer referensi objek; operasi tersebut tidak membuat pekerjaan broker lain menjadi atomic.
Kegagalan broker menjadi bagian dari availability syscall
Thread yang diblokir pada user notification bergantung pada sisi listener untuk terus membuat progress. Jika broker overload, deadlock, atau menunggu resource yang dipegang target, call yang dimediasi dapat tertahan. Arah dependency dengan demikian menjadi properti desain utama.
Broker sebaiknya tidak memerlukan operasi yang dimediasi dari dependency chain yang sama untuk melayani request. Mediasi rekursif dapat membentuk siklus ketika target menunggu broker sementara broker menunggu aksi yang juga tidak dapat berjalan. Pemisahan resource broker, pembatasan kumpulan syscall yang dimediasi, dan definisi perilaku shutdown membuat dependency tersebut tetap terlihat.
Lifetime listener juga penting. File descriptor tersebut adalah resource kernel yang ownership-nya dapat ditransfer memakai mekanisme descriptor passing biasa. Process supervision perlu menetapkan komponen yang menjaga listener tetap aktif serta nasib request yang diblokir saat komponen tersebut berhenti.
User notification adalah delegasi policy, bukan virtualisasi syscall transparan
seccomp user notification menyediakan control point yang sempit: filter mengidentifikasi percobaan syscall terpilih, kernel memblokir percobaan itu, dan listener menerima metadata yang cukup untuk keputusan policy di user space. Broker dapat menolak, mengemulasi hasil, melanjutkan eksekusi, atau memakai operasi yang didukung seperti descriptor injection.
Desain yang kuat mempertahankan perbedaan antara nilai register yang ditangkap dan objek target yang mutable. Notification ID bersifat sementara, memory target dapat berubah secara concurrent, syscall yang dilanjutkan dieksekusi kemudian dengan semantik kernel normal, dan availability broker menjadi bagian dari jalur eksekusi target.
Constraint tersebut membuat interface ini sesuai untuk mediasi dengan batas yang dirancang secara cermat. Constraint itu juga mencegah notification broker diperlakukan sebagai pengganti transparan bagi semantik syscall kernel. Batas policy dapat diandalkan hanya ketika lifetime request, identitas objek, race pada memory target, dan dependency broker menjadi bagian eksplisit dari desain.