Re: Adding cipher mode as a mount option

[Tyler Hicks <tyhicks@canonical.com>]

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