[PATCH] arch: ensure we don't "munge" pseudo syscall numbers
A number of arches/ABIs have either syscall offsets (the MIPS
family) or specific bits (x32) which are applied to their normal
syscall numbers. We generally handle that via "munging" in
libseccomp, and it works reasonably well. Unfortunately we were
applying this munging process to the negative pseudo syscall
numbers as well and this was causing problems.
This patch fixes the various offset/bit arches/ABIs by not applying
the munging to the negative pseudo syscall numbers.
This resolves GH issue #284:
* https://github.com/seccomp/libseccomp/issues/284
Reported-by: Harald van Dijk <harald@gigawatt.nl>
Acked-by: Tom Hromatka <tom.hromatka@oracle.com>
Signed-off-by: Paul Moore <paul@paul-moore.com>
(imported from commit
34cde704979defcbddb8eea64295acf0e477c250)
Gbp-Pq: Name arch_ensure_we_dont_munge_pseudo_syscall_numbers.patch
[PATCH] tests: use openat and fstat instead of open and stat syscalls in tests 04 and 06
Architectures like aarch64 and riscv64, and all future architectures that
use the generic syscall table, do not support the open and stat syscalls.
Use the openat and fstat syscalls instead.
Signed-off-by: Andreas Schwab <schwab@suse.de>
Acked-by: Tom Hromatka <tom.hromatka@oracle.com>
Signed-off-by: Paul Moore <paul@paul-moore.com>
(imported from commit
a317fabc1fd915f19f7e7326bf7dcb77493f1210)
Gbp-Pq: Name tests_use_openat_and_fstat_instead_of_open_and_stat_syscalls.patch
[PATCH] build: undefine "mips" to prevent build problems for MIPS targets
It turns out that the MIPS GCC compiler defines a "mips" cpp macro
which was resulting in build failures on MIPS so we need to
undefine the "mips" macro during build. As this should be safe
to do in all architectures, just add it to the compiler flags by
default.
This was reported in the following GH issue:
* https://github.com/seccomp/libseccomp/issues/274
Reported-by: Rongwei Zhang <pudh4418@gmail.com>
Suggested-by: Rongwei Zhang <pudh4418@gmail.com>
Acked-by: Tom Hromatka <tom.hromatka@oracle.com>
Signed-off-by: Paul Moore <paul@paul-moore.com>
(imported from commit
5cd9059618a0810ee47c21e6b44c5a876b75e23d)
Gbp-Pq: Name build_undefine_mips_to_prevent_build_problems.patch
[PATCH] system: change our notification fd handling
This commit changes how we handle the notification fd by only
requesting it via _NEW_LISTENER if the filter has a _NOTIFY action
in it. We also augment the seccomp_reset(NULL, ...) behavior so
that it closes the notification fd before resetting the global
state; applications that need to keep their notification fd open
across a call to seccomp_reset(NULL, ...) can simply dup() it.
Although one would have to wonder why the application would be
calling seccomp_reset(NULL, ...) in that case.
Acked-by: Tom Hromatka <tom.hromatka@oracle.com>
Signed-off-by: Paul Moore <paul@paul-moore.com>
(imported from commit
02812f99e8d1df2e671dac675b4af663d0266303)
Gbp-Pq: Name system_change_our_notification_fd_handling.patch
[PATCH] all: only request the userspace notification fd once
It turns out that requesting the seccomp userspace notifcation fd
more than once is a bad thing which causes the kernel to complain
(rightfully so for a variety of reasons). Unfortunately as we were
always requesting the notification fd whenever possible this results
in problems at filter load time.
Our solution is to move the notification fd out of the filter context
and into the global task context, using a newly created task_state
structure. This allows us to store, and retrieve the notification
outside the scope of an individual filter context. It also provides
some implementation improvements by giving us a convenient place to
stash all of the API level related support variables. We also extend
the seccomp_reset() API call to reset this internal global state when
passed a NULL filter context.
There is one potential case which we don't currently handle well:
threads. At the moment libseccomp is thread ignorant, and that works
well as the only global state up to this point was the currently
supported API level information which was common to all threads in a
process. Unfortunately, it appears that the notification fd need not
be common to all threads in a process, yet this patch treats it as if
it is common. I suspect this is a very unusual use case so I decided
to keep this patch simple and ignore this case, but in the future if
we need to support this properly we should be able to do so without
API changes by keeping an internal list of notification fds indexed
by gettid(2).
This fixes the GitHub issue below:
* https://github.com/seccomp/libseccomp/issues/273
Reported-by: Tobias Stoeckmann <tobias@stoeckmann.org>
Acked-by: Tom Hromatka <tom.hromatka@oracle.com>
Signed-off-by: Paul Moore <paul@paul-moore.com>
(imported from commit
ce314fe4111887c593e3c6b17c60d93bc6ab66b9)
Gbp-Pq: Name all_only_request_the_userspace_notification_fd_once.patch
projects / libseccomp.git / log