Messages in this thread Patch in this message | | | From | Andy Lutomirski <> | Date | Mon, 3 Feb 2014 13:09:54 -0800 | Subject | Re: [PATCH v2.1] audit: Only use the syscall slowpath when syscall audit rules exist |
| |
On Mon, Feb 3, 2014 at 12:35 PM, Eric Paris <eparis@redhat.com> wrote: > Hmmmm, > > My problem with doing this has always actually been because of SELinux. > Knowing syscall information with AVCs can be a huge help running down > problems. We already make people load rules if they want to get > pathname type records, so maybe this is fine. Or we could make SELinux > take a reference on the number of audit rules, but that was your > particular use case. Not sure how I feel about losing syscall > information by default on AVCs... >
Hmm. I never noticed that feature. That'll show me :)
I would personally happily give that up for a 30-50% reduction in systemwide syscall latency.
Looking at the 64-bit syscall entry code, it looks like the syscall nr is always saved to pt_regs (as orig_rax) and the arguments are shoved into the usual places in pt_regs. Have you ever tried using syscall_get_nr and syscall_get_arguments from the audit code without setting TIF_SYSCALL_AUDIT? I may be missing something here, but it looks like it'll work.
> Do we always have audit_context allocated? I need to look how the TIF > and audit_context are correlated.
In 3.13, TIF_SYSCALL_AUDIT is set iff audit_context is allocated. In 3.12 and below that was not the case due to a bug.
> > For a completely seperate non-audit patch idea I've toyed with making > the arch/syscall_nr a0,a1,a2,a3 stored in task struct rather than audit > context. Would mean that recording that information on syscall entry > could be fast/easy and done quickly in syscall entry assembly code. > Then on entry we could track only if there are rules on the 'entry' list > and skip if none. On exit we could do the same only with exit rules. > Right now all 3 of those different things are tracked in > TIF_SYSCALL_AUDIT (As I recall the slow path is usually a lot of things > other than audit, but audit is what forces us onto the slow patch)
I think that you can already fish out the syscall args on x86_64 at least. The attached awful patch appears to work, for example.
Test code:
#include <stdio.h> #include <linux/prctl.h>
int main(int argc, char **argv) { if (argc != 5) { printf("Usage: test_pr500 arg2 arg3 arg4 arg5\n"); return 1; }
prctl(500, atoi(argv[1]), atoi(argv[2]), atoi(argv[3]), atoi(argv[4])); return 0; }
FWIW, I don't know *why* the syscall fast path does this, but it's convenient for this use :)
Out of curiosity, why does the audit code ignore a4 and a5?
--Andy diff --git a/kernel/sys.c b/kernel/sys.c index c0a58be..48b81d3 100644 --- a/kernel/sys.c +++ b/kernel/sys.c @@ -41,6 +41,7 @@ #include <linux/syscore_ops.h> #include <linux/version.h> #include <linux/ctype.h> +#include <asm/syscall.h> #include <linux/compat.h> #include <linux/syscalls.h> @@ -1996,6 +1997,13 @@ SYSCALL_DEFINE5(prctl, int, option, unsigned long, arg2, unsigned long, arg3, if (arg2 || arg3 || arg4 || arg5) return -EINVAL; return current->no_new_privs ? 1 : 0; + case 500: + { + struct pt_regs *regs = task_pt_regs(current); + unsigned long a[6]; + syscall_get_arguments(current, regs, 0, 6, a); + printk("nr=%d a0=%lu a1=%lu a2=%lu a3=%lu a4=%lu a5=%lu\n", syscall_get_nr(current, regs), a[0], a[1], a[2], a[3], a[4], a[5]); + } default: error = -EINVAL; break; | |