no more buffer overflows

Dan Osterrath do3 at mail.inf.tu-dresden.de
Mon May 5 06:47:13 PDT 2003


Am Montag, 5. Mai 2003 15:24 schrieb Archaic:
> -----------------------------------------------------------------------
> Note that the kernel will relocate every shared-library to the
> ASCII-armor, but the binary address is determined at link-time. To ease
> the relinking of applications to the ASCII-armor, Arjan Van de Ven has
> written a binutils patch (binutils-2.13.90.0.18-elf-small.patch), which
> adds a new 'ld' flag "ld -melf_i386_small" (or "gcc
> -Wl,-melf_i386_small") to relink applications into the ASCII-armor. (The
> patch can be found at he exec-shield URL as well.)
> -----------------------------------------------------------------------
>
> I can't figure out from that whether or not the binutils patch is
> neccessary if you compile stuff _after_ switching to the patched kernel
> (like building an LFS while running the patched kernel).

AFAIUTC (as far as I understood that correctly) this patch make ld linking 
some code directly into ASCII-armor. Otherwise the kernel has to relocate 
(move?) the code into this area at startup which would take a while.
So the patch would generate faster startup code although I don't know whether 
we could safely add the linker flag to every package of chapter 6. I even 
don't know what's this ASCII-armor area. (I didn't read the whole announce as 
a lack of time today.)
But if anyone has some time left he could try a base LFS with this flag. 
AFAIUTC this (kernel) patch will be merged in future kernels so it might be 
worth careing about this issue in LFS and not only reject it as a topic for a 
hint.

-- 
----------------------------------------------------------------------
%> ln -s /dev/null /dev/brain
%> ln -s /dev/urandom /dev/world
%> dd if=/dev/world of=/dev/brain
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
URL: <http://lists.linuxfromscratch.org/pipermail/lfs-security/attachments/20030505/cdb79c86/attachment.sig>


More information about the lfs-security mailing list