[panda-users] Osi_linux plugin

Simone Mazzoni simone.mazzoni13 at gmail.com
Fri Apr 17 13:38:05 EDT 2015


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/cc6f830e/attachment-0001.htm
-------------- 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/cc6f830e/attachment-0005.png
-------------- 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/cc6f830e/attachment-0006.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/cc6f830e/attachment-0007.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/cc6f830e/attachment-0008.png
-------------- 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/cc6f830e/attachment-0009.png


More information about the panda-users mailing list