Arm Community
Site
Search
User
Site
Search
User
Support forums
Arm Development Studio forum
TrustZone and CoreSight debug
Jump...
Cancel
Locked
Locked
Replies
2 replies
Subscribers
119 subscribers
Views
4602 views
Users
0 members are here
Options
Share
More actions
Cancel
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
TrustZone and CoreSight debug
china liu
over 12 years ago
Note: This was originally posted on 27th March 2013 at
http://forums.arm.com
hi, experts:
If a CPU supports TZ feature.
Could a hacker use coresight debug tool to trace its internal data stream?
best wishes,
Top replies
Martin Weidmann
over 12 years ago
+1
Note: This was originally posted on 27th March 2013 at http://forums.arm.com There are several signals that control who can debug what. These include SPNIDEN (Secure Privileged Non-Invasive Debug Enable...
Parents
Martin Weidmann
over 12 years ago
Note: This was originally posted on 27th March 2013 at
http://forums.arm.com
There are several signals that control who can debug what. These include SPNIDEN (Secure Privileged Non-Invasive Debug Enable) and SPIDEN (Secure Privileged Invasive Debug Enable). These signals are sampled by the processor at reset (and only at reset). Based on them, it will either allow/not allow debug of the secure world.
(For reference, Invasive debug is things like stepping and breakpoints. Non-invasive is things like trace.)
What you might expect is the production devices (going into real products) would have these signals tied to disable secure debug. While development boards would might have them tied to enable secure debug.
Debug of User mode is controlled by bits in a register. So it would be up to the secure OS whether you could debug secure apps.
There are also signals to enable/disable non-secure debug.
Cancel
Vote up
+1
Vote down
Cancel
Reply
Martin Weidmann
over 12 years ago
Note: This was originally posted on 27th March 2013 at
http://forums.arm.com
There are several signals that control who can debug what. These include SPNIDEN (Secure Privileged Non-Invasive Debug Enable) and SPIDEN (Secure Privileged Invasive Debug Enable). These signals are sampled by the processor at reset (and only at reset). Based on them, it will either allow/not allow debug of the secure world.
(For reference, Invasive debug is things like stepping and breakpoints. Non-invasive is things like trace.)
What you might expect is the production devices (going into real products) would have these signals tied to disable secure debug. While development boards would might have them tied to enable secure debug.
Debug of User mode is controlled by bits in a register. So it would be up to the secure OS whether you could debug secure apps.
There are also signals to enable/disable non-secure debug.
Cancel
Vote up
+1
Vote down
Cancel
Children
No data