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
