Libseccomp: BUG: seccomp_arch_add() mengembalikan -EEXISTS pada ketidakcocokan endian

Dibuat pada 20 Jun 2017  ·  18Komentar  ·  Sumber: seccomp/libseccomp

(perhatikan bahwa deskripsi masalah saya dimulai dengan golang tetapi sebenarnya ini adalah masalah C, lihat di bawah)

Saya sedang menulis beberapa unit test hari ini yang menjalankan ScmpFilter.AddArch(seccomp.ArchPPC) pada sistem amd64 saya. Ini tidak mengembalikan kesalahan apa pun, namun arsitekturnya tidak ditambahkan ke filter (seperti yang terlihat melalui exportPFC).

Berikut ini adalah pereproduksi sepele (perlu dijalankan pada amd64 atau i386):

package main

import (
    "os"
    "github.com/seccomp/libseccomp-golang"
)

func main() {
    secFilter, err := seccomp.NewFilter(seccomp.ActKill)
    if err != nil {
        panic(err)
    }
    err = secFilter.AddArch(seccomp.ArchPPC)
    if err != nil {
        panic(err)
    }
    secFilter.ExportPFC(os.Stdout)
}

Setelah sedikit debugging ternyata seccomp_arch_add() akan mengembalikan EEXIST jika ada ketidakcocokan endian. Di db.c:db_col_db_add() ada:

if (col->endian != 0 && col->endian != db->arch->endian)
        return -EFAULT;

Kode golang (seharusnya) mengabaikan EEXIST yang mengarah ke perilaku yang saya amati.

Saya ingin tahu apakah masuk akal bahwa seccomp_arch_add() akan mengembalikan kode kesalahan yang berbeda, mungkin EINVAL atau sesuatu? Jika ini terlalu berbahaya (karena dapat merusak aplikasi yang ada), mungkin ini dapat didokumentasikan dengan lebih baik. Saya senang memberikan PR.

bug prioritmedium
Sumber
picture mvo5

Semua 18 komentar

Terima kasih telah melaporkan ini, saya harus melihat lebih dekat.

pcmoore picture pcmoore pada 21 Jun 2017

Saya sangat menyesal butuh waktu lama untuk kembali ke @mvo5 ini , saya menghargai kesabaran Anda.

Untuk memperjelas sedikit, db.c:db_col_db_add() yang relevan saat ini terlihat seperti ini:

        if (col->endian != 0 && col->endian != db->arch->endian)
                return -EEXIST;

... Saya pikir versi di atas dalam laporan masalah asli adalah salinan yang ditambal secara lokal untuk mengatasi masalah tersebut. Yang mengatakan, mengubah kesalahan yang dikembalikan di sini memang terdengar masuk akal; kami telah menggunakan EDOM setidaknya di beberapa kode arch/endian lainnya, apakah itu terdengar masuk akal bagi Anda?

Bagaimana menurutmu @mheon?

Sepertinya kita mungkin juga harus memperbarui db.c:db_col_merge() saat kita melakukannya.

pcmoore picture pcmoore pada 15 Jan 2019
👍1

Dari sudut pandang API, saya benar-benar berpikir masuk akal untuk membuat perubahan - kode kesalahan yang berlebihan selalu bermasalah untuk debugging.

Di sisi libseccomp-golang, ini seharusnya tidak memerlukan perubahan kode apa pun, selama konvensi ERRNO negatif dipertahankan; mungkin beberapa baris komentar di AddArch untuk menjelaskan apa arti kesalahan baru, sehingga dokumentasi API akan lengkap.

mheon picture mheon pada 15 Jan 2019

Travis masih menjalankan kernel yang terlalu tua, sehingga pengujian #47 gagal lagi. Seperti yang disebutkan @pcmoore beberapa waktu lalu, saya akan mencoba menambahkan beberapa kecerdasan ke dalam tes untuk menghindari hal ini.

Jika tidak, segala sesuatu yang lain dari perubahan ini terlihat bagus di buku saya

drakenclimber picture drakenclimber pada 4 Feb 2019

@drakenclimber Saya pikir maksud Anda tes 46, bukan 47, kan?

Beberapa bulan yang lalu saya menambahkan pemeriksaan level API untuk tes langsung, tetapi saya rasa kita tidak memerlukannya untuk tes bpf-sim, bukan? Tes BPF-sim berjalan bersih ...?

pcmoore picture pcmoore pada 4 Feb 2019

Travis pasti muntah pada tes # 47 (KILL_PROCESS) untuk proses di atas. Saya juga melihat kegagalan yang sama pada HEAD master pagi ini ketika saya mendorongnya ke cabang terpisah sebagai pemeriksaan kewarasan.

Uji 47-live-kill_process%%001-00001 hasil: FAILURE 47-live-kill_process 3 KILL_PROCESS rc=12

Kami membicarakan hal ini beberapa waktu yang lalu, jadi ingatan saya mungkin kabur, tetapi saya pikir Travis memiliki masalah dengan uji KILL_PROCESS karena kernel Travis lebih tua dari 4.14 ketika fitur itu diperkenalkan.

Atau aku gila... dan salah ingat sama sekali?

drakenclimber picture drakenclimber pada 5 Feb 2019

Hmm, apakah kita melihat log yang sama? Saya melihat build dan log di bawah ini:

yang menunjukkan hasil berikut (hanya menyalin tes "c" di sini, hasil "python" sama):

 batch name: 46-sim-kill_process
 test mode:  c
 test type:  bpf-sim
