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-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
