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