• Locked Locked
  • Replies 2 replies
  • Subscribers 119 subscribers
  • Views 4548 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

TrustZone and CoreSight debug

china liu
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,
  • Note: This was originally posted on 28th March 2013 at http://forums.arm.com

    hi, ttfn:
    thank you!

    best wishes,
  • Arm Employee Badge
    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.