Tracking IPC calls
grizzard at gmail.com
Tue Mar 29 21:23:05 CEST 2005
> >>>jdb can log IPC messages into the trace buffer. Enable them with
> >>>'I*IR+', look at the trace buffer with 'T'. Is that what you are looking
> >>Well that's a start. What we are trying to do is the same thing
> >>programatically. We want to be able to track IPCs over long periods
> >>of time, only storing interesting IPCs. The short story is that we
> >>are working on a number of security applications where this ability
> >>would be interesting. Any pointers on doing the same programatically?
> >> Maybe a look at the jdb code would help?
> I would like to make just an additional note of warning. The tracebuffer
> should serve your short term needs, also because its content is directly
> at user-level. However, the trace buffer is a debugging feature and
> should be regarded as a security hole in a real-life system. So far we
> have no plans of adding an additional mechanism for securely monitoring
> IPC. The indendet way this should work is by installing a monitor in the
> IPC path using mechanisms somehow comparable to IPC redirection
> (http://l4ka.org/publications/2000/synchronous-ipc.pdf). Note, however,
> that this monitoring bears an overhead of an additional IPC and cannot
> be made completely transparent.
Interesting. Ideally the IPC monitor would exist in the kernel and be
as transparent as possible. What I am envisioning is modifying the
interrupt handler that handles the L4 sys calls. I think the jdb code
may be doing something like this, but I need to keep digging into it.
So the big problem that I see for achieving transparency is the
processing and memory overhead. I can see how this would be an issue
for timing. Other than that, I am not thinking of any side effects
that would nullify the transparency?
More information about the l4-hackers