[panda-users] Osi_linux plugin

Fri Apr 17 14:14:27 EDT 2015

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/5dca1c78/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/5dca1c78/attachment-0003.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/5dca1c78/attachment-0004.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/5dca1c78/attachment-0005.png