On Mon, May 1, 2017 at 12:28 PM, Mark Kettenis <mark.kette...@xs4all.nl> wrote: >> From: Dmitry Vyukov <dvyu...@google.com> >> Date: Mon, 1 May 2017 10:43:26 +0200 >> >> On Mon, May 1, 2017 at 8:51 AM, Greg Steuck <blackgne...@gmail.com> wrote: >> > I naively tried to build something with -fsanitize=address using llvm-4.0 >> > port available on OpenBSD 6.1-amd64. I was immediately greeted with: >> > clang-4.0: error: unsupported option '-fsanitize=address' for target >> > 'amd64-unknown-openbsd6.1' >> > >> > How deep a rat hole does one have to go to port ASan to a new >> > flavour of BSD? Is OpenBSD going to be particularly painful with >> > its special malloc and advanced ASLR? Is anybody working on this? > > Our focus is currently still on integrating llvm/clang/lld into > OpenBSD. As far as I know nobody is working on this yet, but it > sounds like something we'd certainly be interested in having. > >> Hi, >> >> I can think of 2 major areas re porting to a new OS: >> 1. Function interception. Presumably our current scheme just works on >> OpenBSD (as it works on Linux and FreeBSD). >> 2. Shadow memory mapping. We need to mmap a multi-TB range in process >> address space. Kernel need to support such huge mappings at all and >> with reasonable performance. How aggressive is ASLR? Is it possible to >> turn it off for a process (that may be the simplest option)? What's so >> special about malloc? Note that asan replaces standard malloc >> entirely. > > The ASLR is pretty aggressive and there is (quite deliberately) no > option to turn it off. Our malloc has some pretty nift bug detection > strategies built-in such as guard pages, aggressive unmapping of freed > memory, aggressive radomization, etc. Many of these features are > turned on by default. But replacing malloc with a different > implementation is still possible in OpenBSD. > > Currently mapping a mult-TB range doesn't work in OpenBSD. But I > think it could be made to work if most of that range will be mapped > with PROT_NONE.
It needs to be mapped with PROT_READ|PROT_WRITE and MAP_NORESERVE. We don't have code that later would detect which parts of the mapping actually become active and need to be remapped from PROT_NONE to PROT_RW, we rely on lazy, on-demand paging in.