Test 46-sim-kill_process%%001-00001 result:   ERROR 46-sim-kill_process rc=12
Test 46-sim-kill_process%%002-00001 result:   ERROR 46-sim-kill_process rc=12
Test 46-sim-kill_process%%003-00001 result:   ERROR 46-sim-kill_process rc=12
Test 46-sim-kill_process%%004-00001 result:   ERROR 46-sim-kill_process rc=12
Test 46-sim-kill_process%%005-00001 result:   ERROR 46-sim-kill_process rc=12
Test 46-sim-kill_process%%006-00001 result:   ERROR 46-sim-kill_process rc=12
 batch name: 47-live-kill_process
 test mode:  c
 test type:  live
Test 47-live-kill_process%%001-00001 result:   SKIPPED (must specify live tests)

... dan ya, kernel lama memang memiliki masalah dengan beberapa tes langsung, tapi itu seharusnya sudah diperbaiki di 9d4f7f69714d5af80309aa1b8a6d2c8300bb6730.

FWIW, build Travis terakhir di cabang master berjalan bersih:

Saya baru saja memicu build baru menggunakan cabang master hanya untuk memverifikasi bahwa semuanya "OK" dengan Travis:

pcmoore picture pcmoore pada 5 Feb 2019

Saya akui bahwa saya sekarang _sangat_ bingung. Tautan Anda pasti menunjukkan tes # 46 sebagai masalahnya. Tetapi ketika saya mengklik tautan "Log Mentah" di sudut kanan atas, itu memberi tahu saya #47 gagal. Untuk tautan yang Anda cantumkan di atas, di sinilah log mentah mengarahkan saya:

drakenclimber picture drakenclimber pada 5 Feb 2019

Jadi melihat lebih dekat, saya pikir kami berdua benar.

46 mengembalikan ERROR seperti yang Anda tunjukkan. Dan #47 mengembalikan FAILURE (yang awalnya saya cari.)

Dan ini juga terlihat dalam ringkasan:

Regression Test Summary
 tests run: 14090
 tests skipped: 114
 tests passed: 14090
 tests failed: 0
 tests errored: 12

Regression Test Summary
 tests run: 16
 tests skipped: 0
 tests passed: 14
 tests failed: 2
 tests errored: 0
drakenclimber picture drakenclimber pada 5 Feb 2019

Saya dapat mereproduksi masalah TravisCI di salah satu sistem saya jika saya boot ke kernel 3.x. Tes 46 akhirnya mengalami masalah di sys_chk_seccomp_action() . Ini pada akhirnya menyebabkan seccomp_init() mengembalikan konteks NULL kembali ke pengujian.

Saya akan membayangkan masalah Test 47 serupa, tetapi saya tidak menyelidiki jalur kegagalannya. (Meskipun perubahan yang ditambahkan @pcmoore untuk memverifikasi API seharusnya mencegah hal ini. Hmmm...)

Saya ingin tahu apa yang berubah pada Travis yang menyebabkan ini. Apakah mereka kembali ke kernel yang sangat tua? Sesuatu di pihak kita?

Sepertinya kita perlu menambahkan beberapa kecerdasan ke tes bpf-sim untuk menangani ini. Apakah kita ingin meniru kolom API yang ditambahkan ke file *.tests atau melakukan sesuatu yang lain sama sekali?

drakenclimber picture drakenclimber pada 5 Feb 2019

Ya, saya benar-benar bingung mengapa itu berfungsi seperti sekarang tidak. Ubuntu 14.xx sudah sangat tua akhir-akhir ini, saya akan melihat apakah ada versi yang lebih baru yang tersedia di Travis.

pcmoore picture pcmoore pada 5 Feb 2019

Sepertinya Ubuntu 16.04 (Xenial) tersedia, mari kita coba ...

pcmoore picture pcmoore pada 5 Feb 2019

Komit 06f63ba691cb9df119c6759e8f0a150a2a9cbe69 membuat kami naik ke Ubuntu 16.04. Saya melakukan ini di cabang master, bukan sebagai PR, karena saya ingin memaksa sakelar ini; jika build rusak kami akan memperbaikinya.

pcmoore picture pcmoore pada 5 Feb 2019
👍1

Bangunan itu tampaknya telah memperbaiki masalah dengan pengujian, tetapi dentang baru saja menemukan kebocoran memori di jalur kode penanganan kesalahan. Saya akan memperbaikinya hanya dalam satu menit.

pcmoore picture pcmoore pada 5 Feb 2019

Luar biasa! Terima kasih atas bantuannya, @pcmoore

drakenclimber picture drakenclimber pada 5 Feb 2019

Oke, dengan commit f8854f990004e71ccb9955c33d88d82cdb97ea42 kita harus memiliki cabang master bangunan yang bersih. Ini berfungsi dengan baik di cabang pribadi saya, menunggu di build utama sekarang.

pcmoore picture pcmoore pada 5 Feb 2019

@drakenclimber Saya melihat Anda sudah menyiapkan tambalan untuk ini di log masalah di atas, tetapi saya belum melihat PR - apakah Anda masih mengejar beberapa masalah dengan tambalan atau sudah siap untuk PR?

pcmoore picture pcmoore pada 18 Feb 2019

Ini harus diselesaikan dengan komit 4a35b6ea6f7c836734536420c50a2745a9e24c69, tutup ini sekarang. Jika ada yang menemukan masalah dengan ini, silakan buka kembali masalah ini atau buat yang baru.

pcmoore picture pcmoore pada 18 Feb 2019
Apakah halaman ini membantu?
0 / 5 - 0 peringkat

Masalah terkait

alban picture alban  ·  9Komentar
pcmoore picture pcmoore  ·  23Komentar
grubeli picture grubeli  ·  3Komentar
cgwalters picture cgwalters  ·  14Komentar
drakenclimber picture drakenclimber  ·  18Komentar