Re: SMC Calls in Trustzone VMM Scenario
Hello Stefan,
Thank you for your answer.
Ok, first I do not see how you can enforce the cache usage with
> respect to the normal world. As long as the cache is enabled, how do
> you confine memory access of the normal world when it's not asking
> for permission (via your smc call)?
> To me it looks like you want to close some covert channels by cache
> data usage/displacement? In that case, maybe it is more reasonable to
> circumvent usage of the cache by the secure world at all?
>
It is not a side channel attack. The Cortex-A8 provides cache locking
mechanisms for the benefit of
real-time embedded systems. I am trying to prevent malicious users from
exploiting these to lock malicious
code in the normal world cache (to avoid memory introspection from the
Secure World) using TrustZone.
Which is why I am working with your OS framework.
There is a designated kernel/core page-table that can be used to add
> kernel mappings. Obviously, you are using some quite old Genode
> version, so I'm not sure how to do that in your case. Nowadays, I
> would add a designated static mapping to the core/kernel mappings in
> the "bootstrap" code for the corresponding board, e.g.:
>
As far as I know, I have a fairly recent version of Genode (17.08). But
yes, now I am trying to
map NONSECURE_RAM memory to the Secure World so that it can access both
secure world and
normal world memory such that in SW there are VA translations that map to
PA's of NW.
Would adding another region in
repos/os/src/server/tz_vmm/spec/imx53/main.cc
<https://github.com/genodelabs/genode/blob/1e8689bafefe156429998c4f2f92ae982675c34c/repos/os/src/server/tz_vmm/spec/imx53/main.cc>
create
these
mappings in SW ie:
_m4if.set_region1(Trustzone::NON*SECURE_RAM_BASE*,
Trustzone::NONSECURE_RAM_SIZE);
Because attempting to have overlapping memory such as edditing
repos/base-hw/src/bootstrap/spec/imx53_qsb/platform_trustzone.cc
<https://github.com/genodelabs/genode/blob/ee4ee6a8ac91592065cbf7a96872a95acb926b17/repos/base-hw/src/bootstrap/spec/imx53_qsb/platform_trustzone.cc>
early_ram_regions(Memory_region{Trustzone::*SECURE_RAM_BASE*,Trustzone::SECURE_RAM_SIZE
+ Trustzone::NONSECURE_RAM_SIZE})
to have early ram region that encompass both secure and nonsecure is not
allowed
as far as I understand.
However, once I do have these new virtual address translations, I am not
sure how to get the VA from a given PA.
VA -> PA I just use the ARM PAR register for translation, but the other way
still eludes me.
I know that linux provides virt_to_pys() and phys_to_virt() functions to
convert between the two.
In the Genode tz_vmm scenario, is there a phys_to_virt() (or equivalent
function) I can use to get
the virtual address that corresponds to a physical address? Or is there any
way I could implement it?
Thank you,
Mauricio
On Wed, Apr 11, 2018 at 2:42 AM, Stefan Kalkowski <
stefan.kalkow...@genode-labs.com> wrote:
> Hi Mauricio,
>
> thank you for sharing your intention.
>
> On Tue, Apr 10, 2018 at 10:51:15PM -0700, Mauricio Gutierrez wrote:
> > Hello Stefan,
> >
> > Thank you for your reply.
> >
> > If you really need to execute code in monitor mode (I wonder why), I
> > > think it will be best to create an explicit interface on the
> > > kernel/core level that can be called from the VMM component, maybe an
> > > extensions of the VM session interface.
> > >
> > > I think it somehow depends on what you are trying to do. If your
> > > routine has to be called every time a secure monitor call was
> > > executed, it is better to handle that directly within the
> > > Vm::exception function. If you have a very special device that needs
> > > to be accessed from secure, privileged/monitor mode you should extend
> the
> > > interface of kernel/core.
> > >
> >
> > Indeed this is what I ended up doing. I have added some exception
> handling
> > in the default case
> > of the Vm::exception function for my smc call (#4) before it switches
> over
> > to user-level privilege.
> >
> > Your are welcome. Maybe, you can give us some insights why do you need
> > > to enter monitor mode at all?
> > >
> >
> > I am trying to make it so that the secure world can lock some normal
> world
> > physical memory into the cache.
> > For security reasons, I do not want to allow the normal word to do it so
> I
> > make an smc into secure world
> > passing the virtual address to load into cache. The secure world then
> uses
> > the VA to PA registers to get the
> > physical address and load the memory into the cache. Of course, the only
> > way this would work would be for
> > the cache entry to be tagged with an NS bit = 1. In orde
Re: SMC Calls in Trustzone VMM Scenario
Hello Stefan, Thank you for your reply. If you really need to execute code in monitor mode (I wonder why), I > think it will be best to create an explicit interface on the > kernel/core level that can be called from the VMM component, maybe an > extensions of the VM session interface. > > I think it somehow depends on what you are trying to do. If your > routine has to be called every time a secure monitor call was > executed, it is better to handle that directly within the > Vm::exception function. If you have a very special device that needs > to be accessed from secure, privileged/monitor mode you should extend the > interface of kernel/core. > Indeed this is what I ended up doing. I have added some exception handling in the default case of the Vm::exception function for my smc call (#4) before it switches over to user-level privilege. Your are welcome. Maybe, you can give us some insights why do you need > to enter monitor mode at all? > I am trying to make it so that the secure world can lock some normal world physical memory into the cache. For security reasons, I do not want to allow the normal word to do it so I make an smc into secure world passing the virtual address to load into cache. The secure world then uses the VA to PA registers to get the physical address and load the memory into the cache. Of course, the only way this would work would be for the cache entry to be tagged with an NS bit = 1. In order to do this, I need to enter monitor mode so that I can change the NS bit to 1 while remaining is secure world. This way I perform the cache loading and locking on behalf of the normal world while being able to check for consistency. The issue I am facing now is that I get a cpu exception 3 (Breakpoint) when I try to write to the given normal world memory from secure world, and I am not sure why. Right now I am trying to access the physical address by temporarily disabling the mmu so PA = VA. However, another method would be to create/edit a page table entry in the secure world such that it maps to the specified physical address, essentially creating world shared memory. However, I am not sure how I would do this in Genode. For example, in the Normal World linux I could edit the paging global directory, but in the Genode OS how could I make a PTE map to a given physical address? Thank you, Mauricio On Mon, Apr 9, 2018 at 2:36 AM, Stefan Kalkowski < stefan.kalkow...@genode-labs.com> wrote: > Hi Mauricio, > > On Wed, Mar 28, 2018 at 07:48:43PM -0700, Mauricio Gutierrez wrote: > > Hello, > > > > I have been doing some work with the Genode Trustzone VMM scenario on my > > i.MX53 development board and I am having a bit of trouble understanding > how > > the SMC calls work between the normal and secure world. Online you talk > > about how you implemented 6 calls in the modified normal world linux > kernel > > but in the main for the tz_vmm I only found 4 different cases in the > > _handle_smc() function. In any case, I wanted to add my own call and was > > able to add it and check that the required arguments are passed correctly > > and everything so that part I think I understand. > > > > However, I need to do some of the handling in Monitor Mode and my > > understanding was that an SMC would throw your into monitor mode but it > > seems the handler operates in user mode? Since it is not privileged then > I > > am not able to call a "cps #22" to switch to monitor mode. In an earlier > > thread I know you refer to the > > > > section "World switch between non-secure world and secure > > > world" in http://genode.org/documentation/articles/trustzone. > > > > But I am still uncertain as to how I could get my case in _handle_smc() > to > > enter monitor mode so that I can play around with the NS bit without > > leaving secure world. > > You are right, our virtual-machine monitor is an unprivileged > user-level component. Because driving the normal world is not > crucial to other components inside the secure world, there is no need > to make them dependent on complex emulation/para-virtualization code inside > the kernel. That is why the kernel contains a slim > exception-vector-only functionality that is used to copy over the > normal world state to the VMM user-level component. This > exception-vector code is entered, e.g., when doing a "smc" call and > can be found here: > > repos/base-hw/src/core/spec/arm_v7/trustzone/exception_vector.s > > That assembly code is the only code executed in monitor mode. In the > end it switches to secure world's supervisor mode and enters the > normal kernel routine. However, it hits subsequently some C++ VMM > kernel object routine here: > > repos/base-hw
SMC Calls in Trustzone VMM Scenario
Hello, I have been doing some work with the Genode Trustzone VMM scenario on my i.MX53 development board and I am having a bit of trouble understanding how the SMC calls work between the normal and secure world. Online you talk about how you implemented 6 calls in the modified normal world linux kernel but in the main for the tz_vmm I only found 4 different cases in the _handle_smc() function. In any case, I wanted to add my own call and was able to add it and check that the required arguments are passed correctly and everything so that part I think I understand. However, I need to do some of the handling in Monitor Mode and my understanding was that an SMC would throw your into monitor mode but it seems the handler operates in user mode? Since it is not privileged then I am not able to call a "cps #22" to switch to monitor mode. In an earlier thread I know you refer to the section "World switch between non-secure world and secure > world" in http://genode.org/documentation/articles/trustzone. But I am still uncertain as to how I could get my case in _handle_smc() to enter monitor mode so that I can play around with the NS bit without leaving secure world. I have been studying what happens when I call an smc, say "smc #4" from normal world. But I have not been able to exactly pin point, where is the entry point for such an exception in the Genode secure world call? What exactly happens once I make that call to secure world and where I can I find/follow the code? Is this covered somewhere in your book? I know about the mode_transitions.s file as well as the exception_vector.s and vm.cc files in repos/base-hw/src/core/spec/arm_v7/trustzone, it seems this is the entry point? But where does it go after we call the nonsecure_to_secure transition? Most importantly, I need to understand where is the code operating in monitor mode? Where does it end and where does it start? How can I tell? If I needed to write at least some part of my smc handler in monitor mode before it switches out, what is the best approach to doing that? I apologize for all the questions and would appreciate any help and guidance you can provide. Thank you, Mauricio -- 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: Compiling Kernel Modules for Genode on iMX53 with TrustZone
Hello Stefan, Thank you for clearing that up. However, I have been trying to compile the kernel and I am getting a lot of warnings and errors. That is, I am trying to cross compile the linux kernel for the tz_vmm for the imx53 on my VM runninng Ubuntu 16.04. I made sure to read the Changes in the documentation folder and have the required verisons of GNU, make, perl and perl modules as specified. I have also been looking around on the Mailing List and there is a link floating around to a guide for compiling the kernel for the tz_vmm scenario but when I click it it tells me the page no longer exists. That being said I do need to build the kernel to get the Module.symvers file among others. I have tried using both the imx5_defconfig and imx5_android_tz_defconfig but when I try to make I keep getting an error: "Target processor does not support smc #0" The commands I run look like this: make ARCH=arm CROSS_COMPILE=~/Documents/Genode/gcc-linaro-arm-none-eabi-4.9-2014.09_linux/bin/arm-none-eabi- distclean make ARCH=arm CROSS_COMPILE=~/Documents/Genode/gcc-linaro-arm-none-eabi-4.9-2014.09_linux/bin/arm-none-eabi- imx5_defconfig make ARCH=arm CROSS_COMPILE=~/Documents/Genode/gcc-linaro-arm-none-eabi-4.9-2014.09_linux/bin/arm-none-eabi- Where the cross compiler is from the Genode toolchain. I recently ran into the thread "Building Genode for Linux/ARM" [1] and there it says that the linux platforms do not support cross-compiling, but I think what they are doing is different? Otherwise, is this still true? If so, if I want to compile the kernel myself would I have to go through the process they did using qemu? I am new to this so sorry if these questions are not the best or missing information. Any help would be appreciated. [1] https://sourceforge.net/p/genode/mailman/message/34123311/ Thank you, Mauricio On Wed, Oct 25, 2017 at 6:04 AM, Stefan Kalkowski < stefan.kalkow...@genode-labs.com> wrote: > Hi Mauricio, > > On 10/25/2017 12:39 AM, Mauricio Gutierrez Barnett wrote: > > Hello, > > > > I have a question about adding kernel modules to the Genode OS. > > > > So I have built and boot the tz_vmm scenario for platform > > hw_imx53_qsb_tz on the i.MX53 development board using another thread on > > this mailing list as a guide. I was able to get it up and running on the > > board with no problems. > > However, I need to install a kernel module into the normal world linux. > > In order to do this I need to be able to cross compile the module for > > the target kernel running in normal world from my desktop. > > However, while I have access to the target compiler I do not have a > > target kernel directory. > > That is, only the final image of linux is provided, not the source code > > used to compile it. > > it is available. I referred to it several times on this mailing list. > The Linux kernel used within the tz_vmm.run test script was built using > the following Linux kernel branch, which is slightly modified to not > crash within the normal world based on the official sources provided by > Freescale: > > https://github.com/skalk/linux/tree/imx53-tz > > > I know the version is provided as Linux version 2.6.35.3-01270-g9533414. > > However, if I try to use the 2.6.35.3-generic version as a target I get > > a symbol version error when I try to insmod: > > > > "disagrees about version of symbol kmalloc_caches > > Unknown symbol kmalloc_caches (err -22)" > > > > I believe this is because the kernel running in the normal world has > > been modified. > > The Freescale sources and vanilla Linux sources are quite different from > each other. I assume it clashes therefore. > > Regards > Stefan > > > I am wondering if there is another way for me to compile kernel modules > > for Genode. If not, would it be possible for you to release the source > > code of your modified kernel which you used to create the Linux Image > > that runs in the normal world? > > > > Thank you for your time, > > > > Mauricio Gutierrez > > > > > > > -- > > 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
Compiling Kernel Modules for Genode on iMX53 with TrustZone
Hello, I have a question about adding kernel modules to the Genode OS. So I have built and boot the tz_vmm scenario for platform hw_imx53_qsb_tz on the i.MX53 development board using another thread on this mailing list as a guide. I was able to get it up and running on the board with no problems. However, I need to install a kernel module into the normal world linux. In order to do this I need to be able to cross compile the module for the target kernel running in normal world from my desktop. However, while I have access to the target compiler I do not have a target kernel directory. That is, only the final image of linux is provided, not the source code used to compile it. I know the version is provided as Linux version 2.6.35.3-01270-g9533414. However, if I try to use the 2.6.35.3-generic version as a target I get a symbol version error when I try to insmod: "disagrees about version of symbol kmalloc_caches Unknown symbol kmalloc_caches (err -22)" I believe this is because the kernel running in the normal world has been modified. I am wondering if there is another way for me to compile kernel modules for Genode. If not, would it be possible for you to release the source code of your modified kernel which you used to create the Linux Image that runs in the normal world? Thank you for your time, Mauricio Gutierrez -- 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
