Date: Fri, 17 Oct 2014 15:19:03 +0100 From: David Carlier <david.carlier@hardenedbsd.org> To: Shawn Webb <lattera@gmail.com>, Warner Losh <imp@bsdimp.com> Cc: PaX Team <pageexec@freemail.hu>, FreeBSD Arch <freebsd-arch@freebsd.org> Subject: Re: PIE/PIC support on base Message-ID: <CAMe1fxai0025voJdr6QPj6UEbOnngnci%2BTg8HJXBAOP5bdnmdQ@mail.gmail.com> In-Reply-To: <CADt0fhyZbnRZVwfvpvZDr5Qqd4X=yfcHR-GO_NFFNZx_ceOjOg@mail.gmail.com> References: <CAMe1fxaYn%2BJaKzGXx%2Bywv8F0mKDo72g=W23KUWOKZzpm8wX4Tg@mail.gmail.com> <CAGSa5y3s9r0DRyinfqV=PJc_BT=Em-SLfwhD25nP0=6ki9pHWw@mail.gmail.com> <CAMe1fxaBEc5T77xjpRsMi_kkc5LXwPGooLWTO9C1FJcLSPnO8w@mail.gmail.com> <CAGSa5y2=bKpaeLO_S5W%2B1YGq02WMgCZn_5bbEMw%2Bx3j-MYDOoA@mail.gmail.com> <CADt0fhzg5G1cLEBNfHXSEi9iP7mCP=8sSwpXbFobig=pm=QsFQ@mail.gmail.com> <CAGSa5y1LBxkUNSgKkw=F9_uykXDeBV7_WL0a7Wt%2B%2BGgMTSULEQ@mail.gmail.com> <CADt0fhweiymn2D09%2Be7f44AreWe%2B8cmAtDVeec0NfmuWuOOhbg@mail.gmail.com> <315B4DC5-0E04-4F6B-BBB0-477D049025BF@bsdimp.com> <CADt0fhyCBa3PTnZ3dpc-hpysyC9V0MXR16s-e10V0ioAfaWHuw@mail.gmail.com> <C7C48B02-E65C-4F90-A503-1FDDCB590B7D@bsdimp.com> <CADt0fhyZbnRZVwfvpvZDr5Qqd4X=yfcHR-GO_NFFNZx_ceOjOg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Agreed with couple WANT_PIE/MK_PIE. Regards. On Fri, Oct 17, 2014 at 3:10 PM, Shawn Webb <lattera@gmail.com> wrote: > On Fri, Oct 17, 2014 at 10:05 AM, Warner Losh <imp@bsdimp.com> wrote: > >> [[cc trimmed ]] >> >> >> On Oct 17, 2014, at 7:46 AM, Shawn Webb <lattera@gmail.com> wrote: >> >> > On Fri, Oct 17, 2014 at 9:41 AM, Warner Losh <imp@bsdimp.com> wrote: >> > >> > On Oct 17, 2014, at 2:05 AM, Shawn Webb <lattera@gmail.com> wrote: >> > >> > > On Fri, Oct 17, 2014 at 3:53 AM, Jeremie Le Hen <jlh@freebsd.org> >> wrote: >> > > >> > >> On Fri, Oct 17, 2014 at 12:15 AM, Shawn Webb <lattera@gmail.com> >> wrote: >> > >>> >> > >>> >> > >>> On Thu, Oct 16, 2014 at 5:59 PM, Jeremie Le Hen <jlh@freebsd.org> >> wrote: >> > >>>> >> > >>>> On Thu, Oct 16, 2014 at 8:21 PM, David Carlier >> > >>>> <david.carlier@hardenedbsd.org> wrote: >> > >>>>> >> > >>>>> I chose the "atomic" approach, at the moment very few binaries a= re >> > >>>>> concerned at the moment. So I applied INCLUDE_PIC_ARCHIVE in the >> > >> needed >> > >>>>> libraries plus created WITH_PIE which add fPIE/fpie -pie flags >> only if >> > >>>>> you >> > >>>>> include <bsd.prog.pie.mk> (which include <bsd.prog.mk>...) >> otherwise >> > >>>>> other >> > >>>>> binaries include <bsd.prog.mk> as usual hence does not apply. >> Look >> > >>>>> reasonable approach ? >> > >>>> >> > >>>> I think I understand what you mean. But I think PIE is commonpla= ce >> > >>>> nowadays and I don't understand what you win by not enabling it f= or >> > >>>> the whole system. Is it a performance concern? Is it to preserv= e >> > >>>> conservative minds from to much change? :) >> > >>> >> > >>> >> > >>> Looping in Kostik, Bryan Drewery, the PaX team, Hunger, and Sean >> Bruno. >> > >>> >> > >>> On i386, there is a performance cost due to not having an extra >> register >> > >>> available for the relocation work that has to happen. PIE doesn't >> carry >> > >> much >> > >>> of a performance penalty on amd64, though it still does carry some >> on >> > >> first >> > >>> resolution of functions (due to the extra relocation step the RTLD >> has to >> > >>> worry about). On amd64, after symbol resolution has taken place, >> there >> > >> is no >> > >>> further performance penalty due to amd64 having an extra register >> to use >> > >> for >> > >>> PIE/PIC. I'm unsure what, if any, performance penalty PIE carries >> on ARM, >> > >>> AArch64, and sparc64. >> > >>> >> > >>> Certain folk would prefer to see PIE enabled only in certain >> > >> applications. >> > >>> /bin/ls can't really make much use of PIE. But sshd can. I >> personally >> > >> would >> > >>> like to see all of base's applications compiled as PIEs, but that'= s >> a >> > >> long >> > >>> ways off. It took OpenBSD several years to accomplish that. Having >> > >> certain >> > >>> high-visibility applications (like sshd, inetd, etc) is a great >> start. >> > >>> Providing a framework for application developers to opt their >> application >> > >>> into PIE is another great start. >> > >>> >> > >>> Those are my two cents. >> > >> >> > >> OK. As long as i386 is still an important architecture, it can mak= e >> > >> sense to enable this on a per-binary basis if we don't want to have= a >> > >> discrepancy between archs. Also I buy your argument on /bin/ls but = I >> > >> was challenging to enable for the whole system because I wonder if >> > >> there aren't some unexpected attack surfaces, besides the obvious >> ones >> > >> (servers). >> > >> >> > >> Do you know what took so much time to OpenBSD? >> > > >> > > >> > > In a private conversation with Theo, I realized that my recollection >> of the >> > > time it took OpenBSD to compile all of base as PIEs was wrong. >> Quoting him: >> > > >> > > "It took 5 people approximately 3 months to debug it, activate it, a= nd >> > > start shipping it the next release. That was on amd64, for all >> > > dynamically linked binaries, except one (a gcc bug took some time to >> > > find). The next architectures followed about 1 or 2 per 6-month >> > > release." >> > > >> > > Given that only one person has worked on this in the past (me) and >> now the >> > > task has been delegated to another (David Carlier), I think we're >> doing >> > > okay on our end. There's a lot of moving parts, and neither of us >> fully >> > > understand all of them completely. We're working on it in >> HardenedBSD, in >> > > the hardened/current/pie branch. >> > > >> > > I'm thinking we might try for a WITH_PIE knob (and *not* use USE_PIE= ) >> and >> > > have certain high-profile applications opt-in to PIE until we work >> out all >> > > the details for everything en masse. Baptiste did bring up a good >> point >> > > with INTERNALLIB and I'm unsure of how we should handle that. >> > >> > WITH_PIE or WITHOUT_PIE controls, on a global basis, via the MK_PIE >> > variable, whether or not the user wants to turn on this feature for >> those >> > program that can do PIE. Designating which programs do, or don=E2=80= =99t, >> > use PIE simply must be done with a different variable. I posted a bit >> of a >> > rant about the current state of things that suggested a couple of >> > alternatives as well as giving some history as to why some options >> > aren=E2=80=99t to be used and the history behind some of my reactions.= :) >> > >> > For this reason, I think WITH_PIE, as I understand your proposal, >> > likely isn=E2=80=99t a good fit with other WITH_xxx variables used in = the src >> > tree today. >> > >> > Gotcha. To be honest, I found your email a tad bit confusing. Are you >> suggesting we create an ENABLE_feature framework? Or are you suggesting = we >> have a USE_PIE flag? Or are you suggesting something different entirely >> (and if you are, what?)? >> >> I=E2=80=99m saying we don=E2=80=99t have a good framework at the moment = to do this. We >> have several bad ones that all have their pitfalls. This is one reason I >> had >> the fast reaction to NO_PIE, then a minute later said =E2=80=9Cgo ahead = and use >> it and I=E2=80=99ll fix it.=E2=80=9D I=E2=80=99m still cool with that po= sition, btw. >> >> As for a name, that can be debated a lot, but I=E2=80=99d like to see s= omething >> new, easy to use and unambiguous. If you are looking for a suggestion >> for that name, let=E2=80=99s go with WANTS_PIE. Only Makefiles can set i= t. >> >> WANTS_PIE undefined means do the default behavior as defined by the >> current MK_PIE setting and perhaps system policy. =E2=80=9CGo with this = flow." >> >> WANTS_PIE=3Dyes means that if MK_PIE is =E2=80=9Cyes=E2=80=9D, then do P= IE things for >> this thing we=E2=80=99re building. If MK_PIE is =E2=80=9Cno=E2=80=9D, th= ough PIE is disabled for >> everything. >> >> WANTS_PIE=3Dno means that if MK_PIE is =E2=80=9Cyes=E2=80=9D, then disab= le doing PIE >> things for this component. If MK_PIE is no, it is also disabled. >> >> This could also be extended to NEEDS_foo, which says =E2=80=9CI need foo= to >> build, and if MK_foo is set to no, don=E2=80=99t build me.=E2=80=9D I do= n=E2=80=99t think anything >> that you are doing falls into this category though. >> >> WANTS/NEEDS also avoids the historical use of USE in the ports tree >> possibly creating confusion. >> >> If you go with WANTS_PIE, then you wouldn=E2=80=99t need bad.*.pie.mk. >> >> Comments? > > > I like that idea. I think we need buy off from Kostik. David, what are > your thoughts? > > Thanks, > > Shawn >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAMe1fxai0025voJdr6QPj6UEbOnngnci%2BTg8HJXBAOP5bdnmdQ>