Date: Sat, 25 May 2013 09:03:57 -0500 From: Bryan Drewery <bdrewery@FreeBSD.org> To: freebsd-hackers@FreeBSD.org, Jeremie Le Hen <jlh@FreeBSD.org> Subject: Re: Turn libc.so into an ld script Message-ID: <51A0C4CD.6000709@FreeBSD.org> In-Reply-To: <20130525080639.GS71389@caravan.chchile.org> References: <20130525080639.GS71389@caravan.chchile.org>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2QWFUPXFEWVEIJIRFAVTU Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I've been running my systems with this modification since Feb 2012 and have seen no problems beyond file(1) usage on /usr/lib/libc.so in openssl's configure. I've taken ports/168010 and ports/138228 for exp-runs. I want to get (optional) SSP support into ports this year. I'll start a libc.ld exp-run tomorrow. It will be ran against 9.1-RELEASE since HEAD currently only has 1/2 of the ports tree passing due to the clang switch. Bryan On 5/25/2013 3:06 AM, Jeremie Le Hen wrote: > Hi, >=20 > There has been quite a while since the SSP glue has been committed in > the tree. Yet there has always been a gloomy corner case since then > that was reported from time to time, mainly by port maintainers, which > has been hard to reproduce. This is the main showstopper to enable SSP= > for ports by default. >=20 > On i386 for PIC objects, gcc uses the __stack_chk_fail_local hidden > symbol instead of calling __stack_chk_fail directly [1]. This happen > not only with our gcc-4.2.1 but also with the latest gcc-4.8. If you > want the very nasty details, see [2]. >=20 > OTOH the problem doesn't exist on other architectures. It also doesn't= > exist with Clang as the latter will somehow manage to create the > function in the object file at compile time (contrary to only > referencing it through a symbol that will be brought in at link time). >=20 > In a perfect world, when an object file is compiled with > -fstack-protector, it will be linked into a binary or a DSO with this > same flag as well, so GCC will add libssp_nonshared.a to the linker > command-line. Unfortunately, we don't control softwares in ports and w= e > may have such broken DSO. This is the whole point of this patch. >=20 > I wrote a specific test that exhibits the error: > http://people.freebsd.org/~jlh/twisted_ssp_linktime_fail.shar > If you run "make main" on i386, it will fail. More details at [3]. >=20 > So the attached patch turns libc.so into an ld script which will > automatically _propose_ libssp_nonshared.a along with the real libc DSO= > to the linker. It is important to understand that the object file > contained in this library will be pulled in the resulting binary > _only if_ the linker notices one of its symbols is needed (i.e. one of > the SSP symbol is missing). Otherwise nothing is changed, except a > slight theorical overhead that I wasn't able to measure on my Core 2 > developement machine with -j 4: >=20 > x current > + current_libc_ldscript > +----------------------------------------------------------------------= --------+ > | ++ x+ xx + = x| > |||_____________M__M_______A____A___________________|__________| = | > +----------------------------------------------------------------------= --------+ > N Min Max Median Avg St= ddev > x 4 9130 9227 9136 9157 46.74= 0418 > + 4 9126 9207 9132 9148 39.42= 0807 >=20 >=20 > Any objection to the patch? >=20 > Thanks for reading, >=20 >=20 > [1] See comment here if you wonder why: > sed -n 19460,+3p src/contrib/gcc/config/i386/i386.c >=20 > [2] When compiling a source file to an object file, if you use somethin= g > which is external to the compilation unit, GCC doesn't know yet if > this symbol will be inside or outside the DSO. So it expects the > worst case and routes the symbol through the GOT, which means > additional space and extra relocation for rtld(1). >=20 > Declaring a symbol has hidden tells GCC to use the optimal route (n= o > GOT), but on the other hand this means the symbol has to be provide= d > in the same DSO (namely libssp_nonshared.a). >=20 > On i386, GCC actually uses an hidden symbol for SSP in PIC objects > to save PIC register setup, as said in [1]. >=20 > [3] As abstractly explained in [2], the problem shows up as long as you= > compile a PIC (or PIE) object but you don't link it directly with > libssp_nonshared.a. > =20 > So in the test I gave, you can also trigger the problem by setting > "BIN_CFLAGS=3D -fstack-protector-all -fPIE" and leaving BIN_LDFLAGS= > blank, whatever you did with LIB_{CFLAGS,LDFLAGS}. >=20 > This won't happen without -fPIE here, because a non-hidden symbol > will be emitted in that case. >=20 >=20 >=20 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.o= rg" >=20 --=20 Regards, Bryan Drewery ------enig2QWFUPXFEWVEIJIRFAVTU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRoMTTAAoJEG54KsA8mwz5bl4P/2JZycpXMTyqAlXt3OW5XxDR rq/9L+CdnEn4KZHD6BgktN1k547LQdW2CrJ/NRaSgExESKdjEN2aCEEetUC38VFy 94HuKHw4PfXVE4V574OHHxXWiyU+Hc7J8zVJ0AArdP7E91SH+h990vETJ7EmNAtm yAjA/guBKob/dpL2dvLkzHkMAEqp3bcNpthEaTbx9jjKmpy+zV3vUQL3RmGCc7Dl dE1pad/oe+PhWBPGGwGXPz/eV9aU7n6vVpo3BIFGPqe2wI2EoXpqqPxVA5Qb2feH ix4yK7W0KZkYuIz5CdxkZJE6mpKBsh7i6fUugX3528+N9CTsc5BN3K13TC9rctF/ P0IO7+sP6bdNMOJ55kq/ojUgdx2RB9ZZZzVHEHZoE+wzOekOY9JC17HKZsLj7P86 uI/lDAbEPjUG/C5+sktnmjhF2gFVXgPeAnkp8H4Rn3Uih6PFH5VO8xU15/6q6Gal eegIyb7H3TDLWdHC4+6H2ZEjqxvSJeZyYp4ElKiOw/yW2f7xye4lEzOu+DIqpORS MfRP8C4vsYsPeVu397c4MOSejaF1wDp2W9HbElRmdxp0jizLBNBlJKhAooCRyl3N 5XD68CxrAO8B95uCF7CMr3vuco7YQrx2sRk90XbyMjAB+a4CwoM3f2zsV3B3DeFd /yHortaoJGwylLr98Oq8 =NgG8 -----END PGP SIGNATURE----- ------enig2QWFUPXFEWVEIJIRFAVTU--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?51A0C4CD.6000709>