On Sat, 18 Apr 2020 at 04:19, Dewayne Geraghty <dewayne at 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.> 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...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.
On Mon, Apr 20, 2020 at 10:00:06AM -0400, Ed Maste wrote:> On Sat, 18 Apr 2020 at 04:19, Dewayne Geraghty > <dewayne at 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.
Thank-you for the pointer to elfctl. Unfortunately it looks like I need to create the section in the image file, due to my: (for example) # elfctl -l /usr/bin/ztest Known features are: aslr Disable ASLR protmax Disable implicit PROT_MAX stackgap Disable stack gap elfctl: NT_FREEBSD_FEATURE_CTL note not found on FreeBSD 12.1-STABLE #0 r359973M: Thu Apr 16 amd64 1201513 1201513 I had a look inside # readelf -SW /usr/bin/ztest I also looked inside /usr/share/mk/bsd.prog.mk (because it has elf hardening knobs) but no clues. Perhaps if you could provide a pointer? (Though I wonder how the new section will be inserted into some of the ports that require gcc? An adventure awaits...) Kind regards, Dewayne. PS Yes Konstantin had previously provided substantial assistance to resolve the ntpd issue. On 21/04/2020 12:00 am, Ed Maste wrote:> On Sat, 18 Apr 2020 at 04:19, Dewayne Geraghty > <dewayne at 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. > >> 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... > > 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. > _______________________________________________ > freebsd-security at freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe at freebsd.org" >
On Wed, 22 Apr 2020 at 02:10, Dewayne Geraghty <dewayne at heuristicsystems.com.au> wrote:> > Thank-you for the pointer to elfctl. Unfortunately it looks like I need > to create the section in the image file, due to my: (for example) > > # elfctl -l /usr/bin/ztest > Known features are: > aslr Disable ASLR > protmax Disable implicit PROT_MAX > stackgap Disable stack gap > elfctl: NT_FREEBSD_FEATURE_CTL note not found > > on > FreeBSD 12.1-STABLE #0 r359973M: Thu Apr 16 amd64 1201513 1201513Ah, yes - r340701 needs to be MFC'd to stable/12 to make this work there.