Re: Release DigSig 0.1: LSM module checking digital signatures before loading the binaries

From: Crispin Cowan (crispinat_private)
Date: Wed Sep 17 2003 - 18:24:59 PDT

  • Next message: Leendert van Doorn: "Re: Release DigSig 0.1: LSM module checking digital signatures before loading the binaries"

    Makan Pourzandi wrote:
    > Release of digsig.0.1
    > We implemented a kernel module using LSM hooks for 2.5.66
    > which checks signatures before running a binary. The main goal is to 
    > insert digital signatures inside the ELF binary
    > and verify this signature before loading the binary. 
    This sounds *very* similar to CryptoMark 1, which we released in 2001 It also used GPG to 
    apply public key signatures to executables
    > However, in order to reduce the overhead in the kernel, we took only the
    > minimum code necessary from GPG. We took only the MPI (Multi Precision
    > Integer) source code and the RSA crypto source code. This helped much
    > to reduce the amount of code imported to the kernel in sourc code of
    > the original (only 1/10 of the original gnupg 1.2.2 sourc code has
    > been imported to the kernel module).
    We did that, too. Is digsig a compelte re-implementation? Or is it based 
    on the CryptoMark release? Either is plausible, as we did not widely 
    publicize this result (we regarded it as a failed attempt due to high 
    overhead) but we do know that some people tried to build on it.
    > Performances
    > ===============
    > This is release 0.1. We have done some benchmarks.
    > We ran lmbench on a Pentium IV, 2.4 GHz, 500 mega bytes of memory,
    > running Linux 2.5.66. Our benchmarks show that the execution time
    > (exec function call) multiplies by a factor of 4 when the module is
    > loaded (no changes for fork call, as the binary is not loaded into
    > memory). 
    We found the performance penalties to be *substantial*, typically in the 
    500% slowdown range. The problem is that the cost of digital signatures 
    is more or less linear in the size of the program, mostly to compute the 
    MD5 of the program. Small programs tend to be short-lived, while larger 
    programs tend to be longer-lived, and the net result was 200% to 500% 
    slowdown across the board. I suggest you try doing a kernel build with 
    and without digsig and see what it does to your performance overhead. If 
    you don't see the same overhead that we did, then I'd be very curious 
    about the details.
    We then went and did an OpneSSL implementation. Unfortunately, that is 
    not releasable, because OpenSSL uses the 4-clause license, which is 
    asserted to be incompatible with the kernel's GPL by some significant 
    linux kernel authors.
    Crispin Cowan, Ph.D. 
    Chief Scientist, Immunix

    This archive was generated by hypermail 2b30 : Wed Sep 17 2003 - 18:25:53 PDT