Re: [ARCH question] Do syscall_get_nr and syscall_get_arguments always work?
On Tue, Feb 18, 2014 at 11:39 AM, Eric Paris <eparis(a)redhat.com> wrote:
On Fri, 2014-02-07 at 08:40 -0800, Andy Lutomirski wrote:
> On Fri, Feb 7, 2014 at 4:58 AM, Jonas Bonn <jonas.bonn(a)gmail.com> wrote:
> > Hi Andy,
> >
> > On 5 February 2014 00:50, Andy Lutomirski <luto(a)amacapital.net> wrote:
> >>
> >> I can't even find the system call entry point on mips.
> >>
> >>
> >> Is there a semi-official answer here?
> >
> > I don't have an official answer for you, but when I wanted to do
> > something with these entry points a couple of years back I discovered
> > that they aren't very thoroughly implemented across the various
> > architectures. I started cleaning this up and can probably dig up
> > some of this for you if you need it.
>
> The syscall_get_xyz functions are certainly implemented and functional
> in all relevant architectures -- the audit code is already using them.
> The thing I'm uncertain about is whether they are usable with no
> syscall slow path bits set.
>
> I guess that, if the syscall restart logic needs to read the argument
> registers, then they're probably reliably saved...
Al just indicated to me that on at least ia64, syscall_get_arguments()
is really expensive. So maybe not a deal breaker, but sounds like we'd
lose a lot of performance trying to get them at syscall exit...
I wonder how slow syscall_get_arguments has to be before it's a real
problem. Remember that we only need to call it when we already know
that an audit record needs to be written (or if a syscall argument is
used in a filter rule, I suppose -- I'm sure sure whether that's
possible). As long as syscall_get_nr is fast, which I think it is on
ia64, then the tradeoff might still be a win.
But I think this is still a bit of a lost cause. Currently, if I'm
reading the code correctly, signal delivery to a non-auditd process
can result in writing an audit event. If the signal is delivered
during a syscall, then current code will write an audit record for
that syscall on syscall exit.
If we want to preserve that behavior without a syscall audit hook,
then the signal delivery code needs to know whether it's in the middle
of a syscall. AFAIK this is not possible.
On the other hand, most interesting signals are probably *not* the
result of a syscall anyway, so it may make sense to just remove that
code entirely.
TBH, as long as something happens to get rid of audit overhead when
there are no rules, my interest in personally writing something fancy
to make the nonzero-number-of-rules case have less overhead is rather
low.
--Andy