Query regarding extracting instruction which caused a data-abort exception

Thu Jun 15 08:19:07 CEST 2017

On 06/14/2017 03:36 PM, rijurekha at ...71... wrote:
> Follow up question:
> 
> At https://sourceforge.net/p/genode/mailman/message/34685275/, you said
> ========================================================================
> In the tz_vmm, the whole non-secure RAM is mapped as IOMEM [4], which is
> - using ARM-speak - tagged as "Device Memory" and thus non-cached. So,
> yes, the tz_vmm must not flush caches as it should always use these
> non-cached mappings.
> ========================================================================
> 
> So this particular physical address used by linux UART code is non-cached
> in genode? So why should cache-incoherence be an issue in tz_vmm?

As long as it is mapped uncached in the secure world *and* the normal
world, cache-coherency is not an issue. As far as I understood you
correctly, you tried to decode instructions within the Linux kernel's
text segment? I bet the Linux kernel maps it as cached memory.

Regards
Stefan

> 
> Thanks!
> Riju
> 
>> Hello Stefan
>> Thanks for your reply. I have a quick clarification to ask for. As you
>> mentioned about problems with cache-incoherent memory. What we are trying
>> to read is in code segment, I don't see how it can be changed. Since it is
>> not changing cache coherency should not be an issue, this is my
>> understanding. Can you please help me see where I might be wrong?
>>
>> Thanks
>> Abhishek
>>
>> On Wed, Jun 14, 2017 at 2:58 PM, <rijurekha at ...71...> wrote:
>>
>>> Thanks a lot Stefan, Will correlate with the linux binary.
>>>
>>> Riju
>>>
>>>> Hi,
>>>>
>>>> On 06/14/2017 02:40 PM, rijurekha at ...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 at lists.sourceforge.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 at lists.sourceforge.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 at lists.sourceforge.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 at lists.sourceforge.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 at lists.sourceforge.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 at lists.sourceforge.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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/genode-main
> 

-- 
Stefan Kalkowski
Genode Labs

https://github.com/skalk · http://genode.org/