Thanks a lot Stefan, Will correlate with the linux binary.

Riju

> Hi,
>
> On 06/14/2017 02:40 PM, rijurekha@...71... wrote:
>>
>> We want to read the instruction faulting in NW linux in tz_vmm,
>> disassemble it, emulate it in genode code and restart the VM at the next
>> instruction of the normal world. Do you think this is feasible, or your
>> comments about "synchronous data abort in IMX53 vs. asynchronous aborts
>> in
>> Versatile Express" don't hold always?
>
> As I said in my previous mail: I only observed synchronous data-abort on
> i.MX53. So I think this is not the show-stopper.
>
> Anyway please read my whole mail especially the section regarding the
> caching issues. Being in your position, I would first correlate the
> instruction pointer values with your Linux binary, e.g. using objdump,
> before you start to do instruction decoding on cache-incoherent memory.
>
> Regards
> Stefan
>
>>
>> Thanks!
>> Riju
>>
>>> Hello,
>>>
>>> On 06/13/2017 11:17 AM, Abhishek Kumar wrote:
>>>> Hello
>>>> I am trying to modify genode trustzone. I want to read the instruction
>>>> which lead to data abort exception in normal world, in the `dump`
>>>> function in tz_vmm. I have value of all the registers through `_state`
>>>> register. We tried with `_state->ip`. On converting 16 bits stored at
>>>> the address pointed by _state->ip, we got ARM Thumb instruction:
>>>>
>>>>     STRH    R0, [R0, #6]
>>>>
>>>>
>>>>
>>>> But the value (R0) + 6, doesn't match dfar. We're not sure if
>>>> _state->ip
>>>> is the register to go with. We tried with _state->mode[2].lr which is
>>>> lr_abt register. But the address stored in lr_abt, lr_abt-16,
>>>> lr_abt-32
>>>> all have 0s.
>>>>
>>>> Which is right register to get the address of the instruction which
>>>> caused the data-abort exception?
>>>
>>> As long as you get an synchronous data-abort from the normal world,
>>> reading the current instruction pointer of the 'state' structure is
>>> perfectly fine. The mode-specific lr register is useful for the
>>> handling
>>> of MMU faults within the "normal" world itself. They are not modified,
>>> as long as the "normal" world MMU can resolve an access, but some bus
>>> resp. CSU is answering that the access is not allowed. This will not
>>> change the "normal" world register set.
>>>
>>> On the other hand, in general a bus fault triggered by unallowed access
>>> of the "normal" world does not necessarily mean a synchronous
>>> data-abort, although on i.MX53 I only observed those. In general, it
>>> can
>>> also provoke an asynchronous external data-abort, which means that the
>>> instruction pointer is not necessarily pointing to the instruction that
>>> triggered the fault.
>>>
>>> Moreover, looking at the "normal" world's memory from the secure side
>>> is
>>> troublesome. Because the normal and secure world's memory view is not
>>> cache-coherent. Cache entries are always tagged by the NS bit. That
>>> means you have to take care to flush caches yourself. If you want to
>>> debug instructions, you should instead look at the Linux binary itself
>>> and not into the memory on the secure side. To me it looks strange that
>>> you identify a Thumb instruction in the kernel here.
>>>
>>> Btw. these kind of TrustZone/i.MX53 questions were asked repeatedly in
>>> the past, and are mostly answered in our TrustZone report:
>>>
>>>   https://genode.org/documentation/articles/trustzone
>>>
>>> and in the discussions of our mailing list:
>>>
>>>   https://sourceforge.net/p/genode/mailman/search/?q=trustzone
>>>
>>> Regards
>>> Stefan
>>>
>>>>
>>>> Thanks
>>>> Abhishek
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> genode-main mailing list
>>>> genode-main@...172...net
>>>> https://lists.sourceforge.net/lists/listinfo/genode-main
>>>>
>>>
>>> --
>>> Stefan Kalkowski
>>> Genode Labs
>>>
>>> https://github.com/skalk · http://genode.org/
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> genode-main mailing list
>>> genode-main@...172...net
>>> https://lists.sourceforge.net/lists/listinfo/genode-main
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> genode-main mailing list
>> genode-main@...169.....172...net
>> https://lists.sourceforge.net/lists/listinfo/genode-main
>>
>
> --
> Stefan Kalkowski
> Genode Labs
>
> https://github.com/skalk · http://genode.org/
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> genode-main mailing list
> genode-main@...449...2...net
> https://lists.sourceforge.net/lists/listinfo/genode-main
>


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
genode-main mailing list
genode-main@...172...net
https://lists.sourceforge.net/lists/listinfo/genode-main