I am trying to learn about optee. What is the best way to get started?
Can I run an example system in QEMU? If so, how would I start?
I have heard references on videos and see in README.md a reference to a shell script based setup. Do I follow these directions given at optee_os/README.md:
$ cd $HOME $ mkdir devel $ cd devel $ git clone https://github.com/OP-TEE/optee_os.git
or these:
$ mkdir -p $HOME/devel/optee $ cd $HOME/devel/optee $ repo init -u https://github.com/OP-TEE/manifest.git -m ${TARGET}.xml [-b ${BRANCH}] $ repo sync
I see an entry.S in plat-sunxi, but not in any of the other platforms. Is this the new way of doing things or is it the old way. (The exception table seems to be defined in generic_entry_a32.S and generic_entry_a64.S.
For the ARMv7-A architectures, it seems that bootstrap code is included. Is that correct?
Does the bootstrap code also launch the Linux kernel?
How is flash access mediated? I was expecting to find that TrustZone was used to isolate, e.g. the SDIO controller from the normal world and that the TEE would mediate access to the nonvolatile storage. But that would require changes to the Linux kernel, which I don't see. Instead, I see support for secure storage in the normal world.
It seems that the following architectures are supported:
cortex-a7 cortex-a9 cortex-a15 cortex-a53 cortex-a57
I prefer to ask these questions on a public mailing list. They seem a little too involved for IRC, and I'm sure there are others besides I who would benefit from the answers.
Thank you for your time.
--wpd
Hi, Patrick.
I can't answer to all your questions, but here is what I have:
On 18 November 2016 at 16:52, Patrick Doyle wpdster@gmail.com wrote:
I am trying to learn about optee. What is the best way to get started?
Depends on what you want to achieve. There are number or docs in the main repository: https://github.com/OP-TEE/optee_os/tree/master/documentation
Can I run an example system in QEMU? If so, how would I start?
Yes, you can. Basically you need to use repo tool as you suggested. Use manifest 'qemu_v8_stable.xml'. After "repo sync" just cd to `build` dir and run # make run
This will compile all code and launch qemu with two terminals.
I have heard references on videos and see in README.md a reference to a shell script based setup. Do I follow these directions given at optee_os/README.md:
$ cd $HOME $ mkdir devel $ cd devel $ git clone https://github.com/OP-TEE/optee_os.git
or these:
$ mkdir -p $HOME/devel/optee $ cd $HOME/devel/optee $ repo init -u https://github.com/OP-TEE/manifest.git -m ${TARGET}.xml [-b ${BRANCH}] $ repo sync
I see an entry.S in plat-sunxi, but not in any of the other platforms. Is this the new way of doing things or is it the old way. (The exception table seems to be defined in generic_entry_a32.S and generic_entry_a64.S.
ARMv-7 is somewhat chaotic when it comes to initialization. Every platform has own quirks. But exception tables you see are generic as they used in Secure Supervisor (or S-EL1) mode.
For the ARMv7-A architectures, it seems that bootstrap code is included. Is that correct?
If under "bootstrap code" you mean "Secure Monitor" then yes, it is included for ARMv7-A.
Does the bootstrap code also launch the Linux kernel?
If we are talking about ARMv7, then yes. Check out generic_boot.c. There are variable nsec_entry that points to entry point for Normal World. In ARMv8 there are Trusted Firmware which acts as Secure Monitor. This simplifies life of OP-TEE kernel.
How is flash access mediated? I was expecting to find that TrustZone was used to isolate, e.g. the SDIO controller from the normal world and that the TEE would mediate access to the nonvolatile storage. But that would require changes to the Linux kernel, which I don't see. Instead, I see support for secure storage in the normal world.
It is heavily platform dependent. There are platforms where access to boot flash is protected by TZ, but on most of the platforms it is not.
It seems that the following architectures are supported:
cortex-a7 cortex-a9 cortex-a15 cortex-a53 cortex-a57
You can say than any ARMv7-A or ARMv8-A core with Security Extensions enabled is supported.
I prefer to ask these questions on a public mailing list. They seem a little too involved for IRC, and I'm sure there are others besides I who would benefit from the answers.
Thank you for your time.
--wpd _______________________________________________ Tee-dev mailing list Tee-dev@lists.linaro.org https://lists.linaro.org/mailman/listinfo/tee-dev
Thanks for the answers.
What about memory management? I have been reading through the ARM documentation about TrustZone (it's a pretty slow read for me, so this may take some time), but some of what I've seen with op-tee indicates that it runs out of off-chip DRAM, which seems pretty insecure to me, especially if a (root) user space application can gain access to /dev/mem or /dev/kmem, or if a (malicious) kernel module started poking around where it shouldn't.
How is access to secure RAM managed with op-tee? I am starting to understand a little bit about the NS bit in the ARM Secure Configuration Register, and the (effective) 33 bit address space that provides, but I don't understand how a TrustZone based TEE would protect access to its memory resources. Where could/should I look to learn more?
--wpd
Patrick,
Memory security is enforced on hardware level. There are reference ARM implementation named ARM TZC-400. But I haven't seen SoC that use that controller. I had experience with TI chips. They use special extension to theirs L3 Interconnect bus, Renesas also have hardware extensions for DRAM controller and also some extension for AXI bus. So, as you can see, this is device-specific. Thus, secure regions are configured in platform code or earlier, in bootloaders/ROM-code.
Because secure regions in DRAM are enforced by hardware, Normal World (Linux kernel) have no means to access this regions in any way.
If you want to know more about how it is works on hardware level - take a look at ARM AXI specs. Idea is to carry NS bit with memory read/write transaction to slave device, where slave device can examine this bit and decide what to do with transaction.
TrustZone is very complex thing. There are Security Extensions not only in computing cores, but also in MMU, interrupt controller, data bus, etc.
On 24 November 2016 at 15:25, Patrick Doyle wpdster@gmail.com wrote:
Thanks for the answers.
What about memory management? I have been reading through the ARM documentation about TrustZone (it's a pretty slow read for me, so this may take some time), but some of what I've seen with op-tee indicates that it runs out of off-chip DRAM, which seems pretty insecure to me, especially if a (root) user space application can gain access to /dev/mem or /dev/kmem, or if a (malicious) kernel module started poking around where it shouldn't.
How is access to secure RAM managed with op-tee? I am starting to understand a little bit about the NS bit in the ARM Secure Configuration Register, and the (effective) 33 bit address space that provides, but I don't understand how a TrustZone based TEE would protect access to its memory resources. Where could/should I look to learn more?
--wpd
On Thu, Nov 24, 2016 at 9:47 AM, Volodymyr Babchuk vlad.babchuk@gmail.com wrote:
Patrick,
Memory security is enforced on hardware level. There are reference ARM implementation named ARM TZC-400. But I haven't seen SoC that use that controller.
Ahhh.... things are starting to make sense. Thank you for your explanation. I am trying to map what I learn about OP-TEE onto the SAMA5D2x processor from Atmel/Microchip since that is the SoC with which I have the most (recent) experience. I see in the data sheet for that part that it has a pair of switch matrices (H64MX/H32MX) through which access to the external SDRAM is mediated. I see also that it has a mechanism for splitting external memory into secure & non-secure banks. (I haven't completely grokked the details of that split, but for this level of understanding, I don't need to -- I just need to see for myself how it was done on a system I recognize). I'll bet I'll be able to find a similar mechanism on one of the op-tee supported processors, now that I know what it should look like.
Thanks for you help.
--wpd
-
Patrick Doyle -
Volodymyr Babchuk