Date: Mon, 20 Apr 2020 16:21:59 +0200 From: Marcin Wojtas <mw@semihalf.com> To: Ed Maste <emaste@freebsd.org> Cc: freebsd-security@freebsd.org, Rafal Jaworowski <raj@semihalf.com> Subject: Re: ASLR/PIE status in FreeBSD HEAD Message-ID: <CAPv3WKdQrS4oAcUcNn_mQOUJCmKm88LWhv62yf5B0BkmnyGpaA@mail.gmail.com> In-Reply-To: <CAPyFy2Cis6mKP%2BtRqEG8CwODgLXVBpQsxQ4FJX6wrpiPODr=Bg@mail.gmail.com> References: <CAPv3WKfYyVnfNDTPOEN6TF_GjJr=ThdNeB1yMtTEoQoxEdHMDg@mail.gmail.com> <CAPyFy2Cis6mKP%2BtRqEG8CwODgLXVBpQsxQ4FJX6wrpiPODr=Bg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Ed, pt., 17 kwi 2020 o 15:52 Ed Maste <emaste@freebsd.org> napisa=C5=82(a): > > 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 st= atus > > 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 pre= vent > > enabling ASLR by default in the kernel and building the base system wit= h > > -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). I was thinking if it is possible to come up with such wide test coverage to test every single application from the base system. Do you think it is achievable or should we rather follow the approach to do as many tests as possible, but rely on the community feedback to catch the corner cases (like the ntpd issue mentioned in this thread)? What about the ports? > > > 2. In case the enablement becomes eventually approved, will it be bette= r 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. Understood. If there is likely a performance trade-off, how about doing tests e.g. on i386 and armv7? In case of a big drop or other issues, could limiting ALSR/PIE to 64-bit-only be a considered solution? > > > 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 reason= able > > to create a kind of reference matrix (archs vs tests)? Those could be d= one > > 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. Indeed I thought of kyua and measuring buildworld execution time for stressing the DUT and having the first comparison numbers for the low price. Do you think it is possible to get help here, i.e. is there a FreeBSD devops team, maintaining the Jenkins CI whose spare cycles could be used for this purpose? Or is this a field requiring external help from interested parties? Even before the automation, would it be useful to perform some runs on chosen archs? > > 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. Yes, making use of something actively maintained would be great. Do you see a need for IO stressing/benchmarking for the discussed cases? Best regards, Marcin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPv3WKdQrS4oAcUcNn_mQOUJCmKm88LWhv62yf5B0BkmnyGpaA>