Date: Fri, 17 Apr 2020 09:51:56 -0400 From: Ed Maste <emaste@freebsd.org> To: Marcin Wojtas <mw@semihalf.com> Cc: freebsd-security@freebsd.org, Rafal Jaworowski <raj@semihalf.com> Subject: Re: ASLR/PIE status in FreeBSD HEAD Message-ID: <CAPyFy2Cis6mKP%2BtRqEG8CwODgLXVBpQsxQ4FJX6wrpiPODr=Bg@mail.gmail.com> 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
On Fri, 17 Apr 2020 at 08:58, Marcin Wojtas <mw@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPyFy2Cis6mKP%2BtRqEG8CwODgLXVBpQsxQ4FJX6wrpiPODr=Bg>