On 14/12/20 at 14:36 -0500, Reinhard Tartler wrote: > > > > === RUN TestRuleAddAndLoad > > seccomp_test.go:588: Syscall should have returned error code! > > --- FAIL: TestRuleAddAndLoad (0.00s) > > > Source code is here: > https://sources.debian.org/src/golang-github-seccomp-libseccomp-golang/0.9.1-2/seccomp_test.go/#L529-L589 > > This test is basically loading a seccomp rule and expects that the > getpid() syscall fails with the rule loaded, but in that test it seems > to pass. This might mean that seccomp isn't working on that box. > > Lucas, can you elaborate a bit what kind of test system you were using? > Do you have any explanation what might be going on with the test setup that > would make seccomp not work or only under certain conditions?
Hi, This is a system running plain debian stable with an unstable chroot (using sbuild). I cannot think of something strange. I tried disabling SMT (hyperthreading) because with it enabled, the system has 160 visible cores, which breaks some builds. But it did not change anything. # uname -a Linux drac-6.grenoble.grid5000.fr 4.19.0-13-powerpc64le #1 SMP Debian 4.19.160-2 (2020-11-28) ppc64le GNU/Linux I also tried with a Debian testing image and could reproduce it. Kernel was linux-image-5.9.0-1-powerpc64le 5.9.1-1 Lucas
