OSDev.org

I have been reading thru the intel manual on debugging.
As well as I found this article to give me the general theory of how a debugger can be created/ how they work.
http://www.alexonlinux.com/how-debugger ... f_contents

I am surprised that to step thru code the debugger has to modify each line first byte with the code 0xcc = int 3 to call the debugger handler
So in theory once the program that is to be debugged is loaded into memory and the debugger run on it.... the debugger modifies the code of
of the debuggie process putting that 0xcc (int 3 ) finishing that instruction and repeating to create breakpoints or stopping points in the program.

Questions
1) In linux debugging userland programs can be broken down into ptrace syscalls/int 3 and signals along with a few other things
But I am curious if you are debugging in kernel land how this all works since at that point you are no longer having a parent process and child process issue. (i.e no fork() ,...etc)
See in user land you grant gdb debugger access to debug a program thru ptrace syscalls and signals.h (i.e gdb can modify the process with 0xcc)
But in kernel land there is no gdb , or useland api so either one would have to build the functionality of a debugger into the kernels process loader
Or build a kernel level program that can be executed by the kernel process loader and have the ability to fork / have the ability to modify the child process code or something.

I am really curious about clearing this issue up.
What I am think is a kernel debugger <--(I believe that is there name for a debugger in kernel land) is that they are easier in theory because you don't have to ask permission for memory reads/writes normally since you are already in ring0 so you could in theory just have the debugger just be the same as your loader but instead of jumping to the code once loaded it would first set break points with 0xcc to maintain control of the kernel application.


2)
In terms of security
I know bufferoverflow days are coming to an end but could one still use ptrace to allow or write a kernel module to allow him to modify a process's instructions not just placing 0xcc's for break points like debuggers do. But it could be some rude/malicous debugger program that
places machine code like ret or push some address ,..etc At this point the theory of how to write a debugger could be used to implement a malicous debugger that does this. Thus giving you the same control as buffer overflows back in the day
sssssssssshhhhhhh I won't tell

1) debugging in this case is all done in your debug interupt handler.

2)didn't read like a question , but yes that is possible, use tools you trust.

1) debugging in this case is all done in your debug interupt handler.

Ok , but then a kernel debugger could only debug the kernel at the point of the IDT being setup before that no debugging could ever by done
So a kernel debugger will only ever be good to debug passed the point of at least the interrupts being setup.
So the only true way to step thru your kernel step by step is to run it in a virtual machine thus making it an application level program for that particular run.

2) Is there an equivalent way that windows and mac debuggers work I know in theory the use the same mechanism as linux or any other os's would int 3 ,..etc
But I am more wondering if there is an article that goes thru the function equivalent to ptrace for windows and mac?
Would be nice to know what win32 api or other api functions I can used to do the equivalent gdb ptrace() /signal.h thing a m bob

Not necessary to use int 3. You can use the debugger registers to invoke the debug handler. And if you use some vm (like bochs or virtualbox) which has an internal debugger, no IDT and debugger handler needed at all, it can debug any point without modifying the code (since vm is aware of guest's full state).

It is also possible to use GDB in conjunction with QEMU.

GDB also works with VMWare.

Most environments have different interfaces for applications and kernel debugging, and few of them are able to use the same debugger to trace calls from application to kernel for this reason. Applications typically use signals (Unix) or a DLL-interface (Win32), and these things don't exist in the kernel.

I solved this by not using application-only interfaces for debugging, rather implementing debugging at the kernel level, and then emulating the Win32 PE interface for the application and using the native interface for kernel in the debug-engine, so I can easily trace calls from application to kernel. AFAIK, Linux cannot do this, but I know Windows CE can (OTOH, the Windows CE version I used run everything in ring 0, so that might be why it worked).

Another issue with typical debuggers is that they freeze the process they are debugging, and this is not a good design for tracing calls into kernel, as you cannot freeze the kernel when debugging it.

Linux has quite a few utilities for that.. and for BSD, there is ktrace(1).

Brynet-Inc wrote:Linux has quite a few utilities for that.. and for BSD, there is ktrace(1).

It has, but they are not integrated into the application debugger.

rdos wrote:It has, but they are not integrated into the application debugger.

I don't recall saying they were, but in some cases, they might be. See DTrace.

[url]http://www.alexonlinux.com/how-debugger-works#table_of_contents
[/url]

also from the above link

it shows you the typical flow of how a debugger works to set a breakpoint but it doesn't show how you can dump registers or view varibles / memory/ the stack. Is there a general procedure like 0xcc for the registers/stack...etc dumps.

Sam111 wrote:[url]http://www.alexonlinux.com/how-debugger-works#table_of_contents
[/url]

also from the above link

it shows you the typical flow of how a debugger works to set a breakpoint but it doesn't show how you can dump registers or view varibles / memory/ the stack. Is there a general procedure like 0xcc for the registers/stack...etc dumps.

The OS needs to store the registers of threads somewhere so the debugger can read them. As the debugged thread hits a break-point or exception, the kernel needs to save it's register state and inform the debugger what happened. The debugger would then use some syscall to read registers.

In my design, saving/loading register in the scheduler uses the same area as when breakpoints or exceptions are hit. That's how the kernel debug-interface is done. The kernel also has a special "debug-queue" where threads that are debugged or stopped on exceptions are blocked.

O, I see

then I am curious what the DWARF / debugging additional sections in an ELF binary actually
enhance.... i.e int 3 or int 1 would be used to set break point or read registers / memory (variables) / stack stuff.

what exactly does the addition DWARF/debugging additional sections provide.
Since in theory you can debug any application even one without any debugging sections or symbol tables.

adding debug information allows you to see in the debugger your using what the higher level code was that failed. for example recreating C code from assembly is dodgy because compiler version is not known, optimizations are not known, spacing is not preserved, function/variable names and comments are not kept, etc. using just the registers at any given moment can work, but the more information you have the better.

It is often possible to relate a register-only dump to the original C/C++ code (by the use of a map-file), but it is not a very attractive way of doing it. A debugger with full symbolic support is much easier to use.