Libseccomp: RFE: membedakan syscalls yang tidak diketahui
Dipicu oleh diskusi (pada bulan Juni & Agustus ) di systemd-devel ..
systemd-nspawn memilih untuk mengembalikan EPERM untuk syscalls yang tidak masuk daftar putih. Namun, ini menyebabkan masalah dalam kasus seperti openat2 , di mana libc memeriksa ENOSYS dan kembali ke implementasi yang berbeda.
Menurut saya solusi 'kebanyakan benar' adalah memeriksa apakah nomor syscall berada dalam kisaran syscalls yang ditentukan yang ada pada saat seccomp dibangun. Saya yakin ada kasus sudut (saya tahu beberapa lengkungan melakukan hal-hal aneh), tetapi jika alat yang mengurai syscalls.csv dll dapat menghasilkan #define untuk nomor syscall maksimum yang diketahui yang mungkin berguna?
srd424
Semua 18 komentar
Hai @srd424. Saya ingin memastikan bahwa saya mengerti apa yang Anda minta dalam masalah ini ... kedengarannya bagi saya bahwa pada dasarnya Anda ingin tahu apakah libseccomp "tahu" tentang syscall yang diberikan, terlepas dari apakah syscall tertentu diimplementasikan pada lengkungan itu /ABI, ya?
Jika demikian, saya yakin Anda harus dapat menggunakan seccomp_syscall_resolve_name(...) untuk mendapatkan informasi yang Anda inginkan. Jika nilai kembalian adalah __NR_SCMP_ERROR maka syscall tidak diketahui oleh libseccomp, jika positif maka syscall ada di arch/ABI asli, dan jika negatif maka syscall tidak ada di arch/ ABI. Apakah itu berhasil untuk Anda?
pcmoore
pada 16 Agu 2020
Itu mungkin membuat filter.. bertele-tele!
Apa yang saya harapkan untuk dilakukan adalah memiliki aturan filter yang membandingkan nomor syscall dengan yang tertinggi yang diketahui, dan jika lebih besar, return ENOSYS , jika tidak return EPERM (Dengan asumsi bahwa syscalls yang masuk daftar putih telah ditangani dengan aturan sebelumnya.)
Namun melihat detail untuk seccomp_rule_add , saya tidak yakin itu akan berhasil .. nomor syscall diperlakukan secara khusus. Filter bpf mentah mungkin dapat dibuat untuk melakukan ini, tetapi itu berarti beberapa perubahan yang lebih invasif pada libseccomp - mungkin di atas nilai gaji saya!
srd424
pada 16 Agu 2020
Mungkin atau mungkin tidak fungsionalitas yang masuk akal untuk ditambahkan ke libseccomp karena saya kira masalah asli dapat terjadi untuk banyak pengguna perpustakaan. Sepertinya itu (hanya?) Menjadi pertanyaan untuk menghasilkan tindakan default yang sedikit lebih canggih..
srd424
pada 16 Agu 2020
Itu mungkin membuat filter.. bertele-tele!
Saya tidak begitu yakin apa yang Anda maksud di sini ... ? Panggilan ke seccomp_syscall_resolve_name(...) sebenarnya tidak memengaruhi filter, itu hanya menanyakan libseccomp syscall db internal untuk melakukan resolusi syscall. Anda dapat memanggilnya sekali, seribu kali, atau tidak pernah dan filter Anda akan sama persis :)
Apa yang saya harapkan untuk dilakukan adalah memiliki aturan filter yang membandingkan nomor syscall dengan yang tertinggi yang diketahui, dan jika lebih besar, kembalikan ENOSYS, jika tidak, kembalikan EPERM (Dengan asumsi bahwa syscalls yang masuk daftar putih telah ditangani oleh aturan sebelumnya.)
Oke, saya pikir saya mulai mengerti apa yang Anda minta sekarang. Anda ingin filter itu sendiri, bukan kode aplikasi, untuk mengambil tindakan tertentu (kembalikan ENOSYS dalam contoh di atas) jika syscall tidak diketahui oleh libseccomp? Apakah itu pada dasarnya, atau apakah saya melewatkan sesuatu lagi?
pcmoore
pada 17 Agu 2020
Komentar di utas kedua yang disebutkan di atas membuat saya tersenyum :+1:
Saya sudah mencoba membuka diskusi tentang penanganan ENOSYS di libseccomp di
https://github.com/seccomp/libseccomp/issues/286 , tapi saya mungkin tidak
menjadi sangat koheren..
Setelah membaca utas yang Anda sebutkan, saya pikir saya berada di halaman yang sama.
Jika seseorang (libseccomp, nspawn, siapa pun) dapat mengembalikan ENOSYS , maka glibc akan mencoba mundur dari syscall yang lebih baru, misalnya openat2 , ke syscall yang lebih lama, misalnya openat . Mengembalikan EPERM ke glibc hanya membuat glibc berpikir bahwa panggilan itu tidak diizinkan, dan glibc akan menyerah. Apakah itu penulisan ulang yang adil dari komentar awal dalam masalah ini?
Saya pikir permintaan itu masuk akal. Saya perlu berpikir lagi jika libseccomp dapat memenuhi kebutuhan ini, tetapi saya tidak keberatan saat ini. Pasti ada peluang untuk meningkatkan pengalaman pengguna akhir di sini.
Terima kasih untuk RFEnya.
drakenclimber
pada 17 Agu 2020
Jika seseorang (libseccomp, nspawn, siapa pun) dapat mengembalikan
ENOSYS, maka glibc akan mencoba mundur dari syscall yang lebih baru, misalnyaopenat2, ke syscall yang lebih lama, misalnyaopenat. MengembalikanEPERMke glibc hanya membuat glibc berpikir bahwa panggilan itu tidak diizinkan, dan glibc akan menyerah. Apakah itu penulisan ulang yang adil dari komentar awal dalam masalah ini?
Ya, itu terdengar benar. Pendapat dari orang-orang systemd adalah bahwa EPERM sebagian besar waktu masuk akal untuk syscalls yang ditolak, mungkin karena menyampaikan "tidak diizinkan" untuk pengguna akhir/admin. Oleh karena itu ide untuk membedakan antara syscalls "baru" dan "lama" dan melakukan ENOSYS untuk apa pun yang tidak dikenali. Saya berasumsi kita tidak ingin menghitung dan menguji setiap syscall di BPF karena alasan kinerja, jadi melacak tanda air yang tinggi untuk nomor syscall yang diketahui per-lengkungan sepertinya merupakan cara "usaha terbaik" untuk dilakukan.
Akan menarik untuk mengetahui apa yang dilakukan buruh pelabuhan, podman, lxc dll. dengan penyaringan seccomp mereka, untuk melihat apakah mereka akan mendapat manfaat. Sementara itu, saya telah melakukan PR untuk tambalan untuk nspawn yang memungkinkan pencatatan peristiwa seccomp, yang akan membuat debugging sedikit lebih mudah.
srd424
pada 17 Agu 2020
Saya pikir permintaan itu masuk akal. Saya perlu berpikir lagi jika libseccomp dapat memenuhi kebutuhan ini, tetapi saya tidak keberatan saat ini. Pasti ada peluang untuk meningkatkan pengalaman pengguna akhir di sini.
Terima kasih untuk RFEnya.
Saya setuju dengan @drakenclimber , permintaan ini terdengar masuk akal, saya pikir saya hanya perlu lebih banyak waktu untuk memikirkan solusi yang mungkin :)
Pada tingkat yang cukup mendasar, ini mirip dengan RFE #11, dan pada akhirnya itu mungkin cara termudah untuk mengimplementasikan ini dengan cara yang tidak buruk untuk aplikasi: aplikasi dapat menentukan versi kernel API yang didukung maksimum, mis. v5.8 (jelas tokenized), serta tindakan yang diberikan untuk apa pun di luar dan kemudian libseccomp menangani sisanya. Apakah itu akan berhasil untuk kalian @ srd424?
pcmoore
pada 18 Agu 2020
Hai, ini juga dibahas di https://github.com/systemd/systemd/pull/16739 .
aplikasi dapat menentukan versi kernel API maksimum yang didukung, misalnya v5.8 (jelas diberi token), serta tindakan yang diberikan untuk apa pun di luar dan kemudian libseccomp menangani sisanya.
Ini akan bekerja dengan baik. Di systemd/systemd-nspawn kami ingin mengembalikan errno khusus untuk syscalls yang secara eksplisit diizinkan dan ditolak, EPERM untuk yang lain dalam "versi kernel API yang didukung", dan ENOSYS untuk yang baru.
Saya rasa implementasinya tidak akan terlalu rumit. Misalnya untuk amd64, syscalls "dikenal" dapat dinyatakan sebagai n <= 181 || 186 <= n <= 235 || 237 <= n <= 334 || 424 <= n <= 439 . Dan ekspresi seperti itu dapat dengan mudah dihasilkan secara terprogram dari tabel syscall.
keszybz
pada 19 Agu 2020
94 bisa berhubungan juga.
topimiettinen
pada 19 Agu 2020
Saya kurang berkafein pagi ini, tetapi apakah penanganan ENOSYS akan memberi kami kemungkinan untuk mengubah daftar yang diizinkan besar menjadi daftar kecil yang ditolak untuk kemungkinan kemenangan kinerja juga?
srd424
pada 19 Agu 2020
Saya rasa implementasinya tidak akan terlalu rumit. Misalnya untuk amd64, syscalls "dikenal" dapat dinyatakan sebagai n <= 181 || 186 <= n <= 235 || 237 <= n <= 334 || 424 <= n <= 439. Dan ekspresi tersebut dapat dengan mudah dihasilkan secara programatis dari tabel syscall.
Seperti yang Anda singgung, BPF yang sebenarnya akan menjadi khusus untuk versi arch/ABI dan kernel. Dalam contoh x86_64 di atas BPF tidak akan terlalu buruk, tetapi kami tidak seberuntung itu untuk lengkungan/versi lainnya. Terlepas dari itu, sekarang ini adalah dua masalah yang secara efektif meminta hal yang sama jadi saya pikir itu adalah sesuatu yang ingin kami lakukan ... Saya tidak akan mulai melompat-lompat tentang betapa mudahnya hal itu dulu; )
94 bisa berhubungan juga.
Semacam ya, semacam tidak. Ini melibatkan rentang, tetapi # 94 adalah tentang rentang argumen yang ditentukan pemanggil (yang masih merupakan sesuatu yang saya pikir ingin kita lakukan, PR baru saja masuk pada waktu yang buruk dan saya pikir API perlu beberapa penyesuaian) sedangkan yang kita bicarakan adalah rentang syscall yang dibuat secara implisit yang dihasilkan oleh perpustakaan itu sendiri.
Saya kurang berkafein pagi ini, tetapi apakah penanganan ENOSYS akan memberi kami kemungkinan untuk mengubah daftar yang diizinkan besar menjadi daftar kecil yang ditolak untuk kemungkinan kemenangan kinerja juga?
Dari perspektif aplikasi, misalnya systemd, jika Anda mencoba memblokir syscalls "baru" maka ya ... dengan asumsi kita membicarakan hal yang sama :)
pcmoore
pada 19 Agu 2020
Untuk lebih spesifik .. saat ini siapa pun yang mencoba _securely_ memblokir syscalls tertentu secara efektif harus masuk daftar, karena Anda tidak dapat memastikan syscalls apa yang mungkin ditambahkan oleh kernel yang lebih baru. Jika kita dapat meminta libseccomp untuk secara otomatis memblokir syscalls yang tidak dikenal, itu berarti kita dapat dengan aman beralih ke daftar penolakan kecil?
srd424
pada 19 Agu 2020
Untuk lebih spesifik .. saat ini siapa pun yang mencoba _securely_ memblokir syscalls tertentu secara efektif harus masuk daftar, karena Anda tidak dapat memastikan syscalls apa yang mungkin ditambahkan oleh kernel yang lebih baru. Jika kita dapat meminta libseccomp untuk secara otomatis memblokir syscalls yang tidak dikenal, itu berarti kita dapat dengan aman beralih ke daftar penolakan kecil?
Saya sangat berharap kita bisa sampai di sana, karena itu akan menjadi fitur yang benar-benar luar biasa. Misalnya, Docker saat ini menggunakan daftar yang diizinkan dan daftar defaultnya sekarang ~240 syscalls (dan selalu bertambah).
Dampak kinerja dari daftar yang begitu besar dapat menjadi penghalang. Perhatikan bahwa ini dapat sedikit dikurangi dengan menggunakan fitur pohon biner yang kami tambahkan di v2.5.
drakenclimber
pada 19 Agu 2020
Untuk lebih spesifik .. saat ini siapa pun yang mencoba _securely_ memblokir syscalls tertentu secara efektif harus masuk daftar, karena Anda tidak dapat memastikan syscalls apa yang mungkin ditambahkan oleh kernel yang lebih baru. Jika kita dapat meminta libseccomp untuk secara otomatis memblokir syscalls yang tidak dikenal, itu berarti kita dapat dengan aman beralih ke daftar penolakan kecil?
Saya tidak melihat bagaimana ini bisa berhasil. Tidak diketahui oleh libseccomp dan tidak diketahui oleh penulis daftar penolakan biasanya akan memiliki arti yang berbeda. Yang berarti bahwa masalah konseptual tidak akan hilang bahkan jika libseccomp memiliki gambaran yang lebih jelas tentang panggilan sistem yang didukung secara internal.
fweimer
pada 21 Agu 2020
Poin bagus - saya kira kita perlu set yang terdefinisi dengan baik yang ditandai oleh versi kernel agar bisa berfungsi, yang sepertinya sedang dibahas sedikit.
srd424
pada 21 Agu 2020
Saya rasa implementasinya tidak akan terlalu rumit. Misalnya untuk amd64, syscalls "dikenal" dapat dinyatakan sebagai n <= 181 || 186 <= n <= 235 || 237 <= n <= 334 || 424 <= n <= 439. Dan ekspresi tersebut dapat dengan mudah dihasilkan secara programatis dari tabel syscall.
Seperti yang Anda singgung, BPF yang sebenarnya akan menjadi khusus untuk versi arch/ABI dan kernel. Dalam contoh x86_64 di atas BPF tidak akan terlalu buruk, tetapi kami tidak seberuntung itu untuk lengkungan/versi lainnya. Terlepas dari itu, sekarang ini adalah dua masalah yang secara efektif meminta hal yang sama jadi saya pikir itu adalah sesuatu yang ingin kami lakukan ... Saya tidak akan mulai melompat-lompat tentang betapa mudahnya hal itu dulu; )
Tabelnya cukup kontinu:
>>> l = {int(s[1]):s[0] for s in (s.split() for s in open('syscalls-x86_64').readlines()) if len(s)>1}; x = np.array(sorted(l.keys())); np.diff(x)
array([ 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 5, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 2, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 90, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1])
>>> l = {int(s[1]):s[0] for s in (s.split() for s in open('syscalls-alpha').readlines()) if len(s)>1}; x = np.array(sorted(l.keys())); np.diff(x)
array([ 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 2, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 2, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 3, 1, 2, 1, 1,
1, 1, 1, 2, 1, 1, 1, 3, 12, 3, 3, 1, 11, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
2, 1, 1, 1, 1, 1, 1, 5, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 2, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 39, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 2, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 2, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 2, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 2, 1, 1, 1, 1, 3, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 2, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 2, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
2, 1, 1, 1])
>>> l = {int(s[1]):s[0] for s in (s.split() for s in open('syscalls-arm').readlines()) if len(s)>1}; x = np.array(sorted(l.keys())); np.diff(x)
array([1, 1, 1, 1, 1, 1, 2, 1, 1, 1, 1, 2, 1, 1, 3, 1, 1, 2, 1, 2, 3, 4,
1, 2, 1, 1, 1, 1, 1, 1, 1, 2, 1, 1, 2, 1, 1, 1, 2, 1, 2, 3, 1, 1,
1, 1, 1, 1, 1, 3, 1, 1, 1, 1, 1, 2, 1, 1, 1, 1, 2, 2, 1, 1, 1, 3,
1, 1, 1, 1, 1, 1, 2, 1, 3, 1, 1, 1, 1, 1, 3, 3, 1, 1, 2, 1, 1, 1,
1, 2, 1, 1, 2, 1, 2, 1, 1, 1, 1, 1, 2, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 3, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 3, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 3, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 3, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 2, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 2, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 2, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1])
>>> l = {int(s[1]):s[0] for s in (s.split() for s in open('syscalls-riscv64').readlines()) if len(s)>1}; x = np.array(sorted(l.keys())); np.diff(x)
array([ 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 2, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 16, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 130, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1])
Saya menerapkan filter syscalls "dikenal" untuk systemd-nspawn di https://github.com/systemd/systemd/pull/16819 . https://github.com/systemd/systemd/pull/16819/commits/158e30ffd9355a7640a7276276eb9219b6c87914 memiliki dump dari beberapa program yang dihasilkan libseccomp. Dump itu panjang, jadi saya tidak akan mengulanginya di sini, tetapi SCMP_FLTATR_CTL_OPTIMIZE membuat program lebih efisien, tetapi juga lebih lama. Hal-hal dapat dibuat ~50 kali lebih pendek dengan menggunakan perbandingan jangkauan.
keszybz
pada 22 Agu 2020
Saya baru saja menemukan utas ini, hanya menimpali untuk mengatakan bahwa saya telah memikirkan hal yang sama dan ini jelas merupakan sesuatu yang ingin diselesaikan oleh Docker/runc juga. Melakukannya dengan versi kernel maksimum mungkin adalah cara terbaik untuk melakukannya, karena itu berarti penulis profil (dan runtime container) tidak perlu melacak syscalls yang ditambahkan di luar urutan atau apa syscall terbaru pada saat penulisan profil.
cyphar
pada 27 Nov 2020
Berdasarkan pembahasan di atas, sepertinya sebagian besar (semua?) orang di sini percaya bahwa masalah #11 adalah cara yang tepat untuk menyelesaikan masalah ini; adakah yang punya masalah dengan menutup masalah ini demi memindahkan diskusi di masa mendatang ke masalah asli (#11)?
pcmoore
pada 2 Des 2020
Masalah terkait
erdumbledore
·
3Komentar
cgwalters
·
14Komentar
mvo5
·
18Komentar
diekmann
·
3Komentar
drakenclimber
·
10Komentar
Komentar yang paling membantu
Berdasarkan pembahasan di atas, sepertinya sebagian besar (semua?) orang di sini percaya bahwa masalah #11 adalah cara yang tepat untuk menyelesaikan masalah ini; adakah yang punya masalah dengan menutup masalah ini demi memindahkan diskusi di masa mendatang ke masalah asli (#11)?