public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrea Arcangeli <andrea@suse.de>
To: Jesse Pollard <pollard@tomcat.admin.navo.hpc.mil>
Cc: Josue.Amaro@oracle.com, linux-kernel@vger.kernel.org
Subject: Re: Advanced Linux Kernel/Enterprise Linux Kernel
Date: Tue, 14 Nov 2000 18:34:07 +0100	[thread overview]
Message-ID: <20001114183407.A6576@athlon.random> (raw)
In-Reply-To: <200011141459.IAA413471@tomcat.admin.navo.hpc.mil>
In-Reply-To: <200011141459.IAA413471@tomcat.admin.navo.hpc.mil>; from pollard@tomcat.admin.navo.hpc.mil on Tue, Nov 14, 2000 at 08:59:49AM -0600

On Tue, Nov 14, 2000 at 08:59:49AM -0600, Jesse Pollard wrote:
>    I (meaning me) would like the ability to audit every system call. (yes,
>    this is horrendous, if everything is logged, but I want to be able to
>    choose how much is logged at the source of the data, rather than at
>    the destination. That would reduce the total data flood to what is
>    manageable or desired.

Yes, you really need to control the logging at the source of the data. To do
that we need to use to use self modifying tricks as dprobes and GKHI does to
provide "fast unregistered hooks".

o	with dprobes the hooks will be _absolutely_ zero cost if they're
	unregistered but they're very costly (basically enter/exit kernel
	for every hook) when they're registered (so they're ok if
	your auditing doesn't happen all the time).

	dprobe hooks also binds you to a certain binary image (not a generic
	interface stable across different kernel binaries)

o	GKHI provides fast unregistered hooks too, if implemented with
	5 nops as suggested they will cost around 3 cycles when they're
	unregistered, and they will provide good performance also when
	they're registered (no enter/exit kernel as dprobes needs
	to do) and you can control them via userspace without being dependent
	on binary offsets (just like with every other hook we have in kernel
	just now but with the difference that our current hooks aren't self
	modifying so they adds branches also when they're unregistered so
	they're bad for usages like syscall auditing). However bloating every
	syscall with tons of GKHI hooks isn't possible either or it will become
	a performance problem too eventually. It depends what you need exactly.
	I'd say one GKHI hook per syscall shouldn't have measurable impact on
	performance.

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

  parent reply	other threads:[~2000-11-14 18:04 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-11-14 14:59 Advanced Linux Kernel/Enterprise Linux Kernel Jesse Pollard
2000-11-14 15:47 ` David Weinehall
2000-11-14 17:14 ` Michael Rothwell
2000-11-14 16:20   ` Mike Dresser
2000-11-14 17:27     ` Michael Rothwell
2000-11-14 17:32       ` Michael Rothwell
2000-11-14 16:25   ` Richard B. Johnson
2000-11-14 17:29     ` Michael Rothwell
2000-11-14 16:38       ` Mark Hahn
2000-11-14 19:23         ` spam
2000-11-14 16:41       ` Richard B. Johnson
2000-11-14 17:06         ` Michael Meissner
2000-11-14 17:59           ` Richard B. Johnson
2000-11-14 17:51         ` Buddha Buck
2000-11-14 18:10         ` Michael Rothwell
2000-11-14 18:00           ` Richard B. Johnson
2000-11-15  0:31             ` Gerhard Mack
2000-11-14 20:08         ` Alexander Viro
2000-11-14 16:57       ` David Relson
2000-11-14 18:17     ` Rik van Riel
2000-11-14 19:15     ` spam
2000-11-14 16:53   ` David Relson
2000-11-14 17:06   ` Andrea Arcangeli
2000-11-14 17:55   ` Andreas Dilger
2000-11-14 18:35   ` Christoph Hellwig
2000-11-14 23:06   ` Werner Almesberger
2000-11-15  4:25   ` Albert D. Cahalan
2000-11-17 22:10   ` Daniel Phillips
2000-11-18  0:58     ` Eric W. Biederman
2000-11-18 20:13       ` Daniel Phillips
2000-11-18 16:40     ` Pavel Machek
2000-11-19 20:37       ` Daniel Phillips
2000-11-20 13:34         ` Pavel Machek
2000-11-14 17:34 ` Andrea Arcangeli [this message]
  -- strict thread matches above, loose matches on Subject: below --
2000-11-17  5:28 Bernd Eckenfels
2000-11-15  4:19 Marty Fouts
2000-11-14 18:20 Marty Fouts
2000-11-14 18:18 Marty Fouts
2000-11-14 18:10 Marty Fouts
2000-11-14 19:43 ` Steve VanDevender
2000-11-15  1:13   ` Leo Mauro
2000-11-14 18:06 Marty Fouts
2000-11-14 18:03 Marty Fouts
2000-11-08 20:31 [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI) richardj_moore
2000-11-13 21:56 ` Advanced Linux Kernel/Enterprise Linux Kernel Josue Emmanuel Amaro
2000-11-14  7:49   ` Lars Marowsky-Bree
2000-11-14 18:33   ` lamont

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20001114183407.A6576@athlon.random \
    --to=andrea@suse.de \
    --cc=Josue.Amaro@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pollard@tomcat.admin.navo.hpc.mil \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox