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

Filipe Cabecinhas via llvm-commits llvm-commits at lists.llvm.org
Tue May 17 06:02:16 PDT 2016


filcab added inline comments.

================
Comment at: projects/compiler-rt/lib/hardened_allocator/scudo_utils.cc:111
@@ +110,3 @@
+  std::hash<std::thread::id> hasher;
+  return getRdTSC() ^ hasher(std::this_thread::get_id()) ^
+      std::chrono::high_resolution_clock::now().time_since_epoch().count();
----------------
dvyukov wrote:
> cryptoad wrote:
> > filcab wrote:
> > > Using `/dev/urandom` should be what you need, yes.
> > > Did you still have problems with urandom, btw?
> > /dev/udrandom appeared to work fine.
> /dev/urandom is not what you need. It trades security for performance. I.e. instead of blocking it will just give you predictable randomness. Which kind of defeats the whole purpose of a security allocator.
> /dev/random blocks when it does not have enough entropy. But there is not much you can do if you do need the entropy.
> If it returns less bytes, read again. That's how it works with all read calls.
People like Daniel Bernstein and Thomas Ptacek (and others) tend to disagree and say that /dev/urandom is what we need:
http://blog.cr.yp.to/20140205-entropy.html
http://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/

I'm no expert in this, so I tend to rely on people who work on this kind of thing.


http://reviews.llvm.org/D20084





More information about the llvm-commits mailing list