Messages in this thread |  | | | Date | Tue, 2 Mar 2004 10:02:14 -0500 | | From | Rik Faith <> | | Subject | Re: [PATCH][RFC] Light-weight Auditing Framework |
| |
On Tue 2 Mar 2004 06:09:09 -0500, Rik Faith <faith@redhat.com> wrote: > On Tue 2 Mar 2004 10:44:38 +0100, Olaf Kirch <okir@suse.de> wrote: > > A better approach may be to have the kernel write audit records > > directly to the audit trail; this solves both the record loss issue > > and improves performance. > > This seems like it would solve several problems. I'll have to think > about it more. (You still have to worry about what happens when the > drive is too slow for the message rate, how to detect this, and, > perhaps, how to limit its impact on systems where reliable delivery of > messages is not absolutely critical. With netlink, these worries are > easy to deal with.)
OK, I've thought about this more. I can appreciate the argument that writing directly to disk avoids the performance impact of having a user-space daemon write to disk (e.g., scheduling and, possibly, extra copies). However, I do not believe this addresses the fundamental problem and, because of the nature of the problem, I do not believe the performance improvement will be observed in all cases. Let me explain.
CPUs can generate audit records magnitudes of order faster than they can be written to disk. Further, the production is non-uniform. Because this problem involves a bursty producer and a slow consumer, I view it as a queuing problem. Writing directly to disk makes the consumer marginally faster, but it does not change the fundamental relationships in the problem -- the consumer is still magnitudes of order slower than the producer. This means that, even though the direct-write consumer is faster, the speed of the whole queue hasn't changed much, if at all.
Further, I am concerned that using direct writes instead of netlink moves hard problems from one (simple, flexibly) layer to another (more complex, less flexible) layer. For example, the file system may have already made some decisions for you that you could have made differently if you had access to information about the netlink-managed queue.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |