On 06/14/2017 03:36 PM, rijure...@mpi-sws.org 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, <rijure...@mpi-sws.org> wrote: >> >>> Thanks a lot Stefan, Will correlate with the linux binary. >>> >>> Riju >>> >>>> Hi, >>>> >>>> On 06/14/2017 02:40 PM, rijure...@mpi-sws.org 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@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@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@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@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@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@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@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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
