summaryrefslogtreecommitdiff
path: root/libhurdbugaddr
diff options
context:
space:
mode:
authorJustus Winter <4winter@informatik.uni-hamburg.de>2013-08-15 18:41:50 +0200
committerSamuel Thibault <samuel.thibault@ens-lyon.org>2013-09-15 23:38:39 +0200
commit23ca8f5f942f831ec5be3667fd0a29873fae2912 (patch)
tree563f10c57fb548efeefbb2a2f9afe168590ae502 /libhurdbugaddr
parenta9a800dbaa0e79ecba232e477291a38e119e2df9 (diff)
exec: remove support for transparently unbzip2ing executables
Remove support for transparently unbzip2ing executables from the exec server. The code in question makes the exec server unnecessarily complex and since the exec server is an essential process, crashing it makes /hurd/init crash the whole system. Since the bzip2 code is not thread-safe, all access to it is serialized, so there is a trivial way for one user to delay another users bzip2ed executables for some unspecified time. This can be accomplished by padding any program with easily compressed data, zipping it and executing it. Using such a program as an passive translator and then triggering its execution by the filesystem translator also stalls any requests to that filesystem (observed using the libdiskfs-based ext2fs). Since compressed executables cannot be mapped into the memory, they have to be uncompressed into allocated memory first. This is slower and any user with access to the exec server can make it allocate arbitrary amounts of memory. If the Hurd had proper memory accounting, this would probably be a way around it. So the compression support in exec seemingly creates various issues for little value, at least with the abundance of nonvolatile memory available today. * exec/Makefile: Remove bzip2 related files. * exec/exec.c: Remove anything #ifdef BZIP2ed. * exec/do-bunzip2.c: Move to libstore.
Diffstat (limited to 'libhurdbugaddr')
0 files changed, 0 insertions, 0 deletions