My allocator is much complex than that, it has start heuristics and then makes different mmap/munmap until it finds a location having the right (possibly reduced) size. That's why I was surprised to see munmap failed after successful mmap. I'll refine my strategy or I'll fall back to -novm.
-----Original Message----- From: Theo de Raadt [mailto:[email protected]] Sent: Wednesday, January 20, 2021 09:08 To: [email protected] Cc: 'Otto Moerbeek'; [email protected] Subject: Re: munmap sometimes does coredump on arm after mmap success At a rather fundamental level, any software which assumes it controls the address space totally, when it has *no facts to base that assumption on*, is broken. Completely broken. Always has been. Christian Jullien <[email protected]> wrote: > Many thanks for your replies. > OpenLisp has always the possibility to use -novm option which uses malloc > instead. It of course prevents save/restore core images to work. > I'll try different strategies wo. MAX_FIXED and also how to avoid SAR and > let you informed. > > Now a BIG thanks to OpenBSD team members for your work and support. > > C. > > -----Original Message----- > From: Theo de Raadt [mailto:[email protected]] > Sent: Wednesday, January 20, 2021 08:41 > To: Otto Moerbeek > Cc: [email protected]; [email protected] > Subject: Re: munmap sometimes does coredump on arm after mmap success > > Otto Moerbeek <[email protected]> wrote: > > > On Wed, Jan 20, 2021 at 07:04:08AM +0100, Christian Jullien wrote: > > > > > Hi, > > > > > > I'm running OpenBSD 6.8 on arm : > > > > > > $ sysctl | grep hw > > > hw.machine=armv7 > > > hw.model=ARM Cortex-A8 r3p2 > > > hw.ncpu=1 > > > hw.byteorder=1234 > > > hw.pagesize=4096 > > > hw.disknames=<edited> > > > hw.diskcount=2 > > > hw.cpuspeed=0 > > > hw.product=TI AM335x BeagleBone Black > > > hw.serialno==<edited> > > > hw.physmem=477257728 > > > hw.usermem=477241344 > > > hw.ncpufound=1 > > > hw.allowpowerdown=1 > > > hw.ncpuonline=1 > > > > > > $ uname -a > > > OpenBSD <edited> 6.8 GENERIC#353 armv7 > > > $ clang -v > > > OpenBSD clang version 10.0.1 > > > Target: armv7-unknown-openbsd6.8-gnueabi > > > Thread model: posix > > > InstalledDir: /usr/bin > > > > > > And I'm trying to port my OpenLisp ISLISP compiler on it (which is quite > > > different than OpenLISP, I have anteriority of the name). It needs a > portion > > > of memory reserved at a fixed address to allow to expand memory on > demand > > > and to save/restore images. > > > This code works on all systems I know (> 160 GNU triplets) and it works > for > > > years on OpenBSD x86/x64. > > > > > > On arm, the portion of code below, sometimes does a coredump after mmap > > > successfully returned the desired memory mapped region. > > > Changing the start address or memory size (down to 0x200000 == 2Mb) does > not > > > change the issue. > > > I can understand that mmap can fail for some given values but not why > munmap > > > fails after mmap success. > > > > This is not a bug. > > > > mmap with MAP_FIXED replaces any existing mapping. The unmap then zaps > that > > mapping, which could contain code or data used by the process. Due to > > address space randomization of various things, it depens on luck. > > > > The proper way is to not depend on a fixed address. If your image dump > > contains addresses, make them relative. For OpenLisp that might be a > > huge task though. But depending on fixed addresses is not going to > > work in the end. > > > > An approach that does not do damage but won't succeeed all the time: > > > > Try without MAP_FIXED. The hint will be used and if it overlaps with > > an existing mapping, mmap will return a different address or MAP_FAILED > > if it could not. Then check the address and if it isn't the expected > > address, bail out. It is better to fail than to cause memory corruption. > > Yep. > > As an experiment, try MAP_FIXED and suggest the address &printf. > > Good times, really very good times. >
