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 http://immunix.org/CryptoMark/cryptomark-1.0.tar.gz It also used GPG to apply public key signatures to executables http://citeseer.nj.nec.com/beattie00cryptomark.html > 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. Thanks, Crispin -- Crispin Cowan, Ph.D. http://immunix.com/~crispin/ Chief Scientist, Immunix http://immunix.com http://www.immunix.com/shop/
This archive was generated by hypermail 2b30 : Wed Sep 17 2003 - 18:25:53 PDT