RFE: dietlibc review

Enrico Scholz enrico.scholz at informatik.tu-chemnitz.de
Thu May 19 21:50:58 UTC 2005


notting at redhat.com (Bill Nottingham) writes:

>> > Wasn't looking at the specs, actually; just the source; it certainly
>> > doesn't require dietlibc in that sense.
>> ...
>> But for util-vserver, I hope that I made the warnings big and fat enough
>> when the tools will be built against glibc. ;)
>
> I suppose; it just seems to me that building against an alternate
> libc exposes you to many of the same problems that building with an
> alternate compiler does;

All the mentioned programs were developed with dietlibc in mind. But
afaik, X11 or gcc can be built with dietlibc also.


> it's more likely to experience odd bugs that other things don't,

indeed; dietlibc with non-mainstream archs (not x86) is problematic :( I
hope that I got it right that at least the mentioned programs can be
compiled on the supported platforms.


> it limits you from various features that are in the standard libc

glibc has mechanisms like dynamic loading of libnss libraries. This
makes it completely unusable for chroot operations (both for security
and functional aspects); e.g. you will see odd errors with 'rpm --root'
and LDAP nss-switching in the host. Static linking against dietlibc
removes this problem completely.

Beside that... dietlibc is much more efficiently than glibc; e.g. a
simple 'int main() {}' (this is all what is needed for /bin/true) will
need more resources with glibc than a complex program linked against
dietlibc. It is sick what 'strace /bin/true' gives out... ;)


> (including some of the memory protection ones), etc.

dietlibc has stack-randomization also. And in the age of vsyscalls
return-to-libc attacks are possible with random dynamic library
loading.

And... it is better to program in a secure manner instead of hoping that
some magic memory protection (which can be circumvented in most cases)
protects you against exploits.




Enrico
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 480 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-extras-list/attachments/20050519/dddef7a3/attachment.sig>


More information about the fedora-extras-list mailing list