• Locked Locked
  • Replies 3 replies
  • Subscribers 119 subscribers
  • Views 4709 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Switch to Non-Secure State During Boot Sequence

Geary Sutterfield
Note: This was originally posted on 2nd January 2013 at http://forums.arm.com

According to the specs, after a reset, a processor with the Security Extensions boots into secure mode. I thought I read somewhere that if the TEE isn't initialized, then the REE will be loaded and continue to run in secure state. Is that correct? If a switch is done to non-secure state before the REE is loaded, then how is that done? Is there ALWAYS some code present in the boot sequence to make that switch, even if there's no TEE? This question came up while I was discussing hypervisor mode with a colleague, and we found that hypervisor mode was not available while in secure state. To run using the Virtualization Extensions, the processor would have to be in non-secure state. So that seems to imply that a switch to non-secure state must be done at some point. But we didn't understand how that was done if an OEM didn't implement a TEE.

A related question: Do the processor manufacturers implement a TrustZone enable/disable fuse or switch? I didn't see anything in the ARM processor specs that described a global enable/disable TrustZone hardware switch. If there is such a switch, that would be another way to enter non-secure mode at boot time without additional state switching code.

Thanks for any insight into how this works.
Parents
  • Note: This was originally posted on 3rd January 2013 at http://forums.arm.com


    I''ll take the second part of your question first....

    There is no "TrustZone disable bit" in a processor which implements TrustZone (or ARM Security Extensions to give it its full title).  Basically because what TrustZone provides (seperation of memory spaces and execution environments) isn't the kind of thing that you easily turn on/off.  That doesn't of course mean you have to actively use, and in many designs it won't be.

    You will, however, probably see a number of TrustZone related fuses in a design.  For example, a fuse used to disable debug of the Secure world in production devices.  Or you might have a fuse which the boot software reads to see whether it should load the Secure OS or not....

    Leading us nicely back to the first part of the question :-)

    If you're not planning to actively use TZ you should still run your code in the Normal world.  This is not just because you won;t have access to virtualization in the Secure world.  So the initial boot code should always drop you into the Normal world.  Question is whether it boots a secure OS first.



    Thanks for the response. I understand that TrustZone is integrated into architecture. So it makes sense there's no disable switch or fuse. But that leads to another question that we've been struggling with. The scenario is we have a device that is TrustZone-enabled, but it doesn't boot a secure OS. In theory, since the processors boots into secure mode, could we write our own code to initialize the TEE, boot the secure OS, etc., then switch to non-secure mode? We were assuming the OEMs were doing something to prevent that from being done by a third party.
Reply
  • Note: This was originally posted on 3rd January 2013 at http://forums.arm.com


    I''ll take the second part of your question first....

    There is no "TrustZone disable bit" in a processor which implements TrustZone (or ARM Security Extensions to give it its full title).  Basically because what TrustZone provides (seperation of memory spaces and execution environments) isn't the kind of thing that you easily turn on/off.  That doesn't of course mean you have to actively use, and in many designs it won't be.

    You will, however, probably see a number of TrustZone related fuses in a design.  For example, a fuse used to disable debug of the Secure world in production devices.  Or you might have a fuse which the boot software reads to see whether it should load the Secure OS or not....

    Leading us nicely back to the first part of the question :-)

    If you're not planning to actively use TZ you should still run your code in the Normal world.  This is not just because you won;t have access to virtualization in the Secure world.  So the initial boot code should always drop you into the Normal world.  Question is whether it boots a secure OS first.



    Thanks for the response. I understand that TrustZone is integrated into architecture. So it makes sense there's no disable switch or fuse. But that leads to another question that we've been struggling with. The scenario is we have a device that is TrustZone-enabled, but it doesn't boot a secure OS. In theory, since the processors boots into secure mode, could we write our own code to initialize the TEE, boot the secure OS, etc., then switch to non-secure mode? We were assuming the OEMs were doing something to prevent that from being done by a third party.
Children
No data