Hi
From the article in this link
http://genode.org/documentation/articles/trustzone , I understood that the DDR RAM in i.mx53 QSB is partitioned off between normal world and secure world. I just want to read a file in the normal world from application running in the secure side. Is there any possibility to get access to any file in normal world from the secure world? thanks for your help in advance.
Regards, Joseph
Hello Joseph,
On 11/17/2014 04:04 AM, Joseph Lee wrote:
Hi
From the article in this link http://genode.org/documentation/articles/trustzone , I understood that the DDR RAM in i.mx53 QSB is partitioned off between normal world and secure world. I just want to read a file in the normal world from application running in the secure side. Is there any possibility to get access to any file in normal world from the secure world? thanks for your help in advance.
If you want to access files in the "secure world", you first need some interface in between, which is not existent right now, at least not for file access. When designing such an interface, e.g. by adding a special file system driver in Linux that communicates via hypercalls with the "secure world", you can of course define a dedicated memory area of the "normal world" to be used to transfer payload.
Although the DDR RAM is partitioned between both worlds that doesn't mean the "secure world" can't access memory of the "normal world". It only means that the memory assigned to the "secure world" can be accessed exclusively by it, and not by the "normal world".
Nevertheless, caution is advised when using shared memory in between both worlds, as long as the memory might land in the cache of either of both worlds. The cache is TrustZone aware, and tags all cache lines to be secure, or non-secure, thereby effectively partitioning the cache. So if you use shared memory in between "secure" and "normal world" it needs to be either marked as uncached, or you need to clean the corresponding cache-lines after writing data to shared memory respectively invalidate cache-lines before reading data from shared memory.
I hope this clarifies your question?
Regards Stefan
Regards, Joseph
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.cl...
genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Thanks Stefan for your detailed explanation.
Is there something similar to the /dev/mem and system call mmap() technique to access physical memory region in guest VM RAM from VMM?
Thanks in advance for answers
Kind regards,
Joseph
On Mon, Nov 17, 2014 at 8:03 AM, Stefan Kalkowski < stefan.kalkowski@...1...> wrote:
Hello Joseph,
On 11/17/2014 04:04 AM, Joseph Lee wrote:
Hi
From the article in this link http://genode.org/documentation/articles/trustzone , I understood that the DDR RAM in i.mx53 QSB is partitioned off between normal world and secure world. I just want to read a file in the normal world from application running in the secure side. Is there any possibility to get access to any file in normal world from the secure world? thanks for your help in advance.
If you want to access files in the "secure world", you first need some interface in between, which is not existent right now, at least not for file access. When designing such an interface, e.g. by adding a special file system driver in Linux that communicates via hypercalls with the "secure world", you can of course define a dedicated memory area of the "normal world" to be used to transfer payload.
Although the DDR RAM is partitioned between both worlds that doesn't mean the "secure world" can't access memory of the "normal world". It only means that the memory assigned to the "secure world" can be accessed exclusively by it, and not by the "normal world".
Nevertheless, caution is advised when using shared memory in between both worlds, as long as the memory might land in the cache of either of both worlds. The cache is TrustZone aware, and tags all cache lines to be secure, or non-secure, thereby effectively partitioning the cache. So if you use shared memory in between "secure" and "normal world" it needs to be either marked as uncached, or you need to clean the corresponding cache-lines after writing data to shared memory respectively invalidate cache-lines before reading data from shared memory.
I hope this clarifies your question?
Regards Stefan
Regards, Joseph
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.cl...
genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
-- Stefan Kalkowski Genode Labs
http://www.genode-labs.com/ · http://genode.org/
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.cl... _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hi Joseph,
On 12/11/2014 02:54 AM, Joseph Lee wrote:
Thanks Stefan for your detailed explanation.
Is there something similar to the |/dev/mem| and system call |mmap() technique to |access physical memory region in guest VM RAM from VMM?
In Genode there is no global view regarding physical memory like "/dev/mem" in Linux. Corresponding to your system's policy you can gain a specific amount of anonymous RAM from the system, or specific I/O memory regions (e.g. for device drivers) referenced by their physical memory address. For the TrustZone scenario we added a fixed portion of RAM to the I/O memory regions administered by the core process. Thereby, the VMM is able to request the VM's RAM via an IOMEM session during its startup routine. Such memory is mapped as uncached to the VMM's address space. The VMM has to copy over at least the kernel to the VM's RAM before starting the non-secure guest OS.
To sum it up, you don't need to care about gaining the VM's physical memory nor about mapping it, as it is already present in the VMM's address space. But if you want to read/write from/to it, you have to assure that the guest OS will either not cache the memory region used for hypervisor communication, or the guest OS has to flush the related cache lines whenever it wrote to it, or invalidates them before reading it.
Regards Stefan
Thanks in advance for answers
Kind regards,
Joseph
On Mon, Nov 17, 2014 at 8:03 AM, Stefan Kalkowski <stefan.kalkowski@...1... mailto:stefan.kalkowski@...1...> wrote:
Hello Joseph, On 11/17/2014 04:04 AM, Joseph Lee wrote: > Hi > > From the article in this link > http://genode.org/documentation/articles/trustzone , I understood that > the DDR RAM in i.mx53 QSB is partitioned off between normal world and > secure world. I just want to read a file in the normal world from > application running in the secure side. Is there any possibility to get > access to any file in normal world from the secure world? thanks for > your help in advance. > If you want to access files in the "secure world", you first need some interface in between, which is not existent right now, at least not for file access. When designing such an interface, e.g. by adding a special file system driver in Linux that communicates via hypercalls with the "secure world", you can of course define a dedicated memory area of the "normal world" to be used to transfer payload. Although the DDR RAM is partitioned between both worlds that doesn't mean the "secure world" can't access memory of the "normal world". It only means that the memory assigned to the "secure world" can be accessed exclusively by it, and not by the "normal world". Nevertheless, caution is advised when using shared memory in between both worlds, as long as the memory might land in the cache of either of both worlds. The cache is TrustZone aware, and tags all cache lines to be secure, or non-secure, thereby effectively partitioning the cache. So if you use shared memory in between "secure" and "normal world" it needs to be either marked as uncached, or you need to clean the corresponding cache-lines after writing data to shared memory respectively invalidate cache-lines before reading data from shared memory. I hope this clarifies your question? Regards Stefan > Regards, > Joseph > > > ------------------------------------------------------------------------------ > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > with Interactivity, Sharing, Native Excel Exports, App Integration & more > Get technology previously reserved for billion-dollar corporations, FREE > http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk > > > > _______________________________________________ > genode-main mailing list > genode-main@lists.sourceforge.net <mailto:genode-main@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/genode-main > -- Stefan Kalkowski Genode Labs http://www.genode-labs.com/ · http://genode.org/ ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net <mailto:genode-main@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/genode-main
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.cl...
genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Thank you Stefan,
In VMM, the virtual address spaces of VM is starting from the base address (_ram.base( ) ) to the size of RAM (256MB). Is that correct? my question is how do we read the contents of physical memory of VM inside VMM/secure world.
Thanks,
On Friday, December 12, 2014, Stefan Kalkowski < stefan.kalkowski@...1...> wrote:
Hi Joseph,
On 12/11/2014 02:54 AM, Joseph Lee wrote:
Thanks Stefan for your detailed explanation.
Is there something similar to the |/dev/mem| and system call |mmap()
technique to |access
physical memory region in guest VM RAM from VMM?
In Genode there is no global view regarding physical memory like "/dev/mem" in Linux. Corresponding to your system's policy you can gain a specific amount of anonymous RAM from the system, or specific I/O memory regions (e.g. for device drivers) referenced by their physical memory address. For the TrustZone scenario we added a fixed portion of RAM to the I/O memory regions administered by the core process. Thereby, the VMM is able to request the VM's RAM via an IOMEM session during its startup routine. Such memory is mapped as uncached to the VMM's address space. The VMM has to copy over at least the kernel to the VM's RAM before starting the non-secure guest OS.
To sum it up, you don't need to care about gaining the VM's physical memory nor about mapping it, as it is already present in the VMM's address space. But if you want to read/write from/to it, you have to assure that the guest OS will either not cache the memory region used for hypervisor communication, or the guest OS has to flush the related cache lines whenever it wrote to it, or invalidates them before reading it.
Regards Stefan
Thanks in advance for answers
Kind regards,
Joseph
On Mon, Nov 17, 2014 at 8:03 AM, Stefan Kalkowski <stefan.kalkowski@...1... javascript:; <mailto:stefan.kalkowski@...1... javascript:;>> wrote:
Hello Joseph, On 11/17/2014 04:04 AM, Joseph Lee wrote: > Hi > > From the article in this link > http://genode.org/documentation/articles/trustzone , I understoodthat
> the DDR RAM in i.mx53 QSB is partitioned off between normal worldand
> secure world. I just want to read a file in the normal world from > application running in the secure side. Is there any possibility to get > access to any file in normal world from the secure world? thanksfor
> your help in advance. > If you want to access files in the "secure world", you first needsome
interface in between, which is not existent right now, at least notfor
file access. When designing such an interface, e.g. by adding aspecial
file system driver in Linux that communicates via hypercalls with the "secure world", you can of course define a dedicated memory area ofthe
"normal world" to be used to transfer payload. Although the DDR RAM is partitioned between both worlds that doesn't mean the "secure world" can't access memory of the "normal world". It only means that the memory assigned to the "secure world" can be accessed exclusively by it, and not by the "normal world". Nevertheless, caution is advised when using shared memory in between both worlds, as long as the memory might land in the cache of eitherof
both worlds. The cache is TrustZone aware, and tags all cache linesto
be secure, or non-secure, thereby effectively partitioning the cache. So if you use shared memory in between "secure" and "normal world" it needs to be either marked as uncached, or you need to clean the corresponding cache-lines after writing data to shared memory respectively invalidate cache-lines before reading data from shared memory. I hope this clarifies your question? Regards Stefan > Regards, > Joseph > > >
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > with Interactivity, Sharing, Native Excel Exports, App Integration & more > Get technology previously reserved for billion-dollar corporations, FREE >http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.cl...
> > > > _______________________________________________ > genode-main mailing list > genode-main@lists.sourceforge.net <javascript:;> <mailto:genode-main@lists.sourceforge.net <javascript:;>> > https://lists.sourceforge.net/lists/listinfo/genode-main > -- Stefan Kalkowski Genode Labs http://www.genode-labs.com/ · http://genode.org/
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports andDashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations,FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.cl...
_______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net <javascript:;> <mailto:genode-main@lists.sourceforge.net <javascript:;>> https://lists.sourceforge.net/lists/listinfo/genode-main
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.cl...
genode-main mailing list genode-main@lists.sourceforge.net javascript:; https://lists.sourceforge.net/lists/listinfo/genode-main
-- Stefan Kalkowski Genode Labs
http://www.genode-labs.com/ · http://genode.org/
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.cl... _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net javascript:; https://lists.sourceforge.net/lists/listinfo/genode-main
Hi Joseph,
Am 03.12.2015 um 08:02 schrieb Joseph Lee:
In VMM, the virtual address spaces of VM is starting from the base address (_ram.base( ) ) to the size of RAM (256MB). Is that correct? my question is how do we read the contents of physical memory of VM inside VMM/secure world.
I've recently wrote an answer to another question on the mailing list that should also answer your questions: http://sourceforge.net/p/genode/mailman/message/34666744/
Cheers, Martin
Thanks a lot Martin. I have some more questions. How in VMM I can read contents of VM's RAM by accessing the physical memory address directly instead of virtual address? Or is MMU in Genode configured for one to one mapping the virtual address to physical address? how do i use DMA without involving the CPU to read contents of VM's RAM inside VMM?
Thanks,
On Thu, Dec 3, 2015 at 11:45 AM, Martin Stein <martin.stein@...1...> wrote:
Hi Joseph,
Am 03.12.2015 um 08:02 schrieb Joseph Lee:
In VMM, the virtual address spaces of VM is starting from the base address (_ram.base( ) ) to the size of RAM (256MB). Is that correct? my question is how do we read the contents of physical memory of VM inside VMM/secure world.
I've recently wrote an answer to another question on the mailing list that should also answer your questions: http://sourceforge.net/p/genode/mailman/message/34666744/
Cheers, Martin
Go from Idea to Many App Stores Faster with Intel(R) XDK Give your users amazing mobile app experiences with Intel(R) XDK. Use one codebase in this all-in-one HTML5 development environment. Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs. http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140 _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hi Joseph,
Am 10.12.2015 um 14:08 schrieb Joseph Lee:
I have some more questions. How in VMM I can read contents of VM's RAM by accessing the physical memory address directly instead of virtual address?
I wonder why you want to do this? In the userland on Genode+ARM, the MMU is always enabled, there is and shall be no way to disable it from within the userland. You can use the IOMEM mapping of the VM RAM in the tz_vmm [1] to access non-secure RAM. Likewise, you can IOMEM-map this RAM in other components. When IOMEM-mapped, the VM RAM is non-cached in the VMM but it may be partially cached in the non-secure world. So, either you only access regions that are non-cached also in the non-secure world or synchronize before accessing them (For details regarding these two cases see a recent mail [6] of me).
Or is MMU in Genode configured for one to one mapping the virtual address to physical address?
No. It is possible to determine the physical address of a dataspace via [4] and to suggest a local mapping address via [3] but what do you expect to be the benefit of a 1:1 mapping?
how do i use DMA without involving the CPU to read contents of VM's RAM inside VMM?
I don't know how this is done but AFAIK nothing speaks against doing it. DMA engines are configured in the CSU [5] whether to be allowed or forbidden to access secure RAM.
Cheers, Martin
[1] https://github.com/genodelabs/genode/blob/master/repos/os/src/server/tz_vmm/...
[3] https://github.com/genodelabs/genode/blob/master/repos/base/include/rm_sessi...
[4] https://github.com/genodelabs/genode/blob/master/repos/base/include/dataspac...
[5] https://github.com/genodelabs/genode/blob/master/repos/base-hw/src/core/incl...
[6] http://sourceforge.net/p/genode/mailman/message/34685275/
-
Joseph Lee -
Martin Stein -
Stefan Kalkowski