Date: Sat, 18 Apr 2020 10:12:32 +1000 From: Dewayne Geraghty <dewayne@heuristicsystems.com.au> To: freebsd-security@freebsd.org Subject: Re: ASLR/PIE status in FreeBSD HEAD Message-ID: <b57fd929-9776-5ff8-f7f6-91a1c8089da3@heuristicsystems.com.au> In-Reply-To: <CAPv3WKfYyVnfNDTPOEN6TF_GjJr=ThdNeB1yMtTEoQoxEdHMDg@mail.gmail.com> References: <CAPv3WKfYyVnfNDTPOEN6TF_GjJr=ThdNeB1yMtTEoQoxEdHMDg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. On the build server, the i386 jail with aslr enabled wasn't able to build gcc9; so this was disabled kern.elf32.*. 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... And yes we started with HardenedBSD which was very successful in late 2018, and contains many good ideas. As some applications on the On 17/04/2020 10:58 pm, Marcin Wojtas wrote: > Hi, > > Together with our customers, Semihalf is interested in improving the status > of security mitigations enablement in FreeBSD. To start with, based on our > initial research it seems that after 2019 enhancements the ASLR/PIE > features are in pretty much ready state. > > Building the world using the 'WITH_PIE' flag produced proper binaries and > the sanity showed no obvious degradations. Additionally, for the ASLR we > performed a comparison of the pax tests ( > https://github.com/opntr/paxtest-freebsd) for amd64/arm64 and they indicate > the feature is working fine after setting the according sysctl knobs. I'd > be happy to present the results and discuss the details, but firstly I'd > like to ask more general questions: > > 1. Are there any hard blockers, like missing features or bugs, that prevent > enabling ASLR by default in the kernel and building the base system with > -DWITH_PIE? > > 2. In case the enablement becomes eventually approved, will it be better to > do it for all archs or focus only on the selected ones? > > 3. IMO it may be worth to benchmark/stress the system for the stability > verification and perf comparison purpose. Do you think it may be reasonable > to create a kind of reference matrix (archs vs tests)? Those could be done > to evaluate the current state of the OS, but also for validating each > proposed feature. I also think engaging the FreeBSD CI might be a huge help > in such an effort. BTW, any particular tests / benchmarks come to your mind > as useful in this case? > > I'd appreciate any feedback. > > Best regards, > Marcin Wojtas (mw@) > _______________________________________________ > freebsd-security@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b57fd929-9776-5ff8-f7f6-91a1c8089da3>