Linux: grow a unique random mapping in ASLR

third_party/tcmalloc/chromium/src/system-alloc.cc

 // Copyright (c) 2005, Google Inc.
 // All rights reserved.
 // 
 // Redistribution and use in source and binary forms, with or without
 // modification, are permitted provided that the following conditions are
 // met:
 // 
 //     * Redistributions of source code must retain the above copyright
 // notice, this list of conditions and the following disclaimer.
 //     * Redistributions in binary form must reproduce the above
@@ skipping 119 matching lines @@
 
 void raninit(ranctx* x, u4 seed) {
   u4 i;
   x->a = 0xf1ea5eed;
   x->b = x->c = x->d = seed;
   for (i = 0; i < 20; ++i) {
     (void) ranval(x);
   }
 }
 
+const uint64_t kRandomAddressMask = 0x3ffffffff000ULL;
+
 #endif  // defined(ASLR_IS_SUPPORTED)
 
 // Give a random "hint" that is suitable for use with mmap(). This cannot make
 // mmap fail, as the kernel will simply not follow the hint if it can't.
 // However, this will create address space fragmentation.  Currently, we only
 // implement it on x86_64, where we have a 47 bits userland address space and
 // fragmentation is not an issue.
 void* GetRandomAddrHint() {
 #if !defined(ASLR_IS_SUPPORTED)
   return NULL;
@@ skipping 23 matching lines @@
       int ret = close(urandom_fd);
       ASSERT(ret == 0);
     }
     raninit(&ctx, seed);
   }
   uint64_t random_address = (static_cast<uint64_t>(ranval(&ctx)) << 32) |
                             ranval(&ctx);
   // If the kernel cannot honor the hint in arch_get_unmapped_area_topdown, it
   // will simply ignore it. So we give a hint that has a good chance of
   // working.
   // The mmap top-down allocator will normally allocate below TASK_SIZE - gap,

[jar (doing other things), 2013/02/01 22:31:27]

nit: This comment (lines 185-192) should be placed above line 140.

[jln (very slow on Chromium), 2013/02/01 22:50:47]

Done.

   // with a gap that depends on the max stack size. See x86/mm/mmap.c. We
   // should make allocations that are below this area, which would be
   // 0x7ffbf8000000.
   // We use 0x3ffffffff000 as the mask so that we only "pollute" half of the
   // address space. In the unlikely case where fragmentation would become an
   // issue, the kernel will still have another half to use.
   // A a bit-wise "and" won't bias our random distribution.
-  random_address &= 0x3ffffffff000ULL;
+  random_address &= kRandomAddressMask;
   return reinterpret_cast<void*>(random_address);
 #endif  // ASLR_IS_SUPPORTED
 }
 
