Tracking IPC calls

[Julian Grizzard]

> >>>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
> >>>for?
> >>>
> >>>
> >>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?
> >>
> >>
> Hi,
> 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
> accessible
> 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?

-Julian