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

[Kostya Kortchinsky via llvm-commits]

cryptoad marked an inline comment as done.
cryptoad added a comment.

In http://reviews.llvm.org/D20084#443276, @dvyukov wrote:

> In http://reviews.llvm.org/D20084#441391, @cryptoad wrote:
>
> > One of the outstanding items on my list was to have a look at the CHECK logic to be able to have everything fast fail without callbacks if something went wrong.
>
>
> Why can't we just set Die as CheckFailedCallback?


What I am trying to prevent here is the use of callbacks at all. They would be an interesting target for an attacker as they would be writable function pointers that could be triggered on demand on heap corruption.


================
Comment at: projects/compiler-rt/lib/hardened_allocator/scudo_utils.cc:99
@@ +98,3 @@
+Xorshift128Plus::Xorshift128Plus() {
+  int Fd = open("/dev/urandom", O_RDONLY);
+  bool Success = readRetry(Fd, reinterpret_cast<u8 *>(&State_0_),
----------------
dvyukov wrote:
> urandom is not secure and can allow to guess the cookie in a local setuid binary.
So on this matter it seems that the general agreement is that urandom on modern Linux system is secure and can be used for cryptographic purposes. Even the more recent getrandom system call uses urandom by default, with the following entry in the man page: "Unless you are doing long-term key generation (and perhaps not even then), you probably shouldn't be using GRND_RANDOM.  The cryptographic algorithms used for /dev/urandom are quite conservative, and so should be sufficient for all purposes." 
/dev/random performs poorly in my tests, often blocking the allocator.


http://reviews.llvm.org/D20084