[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHsH6Gsaq0678cUZxM80uMaA+G_G6=w9RbD3YGrxG110Fna4ww@mail.gmail.com>
Date: Fri, 31 Jan 2025 11:43:08 -0800
From: Eyal Birger <eyal.birger@...il.com>
To: Kees Cook <kees@...nel.org>
Cc: luto@...capital.net, wad@...omium.org, oleg@...hat.com,
mhiramat@...nel.org, andrii@...nel.org, jolsa@...nel.org,
alexei.starovoitov@...il.com, olsajiri@...il.com, cyphar@...har.com,
songliubraving@...com, yhs@...com, john.fastabend@...il.com,
peterz@...radead.org, tglx@...utronix.de, bp@...en8.de, daniel@...earbox.net,
ast@...nel.org, andrii.nakryiko@...il.com, rostedt@...dmis.org, rafi@....io,
shmulik.ladkani@...il.com, bpf@...r.kernel.org, linux-api@...r.kernel.org,
linux-trace-kernel@...r.kernel.org, x86@...nel.org,
linux-kernel@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH v2] seccomp: passthrough uretprobe systemcall without filtering
Hi Kees,
On Tue, Jan 28, 2025 at 5:41 PM Kees Cook <kees@...nel.org> wrote:
> [...]
> Also please add a KUnit tests to cover this in
> tools/testing/selftests/seccomp/seccomp_bpf.c
> With at least these cases combinations below. Check each of:
>
> - not using uretprobe passes
> - using uretprobe passes (and validates that uretprobe did work)
>
> in each of the following conditions:
>
> - default-allow filter
> - default-block filter
> - filter explicitly blocking __NR_uretprobe and nothing else
> - filter explicitly allowing __NR_uretprobe (and only other
> required syscalls)
In order to validate my understanding of the required test cases,
I've attached a small bash script which validates them.
As expected, the script fails without the suggested change.
If there are gaps in my understanding of the required scope, please
let me know.
I plan to port these test cases to use the kselftests infrastructure as
requested.
To my understanding, the other issues with regards to the proposed patch
are resolved, i.e. there aren't plans to support a 32 bit or mips flavor
of this syscall, and the suggested patch fails closed if they are added.
As such, is it possible to merge the suggested patch so it could be back
merged? I'm suggesting this in the interest of time, as for example Ubuntu
LTS is going to be using kernel 6.11 soon [1] and other distributions
are probably going to as well, and I believe the coding/review process
for the testing code will take a while and probably won't be backmerged
anyway.
Thanks!
Eyal.
[1] https://www.omgubuntu.co.uk/2025/01/ubuntu-24-04-2-release-date
View attachment "u.sh" of type "text/x-sh" (2392 bytes)
Powered by blists - more mailing lists