Thanks for the comments! I've addressed them in the updated patch.
================ Comment at: docs/SafeStack.rst:107 @@ +106,3 @@ +breaking the probabilistic security guarantees through information leaks, may +be not complete yet. System library functions such as ``setjmp``, exception +handling mechanisms, intrinsics such as ``__buildin_frame_address``, or ---------------- jfb wrote: > "may be not complete yet" is pretty awkward phrasing. I've rephrased this and the previous paragraphs to make it sound less awkward. ================ Comment at: docs/SafeStack.rst:111 @@ +110,3 @@ +such safe stack pointer leaks could be detected by a static binary analysis or +a dynamic binary instrumentation based tools. + ---------------- jfb wrote: > I'd strengthen this last statement: at the moment safe stack assumes that the > compiler's implementation is correct. This has not been verified except > through code inspection, and could always regress in the future. It's > therefore desirable to have a separate static or dynamic binary analysis / > checker. Great point! I think it applies to the entire SafeStack instrumentation, not just the hiding aspect, hence I added this note at the end of the Security Limitations section. http://reviews.llvm.org/D10598 EMAIL PREFERENCES http://reviews.llvm.org/settings/panel/emailpreferences/ _______________________________________________ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
