Query regarding extracting instruction which caused a data-abort exception

Stefan Kalkowski stefan.kalkowski at ...1...
Wed Jun 14 14:24:41 CEST 2017


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:


and in the discussions of our mailing list:



> 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/

More information about the users mailing list