linux-kernel - Re: [ARCH question] Do syscall_get_nr and syscall_get

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1392844700.2165.70.camel@flatline.rdu.redhat.com>
Date:	Wed, 19 Feb 2014 16:18:20 -0500
From:	Eric Paris <eparis@...hat.com>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Jonas Bonn <jonas.bonn@...il.com>, Oleg Nesterov <oleg@...hat.com>,
	linux-arch <linux-arch@...r.kernel.org>, linux-audit@...hat.com,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Andi Kleen <andi@...stfloor.org>,
	Steve Grubb <sgrubb@...hat.com>
Subject: Re: [ARCH question] Do syscall_get_nr and syscall_get_arguments
 always work?

On Tue, 2014-02-18 at 19:09 -0800, Andy Lutomirski wrote:
> On Tue, Feb 18, 2014 at 11:39 AM, Eric Paris <eparis@...hat.com> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/