-
Notifications
You must be signed in to change notification settings - Fork 6
[QUESTION]How to use granary appropriately? #17
Comments
These are good questions and I never really documented the process very well. First, any client with Okay, so, the CFG tool. Most of the time, the only time something gets logged to the kernel debug message log is when modules are loaded/unloaded, or when Granary is initializing itself. Beyond that, Granary doesn't support a useful on-demand logging mechanism for transparency reasons (as well as laziness on my part). But, Granary can do "batch" logging that is accessible from user space, and this is how control-flow graph info is extracted from the CFG tool. So, first, build Granary with the CFG tool, using approximately the following commands: Next, launch your VM using Next, load Granary into the VM. If your VM host name (as configured with SSH) is Now Granary has been loaded, but not started. The distinction between loading and starting Granary is especially important for debugging purposes. For example, if you are debugging a new or existing client that is crashing, then you want to be able to catch the crash in the act, especially if it happens early during Granary's initialization or instrumentation of code. A sane way to debug Granary is to modify the hard-coded paths in the Granary-provided Now, go into your VM, either graphically or through SSH, and run the following command to initialize Granary: Now, load your module. If you dump the tail of the kernel debug message log via This example started with the The logs are now temporarily stored in a relay file system, and can stored by running this command: The file Using the |
thanks! Sorry for boring you frequently.But I really want your help. :) |
Here is how the bounds_checker does it: I suggest reading the watchpoints paper. They are not watchpoints in the Best Regards, Peter Goodman, On 28 February 2014 20:56, Ren Zhen notifications@github.com wrote:
|
Hey,thanks a lot! |
Hi Peter, after all above, what's the right way to debug? thanks! |
Granary breakpoints section. 2)use gdb for remote debugging; after all above, when excuting run in gdb,it says : what's the right way to debug? thanks! —Reply to this email directly or view it on GitHub. |
1). yes,I did. |
Is that a "yes" on step 2 as well? If so, can you copy and paste what shows Best Regards, Peter Goodman, On 2 March 2014 20:00, Ren Zhen notifications@github.com wrote:
|
yes,both 1) and 2). Kernel setup30 if !$in_user_space Granary breakpoints38 catch throw
|
I think one issue is that you are referencing vmlinuz instead of vmlinux. Try running If gdb doesn't find the client::wp::visit_overflow function, then try You should be able to get the mangled name from there, and try adding a Best Regards, Peter Goodman, On 2 March 2014 21:33, Ren Zhen notifications@github.com wrote:
|
1)I found vmlinux in But VM also died! |
This might be a dumb question, but did you run the continue ( Okay, lets try running these steps:
If you hit any issues then please copy & paste the whole gdb session. Thanks for your patience! |
Do as your steps: 4)no native_safe_halt. |
what is more: |
after a while,VM hangs(stoped),but gdb can excute |
single-stepping and leaving the VM interrupted (i.e. in the GDB command interpreter) for a while will usually kill the VM. This typically happens because of kernel watchdogs that look for soft/hard lockups and unresponsiveness, and then start doing bad things. I usually see native_safe_halt but not seeing it is fine. Have you tried loading your special module (after initializing Granary) to see if the breakpoint on visit_overflow gets hit? |
1)initializing Granary; } breakpoint 6 still be set at wrong file /home/renzhen/granary/clients/watchpoints/instrument.h, |
I agree that is unusual. Can you try doing Best Regards, Peter Goodman, On 3 March 2014 00:27, Ren Zhen notifications@github.com wrote:
|
0xffffffffa0207910 is from Breakpoint 6 at 0xffffffffa0207910: file /home/renzhen/granary/clients/watchpoints/instrument.h, line 354. 3)add breakpoint,it seems failure: 0xffffffffa020792d and 0xffffffffa0207930 are from 2) |
To add a breakpoint to an address, do 0xffffffffa0207910 is from Breakpoint 6 at 0xffffffffa0207910: file /home/renzhen/granary/clients/watchpoints/instrument.h, line 354. 3)add breakpoint,it seems failure: 0xffffffffa020792d and 0xffffffffa0207930 are from 2) —Reply to this email directly or view it on GitHub. |
Hi peter,
2)the compiler may optimized the kernel code. 3)Have you tried set breakpoint visi_overflow in your computer? |
I want to see granary's functionality,so I have tried the following:
1.installed granary sucessfully,with config GR_CLIENT=cfg,or null_plus,or bounds_checker, or everything_watched etc;
2.test with a brief kernel module,in which I kmalloc an array memory to a poiter,then
write out of its bound, and without free this memory even after delmod this module.
3.use dmesg, It always only says granary initialised, and test module COMING and GOING so on.It seems granary does not work!
what is wrong I probablly make?
could you provide a brief user manual. thanks a lot! :)
The text was updated successfully, but these errors were encountered: