| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
| |
This commit adds basic support for tracking what kernel introduced a
syscall for a given arch/ABI. It does not provide any of that kernel
version information, leaving only a SCMP_KV_UNDEF placeholder, nor
does it attempt to do anything meaningful with this new source of
information; this patch simply establishes a new syscalls.csv format
so that we can start properly recording the kernel versions.
Acked-by: Tom Hromatka <tom.hromatka@oracle.com>
Signed-off-by: Paul Moore <paul@paul-moore.com>
|
| |
|
|
|
|
|
|
|
| |
This should make it easier to ensure we have arch/ABIs added
properly to libseccomp.
Signed-off-by: Paul Moore <paul@paul-moore.com>
Reviewed-by: Tom Hromatka <tom.hromatka@oracle.com>
Signed-off-by: Tom Hromatka <tom.hromatka@oracle.com>
|
| |
|
|
|
|
|
|
|
| |
Not only does this reduce the amount of duplicated code
significantly, it removes a lot of the "magic" numbers in the
code, and it happened to catch some bugs too.
Acked-by: Tom Hromatka <tom.hromatka@oracle.com>
Signed-off-by: Paul Moore <paul@paul-moore.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch significantly improves the performance of
seccomp_syscall_resolve_name since it replaces the expensive strcmp
for each syscall in the database, with a lookup table.
The complexity for syscall_resolve_num is not changed and it
uses the linear search, that is anyway less expensive than
seccomp_syscall_resolve_name as it uses an index for comparison
instead of doing a string comparison.
On my machine, calling 1000 seccomp_syscall_resolve_name_arch and
seccomp_syscall_resolve_num_arch over the entire syscalls DB passed
from ~0.45 sec to ~0.06s.
PM: After talking with Giuseppe I made a number of additional
changes, some substantial, the highlights include:
* various style tweaks
* .gitignore fixes
* fixed subject line, tweaked the description
* dropped the arch-syscall-validate changes as they were masking
other problems
* extracted the syscalls.csv and file deletions to other patches
to keep this one more focused
* fixed the x86, x32, arm, all the MIPS ABIs, s390, and s390x ABIs as
the syscall offsets were not properly incorporated into this change
* cleaned up the ABI specific headers
* cleaned up generate_syscalls_perf.sh and renamed to
arch-gperf-generate
* fixed problems with automake's file packaging
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
Reviewed-by: Tom Hromatka <tom.hromatka@oracle.com>
[PM: see notes in the "PM" section above]
Signed-off-by: Paul Moore <paul@paul-moore.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
This is long overdue so quite a few changes, including tweaks to
support some newly direct wired syscalls which were previously
multiplexed.
We really need to make sure we update the syscall table more often.
Acked-by: Tom Hromatka <tom.hromatka@oracle.com>
Signed-off-by: Paul Moore <paul@paul-moore.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
First, and most importantly, let me state that this is perhaps the worst
possible example of a patch I can think of, and if anyone tries to submit
a PR/patch like this one I will reject it almost immediately. I'm only
merging this because 1) this patch escalated quickly, 2) splitting it would
require a disproportionate amount of time, and 3) this effort had blocked
other work for too long ... and, well, I'm the maintainer. Consider this
a bit of "maintainer privilege" if you will.
This patch started simply enough: the goal was to add/augment some tests to
help increase the libseccomp test coverage. Unfortunately, this particular
test improvement uncovered a rather tricky bug which escalated quite quickly
and soon involved a major rework of how we build the filter tree in src/db.c.
This rework brought about changes throughout the repository, including the
transaction and ABI specific code.
Signed-off-by: Paul Moore <paul@paul-moore.com>
|
| |
|
|
| |
Signed-off-by: Paul Moore <paul@paul-moore.com>
|
| |
|
|
|
|
|
|
|
|
| |
Instead of dynamically allocating a variable number of arguments,
include an array of ARG_COUNT_MAX elements directly in the struct.
Also perform a number of simplifications to the code with the
understanding that ARG_COUNT_MAX is an ABI independent value that
isn't variable.
Signed-off-by: Paul Moore <paul@paul-moore.com>
|
| |
|
|
|
|
|
|
| |
Unfortunately we were only properly handling some of the multiplexed
ipc() syscalls, this patch correctly handles all of the ipc()
syscalls.
Signed-off-by: Paul Moore <paul@paul-moore.com>
|
| |
|
|
|
|
|
|
|
|
| |
It turns out the socket and ipc related syscalls are also multiplexed
on s390/s390x much like they are on 32-bit x86. Further making things
difficult is that starting with Linux 4.3 the socket syscalls are also
available as directly wired versions, much like 32-bit x86. This
patch attempts to fix all those problems.
Signed-off-by: Paul Moore <paul@paul-moore.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
It turns out there was still a few bugs with the 32-bit x86 socket
syscalls, especially on systems with older kernel headers installed.
This patch corrects these problems and perhaps more importantly,
returns the resolver API functions to returning the negative pseudo
syscall numbers in the case of 32-bit x86, this helps ensure things
continue to work as they did before as the API does not change.
It it important to note that libseccomp still generates filter code
for both multiplexed and direct socket syscalls regardless.
Signed-off-by: Paul Moore <paul@paul-moore.com>
|
| |
|
|
|
|
|
| |
Employer agnostic emails make things a lot easier in the long run so
make sure the paul-moore.com address is used whenever it makes sense.
Signed-off-by: Paul Moore <paul@paul-moore.com>
|
| |
|
|
|
|
|
|
|
| |
Linux 4.3 added direct-wired socket syscalls in addition to the
multiplexed socket syscalls available via socketcall(). This patch
causes libseccomp to generate filters for socket syscall methods on
x86 systems.
Signed-off-by: Paul Moore <paul@paul-moore.com>
|
| |
|
|
|
|
|
| |
Create the infrastructure for arch/ABI specific rule creation that
allows us much more involved arch/ABI customization.
Signed-off-by: Paul Moore <pmoore@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The arch specific filter rewrite code is going to need to become more
complex so move the low level rule addition code directly into the
arch layer instead of the db layer, but still keep the tree manipulation
code in the db layer.
This patch also creates a new arch specific rule_add() function table
entry and allows for this function to create multiple rules from a
single rule.
Signed-off-by: Paul Moore <pmoore@redhat.com>
|
| |
|
|
| |
Signed-off-by: Paul Moore <pmoore@redhat.com>
|
| |
|
|
|
|
|
| |
This will be useful in future patches for rebuilding and manipulating
the filter.
Signed-off-by: Paul Moore <pmoore@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
We use negative syscalls numbers to indicate syscalls that aren't
supported by a certain arch/ABI and unfortunately there were cases
where these bogus syscall values were finding their way into the
filter. This patch corrects this and adds a new test to check for
this in the future.
Reported-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Paul Moore <pmoore@redhat.com>
|
| |
|
|
|
|
|
|
|
| |
I've been putting off simplifing the arch specific code until we had
enough ABIs to know what simplifications made sense. Well, our
supported ABI list is not quite reasonable so go ahead and clean
things up a bit.
Signed-off-by: Paul Moore <pmoore@redhat.com>
|
| |
|
|
|
|
| |
Make it more obvious that these variables are booleans.
Signed-off-by: Paul Moore <pmoore@redhat.com>
|
|
|
No code chanages here, just an effort to improve naming consistency
a bit.
Signed-off-by: Paul Moore <pmoore@redhat.com>
|
