From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
To: Rich Felker <dalias@libc.org>
Cc: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de>,
linux-sh@vger.kernel.org, linux-kernel@vger.kernel.org,
Yoshinori Sato <ysato@users.sourceforge.jp>
Subject: Re: [PATCH 3/4] sh: Add SECCOMP_FILTER
Date: Thu, 03 Sep 2020 06:03:06 +0000 [thread overview]
Message-ID: <54a4db1a-1d41-7fa2-cb74-460256d3be0d@physik.fu-berlin.de> (raw)
In-Reply-To: <20200903035603.GV3265@brightrain.aerifal.cx>
Hi Richi!
On 9/3/20 5:56 AM, Rich Felker wrote:
>> Test 51-live-user_notification%%001-00001 result: FAILURE 51-live-user_notification 5 ALLOW rc\x14
>
> AFAICT, this test is buggy and cannot possibly work. It attempts to
> have SYS_getpid return a 64-bit value and check that the returned
> value matches. On 32-bit archs this will be truncated to 32 bits, but
> the comparison in the caller still compares against the full 64-bit
> value. I have no idea how this seemed to work before.
You're actually right, I forgot about that. Michael discovered this bug as well
and it was consequently fixed:
> https://github.com/seccomp/libseccomp/commit/bee43d3e884788569860a384e6a38357785a3995
>> Test 58-live-tsync_notify%%001-00001 result: FAILURE 58-live-tsync_notify 6 ALLOW rc\x14
>
> This is similar to 51.
>
> I think the commonality of all the failures is that they deal with
> return values set by seccomp filters for blocked syscalls, which are
> getting clobbered by ENOSYS from the failed syscall here. So I do need
> to keep the code path that jumps over the actual syscall if
> do_syscall_trace_enter returns -1, but that means
> do_syscall_trace_enter must now be responsible for setting the return
> value in non-seccomp failure paths.
Same here:
> https://github.com/seccomp/libseccomp/commit/f0686d9de911e7ffcdc7364566c1d146e44657c2
Not sure about the other two tests. I can re-base and re-test.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
WARNING: multiple messages have this Message-ID (diff)
From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
To: Rich Felker <dalias@libc.org>
Cc: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de>,
linux-sh@vger.kernel.org, linux-kernel@vger.kernel.org,
Yoshinori Sato <ysato@users.sourceforge.jp>
Subject: Re: [PATCH 3/4] sh: Add SECCOMP_FILTER
Date: Thu, 3 Sep 2020 08:03:06 +0200 [thread overview]
Message-ID: <54a4db1a-1d41-7fa2-cb74-460256d3be0d@physik.fu-berlin.de> (raw)
In-Reply-To: <20200903035603.GV3265@brightrain.aerifal.cx>
Hi Richi!
On 9/3/20 5:56 AM, Rich Felker wrote:
>> Test 51-live-user_notification%%001-00001 result: FAILURE 51-live-user_notification 5 ALLOW rc=14
>
> AFAICT, this test is buggy and cannot possibly work. It attempts to
> have SYS_getpid return a 64-bit value and check that the returned
> value matches. On 32-bit archs this will be truncated to 32 bits, but
> the comparison in the caller still compares against the full 64-bit
> value. I have no idea how this seemed to work before.
You're actually right, I forgot about that. Michael discovered this bug as well
and it was consequently fixed:
> https://github.com/seccomp/libseccomp/commit/bee43d3e884788569860a384e6a38357785a3995
>> Test 58-live-tsync_notify%%001-00001 result: FAILURE 58-live-tsync_notify 6 ALLOW rc=14
>
> This is similar to 51.
>
> I think the commonality of all the failures is that they deal with
> return values set by seccomp filters for blocked syscalls, which are
> getting clobbered by ENOSYS from the failed syscall here. So I do need
> to keep the code path that jumps over the actual syscall if
> do_syscall_trace_enter returns -1, but that means
> do_syscall_trace_enter must now be responsible for setting the return
> value in non-seccomp failure paths.
Same here:
> https://github.com/seccomp/libseccomp/commit/f0686d9de911e7ffcdc7364566c1d146e44657c2
Not sure about the other two tests. I can re-base and re-test.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
next prev parent reply other threads:[~2020-09-03 6:03 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-22 23:13 [PATCH 1/4] sh: Fix validation of system call number Michael Karcher
2020-07-22 23:13 ` Michael Karcher
2020-07-22 23:13 ` [PATCH 2/4] sh: Rearrange blocks in entry-common.S Michael Karcher
2020-07-22 23:13 ` Michael Karcher
2020-07-22 23:20 ` John Paul Adrian Glaubitz
2020-07-22 23:20 ` John Paul Adrian Glaubitz
2020-07-22 23:13 ` [PATCH 3/4] sh: Add SECCOMP_FILTER Michael Karcher
2020-07-22 23:13 ` Michael Karcher
2020-07-22 23:20 ` John Paul Adrian Glaubitz
2020-07-22 23:20 ` John Paul Adrian Glaubitz
2020-08-28 15:50 ` Rich Felker
2020-08-28 15:50 ` Rich Felker
2020-08-28 16:21 ` John Paul Adrian Glaubitz
2020-08-28 16:21 ` John Paul Adrian Glaubitz
2020-08-28 16:30 ` Rich Felker
2020-08-28 16:30 ` Rich Felker
2020-08-28 16:38 ` John Paul Adrian Glaubitz
2020-08-28 16:38 ` John Paul Adrian Glaubitz
2020-08-28 17:03 ` Rich Felker
2020-08-28 17:03 ` Rich Felker
2020-08-29 0:49 ` Rich Felker
2020-08-29 0:49 ` Rich Felker
2020-08-29 11:09 ` John Paul Adrian Glaubitz
2020-08-29 11:09 ` John Paul Adrian Glaubitz
2020-09-03 3:56 ` Rich Felker
2020-09-03 3:56 ` Rich Felker
2020-09-03 5:46 ` Rich Felker
2020-09-03 5:46 ` Rich Felker
2020-09-03 6:04 ` John Paul Adrian Glaubitz
2020-09-03 6:04 ` John Paul Adrian Glaubitz
2020-09-03 6:17 ` Rich Felker
2020-09-03 6:17 ` Rich Felker
2020-09-03 6:03 ` John Paul Adrian Glaubitz [this message]
2020-09-03 6:03 ` John Paul Adrian Glaubitz
2020-07-22 23:13 ` [PATCH 4/4] sh: bring syscall_set_return_value in line with other architectures Michael Karcher
2020-07-22 23:13 ` Michael Karcher
2020-07-22 23:20 ` John Paul Adrian Glaubitz
2020-07-22 23:20 ` John Paul Adrian Glaubitz
2020-07-22 23:19 ` [PATCH 1/4] sh: Fix validation of system call number John Paul Adrian Glaubitz
2020-07-22 23:19 ` John Paul Adrian Glaubitz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54a4db1a-1d41-7fa2-cb74-460256d3be0d@physik.fu-berlin.de \
--to=glaubitz@physik.fu-berlin.de \
--cc=dalias@libc.org \
--cc=kernel@mkarcher.dialup.fu-berlin.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=ysato@users.sourceforge.jp \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.