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:
signature.asc
Description: Digital signature