+// Allocate |length| bytes of memory using mmap(). The memory will be
+// readable and writeable, but not executable.
+// Like mmap(), we will return MAP_FAILED on failure.
+// |is_aslr_enabled| controls address space layout randomization. When true, we
+// will put the first mapping at a random address and will then try to grow it.
+// If it's not possible to grow an existing mapping, a new one will be created.
+void* AllocWithMmap(size_t length, bool is_aslr_enabled) {
+  // Note: we are protected by the general TCMalloc_SystemAlloc spinlock.
+  static void* address_hint = NULL;
+  if (is_aslr_enabled &&
+      (!address_hint ||
+       reinterpret_cast<uint64_t>(address_hint) & ~kRandomAddressMask)) {

[Chris Evans, 2013/02/01 19:03:23]

I'm not sure the extra complexity here is worth is. In the unlikely event we
start allocating just before 0x40........ and then cross that line, do we really
care?

I like simplicity :)

[jln (very slow on Chromium), 2013/02/01 19:15:41]

I think it's more correct. Our line happens to give us some margin, but that's
an implementation detail. We certainly don't want to end up hitting the stack.

Moreover, not having this makes it even harder to assess how reliable the test
will be.

[jar (doing other things), 2013/02/01 22:31:27]

Do we have concerns about blocking stack growth? Isn't a stack allocated
(anywhere), but not committed, and grown within that bound?

If our hint is problematic, won't it just be ignored?  The only thing we have to
worry about (I think) is asking for an allocation of the bottom page... which
can't happen because the hint will be NULL.

Are there other real concerns on avoiding some addresses?

+1 simplicity (delete line 209).



On 2013/02/01 19:15:41, Julien Tinnes wrote:

[jln (very slow on Chromium), 2013/02/01 22:50:47]

It's a little more complex than "ignored". It's "ignored" when it makes no sense
(i.e. non x86_64 canonical address). Otherwise, the kernel tries to find
something "close enough".

"Collision with the stack" is not detected as problematic by the kernel afaik.
All concerns should be handled by this mask (and the comment explains the
rationale). I would really love to keep this.

In this particular version, it's not crucial, if this was changed by someone
else and became more complex, it may become crucial and would be easy to
overlook.

This is my last attempt at keeping it. If you really don't like it, say so and
I'll remove :)

+    address_hint = GetRandomAddrHint();
+  }
+
+  // address_hint is likely to make us grow an existing mapping.
+  void* result = mmap(address_hint, length, PROT_READ|PROT_WRITE,
+                      MAP_PRIVATE|MAP_ANONYMOUS, -1, 0);
+  if (result == address_hint) {
+    // If mmap() succeeded at a address_hint, our next mmap() will try to grow
+    // the current mapping as long as it's compatible with our ASLR mask.
+    // This has been done for performance reasons, see crbug.com/173371.
+    // It should be possible to strike a better balance between performance
+    // and security but will be done at a later date.
+    // If this overflows, it could only set address_hint to NULL, which is
+    // what we want (and can't happen on the currently supported architecture).
+    address_hint = static_cast<char*>(result) + length;
+  } else {
+    // mmap failed or a collision prevented the kernel from honoring the hint,
+    // reset the hint.
+    address_hint = NULL;
+  }
+  return result;
+}
+
 }  // Anonymous namespace to avoid name conflicts on "CheckAddressBits".
 
 COMPILE_ASSERT(kAddressBits <= 8 * sizeof(void*),
                address_bits_larger_than_pointer_size);
 
 // Structure for discovering alignment
 union MemoryAligner {
   void*  p;
   double d;
   size_t s;
@@ skipping 192 matching lines @@
   // Ask for extra memory if alignment > pagesize
   size_t extra = 0;
   if (alignment > pagesize) {
     extra = alignment - pagesize;
   }
 
   // Note: size + extra does not overflow since:
   //            size + alignment < (1<<NBITS).
   // and        extra <= alignment
   // therefore  size + extra < (1<<NBITS)
-  void* address_hint = NULL;
-  if (FLAGS_malloc_random_allocator) {
-    address_hint = GetRandomAddrHint();
-  }
-  void* result = mmap(address_hint, size + extra,
-                      PROT_READ|PROT_WRITE,
-                      MAP_PRIVATE|MAP_ANONYMOUS,
-                      -1, 0);
+  void* result = AllocWithMmap(size + extra, FLAGS_malloc_random_allocator);
   if (result == reinterpret_cast<void*>(MAP_FAILED)) {
     return NULL;
   }
 
   // Adjust the return memory so it is aligned
   uintptr_t ptr = reinterpret_cast<uintptr_t>(result);
   size_t adjust = 0;
   if ((ptr & (alignment - 1)) != 0) {
     adjust = alignment - (ptr & (alignment - 1));
   }
@@ skipping 226 matching lines @@
     }
   }
 #endif
 }
 
 void TCMalloc_SystemCommit(void* start, size_t length) {
   // Nothing to do here.  TCMalloc_SystemRelease does not alter pages
   // such that they need to be re-committed before they can be used by the
   // application.
 }