> 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.
