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

Dmitry Vyukov via llvm-commits llvm-commits at lists.llvm.org
Tue May 31 00:36:11 PDT 2016


dvyukov added a comment.

In http://reviews.llvm.org/D20084#443951, @cryptoad wrote:

> 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.


But that would mean that an attacker broke ASLR and can write arbitrary values at necessary memory locations. Does it still make sense to defend in such case?


================
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_),
----------------
cryptoad wrote:
> 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.
Okay. You know better.


http://reviews.llvm.org/D20084





More information about the llvm-commits mailing list