Date: Mon, 20 Apr 2020 17:41:59 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Ed Maste <emaste@freebsd.org> Cc: Dewayne Geraghty <dewayne@heuristicsystems.com.au>, freebsd-security@freebsd.org Subject: Re: ASLR/PIE status in FreeBSD HEAD Message-ID: <20200420144159.GT2655@kib.kiev.ua> In-Reply-To: <CAPyFy2DErURgvKASUk_wghdPD=KA2KqT5Osczf7ZO4NFobFnsQ@mail.gmail.com> References: <CAPv3WKfYyVnfNDTPOEN6TF_GjJr=ThdNeB1yMtTEoQoxEdHMDg@mail.gmail.com> <b57fd929-9776-5ff8-f7f6-91a1c8089da3@heuristicsystems.com.au> <CAPyFy2DErURgvKASUk_wghdPD=KA2KqT5Osczf7ZO4NFobFnsQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Apr 20, 2020 at 10:00:06AM -0400, Ed Maste wrote: > On Sat, 18 Apr 2020 at 04:19, Dewayne Geraghty > <dewayne@heuristicsystems.com.au> wrote: > > > > I'm on a similar ride. We run applications in both i386 and amd64 jails > > with FreeBSD's ASLR enabled (sendmail, squid, apache, ...) and all good. > > Great! > > > On the build server, the i386 jail with aslr enabled wasn't able to > > build gcc9; so this was disabled kern.elf32.*. > > i386 has little spare address space and compiling applications as PIE > has a significant performance impact there, so enabling it only on > 64-bit seems quite reasonable. With 4/4 i386 gained +1G for UVA, which makes i386 binaries behaviour on i386 kernel almost identical to amd64 kernel. > > > ntp was the only real application that didn't play nicely with aslr. > > Fortunately, this was very helpful: > > > > /usr/bin/proccontrol -m aslr -s disable /usr/local/sbin/ntpd... It is really -m stackgap that hurted ntpd, but I remember that the code which was causing problems, was removed since then. > > Yes, and you can now (if using stable/12 or -CURRENT) use elfctl to > tag the binary with a note to request randomization be disabled for > the process, although we really should address the underlying issue.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200420144159.GT2655>