little example of my proposal
Carlos Manuel Duclos Vergara
I left in my web page a small C program that indexes the System.map
This program is intended to communicate with linice as a user_helper program
to provide updated information about where are the kernel symbols. Linice
should call this program any time it needs to find about some symbol address.
Then Linice can search the memory and hook into some function. This avoids the
problem of having linice autoloading and uses a standard mechanism used by
other parts of the kernel (hotplug specially).
Anyway, this program is just a concept proof and not a demostration of C
programming. I think tomorrow I will write the driver code to interact with
this program.
bye
PS my web page is at http://www.elbazaar.cl/~carlos
--
Carlos Manuel Duclos Vergara
car...@embedded.cl
http://www.elbazaar.cl/
Goran
So, if I understand correctly, the Linice module would load without any
knowledge of specific symbols (like it needs for 2.4: via module
parameters). Then it would query any symbol it needs by calling that
user helper app, and by carefully using selected public symbols, it
would scan the memory and use some additional smarts that we can
hardcode in order to find the correct addresses to hook (which are not
exported).
In order to load and operate Linice initially, we really dont need all
of those symbols. For example, to start we dont need to hook keyboard,
since after Linice installs itself into the IDT, it will break at any
INT3, so we can simply run a user app with INT3 embedded to kick into
Linice. Then if you have PS/2 keyboard, Linice also hooks into the
keyboard interrupt to internally process all keys, it should work. Then
we can use Linice to peek all over the kernel and make sure any code
search patterns are correct.
The way hotkey break works is indirect: When you press a hotkey, Linice
recognizes the codes (function called by the keyboard layer hook) and
sets one internal flag. Since it also hooks the timer interrupt, it
checks that flag every timer interrupt and will break via it if the
flag is set. That is done to have a consistent stack frame from the IDT
when entering the debugger (keyboard hook would have a different stack
frame), and simplifies things. The only drawback is if the timer is
off, you can't hotkey break. I assume the timer ticker is always on
(unless the machine is really in a screwed up state...)
If you need to do any code re-arrangements, just do it the way you can
make it work, we can even have a separate source branches for 2.4
(published, works) and 2.6 which may look entierly different. Later we
will merge common code into one tree so any fixes/features get shared.
Thanks!
- Goran