Write to specific memory address

Stefan Kalkowski stefan.kalkowski at ...1...
Tue Apr 7 11:17:18 CEST 2015


Hi Vincent,

On 04/03/2015 03:28 PM, Vincent Raes wrote:
> Hello,
> 
> I have been doing some more experimenting with the va_to_pa function and
> the communication between normal and secure world.
> I am currently running Genode in the normal world as well. In the normal
> world I create a RAM dataspace which I then attach to the rm_session of
> the application. I fill this dataspace with data and I pass the virtual
> address to the secure world. The va_to_pa function returns an actual
> value in this case so my problem there was that I had nothing in the
> page table. The problem however is that this address seems incorrect.

As a tip for the future: to determine whether it is correct or not you
could compare what the 'va_to_pa' helper function returns with the
return value of the 'phys_addr()' function of the dataspace interface.

> When I change data at that physical address in the secure world, the
> normal world does not see any change in the dataspace when it has
> control again.
> At first I thought this might have something to do with the cache but
> I'm adding the UNCACHED modifier in the declaration of my dataspace and
> the problem persists.
> 
> After some extra testing with as big a dataspace I could manage, I
> checked the memory for where it was located and I found the dataspace,
> with all the data in it, at a random memory address. This leads me to
> believe that the translation of the virtual address of the dataspace to
> a physical one is simply wrong. I think the virtual address of the
> dataspace is a local address for that rm_session and that this might
> cause this mistranslation.

Indeed a virtual address is _always_ related to a specific RM session.
The RM session represents one virtual address space. In general, every
component in Genode has its own RM session - thereby memory protection
is realized.

Now coming to your problem: as I explained to you in a previous mail the
'va_to_pa' helper function was used just to translate some register
values for our TrustZone guest OS - in this case Linux. In Linux the
current process and the kernel share one address space, although it is
separated in a privileged and non-privileged part. Moreover the whole
memory management is done within the kernel (and we never had to use
user-level virtual addresses). In contrast to that in Genode every
component manages its address space and memory itself. Moreover, our
current own ARM kernel (core process) uses its own address space that is
disjunct from any other component's address space. So if your component
delivers a virtual address to the kernel running in the normal world,
the time it enters the kernel a translation table switch occurs (namely
the TTBRx registers are reloaded). The the normal world kernel then
issues a TrustZone world switch, but its translation table base address
stays within the TTBRx register. Now, when the secure world's virtual
machine monitor tries to interpret the virtual address given in the
register, it uses the translation table that it finds in the TTBRx
register to retrieve the physical address. When using this mechanism in
our original Linux guest settings this worked fine, because the
translation table within the TTBRx was the right one.

In your case, you have to adapt the procedure. Either you do not pass
the dataspace address as a virtual one, but as a physical (as mentioned
above: have a look at the dataspace interface), which is the simple,
recommended way, or you have to pass the translation table base address
of the corresponding component to the VMM in addition to the virtual
address, and change the 'va_to_pa' function to not use the TTBRx
registers implicitely.

Best Regards
Stefan

