Writing to UART mapped memory address

[Stefan Kalkowski]

Hi,

On 06/26/2017 06:14 PM, rijurekha at ...71... wrote:
> In os/src/server/tz_vmm/spec/imx53/main.cc, added the following enums
> (1) UART_BASE = 0x53FBC000,
> (2) UART_SIZE = 0x43FFF
> 
> In os/src/server/tz_vmm/include/vm_base.h
> In Vm_base constructor, added
> (3)_ram_iomem_uart(uart_base, uart_size),
> (4)_ram_uart(uart_base, uart_size,
> (Genode::addr_t)Genode::env()->rm_session()->attach(_ram_iomem_uart.dataspace())),
> 
> In dump(), added
> (5)printf("The memory location is %08lx\n", va_to_pa(_state->dfar));
> (6) printf("_ram.local() is %08lx\n",_ram.local());
> (7) printf("_ram.local() contains %08x\n",*(unsigned int*)(_ram.local()));
> (8) printf("_ram_uart.local() is %08lx\n",_ram_uart.local());
> (9) printf("_ram_uart.local() contains %08x\n",*(unsigned
> int*)(_ram_uart.local()));
> 
> The output:
> [init -> tz_vmm] The memory location is 53fbc080
> [init -> tz_vmm] _ram.local() is 80000000
> [init -> tz_vmm] _ram.local() contains eded1bb6
> [init -> tz_vmm] _ram_uart.local() is 70078000
> init -> tz_vmm -> vmm: raised unhandled data abort DFSR=0x00001008
> ISFR=0x00000007 DFAR=0x70078000 ip=0x7001f440 sp=0xe01fed10
> 
> Thus though _ram and _ram_uart are assigned in the same way (over
> different physical addresses), _ram.local() can be de-referenced and the
> content read, while _ram_uart.local() gives a fault. How are these UART
> addresses starting at 0x53FBC000 different from the
> Trustzone::NONSECURE_RAM_BASE physical addresses?
> 
> Funnily, the DFSR=0x00001008, which is the same value as the abort in the
> normal world linux. That can occur due to CSU configuration of UART made
> secure. But the vmm is in secure world, why is that getting the same abort
> at that same UART physical address?

To be honest, it's a bit exhausting to follow the trap-emulate path that
I discouraged you to follow from the first moment. We already
investigated that, and published a detailed report showing that
TrustZone indeed is not useful for doing device emulation. To me it is
not comprehensible why you are still focussing this solution.

Having said that, what you are trying to do is accessing a device
already in use by the kernel/core concurrently. You are trying to access
the same UART device directly that is used to print all messages of
core's LOG service. Although, that is certainly not the reason that you
are getting the page-fault. Anyway, it is a very bad idea to do so!

It seems to me that you are using an older version of Genode? Looking at
the current 'tz_vmm' component's source code, I can't clearly see what
constructs you are refering to, when adding (3) and (4). It would be
helpful to provide the whole source of the changed component. Without
any further insights, above lines seem reasonable.

> 
> Thanks!
> Riju
> 
> 
> ------------------------------------------------------------------------------
> 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/