Adding cipher mode as a mount option

Adding cipher mode as a mount option

[Will Morrison]

-----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-----

Re: Adding cipher mode as a mount option

[Tyler Hicks]

[-- Attachment #1: Type: text/plain, Size: 2447 bytes --]

On 2013-05-17 22:10:18, Will Morrison wrote:
> 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.

> 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).

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

Thanks for working on this feature!

Tyler

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]