* Re: [PATCH v7 0/6] introduce PIDFD_SELF* sentinels
From: Lorenzo Stoakes @ 2025-02-01 16:38 UTC (permalink / raw)
To: Christian Brauner
Cc: Andrew Morton, Pedro Falcato, Christian Brauner, Shuah Khan,
Liam R . Howlett, Suren Baghdasaryan, Vlastimil Babka,
linux-kselftest, linux-mm, linux-fsdevel, linux-api, linux-kernel,
Oliver Sang, John Hubbard, Tejun Heo, Johannes Weiner,
Michal Koutny, Shakeel Butt
In-Reply-To: <20250201-cremig-desorientiert-aac3b09da8e2@brauner>
On Sat, Feb 01, 2025 at 12:12:46PM +0100, Christian Brauner wrote:
> > Intent is for Christian to take this in his tree (if he so wishes) to be
> > clear!
>
> If you send me an updated blurb I can fold it.
Thanks, I therefore propose replacing the cover letter blurb with the below:
----8<----
If you wish to utilise a pidfd interface to refer to the current process or
thread then there is a lot of ceremony involved, looking something like:
pid_t pid = getpid();
int pidfd = pidfd_open(pid, PIDFD_THREAD);
if (pidfd < 0) {
... error handling ...
}
if (process_madvise(pidfd, iovec, 8, MADV_GUARD_INSTALL, 0)) {
... cleanup pidfd ...
... error handling ...
}
...
... cleanup pidfd ...
This adds unnecessary overhead + system calls, complicated error handling
and in addition pidfd_open() is subject to RLIMIT_NOFILE (i.e. the limit of
per-process number of open file descriptors), so the call may fail
spuriously on this basis.
Rather than doing this we can make use of sentinels for this purpose which can
be passed as the pidfd instead. This looks like:
if (process_madvise(PIDFD_SELF, iovec, 8, MADV_GUARD_INSTALL, 0)) {
... error handling ...
}
And avoids all of the aforementioned issues. This series introduces such
sentinels.
It is useful to refer to both the current thread from the userland's
perspective for which we use PIDFD_SELF, and the current process from the
userland's perspective, for which we use PIDFD_SELF_PROCESS.
There is unfortunately some confusion between the kernel and userland as to
what constitutes a process - a thread from the userland perspective is a
process in userland, and a userland process is a thread group (more
specifically the thread group leader from the kernel perspective). We
therefore alias things thusly:
* PIDFD_SELF_THREAD aliased by PIDFD_SELF - use PIDTYPE_PID.
* PIDFD_SELF_THREAD_GROUP alised by PIDFD_SELF_PROCESS - use PIDTYPE_TGID.
In all of the kernel code we refer to PIDFD_SELF_THREAD and
PIDFD_SELF_THREAD_GROUP. However we expect users to use PIDFD_SELF and
PIDFD_SELF_PROCESS.
This matters for cases where, for instance, a user unshare()'s FDs or does
thread-specific signal handling and where the user would be hugely confused
if the FDs referenced or signal processed referred to the thread group
leader rather than the individual thread.
For now we only adjust pidfd_get_task() and the pidfd_send_signal() system
call with specific handling for this, implementing this functionality for
process_madvise(), process_mrelease() (albeit, using it here wouldn't
really make sense) and pidfd_send_signal().
We defer making further changes, as this would require a significant rework
of the pidfd mechanism.
The motivating case here is to support PIDFD_SELF in process_madvise(), so
this suffices for immediate uses. Moving forward, this can be further
expanded to other uses.
^ permalink raw reply
* Re: [PATCH v7 0/6] introduce PIDFD_SELF* sentinels
From: Christian Brauner @ 2025-02-01 11:12 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Andrew Morton, Pedro Falcato, Christian Brauner, Shuah Khan,
Liam R . Howlett, Suren Baghdasaryan, Vlastimil Babka,
linux-kselftest, linux-mm, linux-fsdevel, linux-api, linux-kernel,
Oliver Sang, John Hubbard, Tejun Heo, Johannes Weiner,
Michal Koutny, Shakeel Butt
In-Reply-To: <7519b85a-cd04-4ae9-a8c8-3d16fb20582e@lucifer.local>
> Intent is for Christian to take this in his tree (if he so wishes) to be
> clear!
If you send me an updated blurb I can fold it.
^ permalink raw reply
* Re: [PATCH 1/5] Add manpage for open_tree(2)
From: Askar Safin @ 2025-02-01 2:43 UTC (permalink / raw)
To: dhowells
Cc: christian.brauner, linux-api, linux-fsdevel, linux-kernel,
linux-man, viro
In-Reply-To: <159680892602.29015.6551860260436544999.stgit@warthog.procyon.org.uk>
David Howells, ping! You still didn't add all these manpages.
https://lore.kernel.org/linux-man/159680892602.29015.6551860260436544999.stgit@warthog.procyon.org.uk/
^ permalink raw reply
* Re: [PATCH v2] seccomp: passthrough uretprobe systemcall without filtering
From: Eyal Birger @ 2025-01-31 19:43 UTC (permalink / raw)
To: Kees Cook
Cc: luto, wad, oleg, mhiramat, andrii, jolsa, alexei.starovoitov,
olsajiri, cyphar, songliubraving, yhs, john.fastabend, peterz,
tglx, bp, daniel, ast, andrii.nakryiko, rostedt, rafi,
shmulik.ladkani, bpf, linux-api, linux-trace-kernel, x86,
linux-kernel, stable
In-Reply-To: <202501281634.7F398CEA87@keescook>
[-- Attachment #1: Type: text/plain, Size: 1709 bytes --]
Hi Kees,
On Tue, Jan 28, 2025 at 5:41 PM Kees Cook <kees@kernel.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
[-- Attachment #2: u.sh --]
[-- Type: text/x-sh, Size: 2392 bytes --]
#!/bin/bash -e
bt=/usr/bin/bpftrace
default_allow_filter=$(cat << EOF
{
scmp_filter_ctx ctx;
ctx = seccomp_init(SCMP_ACT_ALLOW);
seccomp_load(ctx);
seccomp_release(ctx);
}
EOF
)
default_block_filter=$(cat << EOF
{
scmp_filter_ctx ctx;
ctx = seccomp_init(SCMP_ACT_KILL);
for (int i = 0; i < num_syscalls; i++) {
seccomp_rule_add(ctx, SCMP_ACT_ALLOW,
seccomp_syscall_resolve_name(syscalls[i]), 0);
}
seccomp_load(ctx);
seccomp_release(ctx);
}
EOF
)
allow_uretprobe_filter=$(cat << EOF
{
scmp_filter_ctx ctx;
ctx = seccomp_init(SCMP_ACT_KILL);
for (int i = 0; i < num_syscalls; i++) {
seccomp_rule_add(ctx, SCMP_ACT_ALLOW,
seccomp_syscall_resolve_name(syscalls[i]), 0);
}
seccomp_rule_add(ctx, SCMP_ACT_ALLOW, 335, 0);
seccomp_load(ctx);
seccomp_release(ctx);
}
EOF
)
block_uretprobe_filter=$(cat << EOF
{
scmp_filter_ctx ctx;
ctx = seccomp_init(SCMP_ACT_ALLOW);
seccomp_rule_add(ctx, SCMP_ACT_KILL, 335, 0);
seccomp_load(ctx);
seccomp_release(ctx);
}
EOF
)
t()
{
with_uretprobe=$1;
filter_name=$2;
filter=${!filter_name};
echo "Test: uretprobe $with_uretprobe, filter $filter_name"
cat > /tmp/x.c << EOF
#include <stdio.h>
#include <seccomp.h>
char *syscalls[] = {
"exit_group",
};
__attribute__((noinline)) int probed(void)
{
return 1;
}
void apply_seccomp_filter(char **syscalls, int num_syscalls)
$filter
int main(int argc, char *argv[])
{
int num_syscalls = sizeof(syscalls) / sizeof(syscalls[0]);
apply_seccomp_filter(syscalls, num_syscalls);
probed();
return 0;
}
EOF
cat > /tmp/trace.bt << EOF
uretprobe:/tmp/x:probed
{
printf("ret=%d\n", retval);
}
EOF
gcc -o /tmp/x /tmp/x.c -lseccomp
$with_uretprobe && {
$bt /tmp/trace.bt &
btpid=$!
sleep 5 # wait for uretprobe attach
}
/tmp/x
$with_uretprobe && kill $btpid
rm /tmp/x /tmp/x.c /tmp/trace.bt
}
t false "default_allow_filter"
t true "default_allow_filter"
t false "default_block_filter"
t true "default_block_filter"
t false "allow_uretprobe_filter"
t true "allow_uretprobe_filter"
t false "block_uretprobe_filter"
t true "block_uretprobe_filter"
^ permalink raw reply
* Re: [PATCH v7 0/6] introduce PIDFD_SELF* sentinels
From: Lorenzo Stoakes @ 2025-01-31 10:21 UTC (permalink / raw)
To: Andrew Morton
Cc: Pedro Falcato, Christian Brauner, Shuah Khan, Liam R . Howlett,
Suren Baghdasaryan, Vlastimil Babka, linux-kselftest, linux-mm,
linux-fsdevel, linux-api, linux-kernel, Oliver Sang, John Hubbard,
Tejun Heo, Johannes Weiner, Michal Koutny, Shakeel Butt
In-Reply-To: <20250130153236.198664b9a19ccfcdb24f888b@linux-foundation.org>
On Thu, Jan 30, 2025 at 03:32:36PM -0800, Andrew Morton wrote:
> On Thu, 30 Jan 2025 23:10:53 +0000 Pedro Falcato <pedro.falcato@gmail.com> wrote:
>
> > On Thu, Jan 30, 2025 at 10:53 PM Lorenzo Stoakes
> > <lorenzo.stoakes@oracle.com> wrote:
> > >
> > > > The above code sequence doesn't seem at all onerous. I'm not
> > > > understanding why it's worth altering the kernel to permit this little
> > > > shortcut?
> > >
> > > In practice it adds quite a bit of overhead for something that whatever
> > > mechanism is using the pidfd can avoid.
> > >
> > > It was specifically intended for a real case of utilising
> > > process_madvise(), using the newly extended ability to batch _any_
> > > madvise() operations for the current process, like:
> > >
> > > if (process_madvise(PIDFD_SELF, iovec, 10, MADV_GUARD_INSTALL, 0)) {
> > > ... error handling ...
> > > }
> > >
> > > vs.
> > >
> > > pid_t pid = getpid();
> > > int pidfd = pidfd_open(pid, PIDFD_THREAD);
> > >
> > > if (pidfd < 0) {
> > > ... error handling ...
> > > }
> > >
> > > if (process_madvise(PIDFD_SELF, iovec, 10, MADV_GUARD_INSTALL, 0)) {
> > > ... cleanup pidfd ...
> > > ... error handling ...
> > > }
> > >
> > > ...
> > >
> > > ... cleanup pidfd ...
> > >
> > > So in practice, it's actually a lot more ceremony and noise. Suren has been
> > > working with this code in practice and found this to be useful.
> >
> > It's also nice to add that people on the libc/allocator side should
> > also appreciate skipping pidfd_open's reliability concerns (mostly,
> > that RLIMIT_NOFILE Should Not(tm) ever affect thread spawning or a
> > malloc[1]). Besides the big syscall reduction and nice speedup, that
> > is.
> >
> > [1] whether this is the already case is an exercise left to the
> > reader, but at the very least we should not add onto existing problems
>
> Thanks.
>
> Could we please get all the above spelled out much more thoroughly in
> the [0/n] description (aka Patch Series Sales Brochure)?
Ack, will expand if there's a respin, or Christian - perhaps you could fold
the above explanation into the cover letter?
Intent is for Christian to take this in his tree (if he so wishes) to be
clear!
Cheers
^ permalink raw reply
* Re: [PATCH v7 0/6] introduce PIDFD_SELF* sentinels
From: Andrew Morton @ 2025-01-30 23:32 UTC (permalink / raw)
To: Pedro Falcato
Cc: Lorenzo Stoakes, Christian Brauner, Shuah Khan, Liam R . Howlett,
Suren Baghdasaryan, Vlastimil Babka, linux-kselftest, linux-mm,
linux-fsdevel, linux-api, linux-kernel, Oliver Sang, John Hubbard,
Tejun Heo, Johannes Weiner, Michal Koutny, Shakeel Butt
In-Reply-To: <CAKbZUD3w4_4MjrME-0mgRL01eFggb7et2BLa6012tzQX78KK9w@mail.gmail.com>
On Thu, 30 Jan 2025 23:10:53 +0000 Pedro Falcato <pedro.falcato@gmail.com> wrote:
> On Thu, Jan 30, 2025 at 10:53 PM Lorenzo Stoakes
> <lorenzo.stoakes@oracle.com> wrote:
> >
> > > The above code sequence doesn't seem at all onerous. I'm not
> > > understanding why it's worth altering the kernel to permit this little
> > > shortcut?
> >
> > In practice it adds quite a bit of overhead for something that whatever
> > mechanism is using the pidfd can avoid.
> >
> > It was specifically intended for a real case of utilising
> > process_madvise(), using the newly extended ability to batch _any_
> > madvise() operations for the current process, like:
> >
> > if (process_madvise(PIDFD_SELF, iovec, 10, MADV_GUARD_INSTALL, 0)) {
> > ... error handling ...
> > }
> >
> > vs.
> >
> > pid_t pid = getpid();
> > int pidfd = pidfd_open(pid, PIDFD_THREAD);
> >
> > if (pidfd < 0) {
> > ... error handling ...
> > }
> >
> > if (process_madvise(PIDFD_SELF, iovec, 10, MADV_GUARD_INSTALL, 0)) {
> > ... cleanup pidfd ...
> > ... error handling ...
> > }
> >
> > ...
> >
> > ... cleanup pidfd ...
> >
> > So in practice, it's actually a lot more ceremony and noise. Suren has been
> > working with this code in practice and found this to be useful.
>
> It's also nice to add that people on the libc/allocator side should
> also appreciate skipping pidfd_open's reliability concerns (mostly,
> that RLIMIT_NOFILE Should Not(tm) ever affect thread spawning or a
> malloc[1]). Besides the big syscall reduction and nice speedup, that
> is.
>
> [1] whether this is the already case is an exercise left to the
> reader, but at the very least we should not add onto existing problems
Thanks.
Could we please get all the above spelled out much more thoroughly in
the [0/n] description (aka Patch Series Sales Brochure)?
^ permalink raw reply
* Re: [PATCH v7 0/6] introduce PIDFD_SELF* sentinels
From: Pedro Falcato @ 2025-01-30 23:10 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Andrew Morton, Christian Brauner, Shuah Khan, Liam R . Howlett,
Suren Baghdasaryan, Vlastimil Babka, linux-kselftest, linux-mm,
linux-fsdevel, linux-api, linux-kernel, Oliver Sang, John Hubbard,
Tejun Heo, Johannes Weiner, Michal Koutny, Shakeel Butt
In-Reply-To: <b396487f-b906-410d-9ff4-6956d99e2771@lucifer.local>
On Thu, Jan 30, 2025 at 10:53 PM Lorenzo Stoakes
<lorenzo.stoakes@oracle.com> wrote:
>
> On Thu, Jan 30, 2025 at 02:37:54PM -0800, Andrew Morton wrote:
> > On Thu, 30 Jan 2025 20:40:25 +0000 Lorenzo Stoakes <lorenzo.stoakes@oracle.com> wrote:
> >
> > > If you wish to utilise a pidfd interface to refer to the current process or
> > > thread it is rather cumbersome, requiring something like:
> > >
> > > int pidfd = pidfd_open(getpid(), 0 or PIDFD_THREAD);
> > >
> > > ...
> > >
> > > close(pidfd);
> > >
> > > Or the equivalent call opening /proc/self. It is more convenient to use a
> > > sentinel value to indicate to an interface that accepts a pidfd that we
> > > simply wish to refer to the current process thread.
> > >
> >
> > The above code sequence doesn't seem at all onerous. I'm not
> > understanding why it's worth altering the kernel to permit this little
> > shortcut?
>
> In practice it adds quite a bit of overhead for something that whatever
> mechanism is using the pidfd can avoid.
>
> It was specifically intended for a real case of utilising
> process_madvise(), using the newly extended ability to batch _any_
> madvise() operations for the current process, like:
>
> if (process_madvise(PIDFD_SELF, iovec, 10, MADV_GUARD_INSTALL, 0)) {
> ... error handling ...
> }
>
> vs.
>
> pid_t pid = getpid();
> int pidfd = pidfd_open(pid, PIDFD_THREAD);
>
> if (pidfd < 0) {
> ... error handling ...
> }
>
> if (process_madvise(PIDFD_SELF, iovec, 10, MADV_GUARD_INSTALL, 0)) {
> ... cleanup pidfd ...
> ... error handling ...
> }
>
> ...
>
> ... cleanup pidfd ...
>
> So in practice, it's actually a lot more ceremony and noise. Suren has been
> working with this code in practice and found this to be useful.
It's also nice to add that people on the libc/allocator side should
also appreciate skipping pidfd_open's reliability concerns (mostly,
that RLIMIT_NOFILE Should Not(tm) ever affect thread spawning or a
malloc[1]). Besides the big syscall reduction and nice speedup, that
is.
[1] whether this is the already case is an exercise left to the
reader, but at the very least we should not add onto existing problems
--
Pedro
^ permalink raw reply
* Re: [PATCH v7 0/6] introduce PIDFD_SELF* sentinels
From: Lorenzo Stoakes @ 2025-01-30 22:53 UTC (permalink / raw)
To: Andrew Morton
Cc: Christian Brauner, Shuah Khan, Liam R . Howlett,
Suren Baghdasaryan, Vlastimil Babka, pedro.falcato,
linux-kselftest, linux-mm, linux-fsdevel, linux-api, linux-kernel,
Oliver Sang, John Hubbard, Tejun Heo, Johannes Weiner,
Michal Koutny, Shakeel Butt
In-Reply-To: <20250130143754.1b8bb87bfb15175dd434529b@linux-foundation.org>
On Thu, Jan 30, 2025 at 02:37:54PM -0800, Andrew Morton wrote:
> On Thu, 30 Jan 2025 20:40:25 +0000 Lorenzo Stoakes <lorenzo.stoakes@oracle.com> wrote:
>
> > If you wish to utilise a pidfd interface to refer to the current process or
> > thread it is rather cumbersome, requiring something like:
> >
> > int pidfd = pidfd_open(getpid(), 0 or PIDFD_THREAD);
> >
> > ...
> >
> > close(pidfd);
> >
> > Or the equivalent call opening /proc/self. It is more convenient to use a
> > sentinel value to indicate to an interface that accepts a pidfd that we
> > simply wish to refer to the current process thread.
> >
>
> The above code sequence doesn't seem at all onerous. I'm not
> understanding why it's worth altering the kernel to permit this little
> shortcut?
In practice it adds quite a bit of overhead for something that whatever
mechanism is using the pidfd can avoid.
It was specifically intended for a real case of utilising
process_madvise(), using the newly extended ability to batch _any_
madvise() operations for the current process, like:
if (process_madvise(PIDFD_SELF, iovec, 10, MADV_GUARD_INSTALL, 0)) {
... error handling ...
}
vs.
pid_t pid = getpid();
int pidfd = pidfd_open(pid, PIDFD_THREAD);
if (pidfd < 0) {
... error handling ...
}
if (process_madvise(PIDFD_SELF, iovec, 10, MADV_GUARD_INSTALL, 0)) {
... cleanup pidfd ...
... error handling ...
}
...
... cleanup pidfd ...
So in practice, it's actually a lot more ceremony and noise. Suren has been
working with this code in practice and found this to be useful.
The suggestion to embed it as PIDFD_SELF rather than to pass it as a
process_madvise() flag was made on the original series where I extended its
functionality.
So in practice I think it's onerous enough to justify this, plus it allows
for a more fluent use of pidfd's in other cases where one is referring to
the same process/thread, to the extent that I've seen people commenting on
supporting it while sending series relating to pidfd.
Also Christian and others appear to support this idea.
^ permalink raw reply
* Re: [PATCH v7 0/6] introduce PIDFD_SELF* sentinels
From: Andrew Morton @ 2025-01-30 22:37 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Christian Brauner, Shuah Khan, Liam R . Howlett,
Suren Baghdasaryan, Vlastimil Babka, pedro.falcato,
linux-kselftest, linux-mm, linux-fsdevel, linux-api, linux-kernel,
Oliver Sang, John Hubbard, Tejun Heo, Johannes Weiner,
Michal Koutny, Shakeel Butt
In-Reply-To: <cover.1738268370.git.lorenzo.stoakes@oracle.com>
On Thu, 30 Jan 2025 20:40:25 +0000 Lorenzo Stoakes <lorenzo.stoakes@oracle.com> wrote:
> If you wish to utilise a pidfd interface to refer to the current process or
> thread it is rather cumbersome, requiring something like:
>
> int pidfd = pidfd_open(getpid(), 0 or PIDFD_THREAD);
>
> ...
>
> close(pidfd);
>
> Or the equivalent call opening /proc/self. It is more convenient to use a
> sentinel value to indicate to an interface that accepts a pidfd that we
> simply wish to refer to the current process thread.
>
The above code sequence doesn't seem at all onerous. I'm not
understanding why it's worth altering the kernel to permit this little
shortcut?
^ permalink raw reply
* Re: [PATCH v2] seccomp: passthrough uretprobe systemcall without filtering
From: Jiri Olsa @ 2025-01-30 21:53 UTC (permalink / raw)
To: Eyal Birger
Cc: Jiri Olsa, Kees Cook, luto, wad, oleg, mhiramat, andrii,
alexei.starovoitov, cyphar, songliubraving, yhs, john.fastabend,
peterz, tglx, bp, daniel, ast, andrii.nakryiko, rostedt, rafi,
shmulik.ladkani, bpf, linux-api, linux-trace-kernel, x86,
linux-kernel, stable
In-Reply-To: <CAHsH6GvsGbZ4a=-oSpD1j8jx11T=Y4SysAtkzAu+H4_Gh7v3Qg@mail.gmail.com>
On Thu, Jan 30, 2025 at 07:05:42AM -0800, Eyal Birger wrote:
> On Thu, Jan 30, 2025 at 12:24 AM Jiri Olsa <olsajiri@gmail.com> wrote:
> >
> > On Wed, Jan 29, 2025 at 09:27:49AM -0800, Eyal Birger wrote:
> > > Hi,
> > >
> > > Thanks for the review!
> > >
> > > On Tue, Jan 28, 2025 at 5:41 PM Kees Cook <kees@kernel.org> wrote:
> > > >
> > > > On Tue, Jan 28, 2025 at 06:58:06AM -0800, Eyal Birger wrote:
> > > > > Note: uretprobe isn't supported in i386 and __NR_ia32_rt_tgsigqueueinfo
> > > > > uses the same number as __NR_uretprobe so the syscall isn't forced in the
> > > > > compat bitmap.
> > > >
> > > > So a 64-bit tracer cannot use uretprobe on a 32-bit process? Also is
> > > > uretprobe strictly an x86_64 feature?
> > > >
> > >
> > > My understanding is that they'd be able to do so, but use the int3 trap
> > > instead of the uretprobe syscall.
> > >
> > > > > [...]
> > > > > diff --git a/kernel/seccomp.c b/kernel/seccomp.c
> > > > > index 385d48293a5f..23b594a68bc0 100644
> > > > > --- a/kernel/seccomp.c
> > > > > +++ b/kernel/seccomp.c
> > > > > @@ -734,13 +734,13 @@ seccomp_prepare_user_filter(const char __user *user_filter)
> > > > >
> > > > > #ifdef SECCOMP_ARCH_NATIVE
> > > > > /**
> > > > > - * seccomp_is_const_allow - check if filter is constant allow with given data
> > > > > + * seccomp_is_filter_const_allow - check if filter is constant allow with given data
> > > > > * @fprog: The BPF programs
> > > > > * @sd: The seccomp data to check against, only syscall number and arch
> > > > > * number are considered constant.
> > > > > */
> > > > > -static bool seccomp_is_const_allow(struct sock_fprog_kern *fprog,
> > > > > - struct seccomp_data *sd)
> > > > > +static bool seccomp_is_filter_const_allow(struct sock_fprog_kern *fprog,
> > > > > + struct seccomp_data *sd)
> > > > > {
> > > > > unsigned int reg_value = 0;
> > > > > unsigned int pc;
> > > > > @@ -812,6 +812,21 @@ static bool seccomp_is_const_allow(struct sock_fprog_kern *fprog,
> > > > > return false;
> > > > > }
> > > > >
> > > > > +static bool seccomp_is_const_allow(struct sock_fprog_kern *fprog,
> > > > > + struct seccomp_data *sd)
> > > > > +{
> > > > > +#ifdef __NR_uretprobe
> > > > > + if (sd->nr == __NR_uretprobe
> > > > > +#ifdef SECCOMP_ARCH_COMPAT
> > > > > + && sd->arch != SECCOMP_ARCH_COMPAT
> > > > > +#endif
> > > >
> > > > I don't like this because it's not future-proof enough. __NR_uretprobe
> > > > may collide with other syscalls at some point.
> > >
> > > I'm not sure I got this point.
> > >
> > > > And if __NR_uretprobe_32
> > > > is ever implemented, the seccomp logic will be missing. I think this
> > > > will work now and in the future:
> > > >
> > > > #ifdef __NR_uretprobe
> > > > # ifdef SECCOMP_ARCH_COMPAT
> > > > if (sd->arch == SECCOMP_ARCH_COMPAT) {
> > > > # ifdef __NR_uretprobe_32
> > > > if (sd->nr == __NR_uretprobe_32)
> > > > return true;
> > > > # endif
> > > > } else
> > > > # endif
> > > > if (sd->nr == __NR_uretprobe)
> > > > return true;
> > > > #endif
> > >
> > > I don't know if implementing uretprobe syscall for compat binaries is
> > > planned or makes sense - I'd appreciate Jiri's and others opinion on that.
> > > That said, I don't mind adding this code for the sake of future proofing.
> >
> > as Andrii wrote in the other email ATM it's just strictly x86_64,
> > but let's future proof it
>
> Thank you. So I'm ok with using the suggestion above, but more on this below.
>
> >
> > AFAIK there was an attempt to do similar on arm but it did not show
> > any speed up
> >
> > >
> > > >
> > > > Instead of doing a function rename dance, I think you can just stick
> > > > the above into seccomp_is_const_allow() after the WARN().
> > >
> > > My motivation for the renaming dance was that you mentioned we might add
> > > new syscalls to this as well, so I wanted to avoid cluttering the existing
> > > function which seems to be well defined.
> > >
> > > >
> > > > Also please add a KUnit tests to cover this in
> > > > tools/testing/selftests/seccomp/seccomp_bpf.c
> > >
> > > I think this would mean that this test suite would need to run as
> > > privileged. Is that Ok? or maybe it'd be better to have a new suite?
> > >
> > > > 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)
> > >
> > > Ok.
> >
> > please let me know if I can help in any way with tests
>
> Thanks! Is there a way to partition this work? I'd appreciate the help
> if we can find some way of doing so.
sure, I'll check the seccomp selftests and let you know
>
> >
> > >
> > > >
> > > > Hm, is uretprobe expected to work on mips? Because if so, you'll need to
> > > > do something similar to the mode1 checking in the !SECCOMP_ARCH_NATIVE
> > > > version of seccomp_cache_check_allow().
> > >
> > > I don't know if uretprobe syscall is expected to run on mips. Personally
> > > I'd avoid adding this dead code.
>
> Jiri, what is your take on this one?
uretprobe syscall is not expected to work on mips, atm it's strictly x86_64
jirka
^ permalink raw reply
* [PATCH v7 6/6] selftests/mm: use PIDFD_SELF in guard pages test
From: Lorenzo Stoakes @ 2025-01-30 20:40 UTC (permalink / raw)
To: Christian Brauner
Cc: Shuah Khan, Liam R . Howlett, Suren Baghdasaryan, Vlastimil Babka,
pedro.falcato, linux-kselftest, linux-mm, linux-fsdevel,
linux-api, linux-kernel, Oliver Sang, John Hubbard, Tejun Heo,
Johannes Weiner, Michal Koutny, Andrew Morton, Shakeel Butt
In-Reply-To: <cover.1738268370.git.lorenzo.stoakes@oracle.com>
Now we have PIDFD_SELF available for process_madvise(), make use of it in
the guard pages test.
This is both more convenient and asserts that PIDFD_SELF works as expected.
Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
---
tools/testing/selftests/mm/Makefile | 4 ++++
tools/testing/selftests/mm/guard-pages.c | 15 +++------------
2 files changed, 7 insertions(+), 12 deletions(-)
diff --git a/tools/testing/selftests/mm/Makefile b/tools/testing/selftests/mm/Makefile
index 63ce39d024bb..ecc4252fa3fe 100644
--- a/tools/testing/selftests/mm/Makefile
+++ b/tools/testing/selftests/mm/Makefile
@@ -225,6 +225,10 @@ $(OUTPUT)/ksm_tests: LDLIBS += -lnuma
$(OUTPUT)/migration: LDLIBS += -lnuma
+# We need uapi/pdifd.h but need to work around broken linux/fcntl.h, so
+# explicitly import
+$(OUTPUT)/guard-pages: CFLAGS += -I $(top_srcdir)/tools/include
+
local_config.mk local_config.h: check_config.sh
/bin/sh ./check_config.sh $(CC)
diff --git a/tools/testing/selftests/mm/guard-pages.c b/tools/testing/selftests/mm/guard-pages.c
index ece37212a8a2..549653724661 100644
--- a/tools/testing/selftests/mm/guard-pages.c
+++ b/tools/testing/selftests/mm/guard-pages.c
@@ -18,6 +18,7 @@
#include <sys/syscall.h>
#include <sys/uio.h>
#include <unistd.h>
+#include <linux/pidfd.h>
/*
* Ignore the checkpatch warning, as per the C99 standard, section 7.14.1.1:
@@ -50,11 +51,6 @@ static void handle_fatal(int c)
siglongjmp(signal_jmp_buf, c);
}
-static int pidfd_open(pid_t pid, unsigned int flags)
-{
- return syscall(SYS_pidfd_open, pid, flags);
-}
-
static ssize_t sys_process_madvise(int pidfd, const struct iovec *iovec,
size_t n, int advice, unsigned int flags)
{
@@ -370,14 +366,10 @@ TEST_F(guard_pages, multi_vma)
TEST_F(guard_pages, process_madvise)
{
const unsigned long page_size = self->page_size;
- pid_t pid = getpid();
- int pidfd = pidfd_open(pid, 0);
char *ptr_region, *ptr1, *ptr2, *ptr3;
ssize_t count;
struct iovec vec[6];
- ASSERT_NE(pidfd, -1);
-
/* Reserve region to map over. */
ptr_region = mmap(NULL, 100 * page_size, PROT_NONE,
MAP_ANON | MAP_PRIVATE, -1, 0);
@@ -425,7 +417,7 @@ TEST_F(guard_pages, process_madvise)
ASSERT_EQ(munmap(&ptr_region[99 * page_size], page_size), 0);
/* Now guard in one step. */
- count = sys_process_madvise(pidfd, vec, 6, MADV_GUARD_INSTALL, 0);
+ count = sys_process_madvise(PIDFD_SELF, vec, 6, MADV_GUARD_INSTALL, 0);
/* OK we don't have permission to do this, skip. */
if (count == -1 && errno == EPERM)
@@ -446,7 +438,7 @@ TEST_F(guard_pages, process_madvise)
ASSERT_FALSE(try_read_write_buf(&ptr3[19 * page_size]));
/* Now do the same with unguard... */
- count = sys_process_madvise(pidfd, vec, 6, MADV_GUARD_REMOVE, 0);
+ count = sys_process_madvise(PIDFD_SELF, vec, 6, MADV_GUARD_REMOVE, 0);
/* ...and everything should now succeed. */
@@ -463,7 +455,6 @@ TEST_F(guard_pages, process_madvise)
ASSERT_EQ(munmap(ptr1, 10 * page_size), 0);
ASSERT_EQ(munmap(ptr2, 5 * page_size), 0);
ASSERT_EQ(munmap(ptr3, 20 * page_size), 0);
- close(pidfd);
}
/* Assert that unmapping ranges does not leave guard markers behind. */
--
2.48.1
^ permalink raw reply related
* [PATCH v7 5/6] selftests: pidfd: add tests for PIDFD_SELF_*
From: Lorenzo Stoakes @ 2025-01-30 20:40 UTC (permalink / raw)
To: Christian Brauner
Cc: Shuah Khan, Liam R . Howlett, Suren Baghdasaryan, Vlastimil Babka,
pedro.falcato, linux-kselftest, linux-mm, linux-fsdevel,
linux-api, linux-kernel, Oliver Sang, John Hubbard, Tejun Heo,
Johannes Weiner, Michal Koutny, Andrew Morton, Shakeel Butt
In-Reply-To: <cover.1738268370.git.lorenzo.stoakes@oracle.com>
Add tests to assert that PIDFD_SELF* correctly refers to the current
thread and process.
We explicitly test pidfd_send_signal(), however We defer testing of
mm-specific functionality which uses pidfd, namely process_madvise() and
process_mrelease() to mm testing (though note the latter can not be
sensibly tested as it would require the testing process to be dying).
We also correct the pidfd_open_test.c fields which refer to .request_mask
whereas the UAPI header refers to .mask, which otherwise break the import
of the UAPI header.
Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
---
tools/testing/selftests/pidfd/pidfd.h | 2 +
.../testing/selftests/pidfd/pidfd_open_test.c | 6 +-
tools/testing/selftests/pidfd/pidfd_test.c | 76 ++++++++++++++++---
3 files changed, 69 insertions(+), 15 deletions(-)
diff --git a/tools/testing/selftests/pidfd/pidfd.h b/tools/testing/selftests/pidfd/pidfd.h
index d02cfc5ef77b..cc684d872253 100644
--- a/tools/testing/selftests/pidfd/pidfd.h
+++ b/tools/testing/selftests/pidfd/pidfd.h
@@ -15,6 +15,8 @@
#include <sys/types.h>
#include <sys/wait.h>
+#include <linux/pidfd.h>
+
#include "../kselftest.h"
#include "../clone3/clone3_selftests.h"
#include "pidfd_helpers.h"
diff --git a/tools/testing/selftests/pidfd/pidfd_open_test.c b/tools/testing/selftests/pidfd/pidfd_open_test.c
index ce413a221bac..9a40ccb1ff6d 100644
--- a/tools/testing/selftests/pidfd/pidfd_open_test.c
+++ b/tools/testing/selftests/pidfd/pidfd_open_test.c
@@ -31,7 +31,7 @@
#define PIDFD_INFO_CGROUPID (1UL << 0)
struct pidfd_info {
- __u64 request_mask;
+ __u64 mask;
__u64 cgroupid;
__u32 pid;
__u32 tgid;
@@ -148,7 +148,7 @@ static pid_t get_pid_from_fdinfo_file(int pidfd, const char *key, size_t keylen)
int main(int argc, char **argv)
{
struct pidfd_info info = {
- .request_mask = PIDFD_INFO_CGROUPID,
+ .mask = PIDFD_INFO_CGROUPID,
};
int pidfd = -1, ret = 1;
pid_t pid;
@@ -227,7 +227,7 @@ int main(int argc, char **argv)
getegid(), info.sgid);
goto on_error;
}
- if ((info.request_mask & PIDFD_INFO_CGROUPID) && info.cgroupid == 0) {
+ if ((info.mask & PIDFD_INFO_CGROUPID) && info.cgroupid == 0) {
ksft_print_msg("cgroupid should not be 0 when PIDFD_INFO_CGROUPID is set\n");
goto on_error;
}
diff --git a/tools/testing/selftests/pidfd/pidfd_test.c b/tools/testing/selftests/pidfd/pidfd_test.c
index e9728e86b4f2..fcd85cad9f18 100644
--- a/tools/testing/selftests/pidfd/pidfd_test.c
+++ b/tools/testing/selftests/pidfd/pidfd_test.c
@@ -42,12 +42,41 @@ static pid_t pidfd_clone(int flags, int *pidfd, int (*fn)(void *))
#endif
}
-static int signal_received;
+static pthread_t signal_received;
static void set_signal_received_on_sigusr1(int sig)
{
if (sig == SIGUSR1)
- signal_received = 1;
+ signal_received = pthread_self();
+}
+
+static int send_signal(int pidfd)
+{
+ int ret = 0;
+
+ if (sys_pidfd_send_signal(pidfd, SIGUSR1, NULL, 0) < 0) {
+ ret = -EINVAL;
+ goto exit;
+ }
+
+ if (signal_received != pthread_self()) {
+ ret = -EINVAL;
+ goto exit;
+ }
+
+exit:
+ signal_received = 0;
+ return ret;
+}
+
+static void *send_signal_worker(void *arg)
+{
+ int pidfd = (int)(intptr_t)arg;
+ int ret;
+
+ /* We forward any errors for the caller to handle. */
+ ret = send_signal(pidfd);
+ return (void *)(intptr_t)ret;
}
/*
@@ -56,8 +85,11 @@ static void set_signal_received_on_sigusr1(int sig)
*/
static int test_pidfd_send_signal_simple_success(void)
{
- int pidfd, ret;
+ int pidfd;
const char *test_name = "pidfd_send_signal send SIGUSR1";
+ pthread_t thread;
+ void *thread_res;
+ int err;
if (!have_pidfd_send_signal) {
ksft_test_result_skip(
@@ -66,25 +98,45 @@ static int test_pidfd_send_signal_simple_success(void)
return 0;
}
+ signal(SIGUSR1, set_signal_received_on_sigusr1);
+
+ /* Try sending a signal to ourselves via /proc/self. */
pidfd = open("/proc/self", O_DIRECTORY | O_CLOEXEC);
if (pidfd < 0)
ksft_exit_fail_msg(
"%s test: Failed to open process file descriptor\n",
test_name);
+ err = send_signal(pidfd);
+ if (err)
+ ksft_exit_fail_msg(
+ "%s test: Error %d on sending pidfd signal\n",
+ test_name, err);
+ close(pidfd);
- signal(SIGUSR1, set_signal_received_on_sigusr1);
+ /* Now try the same thing only using PIDFD_SELF_THREAD_GROUP. */
+ err = send_signal(PIDFD_SELF_THREAD_GROUP);
+ if (err)
+ ksft_exit_fail_msg(
+ "%s test: Error %d on PIDFD_SELF_THREAD_GROUP signal\n",
+ test_name, err);
- ret = sys_pidfd_send_signal(pidfd, SIGUSR1, NULL, 0);
- close(pidfd);
- if (ret < 0)
- ksft_exit_fail_msg("%s test: Failed to send signal\n",
+ /*
+ * Now try the same thing in a thread and assert thread ID is equal to
+ * worker thread ID.
+ */
+ if (pthread_create(&thread, NULL, send_signal_worker,
+ (void *)(intptr_t)PIDFD_SELF_THREAD))
+ ksft_exit_fail_msg("%s test: Failed to create thread\n",
test_name);
-
- if (signal_received != 1)
- ksft_exit_fail_msg("%s test: Failed to receive signal\n",
+ if (pthread_join(thread, &thread_res))
+ ksft_exit_fail_msg("%s test: Failed to join thread\n",
test_name);
+ err = (int)(intptr_t)thread_res;
+ if (err)
+ ksft_exit_fail_msg(
+ "%s test: Error %d on PIDFD_SELF_THREAD signal\n",
+ test_name, err);
- signal_received = 0;
ksft_test_result_pass("%s test: Sent signal\n", test_name);
return 0;
}
--
2.48.1
^ permalink raw reply related
* [PATCH v7 4/6] selftests: pidfd: add pidfd.h UAPI wrapper
From: Lorenzo Stoakes @ 2025-01-30 20:40 UTC (permalink / raw)
To: Christian Brauner
Cc: Shuah Khan, Liam R . Howlett, Suren Baghdasaryan, Vlastimil Babka,
pedro.falcato, linux-kselftest, linux-mm, linux-fsdevel,
linux-api, linux-kernel, Oliver Sang, John Hubbard, Tejun Heo,
Johannes Weiner, Michal Koutny, Andrew Morton, Shakeel Butt
In-Reply-To: <cover.1738268370.git.lorenzo.stoakes@oracle.com>
Conflicts can arise between system fcntl.h and linux/fcntl.h, imported by
the linux/pidfd.h UAPI header.
Work around this by adding a wrapper for linux/pidfd.h to
tools/include/ which sets the linux/fcntl.h header guard ahead of
importing the pidfd.h header file.
Adjust the pidfd selftests Makefile to reference this include directory and
put it at a higher precidence than any make header installed headers to
ensure the wrapper is preferred.
This way we can directly import the UAPI header file without issue, use the
latest system header file without having to duplicate anything.
Reviewed-by: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
---
tools/include/linux/pidfd.h | 14 ++++++++++++++
tools/testing/selftests/pidfd/Makefile | 3 +--
2 files changed, 15 insertions(+), 2 deletions(-)
create mode 100644 tools/include/linux/pidfd.h
diff --git a/tools/include/linux/pidfd.h b/tools/include/linux/pidfd.h
new file mode 100644
index 000000000000..113c8023072d
--- /dev/null
+++ b/tools/include/linux/pidfd.h
@@ -0,0 +1,14 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#ifndef _TOOLS_LINUX_PIDFD_H
+#define _TOOLS_LINUX_PIDFD_H
+
+/*
+ * Some systems have issues with the linux/fcntl.h import in linux/pidfd.h, so
+ * work around this by setting the header guard.
+ */
+#define _LINUX_FCNTL_H
+#include "../../../include/uapi/linux/pidfd.h"
+#undef _LINUX_FCNTL_H
+
+#endif /* _TOOLS_LINUX_PIDFD_H */
diff --git a/tools/testing/selftests/pidfd/Makefile b/tools/testing/selftests/pidfd/Makefile
index 301343a11b62..5363d5ab27a4 100644
--- a/tools/testing/selftests/pidfd/Makefile
+++ b/tools/testing/selftests/pidfd/Makefile
@@ -1,9 +1,8 @@
# SPDX-License-Identifier: GPL-2.0-only
-CFLAGS += -g $(KHDR_INCLUDES) -pthread -Wall
+CFLAGS += -g -isystem $(top_srcdir)/tools/include $(KHDR_INCLUDES) -pthread -Wall
TEST_GEN_PROGS := pidfd_test pidfd_fdinfo_test pidfd_open_test \
pidfd_poll_test pidfd_wait pidfd_getfd_test pidfd_setns_test \
pidfd_file_handle_test pidfd_bind_mount
include ../lib.mk
-
--
2.48.1
^ permalink raw reply related
* [PATCH v7 0/6] introduce PIDFD_SELF* sentinels
From: Lorenzo Stoakes @ 2025-01-30 20:40 UTC (permalink / raw)
To: Christian Brauner
Cc: Shuah Khan, Liam R . Howlett, Suren Baghdasaryan, Vlastimil Babka,
pedro.falcato, linux-kselftest, linux-mm, linux-fsdevel,
linux-api, linux-kernel, Oliver Sang, John Hubbard, Tejun Heo,
Johannes Weiner, Michal Koutny, Andrew Morton, Shakeel Butt
If you wish to utilise a pidfd interface to refer to the current process or
thread it is rather cumbersome, requiring something like:
int pidfd = pidfd_open(getpid(), 0 or PIDFD_THREAD);
...
close(pidfd);
Or the equivalent call opening /proc/self. It is more convenient to use a
sentinel value to indicate to an interface that accepts a pidfd that we
simply wish to refer to the current process thread.
This series introduces sentinels for this purposes which can be passed as
the pidfd in this instance rather than having to establish a dummy fd for
this purpose.
It is useful to refer to both the current thread from the userland's
perspective for which we use PIDFD_SELF, and the current process from the
userland's perspective, for which we use PIDFD_SELF_PROCESS.
There is unfortunately some confusion between the kernel and userland as to
what constitutes a process - a thread from the userland perspective is a
process in userland, and a userland process is a thread group (more
specifically the thread group leader from the kernel perspective). We
therefore alias things thusly:
* PIDFD_SELF_THREAD aliased by PIDFD_SELF - use PIDTYPE_PID.
* PIDFD_SELF_THREAD_GROUP alised by PIDFD_SELF_PROCESS - use PIDTYPE_TGID.
In all of the kernel code we refer to PIDFD_SELF_THREAD and
PIDFD_SELF_THREAD_GROUP. However we expect users to use PIDFD_SELF and
PIDFD_SELF_PROCESS.
This matters for cases where, for instance, a user unshare()'s FDs or does
thread-specific signal handling and where the user would be hugely confused
if the FDs referenced or signal processed referred to the thread group
leader rather than the individual thread.
For now we only adjust pidfd_get_task() and the pidfd_send_signal() system
call with specific handling for this, implementing this functionality for
process_madvise(), process_mrelease() (albeit, using it here wouldn't
really make sense) and pidfd_send_signal().
We defer making further changes, as this would require a significant rework
of the pidfd mechanism.
The motivating case here is to support PIDFD_SELF in process_madvise(), so
this suffices for immediate uses. Moving forward, this can be further
expanded to other uses.
v7:
* Reworked implementation according to Christian's requirements. We now
only support process_madvise() and pidfd_send_signal() system calls with
PIDFD_SELF as specified.
* Updated tests to account for broken pidfd_open_test.c implementation.
* Fixed missing includes in pidfd self tests.
* Removed tests relating to functionality no longer supported.
* Update guard pages test to use PIDFD_SELF.
v6:
* Avoid static inline in UAPI header as suggested by Pedro.
* Place PIDFD_SELF values out of range of errors and any other sentinel as
suggested by Pedro.
https://lore.kernel.org/linux-mm/cover.1729926229.git.lorenzo.stoakes@oracle.com/
v5:
* Fixup self test dependencies on pidfd/pidfd.h.
https://lore.kernel.org/linux-mm/cover.1729848252.git.lorenzo.stoakes@oracle.com/
v4:
* Avoid returning an fd in the __pidfd_get_pid() function as pointed out by
Christian, instead simply always pin the pid and maintain fd scope in the
helper alone.
* Add wrapper header file in tools/include/linux to allow for import of
UAPI pidfd.h header without encountering the collision between system
fcntl.h and linux/fcntl.h as discussed with Shuah and John.
* Fixup tests to import the UAPI pidfd.h header working around conflicts
between system fcntl.h and linux/fcntl.h which the UAPI pidfd.h imports,
as reported by Shuah.
* Use an int for pidfd_is_self_sentinel() to avoid any dependency on
stdbool.h in userland.
https://lore.kernel.org/linux-mm/cover.1729198898.git.lorenzo.stoakes@oracle.com/
v3:
* Do not fput() an invalid fd as reported by kernel test bot.
* Fix unintended churn from moving variable declaration.
https://lore.kernel.org/linux-mm/cover.1729073310.git.lorenzo.stoakes@oracle.com/
v2:
* Fix tests as reported by Shuah.
* Correct RFC version lore link.
https://lore.kernel.org/linux-mm/cover.1728643714.git.lorenzo.stoakes@oracle.com/
Non-RFC v1:
* Removed RFC tag - there seems to be general consensus that this change is
a good idea, but perhaps some debate to be had on implementation. It
seems sensible then to move forward with the RFC flag removed.
* Introduced PIDFD_SELF_THREAD, PIDFD_SELF_THREAD_GROUP and their aliases
PIDFD_SELF and PIDFD_SELF_PROCESS respectively.
* Updated testing accordingly.
https://lore.kernel.org/linux-mm/cover.1728578231.git.lorenzo.stoakes@oracle.com/
RFC version:
https://lore.kernel.org/linux-mm/cover.1727644404.git.lorenzo.stoakes@oracle.com/
Lorenzo Stoakes (6):
pidfd: add PIDFD_SELF* sentinels to refer to own thread/process
selftests/pidfd: add missing system header imcludes to pidfd tests
tools: testing: separate out wait_for_pid() into helper header
selftests: pidfd: add pidfd.h UAPI wrapper
selftests: pidfd: add tests for PIDFD_SELF_*
selftests/mm: use PIDFD_SELF in guard pages test
include/uapi/linux/pidfd.h | 24 ++++
kernel/pid.c | 24 +++-
kernel/signal.c | 106 +++++++++++-------
tools/include/linux/pidfd.h | 14 +++
tools/testing/selftests/cgroup/test_kill.c | 2 +-
tools/testing/selftests/mm/Makefile | 4 +
tools/testing/selftests/mm/guard-pages.c | 15 +--
.../pid_namespace/regression_enomem.c | 2 +-
tools/testing/selftests/pidfd/Makefile | 3 +-
tools/testing/selftests/pidfd/pidfd.h | 28 +----
.../selftests/pidfd/pidfd_fdinfo_test.c | 1 +
tools/testing/selftests/pidfd/pidfd_helpers.h | 39 +++++++
.../testing/selftests/pidfd/pidfd_open_test.c | 6 +-
.../selftests/pidfd/pidfd_setns_test.c | 1 +
tools/testing/selftests/pidfd/pidfd_test.c | 76 +++++++++++--
15 files changed, 242 insertions(+), 103 deletions(-)
create mode 100644 tools/include/linux/pidfd.h
create mode 100644 tools/testing/selftests/pidfd/pidfd_helpers.h
--
2.48.1
^ permalink raw reply
* [PATCH v7 3/6] tools: testing: separate out wait_for_pid() into helper header
From: Lorenzo Stoakes @ 2025-01-30 20:40 UTC (permalink / raw)
To: Christian Brauner
Cc: Shuah Khan, Liam R . Howlett, Suren Baghdasaryan, Vlastimil Babka,
pedro.falcato, linux-kselftest, linux-mm, linux-fsdevel,
linux-api, linux-kernel, Oliver Sang, John Hubbard, Tejun Heo,
Johannes Weiner, Michal Koutny, Andrew Morton, Shakeel Butt
In-Reply-To: <cover.1738268370.git.lorenzo.stoakes@oracle.com>
It seems tests other than the pidfd tests use the wait_for_pid() function
declared in pidfd.h.
Since we will shortly be modifying pidfd.h in a way that might clash with
other tests, separate this out and update tests accordingly.
Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
---
tools/testing/selftests/cgroup/test_kill.c | 2 +-
.../pid_namespace/regression_enomem.c | 2 +-
tools/testing/selftests/pidfd/pidfd.h | 26 +------------
tools/testing/selftests/pidfd/pidfd_helpers.h | 39 +++++++++++++++++++
4 files changed, 42 insertions(+), 27 deletions(-)
create mode 100644 tools/testing/selftests/pidfd/pidfd_helpers.h
diff --git a/tools/testing/selftests/cgroup/test_kill.c b/tools/testing/selftests/cgroup/test_kill.c
index 0e5bb6c7307a..2367f645fe89 100644
--- a/tools/testing/selftests/cgroup/test_kill.c
+++ b/tools/testing/selftests/cgroup/test_kill.c
@@ -10,7 +10,7 @@
#include <unistd.h>
#include "../kselftest.h"
-#include "../pidfd/pidfd.h"
+#include "../pidfd/pidfd_helpers.h"
#include "cgroup_util.h"
/*
diff --git a/tools/testing/selftests/pid_namespace/regression_enomem.c b/tools/testing/selftests/pid_namespace/regression_enomem.c
index 7d84097ad45c..f3e6989c8069 100644
--- a/tools/testing/selftests/pid_namespace/regression_enomem.c
+++ b/tools/testing/selftests/pid_namespace/regression_enomem.c
@@ -12,7 +12,7 @@
#include <sys/wait.h>
#include "../kselftest_harness.h"
-#include "../pidfd/pidfd.h"
+#include "../pidfd/pidfd_helpers.h"
/*
* Regression test for:
diff --git a/tools/testing/selftests/pidfd/pidfd.h b/tools/testing/selftests/pidfd/pidfd.h
index 0b96ac4b8ce5..d02cfc5ef77b 100644
--- a/tools/testing/selftests/pidfd/pidfd.h
+++ b/tools/testing/selftests/pidfd/pidfd.h
@@ -17,6 +17,7 @@
#include "../kselftest.h"
#include "../clone3/clone3_selftests.h"
+#include "pidfd_helpers.h"
#ifndef P_PIDFD
#define P_PIDFD 3
@@ -73,31 +74,6 @@ static inline int sys_waitid(int which, pid_t pid, siginfo_t *info, int options)
return syscall(__NR_waitid, which, pid, info, options, NULL);
}
-static inline int wait_for_pid(pid_t pid)
-{
- int status, ret;
-
-again:
- ret = waitpid(pid, &status, 0);
- if (ret == -1) {
- if (errno == EINTR)
- goto again;
-
- ksft_print_msg("waitpid returned -1, errno=%d\n", errno);
- return -1;
- }
-
- if (!WIFEXITED(status)) {
- ksft_print_msg(
- "waitpid !WIFEXITED, WIFSIGNALED=%d, WTERMSIG=%d\n",
- WIFSIGNALED(status), WTERMSIG(status));
- return -1;
- }
-
- ret = WEXITSTATUS(status);
- return ret;
-}
-
static inline int sys_pidfd_open(pid_t pid, unsigned int flags)
{
return syscall(__NR_pidfd_open, pid, flags);
diff --git a/tools/testing/selftests/pidfd/pidfd_helpers.h b/tools/testing/selftests/pidfd/pidfd_helpers.h
new file mode 100644
index 000000000000..5637bfe888de
--- /dev/null
+++ b/tools/testing/selftests/pidfd/pidfd_helpers.h
@@ -0,0 +1,39 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef __PIDFD_HELPERS_H
+#define __PIDFD_HELPERS_H
+
+#define _GNU_SOURCE
+#include <errno.h>
+#include <stdlib.h>
+#include <sys/types.h>
+#include <sys/wait.h>
+#include <unistd.h>
+#include "../kselftest.h"
+
+static inline int wait_for_pid(pid_t pid)
+{
+ int status, ret;
+
+again:
+ ret = waitpid(pid, &status, 0);
+ if (ret == -1) {
+ if (errno == EINTR)
+ goto again;
+
+ ksft_print_msg("waitpid returned -1, errno=%d\n", errno);
+ return -1;
+ }
+
+ if (!WIFEXITED(status)) {
+ ksft_print_msg(
+ "waitpid !WIFEXITED, WIFSIGNALED=%d, WTERMSIG=%d\n",
+ WIFSIGNALED(status), WTERMSIG(status));
+ return -1;
+ }
+
+ ret = WEXITSTATUS(status);
+ return ret;
+}
+
+#endif /* __PIDFD_HELPERS_H */
--
2.48.1
^ permalink raw reply related
* [PATCH v7 2/6] selftests/pidfd: add missing system header imcludes to pidfd tests
From: Lorenzo Stoakes @ 2025-01-30 20:40 UTC (permalink / raw)
To: Christian Brauner
Cc: Shuah Khan, Liam R . Howlett, Suren Baghdasaryan, Vlastimil Babka,
pedro.falcato, linux-kselftest, linux-mm, linux-fsdevel,
linux-api, linux-kernel, Oliver Sang, John Hubbard, Tejun Heo,
Johannes Weiner, Michal Koutny, Andrew Morton, Shakeel Butt
In-Reply-To: <cover.1738268370.git.lorenzo.stoakes@oracle.com>
The pidfd_fdinfo_test.c and pidfd_setns_test.c tests appear to be missing
fundamental system header imports required to execute correctly. Add these.
Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
---
tools/testing/selftests/pidfd/pidfd_fdinfo_test.c | 1 +
tools/testing/selftests/pidfd/pidfd_setns_test.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/tools/testing/selftests/pidfd/pidfd_fdinfo_test.c b/tools/testing/selftests/pidfd/pidfd_fdinfo_test.c
index f062a986e382..f718aac75068 100644
--- a/tools/testing/selftests/pidfd/pidfd_fdinfo_test.c
+++ b/tools/testing/selftests/pidfd/pidfd_fdinfo_test.c
@@ -13,6 +13,7 @@
#include <syscall.h>
#include <sys/wait.h>
#include <sys/mman.h>
+#include <sys/mount.h>
#include "pidfd.h"
#include "../kselftest.h"
diff --git a/tools/testing/selftests/pidfd/pidfd_setns_test.c b/tools/testing/selftests/pidfd/pidfd_setns_test.c
index 222f8131283b..a55f6641e0b6 100644
--- a/tools/testing/selftests/pidfd/pidfd_setns_test.c
+++ b/tools/testing/selftests/pidfd/pidfd_setns_test.c
@@ -14,6 +14,7 @@
#include <sys/prctl.h>
#include <sys/wait.h>
#include <unistd.h>
+#include <sys/ioctl.h>
#include <sys/socket.h>
#include <sys/stat.h>
#include <linux/ioctl.h>
--
2.48.1
^ permalink raw reply related
* [PATCH v7 1/6] pidfd: add PIDFD_SELF* sentinels to refer to own thread/process
From: Lorenzo Stoakes @ 2025-01-30 20:40 UTC (permalink / raw)
To: Christian Brauner
Cc: Shuah Khan, Liam R . Howlett, Suren Baghdasaryan, Vlastimil Babka,
pedro.falcato, linux-kselftest, linux-mm, linux-fsdevel,
linux-api, linux-kernel, Oliver Sang, John Hubbard, Tejun Heo,
Johannes Weiner, Michal Koutny, Andrew Morton, Shakeel Butt
In-Reply-To: <cover.1738268370.git.lorenzo.stoakes@oracle.com>
It is useful to be able to utilise the pidfd mechanism to reference the
current thread or process (from a userland point of view - thread group
leader from the kernel's point of view).
Therefore introduce PIDFD_SELF_THREAD to refer to the current thread, and
PIDFD_SELF_THREAD_GROUP to refer to the current thread group leader.
For convenience and to avoid confusion from userland's perspective we alias
these:
* PIDFD_SELF is an alias for PIDFD_SELF_THREAD - This is nearly always what
the user will want to use, as they would find it surprising if for
instance fd's were unshared()'d and they wanted to invoke pidfd_getfd()
and that failed.
* PIDFD_SELF_PROCESS is an alias for PIDFD_SELF_THREAD_GROUP - Most users
have no concept of thread groups or what a thread group leader is, and
from userland's perspective and nomenclature this is what userland
considers to be a process.
We adjust pidfd_get_task() and the pidfd_send_signal() system call with
specific handling for this, implementing this functionality for
process_madvise(), process_mrelease() (albeit, using it here wouldn't
really make sense) and pidfd_send_signal().
Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
---
include/uapi/linux/pidfd.h | 24 +++++++++
kernel/pid.c | 24 +++++++--
kernel/signal.c | 106 ++++++++++++++++++++++---------------
3 files changed, 107 insertions(+), 47 deletions(-)
diff --git a/include/uapi/linux/pidfd.h b/include/uapi/linux/pidfd.h
index 4540f6301b8c..e0abd0b18841 100644
--- a/include/uapi/linux/pidfd.h
+++ b/include/uapi/linux/pidfd.h
@@ -23,6 +23,30 @@
#define PIDFD_INFO_SIZE_VER0 64 /* sizeof first published struct */
+/*
+ * The concept of process and threads in userland and the kernel is a confusing
+ * one - within the kernel every thread is a 'task' with its own individual PID,
+ * however from userland's point of view threads are grouped by a single PID,
+ * which is that of the 'thread group leader', typically the first thread
+ * spawned.
+ *
+ * To cut the Gideon knot, for internal kernel usage, we refer to
+ * PIDFD_SELF_THREAD to refer to the current thread (or task from a kernel
+ * perspective), and PIDFD_SELF_THREAD_GROUP to refer to the current thread
+ * group leader...
+ */
+#define PIDFD_SELF_THREAD -10000 /* Current thread. */
+#define PIDFD_SELF_THREAD_GROUP -20000 /* Current thread group leader. */
+
+/*
+ * ...and for userland we make life simpler - PIDFD_SELF refers to the current
+ * thread, PIDFD_SELF_PROCESS refers to the process thread group leader.
+ *
+ * For nearly all practical uses, a user will want to use PIDFD_SELF.
+ */
+#define PIDFD_SELF PIDFD_SELF_THREAD
+#define PIDFD_SELF_PROCESS PIDFD_SELF_THREAD_GROUP
+
struct pidfd_info {
/*
* This mask is similar to the request_mask in statx(2).
diff --git a/kernel/pid.c b/kernel/pid.c
index 3a10a7b6fcf8..1d2fc59d64fc 100644
--- a/kernel/pid.c
+++ b/kernel/pid.c
@@ -564,15 +564,29 @@ struct pid *pidfd_get_pid(unsigned int fd, unsigned int *flags)
*/
struct task_struct *pidfd_get_task(int pidfd, unsigned int *flags)
{
- unsigned int f_flags;
+ unsigned int f_flags = 0;
struct pid *pid;
struct task_struct *task;
+ enum pid_type type;
- pid = pidfd_get_pid(pidfd, &f_flags);
- if (IS_ERR(pid))
- return ERR_CAST(pid);
+ switch (pidfd) {
+ case PIDFD_SELF_THREAD:
+ type = PIDTYPE_PID;
+ pid = get_task_pid(current, type);
+ break;
+ case PIDFD_SELF_THREAD_GROUP:
+ type = PIDTYPE_TGID;
+ pid = get_task_pid(current, type);
+ break;
+ default:
+ pid = pidfd_get_pid(pidfd, &f_flags);
+ if (IS_ERR(pid))
+ return ERR_CAST(pid);
+ type = PIDTYPE_TGID;
+ break;
+ }
- task = get_pid_task(pid, PIDTYPE_TGID);
+ task = get_pid_task(pid, type);
put_pid(pid);
if (!task)
return ERR_PTR(-ESRCH);
diff --git a/kernel/signal.c b/kernel/signal.c
index a2afd54303f0..1e8f792f88de 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -4009,6 +4009,46 @@ static struct pid *pidfd_to_pid(const struct file *file)
(PIDFD_SIGNAL_THREAD | PIDFD_SIGNAL_THREAD_GROUP | \
PIDFD_SIGNAL_PROCESS_GROUP)
+static int do_pidfd_send_signal(struct pid *pid, int sig, enum pid_type type,
+ siginfo_t __user *info, unsigned int flags)
+{
+ kernel_siginfo_t kinfo;
+
+ switch (flags) {
+ case PIDFD_SIGNAL_THREAD:
+ type = PIDTYPE_PID;
+ break;
+ case PIDFD_SIGNAL_THREAD_GROUP:
+ type = PIDTYPE_TGID;
+ break;
+ case PIDFD_SIGNAL_PROCESS_GROUP:
+ type = PIDTYPE_PGID;
+ break;
+ }
+
+ if (info) {
+ int ret = copy_siginfo_from_user_any(&kinfo, info);
+
+ if (unlikely(ret))
+ return ret;
+
+ if (unlikely(sig != kinfo.si_signo))
+ return -EINVAL;
+
+ /* Only allow sending arbitrary signals to yourself. */
+ if ((task_pid(current) != pid || type > PIDTYPE_TGID) &&
+ (kinfo.si_code >= 0 || kinfo.si_code == SI_TKILL))
+ return -EPERM;
+ } else {
+ prepare_kill_siginfo(sig, &kinfo, type);
+ }
+
+ if (type == PIDTYPE_PGID)
+ return kill_pgrp_info(sig, &kinfo, pid);
+
+ return kill_pid_info_type(sig, &kinfo, pid, type);
+}
+
/**
* sys_pidfd_send_signal - Signal a process through a pidfd
* @pidfd: file descriptor of the process
@@ -4028,7 +4068,6 @@ SYSCALL_DEFINE4(pidfd_send_signal, int, pidfd, int, sig,
{
int ret;
struct pid *pid;
- kernel_siginfo_t kinfo;
enum pid_type type;
/* Enforce flags be set to 0 until we add an extension. */
@@ -4040,54 +4079,37 @@ SYSCALL_DEFINE4(pidfd_send_signal, int, pidfd, int, sig,
return -EINVAL;
CLASS(fd, f)(pidfd);
- if (fd_empty(f))
- return -EBADF;
- /* Is this a pidfd? */
- pid = pidfd_to_pid(fd_file(f));
- if (IS_ERR(pid))
- return PTR_ERR(pid);
+ switch (pidfd) {
+ case PIDFD_SELF_THREAD:
+ pid = get_task_pid(current, PIDTYPE_PID);
+ type = PIDTYPE_PID;
+ break;
+ case PIDFD_SELF_THREAD_GROUP:
+ pid = get_task_pid(current, PIDTYPE_TGID);
+ type = PIDTYPE_TGID;
+ break;
+ default:
+ if (fd_empty(f))
+ return -EBADF;
- if (!access_pidfd_pidns(pid))
- return -EINVAL;
+ /* Is this a pidfd? */
+ pid = pidfd_to_pid(fd_file(f));
+ if (IS_ERR(pid))
+ return PTR_ERR(pid);
- switch (flags) {
- case 0:
+ if (!access_pidfd_pidns(pid))
+ return -EINVAL;
/* Infer scope from the type of pidfd. */
if (fd_file(f)->f_flags & PIDFD_THREAD)
type = PIDTYPE_PID;
else
type = PIDTYPE_TGID;
break;
- case PIDFD_SIGNAL_THREAD:
- type = PIDTYPE_PID;
- break;
- case PIDFD_SIGNAL_THREAD_GROUP:
- type = PIDTYPE_TGID;
- break;
- case PIDFD_SIGNAL_PROCESS_GROUP:
- type = PIDTYPE_PGID;
- break;
- }
-
- if (info) {
- ret = copy_siginfo_from_user_any(&kinfo, info);
- if (unlikely(ret))
- return ret;
-
- if (unlikely(sig != kinfo.si_signo))
- return -EINVAL;
-
- /* Only allow sending arbitrary signals to yourself. */
- if ((task_pid(current) != pid || type > PIDTYPE_TGID) &&
- (kinfo.si_code >= 0 || kinfo.si_code == SI_TKILL))
- return -EPERM;
- } else {
- prepare_kill_siginfo(sig, &kinfo, type);
}
- if (type == PIDTYPE_PGID)
- return kill_pgrp_info(sig, &kinfo, pid);
- else
- return kill_pid_info_type(sig, &kinfo, pid, type);
+ ret = do_pidfd_send_signal(pid, sig, type, info, flags);
+ if (fd_empty(f))
+ put_pid(pid);
+ return ret;
}
--
2.48.1
^ permalink raw reply related
* Re: [PATCH v2] seccomp: passthrough uretprobe systemcall without filtering
From: Eyal Birger @ 2025-01-30 16:29 UTC (permalink / raw)
To: Kees Cook
Cc: Jiri Olsa, luto, wad, oleg, mhiramat, andrii, alexei.starovoitov,
cyphar, songliubraving, yhs, john.fastabend, peterz, tglx, bp,
daniel, ast, andrii.nakryiko, rostedt, rafi, shmulik.ladkani, bpf,
linux-api, linux-trace-kernel, x86, linux-kernel, stable
In-Reply-To: <202501300756.E473D10@keescook>
On Thu, Jan 30, 2025 at 7:57 AM Kees Cook <kees@kernel.org> wrote:
>
> On Thu, Jan 30, 2025 at 07:05:42AM -0800, Eyal Birger wrote:
> > So if we go with the suggestion above, we'll support the theoretical
> > __NR_uretprobe_32 for filtered seccomp, but not for strict seccomp, and
> > that's ok because strict seccomp is less common?
>
> It's so uncommon I regularly consider removing it entirely. :)
>
> > Personally I'd prefer to limit the scope of this fix to the problem we
> > are aware of, and not possible problems should someone decide to reimplement
> > uretprobes on different archs in a different way. Especially as this fix needs
> > to be backmerged to stable kernels.
> > So my personal preference would be to avoid __NR_uretprobe_32 in this patch
> > and deal with it if it ever gets implemented.
>
> That's fine, but I want the exception to be designed to fail closed
> instead of failing open. I think my proposed future-proof check does
> this.
I think it does. I think the code in the patch does too, since it
avoids the special handling for compat, so defaults to the existing
behavior which blocks the syscall.
Eyal.
^ permalink raw reply
* Re: [PATCH v2] seccomp: passthrough uretprobe systemcall without filtering
From: Kees Cook @ 2025-01-30 15:57 UTC (permalink / raw)
To: Eyal Birger
Cc: Jiri Olsa, luto, wad, oleg, mhiramat, andrii, alexei.starovoitov,
cyphar, songliubraving, yhs, john.fastabend, peterz, tglx, bp,
daniel, ast, andrii.nakryiko, rostedt, rafi, shmulik.ladkani, bpf,
linux-api, linux-trace-kernel, x86, linux-kernel, stable
In-Reply-To: <CAHsH6GvsGbZ4a=-oSpD1j8jx11T=Y4SysAtkzAu+H4_Gh7v3Qg@mail.gmail.com>
On Thu, Jan 30, 2025 at 07:05:42AM -0800, Eyal Birger wrote:
> So if we go with the suggestion above, we'll support the theoretical
> __NR_uretprobe_32 for filtered seccomp, but not for strict seccomp, and
> that's ok because strict seccomp is less common?
It's so uncommon I regularly consider removing it entirely. :)
> Personally I'd prefer to limit the scope of this fix to the problem we
> are aware of, and not possible problems should someone decide to reimplement
> uretprobes on different archs in a different way. Especially as this fix needs
> to be backmerged to stable kernels.
> So my personal preference would be to avoid __NR_uretprobe_32 in this patch
> and deal with it if it ever gets implemented.
That's fine, but I want the exception to be designed to fail closed
instead of failing open. I think my proposed future-proof check does
this.
--
Kees Cook
^ permalink raw reply
* Re: [PATCH v2] seccomp: passthrough uretprobe systemcall without filtering
From: Oleg Nesterov @ 2025-01-30 15:57 UTC (permalink / raw)
To: Eyal Birger
Cc: Jiri Olsa, Kees Cook, luto, wad, mhiramat, andrii,
alexei.starovoitov, cyphar, songliubraving, yhs, john.fastabend,
peterz, tglx, bp, daniel, ast, andrii.nakryiko, rostedt, rafi,
shmulik.ladkani, bpf, linux-api, linux-trace-kernel, x86,
linux-kernel, stable
In-Reply-To: <CAHsH6GvsGbZ4a=-oSpD1j8jx11T=Y4SysAtkzAu+H4_Gh7v3Qg@mail.gmail.com>
On 01/30, Eyal Birger wrote:
>
> Personally I'd prefer to limit the scope of this fix to the problem we
> are aware of, and not possible problems should someone decide to reimplement
> uretprobes on different archs in a different way. Especially as this fix needs
> to be backmerged to stable kernels.
+1
Oleg.
^ permalink raw reply
* Re: [PATCH v2] seccomp: passthrough uretprobe systemcall without filtering
From: Eyal Birger @ 2025-01-30 15:05 UTC (permalink / raw)
To: Jiri Olsa, Kees Cook
Cc: luto, wad, oleg, mhiramat, andrii, alexei.starovoitov, cyphar,
songliubraving, yhs, john.fastabend, peterz, tglx, bp, daniel,
ast, andrii.nakryiko, rostedt, rafi, shmulik.ladkani, bpf,
linux-api, linux-trace-kernel, x86, linux-kernel, stable
In-Reply-To: <Z5s3S5X8FYJDAHfR@krava>
On Thu, Jan 30, 2025 at 12:24 AM Jiri Olsa <olsajiri@gmail.com> wrote:
>
> On Wed, Jan 29, 2025 at 09:27:49AM -0800, Eyal Birger wrote:
> > Hi,
> >
> > Thanks for the review!
> >
> > On Tue, Jan 28, 2025 at 5:41 PM Kees Cook <kees@kernel.org> wrote:
> > >
> > > On Tue, Jan 28, 2025 at 06:58:06AM -0800, Eyal Birger wrote:
> > > > Note: uretprobe isn't supported in i386 and __NR_ia32_rt_tgsigqueueinfo
> > > > uses the same number as __NR_uretprobe so the syscall isn't forced in the
> > > > compat bitmap.
> > >
> > > So a 64-bit tracer cannot use uretprobe on a 32-bit process? Also is
> > > uretprobe strictly an x86_64 feature?
> > >
> >
> > My understanding is that they'd be able to do so, but use the int3 trap
> > instead of the uretprobe syscall.
> >
> > > > [...]
> > > > diff --git a/kernel/seccomp.c b/kernel/seccomp.c
> > > > index 385d48293a5f..23b594a68bc0 100644
> > > > --- a/kernel/seccomp.c
> > > > +++ b/kernel/seccomp.c
> > > > @@ -734,13 +734,13 @@ seccomp_prepare_user_filter(const char __user *user_filter)
> > > >
> > > > #ifdef SECCOMP_ARCH_NATIVE
> > > > /**
> > > > - * seccomp_is_const_allow - check if filter is constant allow with given data
> > > > + * seccomp_is_filter_const_allow - check if filter is constant allow with given data
> > > > * @fprog: The BPF programs
> > > > * @sd: The seccomp data to check against, only syscall number and arch
> > > > * number are considered constant.
> > > > */
> > > > -static bool seccomp_is_const_allow(struct sock_fprog_kern *fprog,
> > > > - struct seccomp_data *sd)
> > > > +static bool seccomp_is_filter_const_allow(struct sock_fprog_kern *fprog,
> > > > + struct seccomp_data *sd)
> > > > {
> > > > unsigned int reg_value = 0;
> > > > unsigned int pc;
> > > > @@ -812,6 +812,21 @@ static bool seccomp_is_const_allow(struct sock_fprog_kern *fprog,
> > > > return false;
> > > > }
> > > >
> > > > +static bool seccomp_is_const_allow(struct sock_fprog_kern *fprog,
> > > > + struct seccomp_data *sd)
> > > > +{
> > > > +#ifdef __NR_uretprobe
> > > > + if (sd->nr == __NR_uretprobe
> > > > +#ifdef SECCOMP_ARCH_COMPAT
> > > > + && sd->arch != SECCOMP_ARCH_COMPAT
> > > > +#endif
> > >
> > > I don't like this because it's not future-proof enough. __NR_uretprobe
> > > may collide with other syscalls at some point.
> >
> > I'm not sure I got this point.
> >
> > > And if __NR_uretprobe_32
> > > is ever implemented, the seccomp logic will be missing. I think this
> > > will work now and in the future:
> > >
> > > #ifdef __NR_uretprobe
> > > # ifdef SECCOMP_ARCH_COMPAT
> > > if (sd->arch == SECCOMP_ARCH_COMPAT) {
> > > # ifdef __NR_uretprobe_32
> > > if (sd->nr == __NR_uretprobe_32)
> > > return true;
> > > # endif
> > > } else
> > > # endif
> > > if (sd->nr == __NR_uretprobe)
> > > return true;
> > > #endif
> >
> > I don't know if implementing uretprobe syscall for compat binaries is
> > planned or makes sense - I'd appreciate Jiri's and others opinion on that.
> > That said, I don't mind adding this code for the sake of future proofing.
>
> as Andrii wrote in the other email ATM it's just strictly x86_64,
> but let's future proof it
Thank you. So I'm ok with using the suggestion above, but more on this below.
>
> AFAIK there was an attempt to do similar on arm but it did not show
> any speed up
>
> >
> > >
> > > Instead of doing a function rename dance, I think you can just stick
> > > the above into seccomp_is_const_allow() after the WARN().
> >
> > My motivation for the renaming dance was that you mentioned we might add
> > new syscalls to this as well, so I wanted to avoid cluttering the existing
> > function which seems to be well defined.
> >
> > >
> > > Also please add a KUnit tests to cover this in
> > > tools/testing/selftests/seccomp/seccomp_bpf.c
> >
> > I think this would mean that this test suite would need to run as
> > privileged. Is that Ok? or maybe it'd be better to have a new suite?
> >
> > > 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)
> >
> > Ok.
>
> please let me know if I can help in any way with tests
Thanks! Is there a way to partition this work? I'd appreciate the help
if we can find some way of doing so.
>
> >
> > >
> > > Hm, is uretprobe expected to work on mips? Because if so, you'll need to
> > > do something similar to the mode1 checking in the !SECCOMP_ARCH_NATIVE
> > > version of seccomp_cache_check_allow().
> >
> > I don't know if uretprobe syscall is expected to run on mips. Personally
> > I'd avoid adding this dead code.
Jiri, what is your take on this one?
> >
> > >
> > > (You can see why I really dislike having policy baked into seccomp!)
> >
> > I definitely understand :)
> >
> > >
> > > > + )
> > > > + return true;
> > > > +#endif
> > > > +
> > > > + return seccomp_is_filter_const_allow(fprog, sd);
> > > > +}
> > > > +
> > > > static void seccomp_cache_prepare_bitmap(struct seccomp_filter *sfilter,
> > > > void *bitmap, const void *bitmap_prev,
> > > > size_t bitmap_size, int arch)
> > > > @@ -1023,6 +1038,9 @@ static inline void seccomp_log(unsigned long syscall, long signr, u32 action,
> > > > */
> > > > static const int mode1_syscalls[] = {
> > > > __NR_seccomp_read, __NR_seccomp_write, __NR_seccomp_exit, __NR_seccomp_sigreturn,
> > > > +#ifdef __NR_uretprobe
> > > > + __NR_uretprobe,
> > > > +#endif
> > >
> > > It'd be nice to update mode1_syscalls_32 with __NR_uretprobe_32 even
> > > though it doesn't exist. (Is it _never_ planned to be implemented?) But
> > > then, maybe the chances of a compat mode1 seccomp process running under
> > > uretprobe is vanishingly small.
>
> no plans for __NR_uretprobe_32 at this point
So if we go with the suggestion above, we'll support the theoretical
__NR_uretprobe_32 for filtered seccomp, but not for strict seccomp, and
that's ok because strict seccomp is less common?
Personally I'd prefer to limit the scope of this fix to the problem we
are aware of, and not possible problems should someone decide to reimplement
uretprobes on different archs in a different way. Especially as this fix needs
to be backmerged to stable kernels.
So my personal preference would be to avoid __NR_uretprobe_32 in this patch
and deal with it if it ever gets implemented.
Thoughts and advice appreciated,
Eyal.
^ permalink raw reply
* Re: [PATCH v2] seccomp: passthrough uretprobe systemcall without filtering
From: Jiri Olsa @ 2025-01-30 8:24 UTC (permalink / raw)
To: Eyal Birger
Cc: Kees Cook, luto, wad, oleg, mhiramat, andrii, alexei.starovoitov,
olsajiri, cyphar, songliubraving, yhs, john.fastabend, peterz,
tglx, bp, daniel, ast, andrii.nakryiko, rostedt, rafi,
shmulik.ladkani, bpf, linux-api, linux-trace-kernel, x86,
linux-kernel, stable
In-Reply-To: <CAHsH6Gsv3DB0O5oiEDsf2+Go4O1+tnKm-Ab0QPyohKSaroSxxA@mail.gmail.com>
On Wed, Jan 29, 2025 at 09:27:49AM -0800, Eyal Birger wrote:
> Hi,
>
> Thanks for the review!
>
> On Tue, Jan 28, 2025 at 5:41 PM Kees Cook <kees@kernel.org> wrote:
> >
> > On Tue, Jan 28, 2025 at 06:58:06AM -0800, Eyal Birger wrote:
> > > Note: uretprobe isn't supported in i386 and __NR_ia32_rt_tgsigqueueinfo
> > > uses the same number as __NR_uretprobe so the syscall isn't forced in the
> > > compat bitmap.
> >
> > So a 64-bit tracer cannot use uretprobe on a 32-bit process? Also is
> > uretprobe strictly an x86_64 feature?
> >
>
> My understanding is that they'd be able to do so, but use the int3 trap
> instead of the uretprobe syscall.
>
> > > [...]
> > > diff --git a/kernel/seccomp.c b/kernel/seccomp.c
> > > index 385d48293a5f..23b594a68bc0 100644
> > > --- a/kernel/seccomp.c
> > > +++ b/kernel/seccomp.c
> > > @@ -734,13 +734,13 @@ seccomp_prepare_user_filter(const char __user *user_filter)
> > >
> > > #ifdef SECCOMP_ARCH_NATIVE
> > > /**
> > > - * seccomp_is_const_allow - check if filter is constant allow with given data
> > > + * seccomp_is_filter_const_allow - check if filter is constant allow with given data
> > > * @fprog: The BPF programs
> > > * @sd: The seccomp data to check against, only syscall number and arch
> > > * number are considered constant.
> > > */
> > > -static bool seccomp_is_const_allow(struct sock_fprog_kern *fprog,
> > > - struct seccomp_data *sd)
> > > +static bool seccomp_is_filter_const_allow(struct sock_fprog_kern *fprog,
> > > + struct seccomp_data *sd)
> > > {
> > > unsigned int reg_value = 0;
> > > unsigned int pc;
> > > @@ -812,6 +812,21 @@ static bool seccomp_is_const_allow(struct sock_fprog_kern *fprog,
> > > return false;
> > > }
> > >
> > > +static bool seccomp_is_const_allow(struct sock_fprog_kern *fprog,
> > > + struct seccomp_data *sd)
> > > +{
> > > +#ifdef __NR_uretprobe
> > > + if (sd->nr == __NR_uretprobe
> > > +#ifdef SECCOMP_ARCH_COMPAT
> > > + && sd->arch != SECCOMP_ARCH_COMPAT
> > > +#endif
> >
> > I don't like this because it's not future-proof enough. __NR_uretprobe
> > may collide with other syscalls at some point.
>
> I'm not sure I got this point.
>
> > And if __NR_uretprobe_32
> > is ever implemented, the seccomp logic will be missing. I think this
> > will work now and in the future:
> >
> > #ifdef __NR_uretprobe
> > # ifdef SECCOMP_ARCH_COMPAT
> > if (sd->arch == SECCOMP_ARCH_COMPAT) {
> > # ifdef __NR_uretprobe_32
> > if (sd->nr == __NR_uretprobe_32)
> > return true;
> > # endif
> > } else
> > # endif
> > if (sd->nr == __NR_uretprobe)
> > return true;
> > #endif
>
> I don't know if implementing uretprobe syscall for compat binaries is
> planned or makes sense - I'd appreciate Jiri's and others opinion on that.
> That said, I don't mind adding this code for the sake of future proofing.
as Andrii wrote in the other email ATM it's just strictly x86_64,
but let's future proof it
AFAIK there was an attempt to do similar on arm but it did not show
any speed up
>
> >
> > Instead of doing a function rename dance, I think you can just stick
> > the above into seccomp_is_const_allow() after the WARN().
>
> My motivation for the renaming dance was that you mentioned we might add
> new syscalls to this as well, so I wanted to avoid cluttering the existing
> function which seems to be well defined.
>
> >
> > Also please add a KUnit tests to cover this in
> > tools/testing/selftests/seccomp/seccomp_bpf.c
>
> I think this would mean that this test suite would need to run as
> privileged. Is that Ok? or maybe it'd be better to have a new suite?
>
> > 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)
>
> Ok.
please let me know if I can help in any way with tests
>
> >
> > Hm, is uretprobe expected to work on mips? Because if so, you'll need to
> > do something similar to the mode1 checking in the !SECCOMP_ARCH_NATIVE
> > version of seccomp_cache_check_allow().
>
> I don't know if uretprobe syscall is expected to run on mips. Personally
> I'd avoid adding this dead code.
>
> >
> > (You can see why I really dislike having policy baked into seccomp!)
>
> I definitely understand :)
>
> >
> > > + )
> > > + return true;
> > > +#endif
> > > +
> > > + return seccomp_is_filter_const_allow(fprog, sd);
> > > +}
> > > +
> > > static void seccomp_cache_prepare_bitmap(struct seccomp_filter *sfilter,
> > > void *bitmap, const void *bitmap_prev,
> > > size_t bitmap_size, int arch)
> > > @@ -1023,6 +1038,9 @@ static inline void seccomp_log(unsigned long syscall, long signr, u32 action,
> > > */
> > > static const int mode1_syscalls[] = {
> > > __NR_seccomp_read, __NR_seccomp_write, __NR_seccomp_exit, __NR_seccomp_sigreturn,
> > > +#ifdef __NR_uretprobe
> > > + __NR_uretprobe,
> > > +#endif
> >
> > It'd be nice to update mode1_syscalls_32 with __NR_uretprobe_32 even
> > though it doesn't exist. (Is it _never_ planned to be implemented?) But
> > then, maybe the chances of a compat mode1 seccomp process running under
> > uretprobe is vanishingly small.
no plans for __NR_uretprobe_32 at this point
>
> It seems to me very unlikely. BTW, when I tested the "strict" mode change
> my program was killed by seccomp. The reason wasn't the uretprobe syscall
> (which I added to the list), it was actually the exit_group syscall which
> libc uses instead of the exit syscall.
>
> Thanks again,
> Eyal.
thanks,
jirka
^ permalink raw reply
* Re: [PATCH v2] seccomp: passthrough uretprobe systemcall without filtering
From: Andrii Nakryiko @ 2025-01-29 22:52 UTC (permalink / raw)
To: Eyal Birger
Cc: Kees Cook, luto, wad, oleg, mhiramat, andrii, jolsa,
alexei.starovoitov, olsajiri, cyphar, songliubraving, yhs,
john.fastabend, peterz, tglx, bp, daniel, ast, rostedt, rafi,
shmulik.ladkani, bpf, linux-api, linux-trace-kernel, x86,
linux-kernel, stable
In-Reply-To: <CAHsH6Gsv3DB0O5oiEDsf2+Go4O1+tnKm-Ab0QPyohKSaroSxxA@mail.gmail.com>
On Wed, Jan 29, 2025 at 9:27 AM Eyal Birger <eyal.birger@gmail.com> wrote:
>
> Hi,
>
> Thanks for the review!
>
> On Tue, Jan 28, 2025 at 5:41 PM Kees Cook <kees@kernel.org> wrote:
> >
> > On Tue, Jan 28, 2025 at 06:58:06AM -0800, Eyal Birger wrote:
> > > Note: uretprobe isn't supported in i386 and __NR_ia32_rt_tgsigqueueinfo
> > > uses the same number as __NR_uretprobe so the syscall isn't forced in the
> > > compat bitmap.
> >
> > So a 64-bit tracer cannot use uretprobe on a 32-bit process? Also is
> > uretprobe strictly an x86_64 feature?
> >
>
> My understanding is that they'd be able to do so, but use the int3 trap
> instead of the uretprobe syscall.
>
Syscall-based uretprobe implementation is strictly x86-64 and I don't
think we have any plans to expand it beyond x86-64. But uretprobes in
general do work across many bitnesses and architectures, they are just
implemented through a trap approach (int3 on x86), so none of that
should be relevant to seccomp. It's just that trapping on x86-64 is
that much slower that we had to do syscall to speed it up but quite a
lot.
> > > [...]
> > > diff --git a/kernel/seccomp.c b/kernel/seccomp.c
> > > index 385d48293a5f..23b594a68bc0 100644
> > > --- a/kernel/seccomp.c
> > > +++ b/kernel/seccomp.c
> > > @@ -734,13 +734,13 @@ seccomp_prepare_user_filter(const char __user *user_filter)
> > >
[...]
^ permalink raw reply
* Re: [PATCH v3 0/6] ptrace: introduce PTRACE_SET_SYSCALL_INFO API
From: Oleg Nesterov @ 2025-01-29 18:51 UTC (permalink / raw)
To: Dmitry V. Levin
Cc: Alexey Gladkov, Charlie Jenkins, Eugene Syromyatnikov,
Mike Frysinger, Renzo Davoli, Davide Berardi, strace-devel,
Vineet Gupta, Russell King, Will Deacon, Guo Ren, Brian Cain,
Huacai Chen, WANG Xuerui, Geert Uytterhoeven, Michal Simek,
Thomas Bogendoerfer, Dinh Nguyen, Jonas Bonn, Stefan Kristiansson,
Stafford Horne, James E.J. Bottomley, Helge Deller,
Michael Ellerman, Nicholas Piggin, Christophe Leroy, Naveen N Rao,
Madhavan Srinivasan, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Heiko Carstens, Vasily Gorbik, Alexander Gordeev,
Christian Borntraeger, Sven Schnelle, Yoshinori Sato, Rich Felker,
John Paul Adrian Glaubitz, David S. Miller, Andreas Larsson,
Richard Weinberger, Anton Ivanov, Johannes Berg, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
Chris Zankel, Max Filippov, Arnd Bergmann, Shuah Khan,
linux-snps-arc, linux-kernel, linux-arm-kernel, linux-csky,
linux-hexagon, loongarch, linux-m68k, linux-mips, linux-openrisc,
linux-parisc, linuxppc-dev, linux-riscv, linux-s390, linux-sh,
sparclinux, linux-um, linux-arch, linux-kselftest, linux-api
In-Reply-To: <20250128091445.GA8257@strace.io>
On 01/28, Dmitry V. Levin wrote:
>
> * ptrace: Add explicit padding to the end of struct ptrace_syscall_info,
> simplify obtaining of user ptrace_syscall_info,
> do not introduce PTRACE_SYSCALL_INFO_SIZE_VER0
> * ptrace: Change the return type of ptrace_set_syscall_info_* functions
> from "unsigned long" to "int"
> * ptrace: Add -ERANGE check to ptrace_set_syscall_info_exit,
> add comments to -ERANGE checks
> * ptrace: Update comments about supported syscall stops
> * selftests: Extend set_syscall_info test, fix for mips n32
Again, I can't review 1-3, I know nothing about the non-x86 architectures.
As for 4-6, feel free to add
Reviewed-by: Oleg Nesterov <oleg@redhat.com>
^ permalink raw reply
* Re: [PATCH v2] seccomp: passthrough uretprobe systemcall without filtering
From: Eyal Birger @ 2025-01-29 17:27 UTC (permalink / raw)
To: Kees Cook
Cc: luto, wad, oleg, mhiramat, andrii, jolsa, alexei.starovoitov,
olsajiri, cyphar, songliubraving, yhs, john.fastabend, peterz,
tglx, bp, daniel, ast, andrii.nakryiko, rostedt, rafi,
shmulik.ladkani, bpf, linux-api, linux-trace-kernel, x86,
linux-kernel, stable
In-Reply-To: <202501281634.7F398CEA87@keescook>
Hi,
Thanks for the review!
On Tue, Jan 28, 2025 at 5:41 PM Kees Cook <kees@kernel.org> wrote:
>
> On Tue, Jan 28, 2025 at 06:58:06AM -0800, Eyal Birger wrote:
> > Note: uretprobe isn't supported in i386 and __NR_ia32_rt_tgsigqueueinfo
> > uses the same number as __NR_uretprobe so the syscall isn't forced in the
> > compat bitmap.
>
> So a 64-bit tracer cannot use uretprobe on a 32-bit process? Also is
> uretprobe strictly an x86_64 feature?
>
My understanding is that they'd be able to do so, but use the int3 trap
instead of the uretprobe syscall.
> > [...]
> > diff --git a/kernel/seccomp.c b/kernel/seccomp.c
> > index 385d48293a5f..23b594a68bc0 100644
> > --- a/kernel/seccomp.c
> > +++ b/kernel/seccomp.c
> > @@ -734,13 +734,13 @@ seccomp_prepare_user_filter(const char __user *user_filter)
> >
> > #ifdef SECCOMP_ARCH_NATIVE
> > /**
> > - * seccomp_is_const_allow - check if filter is constant allow with given data
> > + * seccomp_is_filter_const_allow - check if filter is constant allow with given data
> > * @fprog: The BPF programs
> > * @sd: The seccomp data to check against, only syscall number and arch
> > * number are considered constant.
> > */
> > -static bool seccomp_is_const_allow(struct sock_fprog_kern *fprog,
> > - struct seccomp_data *sd)
> > +static bool seccomp_is_filter_const_allow(struct sock_fprog_kern *fprog,
> > + struct seccomp_data *sd)
> > {
> > unsigned int reg_value = 0;
> > unsigned int pc;
> > @@ -812,6 +812,21 @@ static bool seccomp_is_const_allow(struct sock_fprog_kern *fprog,
> > return false;
> > }
> >
> > +static bool seccomp_is_const_allow(struct sock_fprog_kern *fprog,
> > + struct seccomp_data *sd)
> > +{
> > +#ifdef __NR_uretprobe
> > + if (sd->nr == __NR_uretprobe
> > +#ifdef SECCOMP_ARCH_COMPAT
> > + && sd->arch != SECCOMP_ARCH_COMPAT
> > +#endif
>
> I don't like this because it's not future-proof enough. __NR_uretprobe
> may collide with other syscalls at some point.
I'm not sure I got this point.
> And if __NR_uretprobe_32
> is ever implemented, the seccomp logic will be missing. I think this
> will work now and in the future:
>
> #ifdef __NR_uretprobe
> # ifdef SECCOMP_ARCH_COMPAT
> if (sd->arch == SECCOMP_ARCH_COMPAT) {
> # ifdef __NR_uretprobe_32
> if (sd->nr == __NR_uretprobe_32)
> return true;
> # endif
> } else
> # endif
> if (sd->nr == __NR_uretprobe)
> return true;
> #endif
I don't know if implementing uretprobe syscall for compat binaries is
planned or makes sense - I'd appreciate Jiri's and others opinion on that.
That said, I don't mind adding this code for the sake of future proofing.
>
> Instead of doing a function rename dance, I think you can just stick
> the above into seccomp_is_const_allow() after the WARN().
My motivation for the renaming dance was that you mentioned we might add
new syscalls to this as well, so I wanted to avoid cluttering the existing
function which seems to be well defined.
>
> Also please add a KUnit tests to cover this in
> tools/testing/selftests/seccomp/seccomp_bpf.c
I think this would mean that this test suite would need to run as
privileged. Is that Ok? or maybe it'd be better to have a new suite?
> 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)
Ok.
>
> Hm, is uretprobe expected to work on mips? Because if so, you'll need to
> do something similar to the mode1 checking in the !SECCOMP_ARCH_NATIVE
> version of seccomp_cache_check_allow().
I don't know if uretprobe syscall is expected to run on mips. Personally
I'd avoid adding this dead code.
>
> (You can see why I really dislike having policy baked into seccomp!)
I definitely understand :)
>
> > + )
> > + return true;
> > +#endif
> > +
> > + return seccomp_is_filter_const_allow(fprog, sd);
> > +}
> > +
> > static void seccomp_cache_prepare_bitmap(struct seccomp_filter *sfilter,
> > void *bitmap, const void *bitmap_prev,
> > size_t bitmap_size, int arch)
> > @@ -1023,6 +1038,9 @@ static inline void seccomp_log(unsigned long syscall, long signr, u32 action,
> > */
> > static const int mode1_syscalls[] = {
> > __NR_seccomp_read, __NR_seccomp_write, __NR_seccomp_exit, __NR_seccomp_sigreturn,
> > +#ifdef __NR_uretprobe
> > + __NR_uretprobe,
> > +#endif
>
> It'd be nice to update mode1_syscalls_32 with __NR_uretprobe_32 even
> though it doesn't exist. (Is it _never_ planned to be implemented?) But
> then, maybe the chances of a compat mode1 seccomp process running under
> uretprobe is vanishingly small.
It seems to me very unlikely. BTW, when I tested the "strict" mode change
my program was killed by seccomp. The reason wasn't the uretprobe syscall
(which I added to the list), it was actually the exit_group syscall which
libc uses instead of the exit syscall.
Thanks again,
Eyal.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox