Re: [ARCH question] Do syscall_get_nr and syscall_get_arguments always work?

[Eric Paris]

On Tue, 2014-02-18 at 19:09 -0800, Andy Lutomirski wrote:
> On Tue, Feb 18, 2014 at 11:39 AM, Eric Paris <eparis@xxxxxxxxxx> wrote:

> > 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).

It's possible to include a0-a3 in syscall filter rules.  (Al wasn't
supportive of killing __audit_syscall_entry().  He mentioned in
particular difficulties around audit_get_stamp().  Won't pretend to have
my head wrapped around what he was referring to...

> 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.

So?  The info we collect about the target of the signal is not related
to the changes you are discussing.  The work/collection is done as the
task 'sending' the signal (and will only be emitted on syscall exit)

> If the signal is delivered
> during a syscall, then current code will write an audit record for
> that syscall on syscall exit.

Right, so we only care about if the sender has its audit_context all set
up.  We'll only send a record 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.

Clearly we need a syscall exit hook, I agree with that...

> 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.

That's fair   :)

> 
> --Andy


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/