Hi, On 06/14/2017 02:48 PM, rijure...@mpi-sws.org wrote: > Interestingly, the DFAR contains an UART address when UART is made secure > in csu_config.h and an eSDHC address when eSDHC is made secure in > csu_config.h. But this might still be a case of asynchronous abort, only > that DFAR is still pointing to the correct address where the instruction > faulted (not more data aborts have occurred since then), but the other > registers have changed because of the asynchronous nature of the abort. > > How can we know if the abort is asynchronous vs. synchronous? Is an lr_abt > with all 0's already a clear indication that this is asynchronous, and > there is no hope for device emulation?
I would not generalize or depend on anything related to the "exception" case, because TrustZone is not meant as a virtualization solution. Normally, you should just turn off the device or reboot in emergency case. Having said this: Obviously, in case of the i.MX53 the secure world's DFAR is updated to the faulting address if the "normal" world provokes a security violation "on the bus". Therefore, I could imagine the DFSR register is updated too. Normally, this register contains information about the type of data-fault. Have a look at: repos/base-hw/src/core/spec/arm_v7/trustzone/kernel/vm.cc where the DFAR is read and set to the VM state structure, and you could print it, or write it to an arbitrary register for debugging purposes. Regards Stefan > > Thanks! > Riju > > >> Thanks Stefan! >> >> We are actually trying to do device emulation in the secure world genode, >> for peripherals marked as secure (UART or ESDHC) in csu_config.h. We got >> encouraged by the following discussion at >> http://genode.org/documentation/articles/trustzone >> >> ========================================================================== >> The basic idea of emulating device access is to let the hypervisor pass >> control to the VMM as soon as the non-secure OS accesses an address >> outside the permitted physical address ranges. The VMM can then inspect >> the address in question and the program counter of the non-secure OS that >> raised the access violation. Given the program counter value, the VMM can >> fetch and decode the faulting instruction and emulate it in software. >> Because ARM is a RISC architecture, the instruction decoding is rather >> simple. The instruction in question can only be a load or a store >> instruction. No other instruction would raise an access fault. For read >> operations, the VMM would provide the result of the operation by changing >> the corresponding entry of the VM state structure. >> >> That said, we found that the trap-and-execute emulation model is not >> possible to implement with the TrustZone protection mechanisms in general. >> Dependent on the concrete platform, the CPU will not immediately enter the >> hypervisor when the fault occurs but attempts to perform the bus >> transaction. This transaction will trigger an external data abort. This >> abort is similar to a device interrupt. It principally raises an exception >> (so the violation can be detected) but not always immediately. Therefore, >> there is no way to uniquely reconstruct what happened in between the >> invalid access and the reception of the external abort exception in the >> hypervisor. Neither can the hypervisor recover the non-secure world to a >> useful state. >> >> A noteworthy advantage of the CSU compared to the ARM TZ protection >> controller within the ARM Cortex A9 reference board is the way of how >> access violations are handled. As stated in Device emulation, the ARM TZ >> protection controller responds to invalid accesses with an asynchronous >> external abort exception, similar to a device interrupt. Upon the >> execution of an offending instruction, the TZ protection controller >> detects the violation, yet the CPU would continue the execution of further >> instructions until the flagged violation eventually reaches the CPU, >> triggering an external abort exception. This scheme effectively rules out >> any attempt to emulate device accesses. In contrast, the i.MX CSU responds >> to access violations by synchronously yielding control to the exception >> handler. So when such an exception occurs, the offending instruction can >> be determined and emulated in software. However, even though device >> emulation using the CSU is principally possible, we haven't investigated >> this opportunity further. >> =========================================================================== >> >> 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? >> >> 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 >> > > > ------------------------------------------------------------------------------ > 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
