[PATCH] Do not sanitize kernel area on 32-bit targets

Yury Gribov tetra2005 at gmail.com
Tue Mar 25 07:39:08 PDT 2014



================
Comment at: lib/asan/asan_rtl.cc:485
@@ -484,1 +484,3 @@
     ProtectGap(kShadowGapBeg, kShadowGapEnd - kShadowGapBeg + 1);
+    // Allow accesses to unprotected part of address space
+    if (kShadowGapEnd != kHighShadowBeg - 1)
----------------
Yury Gribov wrote:
> Kostya Serebryany wrote:
> > this is weird... This should not be required... hm.. Let me see your comments first. 
> With this patch kShadowGapEnd is now computed as (MEM_TO_SHADOW(kHighShadowEnd + 1) - 1) and kHighShadowEnd = MEM_TO_SHADOW(kHighMemEnd). kHighMemEnd can now be 3G instead of 4G so there is a 16M gap (== 128M / 8) between shadow gap and start of high shadow (see http://code.google.com/p/address-sanitizer/issues/detail?id=278 for exact memory maps). I think we should reserve this memory for ASan to avoid user code messing with ASan internals. The question is whether to mmap (this will allow access to kernel area) or protect it (this will force users to compile code that accesses kernel area without sanitization).
Ok, you were right - it's not required indeed. I replaced with CHECK.


http://llvm-reviews.chandlerc.com/D3119



More information about the llvm-commits mailing list