Re: The case for a standard kernel debugger

[Karim Yaghmour]

[e-mail] 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
               [e-mail]
          Operating System Consultant
 (Linux kernel, real-time and distributed systems)
===================================================