On Dec 23, 2007 11:22 PM, Robert Connolly <[EMAIL PROTECTED]> wrote: > On Sunday December 23 2007 07:14:40 am [EMAIL PROTECTED] 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. > > robert >
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 or 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. -- Kevin Day -- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
