[panda-users] Different values for the same ASID

[aicardi@eurecom.fr]

Thanks for the answer!

I kept digging into the osi plugins and I found out that there was  
another problem that involved tracing the ASID changes and spotting  
the creation/termination of a new process.
I kind of got that this part of the plugin is not fully developed but  
I needed to enable it, so I added to the compilation flags  
-DOSI_PROC_EVENTS (and also -DPROC_EVENTS_DBG to print debug  
information).
What I realized is that inside the function ProcState::update (in  
osi/osi_proc_events.cpp) there are some ASID modifications that I  
cannot explain.
I see this kind of behavior when I trace the execution of a program  
that I've started from a linux bash shell. By looking at the debug  
information printed in that function I can track every running process  
(with the corresponding name, PID and ASID) every time there has been  
a context switch.
In a normal scenario I expect to see the "parent" shell (let's say  
with PID=0x9e1 and ASID=0xf70ed000, from one of my samples) executing  
a fork(), creating a second shell (with PID=0xacd and  
ASID=0xf7e3c000). The second shell, then, should call execve() to  
execute my program (say ./test_program).
The weird thing is that just before calling execve() there is another  
context switch where I can see that the process with PID=0xacd (still  
called 'bash') suddenly changes its ASID from 0xf73ec000 to 0xf73cd000.
At the following context switch I can see that process 0xacd changed  
its name from 'bash' to 'test_program' (as expected) but it kept the  
"new" ASID=0xf73cd000.

Do you have any idea why this is happening?


Thank you in advance!
samaicardi



Quoting Brendan Dolan-Gavitt <brendandg at nyu.edu>:

> The osi plugins tend to retrieve the value that the kernel has stored for
> the ASID in the process data structure. On Linux, that's the kernel
> *virtual* address of the page directory. If you need the ASID value seen by
> the CPU (the physical address), you can subtract off the kernel offset.
>
> It is annoying that this is inconsistent with how it works for Windows
> (where the ASID value the kernel stores is the physical address, and so it
> matches the value stored in the QEMU virtual CPU). I think we would be
> happy to change this, if you want to put together a PR...
>
> -Brendan
>
> On Mon, Nov 20, 2017 at 7:58 PM, <aicardi at eurecom.fr> wrote:
>
>> Hello everyone,
>>
>> I am trying to analyze some linux-x86 replays. I would like to trace
>> every new process and every time a context switch occurs (by
>> registering the callback PANDA_CB_ASID_CHANGED).
>> The thing is that there is a discrepancy between two different ways of
>> retrieving the current asid. One way is to access the 'new_asid'
>> argument of the function registered for the event
>> PANDA_CB_ASID_CHANGED, the other is to call get_current_process(cpu)
>> and access the 'asid' field of the OsiProc struct.
>> The problem is that if I try to use the two methods at the same time I
>> get different asids: if 'new_asid' is e.g. 0xaaaabbbb then the value
>> returned from get_current_process(cpu) is typically the same one but
>> ORed with 0xf0000000 (i.e. 0xfaaabbbb).
>> Does anybody know why this happens?
>>
>> I also noticed that sometimes the arguments of the function registered
>> for PANDA_CB_ASID_CHANGED ('old_asid' and 'new_asid') have the same
>> value. Is it normal? I thought they should be different since there
>> has been a context switch.
>>
>>
>> Thank you in advance!
>> samaicardi
>>
>>
>> ------------------------------------------------------------
>> -------------------
>> This message was sent using EURECOM Webmail: http://webmail.eurecom.fr
>>
>>
>> _______________________________________________
>> panda-users mailing list
>> panda-users at mit.edu
>> http://mailman.mit.edu/mailman/listinfo/panda-users
>>
>
>
>
> --
> Brendan Dolan-Gavitt
> Assistant Professor, Department of Computer Science and Engineering
> NYU Tandon School of Engineering
>



-------------------------------------------------------------------------------
This message was sent using EURECOM Webmail: http://webmail.eurecom.fr