On 23.07.2018 15:09, Joerg Sonnenberger wrote: > On Mon, Jul 23, 2018 at 06:24:09PM +0530, Siddharth Muralee wrote: >>> >>> >>> (1) An implementation detail of userland shouldn't be leaked into the >>> kernel boot (!) process. >>> >> >> Okay. I think this makes sense(I am still pretty new to NetBSD) - Can you >> suggest some other location/config that can be used. > > paxctl. > OK, this is another approach and it should work. >>> (2) There is no fundamental issue that makes the sanitizers incompatible >>> with ASLR. The only issue for asan and friends is the reservation of the >>> shadow buffer and that can and should be handled explicitly. >>> >> >> We have implemented the ATF tests for ASan - The tests work only 50% or >> less when ASLR is on. To get perfect results I think ASLR needs to be off. >> I guess Kamil can provide more info on this. > > I'm very aware of the current situation. Ultimately, stack randomisation > has the same issue. The way we setup the VM space of a new process is > suboptimal for a world that wants to randomize things. I.e. at the > moment, the VM commands (epp->ep_vmcmds) are executed in order and that > makes placing fixed location objects difficult. What should happen is: > (1) Each VM object should grow an object group field. VM objects in the > same group are assigned a random location together. A special group > field value of 0 means no randomisation. > (2) Locations should be assigned first to fixed position fields and > otherwise in descending order of size. > (3) The stack of the main thread should be reserved and integrated into > the VM object reservation just like the rest. The current stack > randomisation should be removed. > > It should be noted that (2) needs to deal with impossible allocations, > so it should do one pass to size up each free range in the address space > that can fit the requested object, pick a random value and then as > second iteration find the correct range. to split. > This part is not clear for us. If this means that we shall rework ASLR in order to be compatible with sanitizers, than it's not viable on our own as of now (mostly as unclear goals here and we have got enough tasks)... but we are up to test a patch. We need to have stack, heap and code of a program in predictable (and quite narrow) ranges and thus ASLR disabled or less aggressive. In the TSan example, we can reuse the Linux and FreeBSD address space with the following assumptions: C/C++ on linux/x86_64 and freebsd/x86_64 0000 0000 1000 - 0080 0000 0000: main binary and/or MAP_32BIT mappings (512GB) 0040 0000 0000 - 0100 0000 0000: - 0100 0000 0000 - 2000 0000 0000: shadow 2000 0000 0000 - 3000 0000 0000: - 3000 0000 0000 - 4000 0000 0000: metainfo (memory blocks and sync objects) 4000 0000 0000 - 5500 0000 0000: - 5500 0000 0000 - 5680 0000 0000: pie binaries without ASLR or on 4.1+ kernels 5680 0000 0000 - 6000 0000 0000: - 6000 0000 0000 - 6200 0000 0000: traces 6200 0000 0000 - 7d00 0000 0000: - 7b00 0000 0000 - 7c00 0000 0000: heap 7c00 0000 0000 - 7e80 0000 0000: - 7e80 0000 0000 - 8000 0000 0000: modules and main thread stack I've documented the NetBSD specifics as: C/C++ on netbsd/amd64 can reuse the same mapping: * The address space starts from 0x1000 (option with 0x0) and ends with 0x7f7ffffff000. * LoAppMem-kHeapMemEnd can be reused as it is. * No VDSO support. * No MidAppMem region. * No additional HeapMem region. * HiAppMem contains the stack, loader, shared libraries and heap. * Stack on NetBSD/amd64 has prereserved 128MB. * Heap grows downwards (top-down). * ASLR must be disabled per-process or globally. -- lib/tsan/rtl/tsan_platform.h I've found it impossible to handle TSan with enabled ASLR, taking the example of a running firefox, so a real-life application that we would want to sanitize. This approach of disabled ASLR ended up as needed for ASan and MSan too. > Joerg > On 23.07.2018 15:57, Mouse wrote: >>> I have recently been working on adding a new boot flag for disabling >>> ASLR during boot. [...useful for some userland stuff...] > > What's wrong with just configuring a kernel without any ASLR at all for > such work? > Nothing wrong and as stated in the beginning, we are doing it. Building and running a custom kernel config or patching the kernel sources seems just to be more than enough to run init(8) and other programs with a sanitizer. It's certainly not convenient. With the proposed bootloader flag we can reuse the same kernel without modifications.
Attachment:
signature.asc
Description: OpenPGP digital signature