Query regarding extracting instruction which caused a data-abort exception

Wed Jun 14 15:15:01 CEST 2017

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genode.org/pipermail/users/attachments/20170614/44ac4df4/attachment.html>