From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Paris Subject: Re: [ARCH question] Do syscall_get_nr and syscall_get_arguments always work? Date: Wed, 19 Feb 2014 16:18:20 -0500 Message-ID: <1392844700.2165.70.camel@flatline.rdu.redhat.com> References: <1392752362.2165.31.camel@flatline.rdu.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Andy Lutomirski Cc: linux-arch , Andi Kleen , "linux-kernel@vger.kernel.org" , Oleg Nesterov , linux-audit@redhat.com, Jonas Bonn List-Id: linux-arch.vger.kernel.org On Tue, 2014-02-18 at 19:09 -0800, Andy Lutomirski wrote: > On Tue, Feb 18, 2014 at 11:39 AM, Eric Paris 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com ([209.132.183.28]:35035 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755171AbaBSVSi (ORCPT ); Wed, 19 Feb 2014 16:18:38 -0500 Message-ID: <1392844700.2165.70.camel@flatline.rdu.redhat.com> Subject: Re: [ARCH question] Do syscall_get_nr and syscall_get_arguments always work? From: Eric Paris Date: Wed, 19 Feb 2014 16:18:20 -0500 In-Reply-To: References: <1392752362.2165.31.camel@flatline.rdu.redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-arch-owner@vger.kernel.org List-ID: To: Andy Lutomirski Cc: Jonas Bonn , Oleg Nesterov , linux-arch , linux-audit@redhat.com, "linux-kernel@vger.kernel.org" , Andi Kleen , Steve Grubb Message-ID: <20140219211820.Y5ZLW_-W1kH3WQG1_SWq1SSCYQEkbzk8UJXNQKaRN7k@z> On Tue, 2014-02-18 at 19:09 -0800, Andy Lutomirski wrote: > On Tue, Feb 18, 2014 at 11:39 AM, Eric Paris 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