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

[Kostya Kortchinsky via llvm-commits]

cryptoad added inline comments.

================
Comment at: projects/compiler-rt/lib/hardened_allocator/scudo_allocator.cc:188
@@ +187,3 @@
+  getAllocator().InitCache(&cache);
+  ThreadInited = true;
+}
----------------
For this, I used the same technique that is used in ASan's PlatformTSDDtor, as it seems to be the most viable one.
I am not sure what alternative would work here.

================
Comment at: projects/compiler-rt/lib/hardened_allocator/scudo_allocator.h:42
@@ +41,3 @@
+/**/
+
+// We will also use our own CheckFailed and Die functions, once again to avoid
----------------
This actually a straight copy from sanitizer_internal_defs.h, just replacing CheckFailed. So I left it as is.
This will go away when I redo the CHECK_IMPL logic to follow kcc@'s suggestion to implement templated failure functions.

================
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() {
----------------
dvyukov wrote:
> 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.
I gave it a try and I have had a lot of issues with /dev/random on my system.
Between the fact that it's blocking, and that sometimes it won't return the amount of bytes requested, the tests have been failing inconsistently.
Tests with /dev/urandom worked better though.
I am going to dig further into that.


http://reviews.llvm.org/D20084