Query regarding extracting instruction which caused a data-abort exception

Stefan Kalkowski stefan.kalkowski at ...1...
Thu Jun 15 08:16:23 CEST 2017


On 06/14/2017 03:15 PM, Abhishek Kumar wrote:
> 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?

The Linux image typically in compressed (zImage) and gets uncompressed
by early assembler code within the Linux kernel itself. With other
words, it gets changed after you load it.

Regards
Stefan

> 
> Thanks
> Abhishek
> 
> On Wed, Jun 14, 2017 at 2:58 PM, <rijurekha at ...71...
> <mailto: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...
>     <mailto: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
>     <https://genode.org/documentation/articles/trustzone>
>     >>>
>     >>> and in the discussions of our mailing list:
>     >>>
>     >>>   https://sourceforge.net/p/genode/mailman/search/?q=trustzone
>     <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
>     <mailto:genode-main at lists.sourceforge.net>
>     >>>> https://lists.sourceforge.net/lists/listinfo/genode-main
>     <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
>     <mailto:genode-main at lists.sourceforge.net>
>     >>> https://lists.sourceforge.net/lists/listinfo/genode-main
>     <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
>     <mailto:genode-main at lists.sourceforge.net>
>     >> https://lists.sourceforge.net/lists/listinfo/genode-main
>     <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
>     <mailto:genode-main at lists.sourceforge.net>
>     > https://lists.sourceforge.net/lists/listinfo/genode-main
>     <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
>     <mailto:genode-main at lists.sourceforge.net>
>     https://lists.sourceforge.net/lists/listinfo/genode-main
>     <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/




More information about the users mailing list