5:50 p.m.
On Tue, Feb 4, 2014 at 11:32 AM, Andy Lutomirski <luto(a)amacapital.net> wrote:
Now we get rid of __audit_syscall_entry. (This speeds up even the
auditing-is-on case.) Instead we have __audit_start_record, which
does more or less the same thing, except that (a) it doesn't BUG if
in_syscall and (b) it *sets* TIF_SYSCALL_AUDIT. This relies on the
fact that syscall_get_nr and syscall_get_arguments are reliable on
x86_64. I suspect that they're reliable everywhere else, too. The
idea is that there's nothing wrong with calling __audit_start_record
more than once. (Maybe it should be called
__audit_record_this_syscall.)
I'd like to make a change that can result in syscall_get_nr and
syscall_get_arguments being called (on current and
task_pt_regs(current)) from any system call (as opposed to being
called only from the audit/trace slowpaths). Is this safe?
Here's my somewhat clueless analysis:
On x86_64, I've tested it, and it works. The entry code saves all of
the argument registers, even in the fast path.
i386 and ia32_compat look okay, too.
If "stmia sp, {r0 - r12} @ Calling r0 - r12" does what I
think it does, then arm should be okay.
I'm totally guessing here, but e10_sync on aarch64 seems to save
enough registers. I admit to being a little bit surprised, though --
aarch64 is new, and if I were designing an ABI, I specify that
syscalls *don't* save registers.
ia64 has a comment in ivt.S that streamlined syscalls save nr in r15.
The rest come from unwind info (!). I assume this has something to do
with the magic ia64 register rotation thing. I have no idea what
happens if there's a NaT in an argument register.
I can't even find the system call entry point on mips.
Is there a semi-official answer here?
--Andy
6:58 a.m.
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.
See:
https://lkml.org/lkml/2011/10/23/87
Then again, this may be in better shape today, already... I didn't check.
/Jonas
--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-arch" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Jonas Bonn
Stockholm, Sweden
10:40 a.m.
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...
--Andy
1:39 p.m.
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...
9:09 p.m.
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
3:18 p.m.
On Tue, 2014-02-18 at 19:09 -0800, Andy Lutomirski wrote:
On Tue, Feb 18, 2014 at 11:39 AM, Eric Paris
<eparis(a)redhat.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
3:21 p.m.
On 14/02/07, 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 just stumbled on syscall_get_arch missing on at least s390x. Others
may have it missing too, but the build quit on discovering that one.
I guess that, if the syscall restart logic needs to read the
argument
registers, then they're probably reliably saved...
--Andy
- RGB
--
Richard Guy Briggs <rbriggs(a)redhat.com>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
3956
days inactive
3973
days old
linux-audit@lists.linux-audit.osci.io
6 comments
4 participants
participants (4)
-
Andy Lutomirski -
Eric Paris -
Jonas Bonn -
Richard Guy Briggs