Re: [PATCH] IA64 audit support

From: Andrew Morton
Date: Thu Jul 01 2004 - 20:34:04 EST


Karim Yaghmour <karim@xxxxxxxxxxx> wrote:
>
>
> Here's what I was trying to say:
>
> Andrew Morton wrote:
> > It's nice and simple.
>
> I, and quite a few other folks, have been trying to get the Linux Trace Toolkit
> in the kernel for the past 5 years and the code being added is almost identical
> to what the audit patch adds, yet we've always got reponses such "this is
> bloated" and Linus told us that he didn't see the use of this kind of stuff.

The auditing framework was quite unintrusive:

arch/i386/kernel/entry.S | 6
arch/i386/kernel/ptrace.c | 10
arch/ppc64/kernel/entry.S | 15
arch/ppc64/kernel/ptrace.c | 29 +
arch/x86_64/ia32/ia32entry.S | 18
arch/x86_64/kernel/entry.S | 21
arch/x86_64/kernel/ptrace.c | 30 +
fs/namei.c | 15
include/asm-i386/thread_info.h | 6
include/asm-ppc64/thread_info.h | 3
include/asm-x86_64/thread_info.h | 5
include/linux/audit.h | 211 ++++++++
include/linux/fs.h | 14
include/linux/netlink.h | 1
include/linux/sched.h | 3
init/Kconfig | 20
kernel/Makefile | 2
kernel/audit.c | 825 ++++++++++++++++++++++++++++++++++
kernel/auditsc.c | 922 +++++++++++++++++++++++++++++++++++++++
kernel/fork.c | 10
security/selinux/avc.c | 168 +++----
security/selinux/include/avc.h | 7
security/selinux/ss/services.c | 2
23 files changed, 2199 insertions(+), 144 deletions(-)

It treads on fork.c and namei.c only, really.

Whereas LTT:

Makefile | 1
arch/i386/config.in | 2
arch/i386/kernel/entry.S | 10
arch/i386/kernel/irq.c | 6
arch/i386/kernel/process.c | 6
arch/i386/kernel/sys_i386.c | 4
arch/i386/kernel/traps.c | 106 +++
arch/i386/mm/fault.c | 11
arch/mips/config.in | 2
arch/mips/ddb5476/irq.c | 10
arch/mips/kernel/irq.c | 10
arch/mips/kernel/scall_o32.S | 38 +
arch/mips/kernel/time.c | 4
arch/mips/kernel/traps.c | 131 +++-
arch/mips/kernel/unaligned.c | 13
arch/mips/mm/fault.c | 15
arch/ppc/config.in | 2
arch/ppc/kernel/entry.S | 38 +
arch/ppc/kernel/irq.c | 6
arch/ppc/kernel/misc.S | 4
arch/ppc/kernel/process.c | 15
arch/ppc/kernel/syscalls.c | 4
arch/ppc/kernel/time.c | 6
arch/ppc/kernel/traps.c | 87 ++
arch/ppc/mm/fault.c | 16
arch/s390/config.in | 2
arch/s390/kernel/entry.S | 18
arch/s390/kernel/process.c | 5
arch/s390/kernel/sys_s390.c | 3
arch/s390/kernel/traps.c | 118 +++
arch/s390/mm/fault.c | 12
arch/sh/config.in | 3
arch/sh/kernel/entry.S | 42 +
arch/sh/kernel/irq.c | 14
arch/sh/kernel/process.c | 13
arch/sh/kernel/sys_sh.c | 4
arch/sh/kernel/traps.c | 88 ++
arch/sh/lib/checksum.S | 1
arch/sh/mm/fault.c | 15
drivers/Makefile | 1
drivers/input/mousedev.c | 1
drivers/s390/s390io.c | 3
drivers/s390/s390mach.c | 12
drivers/trace/Config.help | 36 +
drivers/trace/Config.in | 4
drivers/trace/Makefile | 17
drivers/trace/tracer.c | 1382 +++++++++++++++++++++++++++++++++++++++++++
drivers/trace/tracer.h | 275 ++++++++
fs/buffer.c | 4
fs/exec.c | 7
fs/ioctl.c | 6
fs/open.c | 10
fs/read_write.c | 44 +
fs/select.c | 10
include/linux/trace.h | 433 +++++++++++++
ipc/msg.c | 3
ipc/sem.c | 2
ipc/shm.c | 3
kernel/Makefile | 6
kernel/exit.c | 6
kernel/fork.c | 5
kernel/itimer.c | 5
kernel/sched.c | 6
kernel/signal.c | 4
kernel/softirq.c | 16
kernel/timer.c | 4
kernel/trace.c | 692 +++++++++++++++++++++
mm/filemap.c | 4
mm/memory.c | 4
mm/page_alloc.c | 6
mm/swap_state.c | 5
net/core/dev.c | 7
net/socket.c | 10
73 files changed, 3901 insertions(+), 17 deletions(-)

adds hooks all over the place.

The security code adds hooks everywhere too, but those deliver end-user
functionality rather than being purely a developer support tool.

Developer support tools are good, but are not as persuasive as end-user
features. Because the audience is smaller, and developers know how to
apply patches and rebuild stuff.

> Have we simply not figured out the secret handshake?

It's a balance between (ongoing maintenance cost multiplied by the number of
impacted developers) versus (additional functionality multiplied by the
number of users who benefit from it). To my mind, LTT (and kgdb and various
other developer-support things) don't offer good ratios here.

> I'd really like to have some advice here since I believe we have tried every
> trick in the book: posting the patches for review, asking kernel developers for
> input, porting the patches to multiple architectures, modulirizing the system,
> etc.

If it could use kprobes hooks that'd be neat. kprobes is low-impact.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/