Re: selftests: seccomp_bpf failure on 5.15

From: ebiederm@xmission.com (Eric W. Biederman)
To: Kees Cook <keescook@chromium.org>
Cc: Andrea Righi <andrea.righi@canonical.com>,
	Shuah Khan <shuah@kernel.org>,
	Alexei Starovoitov <ast@kernel.org>,
	Andy Lutomirski <luto@amacapital.net>,
	Will Drewry <wad@chromium.org>,
	linux-kselftest@vger.kernel.org, bpf@vger.kernel.org
Subject: Re: selftests: seccomp_bpf failure on 5.15
Date: Thu, 28 Oct 2021 12:26:26 -0500	[thread overview]
Message-ID: <878rydm56l.fsf@disp2133> (raw)
In-Reply-To: <202110280955.B18CB67@keescook> (Kees Cook's message of "Thu, 28 Oct 2021 09:56:12 -0700")

Kees Cook <keescook@chromium.org> writes:

> On Thu, Oct 28, 2021 at 06:21:12PM +0200, Andrea Righi wrote:
>> The following sub-tests are failing in seccomp_bpf selftest:
>> 
>> 18:56:54 DEBUG| [stdout] # selftests: seccomp: seccomp_bpf
>> ...
>> 18:56:57 DEBUG| [stdout] # #  RUN           TRACE_syscall.ptrace.kill_after ...
>> 18:56:57 DEBUG| [stdout] # # seccomp_bpf.c:2023:kill_after:Expected entry ? PTRACE_EVENTMSG_SYSCALL_ENTRY : PTRACE_EVENTMSG_SYSCALL_EXIT (1) == msg (0)
>> 18:56:57 DEBUG| [stdout] # # seccomp_bpf.c:2023:kill_after:Expected entry ? PTRACE_EVENTMSG_SYSCALL_ENTRY : PTRACE_EVENTMSG_SYSCALL_EXIT (2) == msg (1)
>> 18:56:57 DEBUG| [stdout] # # seccomp_bpf.c:2023:kill_after:Expected entry ? PTRACE_EVENTMSG_SYSCALL_ENTRY : PTRACE_EVENTMSG_SYSCALL_EXIT (1) == msg (2)
>> 18:56:57 DEBUG| [stdout] # # kill_after: Test exited normally instead of by signal (code: 12)
>> 18:56:57 DEBUG| [stdout] # #          FAIL  TRACE_syscall.ptrace.kill_after
>> ...
>> 18:56:57 DEBUG| [stdout] # #  RUN           TRACE_syscall.seccomp.kill_after ...
>> 18:56:57 DEBUG| [stdout] # # seccomp_bpf.c:1547:kill_after:Expected !ptrace_syscall (1) == IS_SECCOMP_EVENT(status) (0)
>> 18:56:57 DEBUG| [stdout] # # kill_after: Test exited normally instead of by signal (code: 0)
>> 18:56:57 DEBUG| [stdout] # #          FAIL  TRACE_syscall.seccomp.kill_after
>> 18:56:57 DEBUG| [stdout] # not ok 80 TRACE_syscall.seccomp.kill_after
>> ...
>> 18:56:57 DEBUG| [stdout] # # FAILED: 85 / 87 tests passed.
>> 18:56:57 DEBUG| [stdout] # # Totals: pass:85 fail:2 xfail:0 xpass:0 skip:0 error:0
>> 18:56:57 DEBUG| [stdout] not ok 1 selftests: seccomp: seccomp_bpf # exit=1
>> 
>> I did some bisecting and found that the failures started to happen with:
>> 
>>  307d522f5eb8 ("signal/seccomp: Refactor seccomp signal and coredump generation")
>> 
>> Not sure if the test needs to be fixed after this commit, or if the
>> commit is actually introducing an issue. I'll investigate more, unless
>> someone knows already what's going on.
>
> Ah thanks for noticing; I will investigate...

I just did a quick read through of the test and while
I don't understand everything having a failure seems
very weird.

I don't understand the comment:
/* Tracer will redirect getpid to getppid, and we should die. */

As I think what happens is it the bpf programs loads the signal
number.  Tests to see if the signal number if GETPPID and allows
that system call and causes any other system call to be terminated.

Which being single threaded would seem to cause the kernel  to execute
the changed code.

How there kernel at that point is having the process exit with anything
except SIGSYS I am not immediately seeing.

The logic is the same as that for SECCOMP_RET_TRAP is there a test for
that, that is also failing?

How do you run that test anyway?

Eric