|
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.
|
