[Audit-test-developer] syscall (hardware) relevancy - proof of concept

[Jiri J. <jja...@re...>]

Hello all,
as discussed in "[design] How to write / run / audit syscall wrappers?",
I went ahead and made an example implementation, including some
documentation and additional design considerations.

Please see the attached/referenced patches for a rough idea how it
works.

These patches are not applicable to current audit-test upstream, which
doesn't yet have all the syscalls we've been implementing in the
meantime, but they should provide grounds for some discussion.

What works on my testing branch; utils/bin/ syscall building based on
the 'relevancy' file and execution of most buckets (incl. syscalls/).

There are however more problems involved:

1)
Arch/mode based limitation was different in utils/bin/ and elsewhere,
namely the syscalls/ bucket. Ie. both do_ipc and all do_{msg,sem,shm}*
binaries were built on most (all?) architectures, so the syscalls/
bucket presumed that both were always available, doing ie.
"which do_msgget" in create_msg_key when only do_ipc is available.
This worked, because both do_ipc and do_{msg,sem,shm}* are implemented
using glibc wrappers, which is still the case, but do_{msg,sem,shm}*
were simply not built, because they weren't relevant to x86_64 MODE=32.
Same with socketcall. In summary - hidden bucket dependencies.

2)
Testing/building matrix. Since the new relevancy is based on what is
really available on a given architecture according to kernel-provided
syscall tables (just the default 'relevancy' file, can be changed),
not what was in Makefile (this import was in a separate commit/patch),
the testing matrix is actually somewhat bigger - meaning we test more
on each architecture.
This can lead to unexpected fails where there were previously none,
such as the uselib() syscall, which is relevant on x86_64, but was
skipped in syscalls/run.conf due to ENOSYS (being obsolete). Cases like
these have to be taken care of in the relevancy file, which then doesn't
match exactly what each architecture provides.
Which is fine, but it should be somehow commented/documented.

3)
Masking syscalls behind libc. This has already been discussed, but let
me point out one additional case - send(2). It turns out that send(2)
actually exists only on ppc64 (and ia64). Everywhere else, it's just
(presumably) translated to sendto(2) via libc.
The fact that audit works with real syscalls (numbers) as well as this
"relevancy" implementation would point to using __NR_$syscall for all
syscalls, to ensure consistency, however I'm hesitant to do it just yet
due to the loss of argument checking.


I'd like to continue working on this, even though it seems somewhat
bigger than originally estimated, as it may - IMHO - clean the use of
syscalls / syscall wrappers within the suite and discover more hidden
dependencies and workarounds.

However I would most certainly like to know your opinions on the
patches. Note that they represent a very early implementation that may
change significantly.

Thanks a lot,
Jiri