> 
> Now my question is, is it possible to find the virtual address of a
> dataspace or anything in which I can store data that will translate to
> the correct physical address with the va_to_pa function?
> 
> Best regards,
> Vincent
> 
> 2015-03-30 8:45 GMT+02:00 Stefan Kalkowski
> <stefan.kalkowski at ...1...
> <mailto:stefan.kalkowski at ...1...>>:
> 
>     Hi Vincent,
> 
>     On 03/27/2015 04:32 PM, Vincent Raes wrote:
>     > Hello,
>     >
>     > Thanks for the advice, it helped a lot. I was indeed confused with the
>     > virtual memory since I could
>     > I have another question, this time involving the tz_vmm itself. In mmu.h
>     > there is a function which should translate a virtual address of the
>     > normal world to a physical address in the secure world.
>     > However this function only returns 0 due to the ram.h throwing an
>     > invalid address when he gets called on by mmu.h. Could this be because
>     > I'm using a different kernel in the normal world/ different board so
>     > that mmu.h does not translate the addresses correctly?
> 
>     These small helper functions in mmu.h are used to decode register values
>     of the normal world that potentially contain virtual addresses to
>     physical ones. Thereby it is assumed the guest OS uses the short
>     translation table format of the ARM v7 architecture. If a given address
>     is not found in the page tables, or if the guest OS did not setup the
>     page tables yet (MMU ist still off) you will get a zero as return value.
> 
>     Regards
>     Stefan
> 
>     >
>     > Best regards,
>     > Vincent
>     >
>     > 2015-03-23 9:27 GMT+01:00 Stefan Kalkowski
>     > <stefan.kalkowski at ...1...
>     <mailto:stefan.kalkowski at ...1...>
>     > <mailto:stefan.kalkowski at ...1...
>     <mailto:stefan.kalkowski at ...1...>>>:
>     >
>     >     Hello Vincent,
>     >
>     >     On 03/20/2015 11:40 AM, Vincent Raes wrote:
>     >     > Hello,
>     >     >
>     >     > I am working with TrustZone using Genode and I am trying to
>     pass data
>     >     > from the secure world to the normal world and vice versa.
>     The problem
>     >     > lies with the fact that the normal world can only access a
>     certain
>     >     part
>     >     > of the RAM memory the board has to offer so all the data I
>     want to
>     >     give
>     >     > to the normal world has to be placed somewhere it can
>     access. And I
>     >     > can't seem to figure out how to place data at a specific
>     address using
>     >     > Genode.
>     >     >
>     >     > When I try to use pointers to the wanted memory location, the
>     >     error "No
>     >     > RM attachment" keeps popping up. This may very well be
>     caused by the
>     >     > fact I am using a pointer to a place that does not yet has a
>     valid
>     >     data
>     >     > object in it. I believe the correct answer has something to do
>     >     with the
>     >     > use of dataspaces but am not sure how or what kind of
>     dataspace I need
>     >     > to use for random data I generate myself.
>     >
>     >     To me it seems you first have to understand the difference between
>     >     virtual memory and physical memory. When using memory
>     addresses in a
>     >     normal application (and even mostly in the kernel) you are
>     dealing with
>     >     virtual memory addresses that are translated in hardware via
>     the MMU to
>     >     physical memory addresses. If you target a memory region that
>     does not
>     >     relate to a valid translation entry in the translation table
>     of the
>     >     process, you will get a translation fault. That is what you
>     see with the
>     >     message "No RM attachment". In Genode the RM session is used to
>     >     administrate the virtual memory address space of a process.
>     >
>     >     In contrast to that: the bus system, and the memory controller are
>     >     dealing with physical memory addresses, and probably the TrustZone
>     >     component that splits the memory in normal and secure one too.
>     If you
>     >     say that the normal world can access only a specific portion
>     of RAM, you
>     >     speak about a physical address range.
>     >
>     >     Your intuition was right: in Genode a portion of RAM is
>     abstracted by a
>     >     dataspace. In general a RAM dataspace is just an anonymous
>     amount of
>     >     RAM, where you do cannot determine its location in physical
>     memory when
>     >     allocating it. In contrast to a RAM dataspace, you can also
>     use an IOMEM
>     >     session to request a specific dataspace, normally used for
>     memory-mapped
>     >     I/O regions of devices. When allocating an IOMEM region of
>     course you
>     >     can and have to specify the actual physical location. So in
>     your case,
>     >     the only possibility to deposit data at a specific RAM
>     location for the
>     >     normal world is to open up an IOMEM session, and attach its
>     dataspace to
>     >     the RM session of your application.
>     >
>     >     BTW: the same was done in our TrustZone example virtual
>     machine monitor
>     >     implmentation (repos/os/src/server/tz_vmm).
>     >
>     >     Regards
>     >     Stefan
>     >
>     >     >
>     >     > Thanks in advance for any advice.
>     >     >
>     >     > Best regards,
>     >     > Vincent
>     >     >
>     >     >
>     >     >
>     >   
>      ------------------------------------------------------------------------------
>     >     > Dive into the World of Parallel Programming The Go Parallel
>     >     Website, sponsored
>     >     > by Intel and developed in partnership with Slashdot Media,
>     is your
>     >     hub for all
>     >     > things parallel software development, from weekly thought
>     >     leadership blogs to
>     >     > news, videos, case studies, tutorials and more. Take a look and
>     >     join the
>     >     > conversation now. http://goparallel.sourceforge.net/
>     >     >
>     >     >
>     >     >
>     >     > _______________________________________________
>     >     > genode-main mailing list
>     >     > genode-main at lists.sourceforge.net
>     <mailto:genode-main at lists.sourceforge.net>
>     >     <mailto:genode-main at lists.sourceforge.net
>     <mailto:genode-main at lists.sourceforge.net>>
>     >     > https://lists.sourceforge.net/lists/listinfo/genode-main
>     >     >
>     >
>     >     --
>     >     Stefan Kalkowski
>     >     Genode Labs
>     >
>     >     http://www.genode-labs.com/ · http://genode.org/
>     >
>     >     ------------------------------------------------------------------------------
>     >     Dive into the World of Parallel Programming The Go Parallel Website,
>     >     sponsored
>     >     by Intel and developed in partnership with Slashdot Media, is your
>     >     hub for all
>     >     things parallel software development, from weekly thought leadership
>     >     blogs to
>     >     news, videos, case studies, tutorials and more. Take a look and join the
>     >     conversation now. http://goparallel.sourceforge.net/
>     >     _______________________________________________
>     >     genode-main mailing list
>     >     genode-main at lists.sourceforge.net
>     <mailto:genode-main at lists.sourceforge.net>
>     >     <mailto:genode-main at lists.sourceforge.net
>     <mailto:genode-main at lists.sourceforge.net>>
>     >     https://lists.sourceforge.net/lists/listinfo/genode-main
>     >
>     >
>     >
>     >
>     >
>     ------------------------------------------------------------------------------
>     > Dive into the World of Parallel Programming The Go Parallel
>     Website, sponsored
>     > by Intel and developed in partnership with Slashdot Media, is your
>     hub for all
>     > things parallel software development, from weekly thought
>     leadership blogs to
>     > news, videos, case studies, tutorials and more. Take a look and
>     join the
>     > conversation now. http://goparallel.sourceforge.net/
>     >
>     >
>     >
>     > _______________________________________________
>     > genode-main mailing list
>     > genode-main at lists.sourceforge.net
>     <mailto:genode-main at lists.sourceforge.net>
>     > https://lists.sourceforge.net/lists/listinfo/genode-main
>     >
> 
>     --
>     Stefan Kalkowski
>     Genode Labs
> 
>     http://www.genode-labs.com/ · http://genode.org/
> 
>     ------------------------------------------------------------------------------
>     Dive into the World of Parallel Programming The Go Parallel Website,
>     sponsored
>     by Intel and developed in partnership with Slashdot Media, is your
>     hub for all
>     things parallel software development, from weekly thought leadership
>     blogs to
>     news, videos, case studies, tutorials and more. Take a look and join the
>     conversation now. http://goparallel.sourceforge.net/
>     _______________________________________________
>     genode-main mailing list
>     genode-main at lists.sourceforge.net
>     <mailto:genode-main at lists.sourceforge.net>
>     https://lists.sourceforge.net/lists/listinfo/genode-main
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the 
> conversation now. http://goparallel.sourceforge.net/
> 
> 
> 
> _______________________________________________
> genode-main mailing list
> genode-main at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/genode-main
> 

-- 
Stefan Kalkowski
Genode Labs

http://www.genode-labs.com/ · http://genode.org/




More information about the users mailing list