On 23.07.2018 21:32, Joerg Sonnenberger wrote: > On Mon, Jul 23, 2018 at 07:13:49PM +0200, Kamil Rytarowski wrote: >> We need to have stack, heap and code of a program in predictable (and >> quite narrow) ranges and thus ASLR disabled or less aggressive. > > What for? Nothing in the sanitizer design should require that. The only > requirement should be that the shadow area can be mapped at a fixed > location. > We need to maintain a function to translate certain ranges to shadow/meta/origin/etc. We cannot map arbitrarily wide ranges to them. Depending on the sanitizer there might be a need for multiple shadow/origin/meta buffers - this is the case of TSan and MSan. ASan uses a single shadow buffer and it sometimes works. ASan is also a special case as it was designed to function in narrow address space (below 32-bit). With TSan I've discovered that there is no room with the current randomization to maintain a set of functions to map into meta buffers. So far there were no problems observed with mapping a buffer at a fixed address (but I don't say that there are none). The issues pop up with discovered mappings out of expected ranges and assert() in the best case, or random corruption and crash in the worst one. It used to be simple to miss that there is ASLR enabled for a process and debug a new crash sanitizers - to prevent this, I've included upstream a function CheckASLR() to detect it and report verbosely. On the other hand, Linux ASLR and Fuchsia ASLR are compatible with the sanitizers and data regions are in predictable and narrow ranges in the process virtual address space. > Joerg >
Attachment:
signature.asc
Description: OpenPGP digital signature