2.4 branch

Robert Connolly robert at linuxfromscratch.org
Tue Nov 28 11:58:55 PST 2006


On Tuesday 28 November 2006 13:55, Robert Baker wrote:
> No ssp will require the removal of the regex_ssp patch in the perl
> section of the book.

I noticed the regex_ssp patch for Perl wasn't needed anymore. I think it has 
something to do with the way SSP was modified when integrated in glibc-2.4 
and gcc-4.1, compared to IBM's version.

> My question is if we intend not to use ssp in the 
> 2.4 branch doesn't that compromise the level of security offered by this
> kind of system? I realize that adding features to GCC can introduce
> issues in and of itself, but stack smashing is one of the most common
> attacks used today... Obviously if the patch affects the stability of
> the system then we are not there yet.

The glibc-2.4/2.5 SSP library is not compatable with the SSP patch for gcc-3.4 
from IBM. I didn't look into back porting gcc-4.1's ssp to gcc-3.4 because I 
suspect it's not straight foreward. I also noticed no one else backported it 
either, like Debian or Gentoo. An alternative is replacing glibc-2.4/2.5's 
SSP library with the one used in glibc-2.3.6, but it makes me wonder why does 
it break Perl's regex. And another alternative is to use IBM's SSP with 
libssp.so (there are patches for this), but again makes me wonder why it 
breaks Perl's regex.

With all the Grsecurity/PaX options enabled in the kernel, the only exploit 
not detected by Grsec, which is detected by SSP, is "return2libc". While this 
is fairly serious I don't think its practical to add SSP to a gcc-3.4 
toolchain, for a release which is expected to be rock-solid. I've considered 
the alternative of using gcc-4.1.1 without mudflap and fortify_source to get 
SSP into the 2.4-branch, but gcc-4.1.1 can't build a linux-2.4 kernel, and 
can't build gcc-2.95.3, without tons of patches which would destabilize 
gcc-2.95.3. There are unfortunate compromises when making a stable release, 
and I think this is one of them.

I hope to make up for this by using sound code in the base system, audited by 
the stricter gcc-4.1.1 (or even gcc-4.2) compiler warnings in unstable and 
merge the differences to the stable packages.

> I have been running thru what we have thus far. In pass 2 of gcc I found
> I had to use --with-dynamic-linker=  just to get the linker tests to
> pass after a gcc install.

I removed the specs_x86 patch all together. It only worked on i386, and it was 
screwing up Binutils' tests because Binutils detects the default dynamic from 
parsing 'gcc --help --verbose', which produces the ./configure command used 
to build GCC (like from gcc -v), and 'ld-*.so' matches twice and makes a mess 
of the '-dynamic-linker' option used in Binutils tests. Since that patch only 
worked for i386 its just as well to use an Sed command to prepend /tools to 
the dynamic linker name when building GCC, and this will work fine with 
uClibc too (with xml conditions). I preferred that patch with the idea of 
having read-only sources, but its not a big deal.

robert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.linuxfromscratch.org/pipermail/hlfs-dev/attachments/20061128/f5637032/attachment.sig>


More information about the hlfs-dev mailing list