changeset: 358:6def8836ecbe
user: arg_AT_localhost.localdomain
date: Sun Nov 01 18:01:14 2009 +0000
files: sta.li/faq.md sta.li/index.md
description:
added faq
diff -r b526eac26e3f -r 6def8836ecbe sta.li/faq.md
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/sta.li/faq.md Sun Nov 01 18:01:14 2009 +0000
_AT_@ -0,0 +1,89 @@
+FAQ
+===
+
+Aren't statically linked executables huge?
+-------------------------------------------
+It depends. Linking a stripped hello world program with glibc results in 600kb.
+Linking it with uclibc in about 7kb. Linking OpenBSD's stripped ksh[1], which
+will be stali's default shell, statically against uclibc results in a 170kb
+binary -- linking it dynamically against glibc results in 234kb.
+Of course this won't scale with every binary, for example we expect surf
+being about 5-6MB in size, but the normal Unix userland will be rather small,
+compared to most popular linux distros.
+
+Aren't whole libraries linked into a static executable?
+-------------------------------------------------------
+No. Good libraries implement each library function in separate object (.o)
+files, this enables the linker (ld) to only extract and link those
+object files from an archive (.a) that export the symbols that are
+actually used by a program.
+
+What's wrong with glibc?
+------------------------
+We think nearly everything is wrong with it. It's enormous complexity,
+it's lack of good structure and well separated object files
+(otherwise linking trivial programs wouldn't result in 600kb oberhead) and
+even worse than that, it's design decision to use ldopen for certain
+"separated" library features (NSS, locales, IDN, ...), which makes it nearly
+impossible to use glibc for static linking in non-trivial programs.
+Unfortunately for certain tools we will ship glibc for pragmatic reasons. Of
+course Ulrich Drepper disagrees[2].
+
+Aren't statically linked executables less secure?
+----------------------------------------------
+Several people argue (with implicitely requiring ABI-stability) that
+dynamically linked executables benefit from security fixes in libraries they
+depend on. This is true, however the opposite is also true: if there is a
+security flaw in a dynamically linked library all programs are affected whereas
+statically executables won't be affected in such a scenario (assumed they have
+been linked against secure libraries).
+
+We know that there is some overhead in re-compiling all affected executables if a
+dependent library is insecure, but we don't see this as a critical
+dis-advantage, because we also focus on a small and maintainable userland,
+where only one tool for each task exists.
+
+Another argument often heared is, that static function have predictable
+addresses, whereas dynamic linking provides the ability of address
+randomization. We have two answers to this: the first is, technically it is
+possible to use platform-independent code in static executables and hence assumed
+the kernel supports address randomization for executables we have a similar
+feature. The second answer is in reality address randomization is predictable
+and we usually see the same addresses when a dynamic library is loaded or has
+been pre-loaded again and again. Thus we consider this as an issue with low
+impact and this is not a real focus for us.
+
+If you are really concerned about the security of statically linked executables,
+have a look at what great ldd exploits[3] exist.
+
+Aren't statically linked executables consuming more memory?
+--------------------------------------------------------
+We believe that due to the small size of the base system the opposite will be
+the case. First of all, the kernel will load each static executable's .rodata, .data,
+.text and .comment sections only once for all instances into memory,
+Second, because each static binary has only been linked with the object files
+necessary, it has been optimised at linkage time already for memory
+consumption. When loading it, we don't require the kernel to map all
+dependent dynamic libraries into memory from which our binary might only use 5%
+of the functions they provide. So in reality the memory footprint is becoming
+less, and the dead code hold in memory (or paged) reduces overall consumption.
+This is also true for programs like surf, it doesn't use all webkit/gtk/glib
+functions.
+
+Isn't starting statically linked executables slower?
+----------------------------------------------------
+In most cases the answer is No. In the theoretical case of a huge static
+executable the payload might be loading the executable into memory, but we
+focus small static executables. In experiments the execution time of a static
+executable was about 4000% faster than with its dynamically linked counterpart
+when no dependent libraries (except glibc) were pre-loaded and 100% faster when
+the dependent libraries were pre-loaded. We believe the overhead for looking up
+all needed symbols in the dynamically loaded libraries seems to be very
+expensive. On modern hardware this is only noticable with endlessly executing
+the static and dynamic executable in a loop for several minutes and counting
+the number of executions. We plan to publish the benchmark results for further
+info at a later point.
+
+[1] You can clone OpenBSD ksh using `git://github.com/dryfish/openbsd-pdksh.git`
+[2]
http://people.redhat.com/drepper/no_static_linking.html
+[3]
http://www.catonmat.net/blog/ldd-arbitrary-code-execution/
diff -r b526eac26e3f -r 6def8836ecbe sta.li/index.md
--- a/sta.li/index.md Sun Nov 01 10:33:52 2009 -0500
+++ b/sta.li/index.md Sun Nov 01 18:01:14 2009 +0000
_AT_@ -78,5 +78,5 @@
Some related links
------------------
* [$6M libc](
http://codingrelic.geekhold.com/2008/11/six-million-dollar-libc.html) bionic is a nice library, though only usable for sane stuff
-* [ldd arbitrary code execution](
http://www.catonmat.net/blog/ldd-arbitrary-code-execution/) nic exploit
+* [ldd arbitrary code execution](
http://www.catonmat.net/blog/ldd-arbitrary-code-execution/) nice exploit
* [static linking](
http://blog.garbe.us/2008/02/08/01_Static_linking/) my old blog entry
changeset: 359:fbb0b1ebf1dc
tag: tip
user: arg_AT_localhost.localdomain
date: Sun Nov 01 18:07:11 2009 +0000
files: sta.li/faq.md
description:
some intermediate fix
diff -r 6def8836ecbe -r fbb0b1ebf1dc sta.li/faq.md
--- a/sta.li/faq.md Sun Nov 01 18:01:14 2009 +0000
+++ b/sta.li/faq.md Sun Nov 01 18:07:11 2009 +0000
_AT_@ -84,6 +84,8 @@
the number of executions. We plan to publish the benchmark results for further
info at a later point.
-[1] You can clone OpenBSD ksh using `git://github.com/dryfish/openbsd-pdksh.git`
-[2]
http://people.redhat.com/drepper/no_static_linking.html
-[3]
http://www.catonmat.net/blog/ldd-arbitrary-code-execution/
+References
+---------
+* [1] You can clone OpenBSD ksh using `git://github.com/dryfish/openbsd-pdksh.git`
+* [2]
http://people.redhat.com/drepper/no_static_linking.html
+* [3]
http://www.catonmat.net/blog/ldd-arbitrary-code-execution/
Received on Sun Nov 01 2009 - 19:07:14 CET