Query regarding extracting instruction which caused a data-abort exception

Stefan Kalkowski stefan.kalkowski at ...1...
Wed Jun 14 15:12:17 CEST 2017


Hi,

On 06/14/2017 02:48 PM, rijurekha at ...71... 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 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
> 

-- 
Stefan Kalkowski
Genode Labs

https://github.com/skalk · http://genode.org/




More information about the users mailing list