We get the correct instruction from *(unsigned
int*)(va_to_pa(_state->ip))=e5930080.
The issue was wrong instruction decoding at
http://armconverter.com/hextoarm/. e5930080 gave
(1) in ARMv7 ARM mode
ANDHI SB, R0, R5, ROR #7 , and
(2) in ARMv7 Thumb mode
0xE5930080: STR R3, [SP, #0x394]
Thanks Stefan! We completely missed DFAR and DFSR are **banked** across
secure and non-secure worlds and the assembler path and the ::read are
seeing two separate copies of these registers.
We verified that we hit .macro _nonsecure_to_secure in monitor handler
with the csu abort exception. We
Hi,
On 06/23/2017 11:10 AM, rijure...@mpi-sws.org wrote:
> Why do you say you do not save DFAR in the assembler path? Isn't DFAR
> saved in lines 15. and 27. below, while other registers are saved in line
> 3. in base-hw/src/core/spec/arm_v7/trustzone/mode_transition.s? This is
> where control
Why do you say you do not save DFAR in the assembler path? Isn't DFAR
saved in lines 15. and 27. below, while other registers are saved in line
3. in base-hw/src/core/spec/arm_v7/trustzone/mode_transition.s? This is
where control will come for csu abort with
_mon_dab_entry: _nonsecure_to_secure
Hi,
On 06/22/2017 07:02 PM, rijure...@mpi-sws.org wrote:
> Thanks a lot Stefan! base-hw/src/core/spec/arm_v7/trustzone/kernel/vm.cc
> and base-hw/src/core/spec/arm_v7/trustzone/mode_transition.s makes the
> memory sharing and register read/write between vmm and vm clearer.
>
> Further doubts:
>
Thanks a lot Stefan! base-hw/src/core/spec/arm_v7/trustzone/kernel/vm.cc
and base-hw/src/core/spec/arm_v7/trustzone/mode_transition.s makes the
memory sharing and register read/write between vmm and vm clearer.
Further doubts:
(1)We put three print statements:
(a) In
On 06/20/2017 04:42 PM, rijure...@mpi-sws.org wrote:
> Analyzed the following files:
> (a) base-hw/src/core/spec/arm/kernel/cpu.cc (calls init trustzone)
> (b) base-hw/src/core/spec/imx53/trustzone/platform_support.cc (defines
> init trustzone where monitor exception entry is assigned with
>
Hi,
On 06/20/2017 02:12 PM, rijure...@mpi-sws.org wrote:
> We read the dfsr value with changes in
> base-hw/include/spec/imx53/vm_state.h,
> base-hw/src/core/spec/arm_v7/trustzone/kernel/vm.cc, and
> os/src/server/tz_vmm/include/vm_base.h dump() function.
>
> We got dfsr = 1008, which gives
Analyzed the following files:
(a) base-hw/src/core/spec/arm/kernel/cpu.cc (calls init trustzone)
(b) base-hw/src/core/spec/imx53/trustzone/platform_support.cc (defines
init trustzone where monitor exception entry is assigned with
_mon_kernel_entry)
(c)
We read the dfsr value with changes in
base-hw/include/spec/imx53/vm_state.h,
base-hw/src/core/spec/arm_v7/trustzone/kernel/vm.cc, and
os/src/server/tz_vmm/include/vm_base.h dump() function.
We got dfsr = 1008, which gives b101000 for the status bits, matching
"bx01000 precise external abort,
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
On 06/14/2017 03:15 PM, Abhishek Kumar wrote:
> 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
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
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
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
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
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
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
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
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
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
21 matches
Mail list logo
