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, <rijurekha@...71...> wrote:
Thanks a lot Stefan, Will correlate with the linux binary.
Riju
Hi,
On 06/14/2017 02:40 PM, rijurekha@...71... 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