thekevinday at gmail.com
Mon Dec 24 07:40:22 PST 2007
On Dec 23, 2007 11:22 PM, Robert Connolly <robert at linuxfromscratch.org> wrote:
> On Sunday December 23 2007 07:14:40 am goodoldmarty at gmail.com wrote:
> > > I think I have a fix. The bug is in the gcc-fpie patch. Using -fpic on
> > > the command line would not disable -fPIE, and some libraries, like the
> > > pic version of libiberty, end up with text relocation's. From what I see
> > > this only affected libbfd and libproc. New patch is here:
> > > http://www.linuxfromscratch.org/~robert/new/gcc-4.1.2-fpie-20071223.patch
> > I don't disagree with the objectives, but that patch is just
> > spoon-feeding anyway. Some people prefer to specify 'all' their own
> > options. What's wrong with instructions to do that, instead of patch's?
> The fpie, fstack-protector, and fortify_source patches are split up and don't
> depend on eachother, so you can choose whichever ones you want. There isn't
> another practical way to do it.
> > Preventing TEXTREL is logical, but what about preventing ELF ET_REL
> > injection in kernel memory? The available tools can now evade
> > PAX/grsecurity and they do this from user space; I find this disturbing.
> I don't know anything about this, maybe someone else does.
My practice is generally to replace those commands with some unique
text-statement such as "REPLACE_ME_WITH_PIE"
then have the user building the system run a sed expression to either
add the -fpie or replace that with an empty statement:
sed -i -e 's|REPLACE_ME_WITH_PIE|-fpie|g' some_file.c
sed -i -e 's|REPLACE_ME_WITH_PIE||g' some_file.c
And then this means you ideally never have to update the patch on
changes in how the -fpie option is added.
This puts the changes in builder-space.
More information about the hlfs-dev