Hi, > Compared to other SPEC benchmarks, the fraction of overhead due to checks > is > > very low for gcc. Much overhead seems to come from heap poisoning and > from > > the quarantine queue, but there are also some 30% of overhead that hide > > elsewhere… I suspect that the allocator might be to blame. This suspicion > > arose because perf showed a high number of samples in the allocator. >
> Have you compared ASan perf stats to those with glibc allocator or > tcmalloc? > That comparison was against glibc's allocator. I haven't tried tcmalloc. Also note that gcc is a single-threaded benchmark AFAIK. I'd like to try other benchmarks and other allocators... do you have a good idea of what else I should try? In ASan allocator objects belonging to different size classes cannot > be adjacent in memory. > OK, that makes sense. In this case the redzone optimizations should indeed be sound. A slightly unrelated thing that we're interested in is heap > randomization under ASan. > I see. Not directly related to what I'm trying to achieve, but an interesting idea in general! I don't have many thoughts regarding that right now, except that the need for deterministic replay is very important. Users should have the possibility to manually set a seed, so they can reproduce an issue once it occurred. Also, this might be very interesting for the stack, too. I think even a slightly randomized stack layout (through random redzone sizes or variable reordering) could make it harder to write exploits. I know ASan is a debugging tool more than a security hardening tool, but I'd still find this interesting. Cheers, Jonas -- You received this message because you are subscribed to the Google Groups "address-sanitizer" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
