Skip to contentSkip to conversation

Adding cipher mode as a mount option

DISCUSSION Will Morrison 2 participants 2 messages May 18, 2013 – May 20, 2013 Ecrypt file system

lore
Share & tools
lore
#0 lore raw

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

As part of implementing GCM integrity checking for eCryptfs, we thought that a good first step would be to take the currently hardcoded mode (cbc) and turn it into a mount option. Once a filesystem can be created and mounted using arbitrary block modes, we can work on allowing integrity protection via GCM.

This should also provide a solution to
https://bugs.launchpad.net/ecryptfs/+bug/1176448

Does this sound like a reasonable first step? If not, what issues are we missing?

In addition, does anyone have tips on speeding up the develop/compile/test cycle?

- -Will, on behalf Will, Zameer, Michael, and Alvin -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJRluMJAAoJEH8zVN2+6bAceKkP/3q0dlVYTO2iPmntmwCrEOwx 6aiejnK4z+U64b1fj+yg006mpeg6eLVXLeGj8kL17r5J26wVx43VRZwNS9ZzQ17P fVKMgAcr4VzOyU/zvrjTC55/mAv62IJSclVRK2SxWwMZt+6aw3tWVFUi0q1DDQrA 3Q4rioEe06wYqmGbPF0J1dy10jLhhtzncDy/Y/M0reUPSfQhq2sgJEBTihY+wPzW wnEEs2IIt9DQu3d1PJgOQoF6UP2jhSGraQgzYiUu9IN3RqIMENG8X9OgkIYonxlH q7ASQg5sZfLEiSLvYq4jZD48zyeXQF262WTSiW2q2mWxo1OMAj13UEgejyPLj518 NQO23mQAnD4qkL6EqXOb547Bh6BQvd1C6qI2sQU7/ZJp8WukpLmHKEYOILKl5pDq +8HFHW2fWx6E8xKG9LoXDFp+nLd9LxLCv+zWm7s+xwXxnABR1ZO4C+1hZ5wTQip5 b7vkiAARSiYYNnALxsc/PWzb0DZsEZPev51ay9xH74ed/9Crt4jrV5WLy5MlTjoU SZJ7IF2x4eoOibfmjpCkCUC7x7vknyLI8uFNOkbnpC0puNHDNX2pdrzJ5dhN7W3B yTN/hkMc7LSEH9pb7OuynmRV4tmXMf6VuJ+rCzxpcv8/XR0XwZiL0Y1kz/bdExGb ZSrxFIJdZtzu68Xj6nHe
=LCBo
-----END PGP SIGNATURE-----

#1 lore raw
Quoted 11 lines · Will Morrison

As part of implementing GCM integrity checking for eCryptfs, we thought that a good first step would be to take the currently hardcoded mode (cbc) and turn it into a mount option. Once a filesystem can be created and mounted using arbitrary block modes, we can work on allowing integrity protection via GCM.

This should also provide a solution to
https://bugs.launchpad.net/ecryptfs/+bug/1176448

Does this sound like a reasonable first step? If not, what issues are we missing?

Yes, it does sound like a reasonable first step.

However, we don't want users to be able to mount with *any* mode. We only want them to be able to mount using a mode that eCryptfs supports.

So, the patch should include a whitelist of modes. The list will only have one mode, CBC. Then when you add all of the backend support for GCM in a future patch, you would also add GCM to the whitelist.

Note that this isn't something that I'd merge upstream without the corresponding backend work to support GCM. This would probably be patch 1 of the larger patchset that adds GCM to eCryptfs.

Quoted 2 lines

In addition, does anyone have tips on speeding up the develop/compile/test cycle?

Do you have any specific bottlenecks that are slowing you down? Otherwise, I'll just be guessing at what you may be doing inefficiently.

One thing that I remember greatly speeding up my eCryptfs kernel development time was to take advantage of eCryptfs being a module and avoid rebuilding the entire kernel after making a change.

If all of your changes are local to fs/ecryptfs/ (which they should be for this feature), then just rebuild the module:

$ make M=fs/ecryptfs

Then, load the new module:

$ sudo insmod fs/ecryptfs/ecryptfs.ko

Now test your changes. No kernel rebuilds, no reboots (unless your change causes a kernel oops ;), etc.

Automated testing should also speed up your development. The ecryptfs-utils bzr tree has a test suite in tests/ (see tests/README). Leverage that as much as possible. Adding a way to test multiple ciphers and modes (AES-128 w/ CBC is currently hardcoded) when you submit your GCM kernel patches will greatly speed up the time it takes to get your patches upstream (because it will be taking the work off of me).

Quoted 2 lines

-Will, on behalf Will, Zameer, Michael, and Alvin

Thanks for working on this feature!

Tyler