• State Accepted Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 2 replies
  • Subscribers 349 subscribers
  • Views 9179 views
  • Users 0 members are here
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

Security principles for TrustZone for ARMv8-M - example slide 22

raghu.ncstate

I noticed on slide 22 of the security principles presentation the function definition sec_sum_silly(int *p, volatile size_t *s); The presenter explicitly noted that they needed to mark the variable s as volatile. Im not sure I see why.

The contents of memory location s might change at any time due to a non secure interrupt(for ex. as the presenter suggested) or from another core, but given that we are copying the value in the statement size_t s_saved = *s, locally onto stack/registers, before performing the range check, I don't see how marking it as volatile will help. Once we copy the size locally, how does it matter if the value in non secure memory changes?

I apologize if I'm missing something obvious.

Thanks

  • +2 Arm Employee Badge
    hi,

    I copied the explanation below but please see the full description in this blog.

    community.arm.com/.../a-few-intricacies-of-writing-armv8-m-secure-code


    Note that *s is declared as volatile. The compiler needs to be aware that s points to volatile memory. This prevents s_saved from being optimised away due to, for example, contention on the registers. This could lead to multiple loads of *s which would lead to a security issue if the *s value is checked, but a different value is used during the for-loop.
  • 0 in reply to Diya Soubra
    Thanks Diya. I agree ! I would however change the wording a little bit. An optimizing compiler TYPICALLY would try to do one load and cache values in registers(assuming we did not declare *s as volatile). So rather than saying s_saved would be optimized away because *s is not marked volatile, and because a compiler prefers to do loads instead of caching it in a register sounds weird. The problem really is that the compiler may not be able to optimize that statement to do one load into a register and use the register later, as one would intuitively expect, when there is register contention, as pointed out in the link above.
    Anyway, it appears that this problem can be extrapolated to secure code performing memcpy's from non secure to secure memory! if the non secure memory pointer is not marked as volatile, the memcpy might be optimized away.