[panda-users] Osi_linux plugin

Fri Apr 17 15:39:35 EDT 2015

For i386-softmmu + latest debian stable osi_linux should work out of the
box. (This is the setup I used to develop it, so you shouldn't even have to
extract new offsets.)

Can you try using osi_test plugin instead of your plugin?

Also, where does your LD_LIBRARY_PATH points to? Make sure it loads the
PANDA plugins from i386-softmmu directory.

M.

2015-04-17 11:14 GMT-07:00 Simone Mazzoni <simone.mazzoni13 at gmail.com>:

> Nope that time, I used x86_64-softmmu (for windows worked fine), but I
> tried again with i386-softmmu and it is the same thing.
> There must be a problem of offset as you said. I extracted the offsets for
> osi_linux using the kernelinfo module, so I don't know what can be wrong.
>
> The Guest OS I am working on is a Debian 7.8.0 32bit.
>
> I don't know how to solve.
>
> P.S: I am not using records but live execution (./qemu-system-i386 -m 1G
> -monitor stdio -hda debian.iso -panda 'osi;osi_linux;my_plugin')
>
> Il giorno ven 17 apr 2015 alle ore 20:01 Manolis Stamatogiannakis <
> mstamat at gmail.com> ha scritto:
>
>> Junk -> reading from the wrong location -> the offsets you are using do
>> not match your setup.
>>
>> Did you recapture your traces on i386-softmmu?
>>
>>
>>
>> 2015-04-17 10:38 GMT-07:00 Simone Mazzoni <simone.mazzoni13 at gmail.com>:
>>
>> OK, I tried just now to retrieve the name of the current process when in
>>> kernel mode (after a sysenter instruction OF35) but if I print the name or
>>> the pid of the process, I get strange values. (Notice that I deleted the
>>> rows where the process name is N/A)
>>> Here an example of the output:
>>>
>>> I do the same this in windows and work just fine, but in linux seems not
>>> to work. Any idea about the reason?
>>>
>>> Thanks.
>>>
>>> - Simone
>>>
>>> Il giorno ven 17 apr 2015 alle ore 17:56 Manolis Stamatogiannakis <
>>> mstamat at gmail.com> ha scritto:
>>>
>>>> You need to call get_current_process() when your process runs in kernel
>>>> mode. Since you are interested in syscalls, injecting the call in
>>>> instrumentation after SYSENTER instruction would work.
>>>>
>>>> This is a known limitation of the current implementation. The problem
>>>> is that calculating the task struct address of the running process while in
>>>> user mode is complicated.
>>>> It should be doable (debianwheezyx86intro does it), but requires to
>>>> extract additional kernel version specific offsets. If you have time to
>>>> investigate and fix this, it would be great.
>>>>
>>>> Working around this limitation isn't hard. Retrieve the process info
>>>> when in kernel mode. Map the info to the physical address of the PGD (do a
>>>> virt->phys conversion of the address in the OsiProc struct). Retrieve the
>>>> info when you need it in user mode (PGD is stored in CR3 register).
>>>>
>>>> There was another discussion on the subject in a previous thread
>>>> involving Igor, Brendan and myself.
>>>>
>>>> Cheers,
>>>> M.
>>>>
>>>> 2015-04-17 0:53 GMT-07:00 Simone Mazzoni <simone.mazzoni13 at gmail.com>:
>>>>
>>>> Hi,
>>>>>
>>>>> I am a little confused at the moment.
>>>>> Let me try to explain what is my purpose.
>>>>>
>>>>> I implemented a plugin that retrieve the syscall parameters from the
>>>>> syscalls called by a specific process in windows. To do that I used the Osi
>>>>> Plugin to intercept the current process in execution using the method "
>>>>> OsiProc *current = get_current_process(env);" from the osi plugin,
>>>>> and it works well.
>>>>>
>>>>> I need now to do the same thing for in a Linux x86 SO (Debian or
>>>>> Ubuntu), so I tried to use the Osi plugin as well but I noticed that that
>>>>> function return null at every execution. I thought that the problem is that
>>>>> the way a process is represented in linux is different from the one in
>>>>> windows, so I tried to use the osi_linux plugin together with the osi one
>>>>> but up to now I wasn't able to run the osi plugin.
>>>>>
>>>>> Is this reasonable?
>>>>>
>>>>> Thanks.
>>>>>
>>>>> - Simone
>>>>>
>>>>> Il giorno gio 16 apr 2015 alle ore 21:04 Manolis Stamatogiannakis <
>>>>> mstamat at gmail.com> ha scritto:
>>>>>
>>>>>>
>>>>>>
>>>>>> 2015-04-16 11:06 GMT-07:00 Simone Mazzoni <simone.mazzoni13 at gmail.com
>>>>>> >:
>>>>>>
>>>>>> 64bit?
>>>>>>> The OSI plugin work only for x86 OSes, am I wrong?
>>>>>>>
>>>>>>
>>>>>> The osi plugin is just a skeleton. It should work with anything at
>>>>>> all.
>>>>>>
>>>>>> I think there was a mention in the list that the windows
>>>>>> introspection would work only with 32bit windows - maybe this confused you.
>>>>>> But this is mostly a limitation of qemu (IIRC it can't run 64bit windows in
>>>>>> the version PANDA is based upon).
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Anyway my host system is a 64bit OS while the OS I want introspect
>>>>>>> is 32 bit. I hope it work.
>>>>>>>
>>>>>>
>>>>>> I don't think it will work. A lot of arithmetic in the plugin
>>>>>> requires to know the width of the address of the guest. It is assumed that
>>>>>> this matches the address width of the qemu target (8bytes for
>>>>>> x86_64-softmmu). This is set by the PTR macro in osi_linux.h.
>>>>>>
>>>>>> Maybe, you can make it work if you #define target_ulong as a 4byte
>>>>>> long type when compiling osi_linux. If you have time to try this and it
>>>>>> turns out it works, let us know.
>>>>>>
>>>>>> But unless you have already amassed a trove of PANDA traces from
>>>>>> 32bit linux running on x86_64-softmmu, it would be simpler to just use
>>>>>> i386-softmmu.
>>>>>>
>>>>>> M.
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Thanks for the help,
>>>>>>>
>>>>>>> - Simone
>>>>>>>
>>>>>>> Il giorno gio 16 apr 2015 17:55 Manolis Stamatogiannakis <
>>>>>>> mstamat at gmail.com> ha scritto:
>>>>>>>
>>>>>>>> There is a default kernel group hardwired in the source.
>>>>>>>>
>>>>>>>> You should point to the proper kernel group of your kernelinfo
>>>>>>>> using the kconf_group parameter. You can also point to the exact location
>>>>>>>> of your kernelinfo with the kconf_file parameter (but usually a softlink is
>>>>>>>> faster :) : "osi;osi_linux:kconf_file=...,kconf_group=...;osi_test"
>>>>>>>>
>>>>>>>> Btw, you don't have to manually extract and parse the dmesg output.
>>>>>>>> kernelinfo_parse.py script does this for you, so you only need to append
>>>>>>>> its output to your kernelinfo file. Also, make sure that your guest OS is
>>>>>>>> also 64 bit.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Manolis
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 2015-04-16 7:51 GMT-07:00 Simone Mazzoni <
>>>>>>>> simone.mazzoni13 at gmail.com>:
>>>>>>>>
>>>>>>>> Hi Manolis,
>>>>>>>>>
>>>>>>>>> I created the kernelinfo.conf file, but I do not understand where
>>>>>>>>> I have to put it in order to make the osi_linux plugin work.
>>>>>>>>> It gives me this error when I try to run panda with this command
>>>>>>>>> line --> ./qemu-system-x86_64 -m 1G -monitor stdio -hda
>>>>>>>>> ../../../challdeb.img -loadvm booted -panda 'osi;osi_linux;osi_test'
>>>>>>>>>
>>>>>>>>> What am I doing wrong?
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>>
>>>>>>>>> -Simone
>>>>>>>>>
>>>>>>>>> Il giorno gio 16 apr 2015 alle ore 15:36 Simone Mazzoni <
>>>>>>>>> simone.mazzoni13 at gmail.com> ha scritto:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> I extracted the parameters from the OS kernel that I want
>>>>>>>>>> introspect.
>>>>>>>>>>
>>>>>>>>>> The parameters are these:
>>>>>>>>>>
>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.872169]
>>>>>>>>>> --KERNELINFO-BEGIN--
>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.873067] name = #1 SMP
>>>>>>>>>> Debian 3.2.65-1+deb7u2 i686
>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.873114] task.size = 1060
>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.873249] #task.init_addr =
>>>>>>>>>> 0xC13E2FE0
>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.873279] task.init_addr =
>>>>>>>>>> 3242078176
>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.873310] task.task_offset =
>>>>>>>>>> 0
>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.873356] task.tasks_offset
>>>>>>>>>> = 212
>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.873394] task.pid_offset =
>>>>>>>>>> 292
>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.873420] task.tgid_offset =
>>>>>>>>>> 296
>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.873447]
>>>>>>>>>> task.group_leader_offset = 328
>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.873475]
>>>>>>>>>> task.thread_group_offset = 384
>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.873504]
>>>>>>>>>> task.real_parent_offset = 304
>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.873532] task.parent_offset
>>>>>>>>>> = 308
>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.873559] task.mm_offset =
>>>>>>>>>> 240
>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.873586] task.stack_offset
>>>>>>>>>> = 4
>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.873615]
>>>>>>>>>> task.real_cred_offset = 504
>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.873642] task.cred_offset =
>>>>>>>>>> 508
>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.873668] task.comm_offset =
>>>>>>>>>> 516
>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.873693] task.comm_size = 16
>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.873722] cred.uid_offset = 4
>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.873749] cred.gid_offset = 8
>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.873774] cred.euid_offset =
>>>>>>>>>> 20
>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.873813] cred.egid_offset =
>>>>>>>>>> 24
>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.873842] mm.mmap_offset = 0
>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.873867] mm.pgd_offset = 36
>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.873901]
>>>>>>>>>> mm.arg_start_offset = 152
>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.873970]
>>>>>>>>>> mm.start_brk_offset = 140
>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.874004] mm.brk_offset = 144
>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.874032]
>>>>>>>>>> mm.start_stack_offset = 148
>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.874078] vma.vm_mm_offset =
>>>>>>>>>> 0
>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.874104]
>>>>>>>>>> vma.vm_start_offset = 4
>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.874133] vma.vm_end_offset
>>>>>>>>>> = 8
>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.874161] vma.vm_next_offset
>>>>>>>>>> = 12
>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.874187]
>>>>>>>>>> vma.vm_flags_offset = 28
>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.874215] vma.vm_file_offset
>>>>>>>>>> = 80
>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.874242] fs.f_dentry_offset
>>>>>>>>>> = 12
>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.874268] fs.f_path_offset =
>>>>>>>>>> 8
>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.874293] fs.d_name_offset =
>>>>>>>>>> 20
>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.874320] fs.d_iname_offset
>>>>>>>>>> = 36
>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.874347] fs.d_parent_offset
>>>>>>>>>> = 16
>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.874369]
>>>>>>>>>> ---KERNELINFO-END---
>>>>>>>>>>
>>>>>>>>>> At this point, if I am not wrong, I have to edit the
>>>>>>>>>> kernelinfo.conf file with the new parameters. It is right or there are
>>>>>>>>>> other things to do?
>>>>>>>>>>
>>>>>>>>>> Thanks.
>>>>>>>>>>
>>>>>>>>>> - Simone
>>>>>>>>>>
>>>>>>>>>> Il giorno mer 15 apr 2015 alle ore 20:41 Manolis Stamatogiannakis
>>>>>>>>>> <mstamat at gmail.com> ha scritto:
>>>>>>>>>>
>>>>>>>>>>> When you run the plugin, kernelinfo.conf must exist in your
>>>>>>>>>>> current directory. So just soft-link it from the source directory of the
>>>>>>>>>>> plugin.
>>>>>>>>>>>
>>>>>>>>>>> In your case however, the stock kernelinfo.conf won't work
>>>>>>>>>>> because it currently contains only information for the 32bit kernel used by
>>>>>>>>>>> debian stable.
>>>>>>>>>>> So you have to compile the kernelinfo module in a guest running
>>>>>>>>>>> (ideally) the same kernel you want to introspect.
>>>>>>>>>>> Then insert it into the kernel (insertion always fails) and use
>>>>>>>>>>> the supplied python script to extract the offsets for that kernel.
>>>>>>>>>>>
>>>>>>>>>>> The offsets should then be appended to kernelinfo.conf. Also
>>>>>>>>>>> make a pull request for the updated kernelinfo.conf when you do this.
>>>>>>>>>>>
>>>>>>>>>>> IIRC, the kernelinfo module had some glitches which prevented it
>>>>>>>>>>> from compiling in recent kernels (e.g. 3.20). So if you encounter any
>>>>>>>>>>> problems, drop me an email so that I expedit making a pull request for the
>>>>>>>>>>> fixed version.
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>> M.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> M.
>>>>>>>>>>>
>>>>>>>>>>> 2015-04-15 8:26 GMT-07:00 Simone Mazzoni <
>>>>>>>>>>> simone.mazzoni13 at gmail.com>:
>>>>>>>>>>>
>>>>>>>>>>>> Hello,
>>>>>>>>>>>>
>>>>>>>>>>>> I tried to use the osi_linux plugin to get the current process
>>>>>>>>>>>> in execution but it seems not to work.
>>>>>>>>>>>> I tried to execute panda with -panda 'osi;osi_linux;osi_test'
>>>>>>>>>>>> but it gives me the following error:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Any idea of the reason?
>>>>>>>>>>>>
>>>>>>>>>>>> I noticed see that the plugin contain a "utils/kernelinfo"
>>>>>>>>>>>> folder that should contain a script or something to extract the correct
>>>>>>>>>>>> offset of the running kernel, but I do not understand how to use it.
>>>>>>>>>>>>
>>>>>>>>>>>> I tried running the osi_test on an Debian SO and on a Ubuntu
>>>>>>>>>>>> 14.04 SO.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks for the help.
>>>>>>>>>>>>
>>>>>>>>>>>> - Simone
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> panda-users mailing list
>>>>>>>>>>>> panda-users at mit.edu
>>>>>>>>>>>> http://mailman.mit.edu/mailman/listinfo/panda-users
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/panda-users/attachments/20150417/b47cbe98/attachment-0001.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Schermata 2015-04-15 alle 17.23.00.png
Type: image/png
Size: 121425 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/panda-users/attachments/20150417/b47cbe98/attachment-0003.png
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot from 2015-04-17 19:34:38.png
Type: image/png
Size: 180200 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/panda-users/attachments/20150417/b47cbe98/attachment-0004.png
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot from 2015-04-16 16:50:14.png
Type: image/png
Size: 96902 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/panda-users/attachments/20150417/b47cbe98/attachment-0005.png