All,
We are working with the Fiasco kernel on x86 arch. We are trying to track IPC messages between processes and maintain a buffer of them in a data structure inside the kernel, maybe buffer to a deticated user space server later. Any pointers as to the best place to add our hooks? We've been playing around with l4/kernel/fiasco/src/kern/shared/idt.cpp. Not sure if we are on the right track or not? Any suggestions?
Thanks!
-Julian
On Mon Mar 28, 2005 at 16:48:02 -0500, Julian Grizzard wrote:
We are working with the Fiasco kernel on x86 arch. We are trying to track IPC messages between processes and maintain a buffer of them in a data structure inside the kernel, maybe buffer to a deticated user space server later. Any pointers as to the best place to add our hooks? We've been playing around with l4/kernel/fiasco/src/kern/shared/idt.cpp. Not sure if we are on the right track or not? Any suggestions?
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?
Adam
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?
Thanks!
-Julian
On Mon Mar 28, 2005 at 17:52:35 -0500, Julian Grizzard wrote:
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?
Sure. :) This logging can be restricted to various things like a thread, a task etc. Adding another restriction for your needs should be doable, hopefully. Just look at files like jdb_trace* or thread-log.cpp.
Adam
On Mon Mar 28, 2005 at 17:52:35 -0500, Julian Grizzard wrote:
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.
Marcus
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
l4-hackers@os.inf.tu-dresden.de