« December 2005 | Main | March 2006 »

February 2006 Archives

February 2, 2006

Encrypted Root Filesystem Revisited

The hard disk on my notebook computer developed a number of bad sectors so I replaced it with a new 7200rpm 100GB drive. I've discussed my experience and gave details about using an encrypted root and LVM filesystem using the Linux 2.6 device mapper.

While I found the disk speed acceptable using the encrypted filesystem, I did note that it was subjectively slower than using an unencrypted filesystem. This time, I used the bonnie++ disk benchmark to test the new disk.

Raw disk benchmark

       ------Sequential Output------ --Sequential Input- --Random-
        -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
  Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
    4G 30299  98 47348  13 20552   6 29947  91 44758   5 137.3   0
       ------Sequential Create------ --------Random Create--------
        -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
  files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
     16  3545  21 +++++ +++  3863  42  3350  20 +++++ +++   867   6

Encrypted disk benchmark

       ------Sequential Output------ --Sequential Input- --Random-
        -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
   Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
     4G 18861  60 40812   9 10534   2 18530  58 30641   4 143.6   0
       ------Sequential Create------ --------Random Create--------
        -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
  files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
     16  3150  87 +++++ +++  3510  92  2919  86 +++++ +++   900  35

While there is an overhead using the encrypted file system (which is likely magnified by using a 4-year old CPU, a 2GHz Pentium 4-M), the overall speed with the 7200rpm drive is acceptable and will be a boost compared to the old 5400rpm drive.

While my notebook previously ran Debian Sarge, I thought I'd try something slightly different, the Debian offshoot Ubuntu Breezy. I found a few issues that had to be resolved to use the encrypted filesystems.

  • Patching /usr/sbin/mkinitrd
    mkinitrd had the wrong devmapper library version. I had to change line 385 from /lib/libdevmapper.so.1.00 to /lib/libdevmapper.so.1.01.
  • Add modules to /etc/mkinitrd/modules
    I added aes_i586, dm_crypt, and dm_mod to /etc/mkinitrd/modules.
  • Modifying /etc/lvm/lvm.conf
    I use an encrypted physicial LVM partition to host my logical volumes. That way, I only have to encrypt the LVM physical partition. Subsequently when booting and decrypting the filesystem, I only have to give once the key to the physical volume and all of the logical volumes created in that partition will be decrypted. This requires some editing of lvm.conf to recognize the encrypted physical volume. I named the LVM physicial volume pv and then added /dev/mapper/pv to the filter specification in the devices section. Also, LVM has to be notified of the device mapper type, so the line types=["device-mapper",16] must be added to the devices section.
  • Change the startup script order
    The script order in /etc/rcS.d/ needs to be changed so that cryptdisks is executed before lvm. This is required so that the lvm script will have access to the unencrypted physicial volume. This is simply done by renaming S28cryptdisks to S25cryptdisks which places it before the lvm script S26lvm.

After those bits of additional configuration, the encrypted root filesystem and encrypted LVM physical volume is working very well. Additionally, I'm using an encrypted swap partition, but there was no additional configuration required beyond what I previously described.

Diverging From Upstream

I have written and currently maintain PURI, a ported version of Franz's open-source URI (Uniform Resource Identifier) library. The Franz library uses a number of Allegro specific optimizations. I've tried to remain true to their optimizations by using similar optimizations on other Lisp implementations where possible.

However, the is one non-Allegro specific optimization that has caused a number of people some trouble: that the library expects input strings to be simple strings rather than generalized lisp strings. That has caused at least 3 people to mention the issue to me. I pondered the best solution for a bit. Likely, the optimum result would be to write a macro that emits generic functions specialized to both simple and generalized strings. However, I took a simpler route: I removed the simple-string specific optimiztions (such as using schar rather than char). I expect the reduction of trouble for library users outweighs the run-time overhead.

A few bug fixes including accomodating a change in the function of SBCL's shink-vector, and PURI 1.4 is now available.

February 4, 2006

Console Password Manager

I'd been looking for a fairly secure way to store an increasing number of passwords. There's a large number of methods one can use. While the most secure might be an encrypted file on a system that has no network access, I do want to have access to the information over a network while I'm traveling. Remote access makes using a graphical client a poor choice.

After a moderate search and trying a number of candidates, I settled on Console Password Manger (CPM) written by Harry Brueckner. It's close to an ideal match to my needs: it's console-based, had an emphasis on security and uses my existing GPG key for encryption. The program is maintained and I've had no issues while using the last three beta versions of the program. Thanks, Harry for the very good tool. Recommended.

About February 2006

This page contains all entries posted to Kevin Rosenberg in February 2006. They are listed from oldest to newest.

December 2005 is the previous archive.

March 2006 is the next archive.

Many more can be found on the main index page or by looking through the archives.

Creative Commons License
This weblog is licensed under a Creative Commons License.