Query regarding extracting instruction which caused a data-abort exception

Wed Jun 14 15:36:24 CEST 2017

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?

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
>