Messages in this thread |  | | From | Karim Yaghmour <> | Subject | Re: The case for a standard kernel debugger | Date | Thu, 5 Oct 2000 19:09:31 -0400 |
| |
richardj_moore@uk.ibm.com wrote: > One big argument against RAS of any sort is that it bloats the kernel and > not every one wants it (until they have a problem). A further argument with > Linux is that you may have to do quite a bit of hard work to get the subset > of RAS you need to co-exist, if it exists at all. Something we're working > on which may help resolve this, and will be made available with the next > drop of Dynamic Probes is Generalised Kernel Hooks Interface (GKHI). The > idea here is to make all our RAS function the option of being dynamically > loadable kernel modules. In most cases we don't need to modify kernel > function, just get control at the right time. So we place hooks in kernel > source, which remain dormant until activated by the GKHI when a RAS module > asks it to. Maybe this will provide a way out of the difficulty.
Sorry for catching this a bit late, but I would like to point out that there already is a generalized kernel hooks interface, that does exactly what is described above, as part of the Linux Trace Toolkit. The hooks inserted in the kernel source don't modify the kernel's behavior, though they can trigger callback functions. To hook onto an event, the following function is used: int trace_register_callback(tracer_call pmTraceFunction, uint8_t pmEventID)
Once this is called, the occurrence of the given event will generate a call to the given callback function. Hence the inserted hooks are dormant until used.
On top of this callback interface, I am currently in the process of completing a state machine engine that would enable it's user to specify event driven state machines. What does this mean? Well, as Alan had suggested, this could be used to test a driver's actual behavior with the state-machine that models it's theoretical behavior. Furthermore, and I think this is a field open with a lot of very interesting opportunities, state machines could be developed that model intrusions and attacks. Hence, the state machine engine could be used as the basis of a very powerful intrusion detection system. The basic example of this is stack overflows. A lot of very cleaver schemes have been developed in order to detect these types of hacks. Yet, with a state-machine that models the types of attacks being conducted, it wouldn't matter which stack overflowed or who did what since the state machine would catch any unauthorized event sequence and, possibly, kill the culprit process, suspend it or warn the sysadmin.
That said, I do think that dynamically inserted probes are useful. As Richard has pointed out, there are situations where this makes a big difference. In a sense, Dprobes could use the architecture already put forward by LTT to log custom events in a system trace and could use the trace hooking mechanism already available to implement whatever RAS function comes on top.
For a full discussion on the performance and architecture issues regarding LTT, I invite the interested reader to take a look at the paper I presented last June at the annual Usenix technical conference: http://www.opersys.com/LTT/ltt-usenix.ps.gz
And LTT can be found at: http://www.opersys.com/LTT/
Cheers
=================================================== Karim Yaghmour karym@opersys.com Operating System Consultant (Linux kernel, real-time and distributed systems) =================================================== - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |