Re: Writing to UART mapped memory address
In base-hw/src/core/include/spec/imx53/trustzone/csu.h, SECURE = 0x33. So SECURE_UART = 1 in base-hw/src/core/include/spec/imx53_qsb/trustzone/csu_config.h should initialize UART as RD+WR for secure user and spvr models as given in Page 956 of http://www.nxp.com/docs/en/reference-manual/iMX53RM.pdf. tz_vmm is in the secure user mode, sho it should be able to read an UART address? 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Re: Writing to UART mapped memory address
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 8000
[init -> tz_vmm] _ram.local() contains eded1bb6
[init -> tz_vmm] _ram_uart.local() is 70078000
init -> tz_vmm -> vmm: raised unhandled data abort DFSR=0x1008
ISFR=0x0007 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=0x1008, 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?
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/genode-main
Re: libc blocking functions/with_libc inside thread
Hello Boris, On Mon, Jun 26, 2017 at 02:46:08PM +0200, Boris Mulder wrote: > Actually the OpenVPN code hangs once it calls the libc socket() > function. Internally, this function calls a blocking write(), and this > write() is handled by Libc::Kernel. thanks to your provided test case and the hint with "blocking write" I was able to validate my suspicion about the blocker in your scenario. A rough sketch of my solution can be found here https://github.com/chelmuth/genode/commits/openvpn_17.05. The issue is the unfortunate interplay of I/O-signal handling in the initial entrypoint and the current implementation of the VFS plugin, which interfaces with our file-system session. In the case of "blocking write" the VFS plugin calls wait_and_dispatch_one_io_signal() directly on the initial entrypoint. In your scenario this results in the initial-entrypoint thread and the OpenVPN thread racing on the handling of first I/O signal. As the entrypoint always wins, the OpenVPN thread is blocked until another I/O signal occurs (which may never happen in the startup phase). The sketched solution just reverses the roles of the first and second application thread. Now, the initial entrypoint implements OpenVPN (handling its own I/O signals) and the additional entrypoint implements the NIC server (with root and session component). I hope this helps. Greets -- Christian Helmuth Genode Labs https://www.genode-labs.com/ · https://genode.org/ https://twitter.com/GenodeLabs · /ˈdʒiː.nəʊd/ Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth > So openVPN does not send or receive any packet yet as it is blocked at > socket(). > > Earlier, we have used lwip as a socket library. When we did that, > socket() (and connect() in TCP mode) did work, but it failed to send any > initial data to the server, likewise blocking on some function. > > We are reaching the limit of our knowledge of genode libc and the > side-effects of the asynchronous entrypoint. At this point our debugging > went down into the libc kernel and there is a limit how deep we can go. > Help on this topic would be appreciated. > > We uploaded the new 17.05 ready code of openVPN (including a run script > which can be run through make run/openvpn) onto > https://github.com/nlcsl/genode/tree/openvpn_17.05 . > > If you have the time, could you try to run it and see if it is possible > to let it produce a single UDP packet? For this, it is not necessary to > setup a server. From there, we could pick it up again. > > We appreciate it, > > Boris > > > On 26-06-17 10:57, Christian Helmuth wrote: > > Hello Boris, > > > > On Fri, Jun 23, 2017 at 03:59:53PM +0200, Boris Mulder wrote: > >> The entrypoint creates the root component, spawns the thread and > >> returns. It will then handle RPC requests, as entrypoints do IIRC. > >> > >> The program acts as a server (serving Nic sessions asynchronously) and > >> as a client to lxip vfs with libc. the code can be found in [1]. > >> > >> How can I have the entrypoint handle I/O signals in libc while also > >> being able to serve clients in Genode? > > This should happen automatically under the hood as libc processes > > signals in ordinary I/O signal handlers in the entrypoint. > > > > Are you able to run the scenario under linux and inspect the > > processing of both threads via GDB? I fear that I cannot help with > > specifics of OpenVPN, but may guide with more details about the > > blocking situation. It may be interesting to know if any network > > packets reach the OpenVPN code. > > > > Greets > > -- > > Met vriendelijke groet / kind regards, > > Boris Mulder > > Cyber Security Labs B.V. | Gooimeer 6-31 | 1411 DD Naarden | The Netherlands > +31 35 631 3253 (office) > > > > -- > 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
Writing to UART mapped memory address
Hello I am running trustzone Genode, with linux in normal world. I have made UART secure and I'm getting the fault address in DFAR register in dump in VM monitor. I want to write to a memory address which is mapped to UART i.e. physical address is in range [53FBC000, 53FF]. I am getting following error when I try to access the address: ``` no RM attachment (faulter 203128 with IP 7001e7d0 attempts to read from address 53fbc080) init -> tz_vmm -> vmm: unresolved pagefault at ip=7001e7d0 sp=e01fed10 fault address=53fbc080 core -> pager_ep: cannot submit unknown signal context ``` I'm using va_to_pa to get the physical address. I'm not sure how Genode maps the virtual addresses to I/O mapped physical region, or how can I write to UART mapped physical address? 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
Re: libc blocking functions/with_libc inside thread
Hello Christian, Actually the OpenVPN code hangs once it calls the libc socket() function. Internally, this function calls a blocking write(), and this write() is handled by Libc::Kernel. So openVPN does not send or receive any packet yet as it is blocked at socket(). Earlier, we have used lwip as a socket library. When we did that, socket() (and connect() in TCP mode) did work, but it failed to send any initial data to the server, likewise blocking on some function. We are reaching the limit of our knowledge of genode libc and the side-effects of the asynchronous entrypoint. At this point our debugging went down into the libc kernel and there is a limit how deep we can go. Help on this topic would be appreciated. We uploaded the new 17.05 ready code of openVPN (including a run script which can be run through make run/openvpn) onto https://github.com/nlcsl/genode/tree/openvpn_17.05 . If you have the time, could you try to run it and see if it is possible to let it produce a single UDP packet? For this, it is not necessary to setup a server. From there, we could pick it up again. We appreciate it, Boris On 26-06-17 10:57, Christian Helmuth wrote: > Hello Boris, > > On Fri, Jun 23, 2017 at 03:59:53PM +0200, Boris Mulder wrote: >> The entrypoint creates the root component, spawns the thread and >> returns. It will then handle RPC requests, as entrypoints do IIRC. >> >> The program acts as a server (serving Nic sessions asynchronously) and >> as a client to lxip vfs with libc. the code can be found in [1]. >> >> How can I have the entrypoint handle I/O signals in libc while also >> being able to serve clients in Genode? > This should happen automatically under the hood as libc processes > signals in ordinary I/O signal handlers in the entrypoint. > > Are you able to run the scenario under linux and inspect the > processing of both threads via GDB? I fear that I cannot help with > specifics of OpenVPN, but may guide with more details about the > blocking situation. It may be interesting to know if any network > packets reach the OpenVPN code. > > Greets -- Met vriendelijke groet / kind regards, Boris Mulder Cyber Security Labs B.V. | Gooimeer 6-31 | 1411 DD Naarden | The Netherlands +31 35 631 3253 (office) -- 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
Re: Query regarding extracting instruction which caused a data-abort exception
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] 0xE5930082: STRHR0, [R0] Decoding by hand using encoding rules at "ARM® Architecture Reference Manual - ARMv7-A and ARMv7-R edition" gives ldr r0, [r3,#128] in ARMv7 ARM mode. This should be the mode as va_to_pa(_state->ip) is an even address. r3(53fbc000)+128 exactly matches the DFAR(53fbc080) and ldr matches the dfsr error that "read" gave "AXI Slave error" causing "precise external abort, nontranslation". https://github.com/jbremer/darm gives the correct decoding. We have ported this to genode, to have inline decoding of faulting instruction and are able to emulate the decoded instruction. Thanks Stefan for your patient and constant help. 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Re: libc blocking functions/with_libc inside thread
Hello Boris, On Fri, Jun 23, 2017 at 03:59:53PM +0200, Boris Mulder wrote: > The entrypoint creates the root component, spawns the thread and > returns. It will then handle RPC requests, as entrypoints do IIRC. > > The program acts as a server (serving Nic sessions asynchronously) and > as a client to lxip vfs with libc. the code can be found in [1]. > > How can I have the entrypoint handle I/O signals in libc while also > being able to serve clients in Genode? This should happen automatically under the hood as libc processes signals in ordinary I/O signal handlers in the entrypoint. Are you able to run the scenario under linux and inspect the processing of both threads via GDB? I fear that I cannot help with specifics of OpenVPN, but may guide with more details about the blocking situation. It may be interesting to know if any network packets reach the OpenVPN code. Greets -- Christian Helmuth Genode Labs https://www.genode-labs.com/ · https://genode.org/ https://twitter.com/GenodeLabs · /ˈdʒiː.nəʊd/ Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth -- 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
