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