commit-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[SCM] Hurd branch, master, updated. hurd-release-0-2-3599-gb2e27fc


From: Samuel Thibault
Subject: [SCM] Hurd branch, master, updated. hurd-release-0-2-3599-gb2e27fc
Date: Sun, 15 Sep 2013 21:47:48 +0000

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "Hurd".

The branch, master has been updated
       via  b2e27fcee4cec98ffc39273ecfaa73aace9da2c3 (commit)
       via  23ca8f5f942f831ec5be3667fd0a29873fae2912 (commit)
      from  a9a800dbaa0e79ecba232e477291a38e119e2df9 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit b2e27fcee4cec98ffc39273ecfaa73aace9da2c3
Author: Justus Winter <address@hidden>
Date:   Thu Aug 15 18:41:51 2013 +0200

    exec: remove support for transparently ungziping executables
    
    Remove support for transparently ungziping 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 gzip code is not thread-safe, all access to it is
    serialized, so there is a trivial way for one user to delay another
    users gzipped 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 gzip related files.
    * exec/exec.c: Remove anything #ifdef GZIPped.
    * exec/unzip.c: Move to libstore.
    * exec/crypt.h: Likewise.
    * exec/gzip.h: Likewise.
    * exec/inflate.c: Likewise.
    * exec/tailor.h: Likewise.
    * exec/util.c: Likewise.
    * libstore/Makefile: Remove the vpath magic for looking up the zip
      stuff.

commit 23ca8f5f942f831ec5be3667fd0a29873fae2912
Author: Justus Winter <address@hidden>
Date:   Thu Aug 15 18:41:50 2013 +0200

    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.

-----------------------------------------------------------------------

Summary of changes:
 exec/Makefile                   |    8 +-
 exec/exec.c                     |  262 ---------------------------------------
 libstore/Makefile               |    4 -
 {exec => libstore}/crypt.h      |    0
 {exec => libstore}/do-bunzip2.c |    0
 {exec => libstore}/gzip.h       |    0
 {exec => libstore}/inflate.c    |    0
 {exec => libstore}/tailor.h     |    0
 {exec => libstore}/unzip.c      |    0
 {exec => libstore}/util.c       |    0
 10 files changed, 1 insertions(+), 273 deletions(-)
 rename {exec => libstore}/crypt.h (100%)
 rename {exec => libstore}/do-bunzip2.c (100%)
 rename {exec => libstore}/gzip.h (100%)
 rename {exec => libstore}/inflate.c (100%)
 rename {exec => libstore}/tailor.h (100%)
 rename {exec => libstore}/unzip.c (100%)
 rename {exec => libstore}/util.c (100%)


hooks/post-receive
-- 
Hurd



reply via email to

[Prev in Thread] Current Thread [Next in Thread]