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@)
On Fri, Apr 17, 2020 at 02:58:06PM +0200, 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:Quick note: paxtest's algorithms for measuring ASLR was meant to test ASLR, not FreeBSD's ASR implementation. Thus, paxtest results for FreeBSD's ASR are moot. Link to the relevant discussion, as pointed out by the dude who coined the term ASLR: https://reviews.freebsd.org/D5603#120017 Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: <http://lists.freebsd.org/pipermail/freebsd-security/attachments/20200417/f28748c5/attachment.sig>
On Fri, 17 Apr 2020 at 08:58, Marcin Wojtas <mw at semihalf.com> wrote:> > Hi, > > Together with our customers, Semihalf is interested in improving the status > of security mitigations enablement in FreeBSD.Happy to hear that there's interest in this work!> 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?I believe there are no showstopper issues but there are a some prerequisites. One is that there are some applications that may misbehave with randomization enabled. They would need to be identified, and tagged (with the elfctl tool now in the base system).> 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?There's a general and increasing preference of avoiding different defaults per architecture. One issue though is that some options may have much larger performance impacts on certain architectures - e.g. position independent executables (PIE) on i386.> 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?Yes, benchmarking and testing are very important tasks on a path to enabling these by default. I agree with the CI comment; we should start with CI build + kyua runs with options turned on, in advance of changing the default. I would be interested in seeing macro-level benchmarking with mitigations on/off - for example, I assume Firefox must have a performance test suite that they use for tracking their own performance changes during development, and we could use benchmarks like that to see the impact of mitigations. Coming up with a full set of appropriate benchmarks will be a useful endeavour.
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 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" >