[PATCH] D20084: [sanitizer] Initial implementation of a Hardened Allocator

[Dmitry Vyukov via llvm-commits]

dvyukov added inline comments.

================
Comment at: projects/compiler-rt/lib/hardened_allocator/scudo_allocator.cc:88
@@ +87,3 @@
+  uptr UserBeg() {
+    return reinterpret_cast<uptr>(this) + ChunkHeaderSize;
+  }
----------------
Does it improve generated code?
Leaving it as 24 is OK in that case, but it needs to be explained in comments. Width of that field has crucial implicit relation with Min/MaxAlignment. When double-checked width, I found that it's not what I would expect it to be. What means that either I missing something else important here, or there is a bug, or things get out of sync. This uncertainty is very unpleasant and takes time for anybody reading the code.

================
Comment at: projects/compiler-rt/lib/hardened_allocator/scudo_utils.cc:110
@@ +109,3 @@
+
+// Default constructor for Xorshift128Plus seeds the state with RdRand64
+Xorshift128Plus::Xorshift128Plus() {
----------------
Yes, all that is predictable.
/dev/random is meant specifically for such cases, it uses various sources of entropy to create strongly random numbers.

On second though, just remove all rdtsc/cpuid/rdrand trickery and read from /dev/random. If rdrand is present, kernel will use it.


http://reviews.llvm.org/D20084