Re: Problems encrypting disk partitions in 2.4.3

[Chris Kuklewicz <chrisk@mit.edu>]

On Thu, May 10, 2001 at 01:14:43PM -0700, Dan Hollis wrote:
> On Thu, 10 May 2001, Herbert Valerio Riedel wrote:
> > the reason you see the problems only on the first mkfs time is, because,
> > as soon as you mount the fs, the kernel changes the transfer block size...
> > and from that moment on, it stays there (unless the kernel has reason to
> > change it again...)
> 
> long term solution would be to make the crypto use 512 byte block size and
> coalesce to kernel transfer size... then it would be blocksize
> independent?
> 
> -Dan
> 
> 
> Linux-crypto:  cryptography in and on the Linux system
> Archive:       http://mail.nl.linux.org/linux-crypto/

Hmm... I will just toss in my two cents.

I know precious little about the details of the linux filesystem, but
I have a generic suggestion.

Obviously it is possible to 'stack' filesystem related layers between
the raw device and the high level filesystem interface.

Things like logical volume management and software raid and NFS and
the loop-back device system, as well as the virutal mememory system.

Is it possible to simply design, either as a patch or in the kernel,
this 'coalesce' layer as an independent entity?  Separate the problem
of block size & addressing from the media.  Can the LVM or loop device
do this already?  Where would the documentation on that be?

For small, portable, encrypted filesystems contained in a file on a
'normal filesysem' such a layer could be used.  For encrypting access
to a raw partition, such a layer might be optional.

Also, what (if anything) is it that prevents the crypto plugin from
being a pure loadable module?  Right now the loopAES requires
disabling the normal loop module and recompiling the entire kernel
before making the modified loop module.  If it is not possible to make
a pure module (that can be added to any compiled kernel), then perhaps
the core kernel modules or interface needs to be enhanced to allow
this.  If such a change does not hurt the core kernel, perhaps it
could be mainlined, allowing future crypto development to plug into
compiled kernels.

This thought was inspired from seeing it mentioned somewhere, whether
to expand the kernel module interface to accomodate future security
related modules as external add-ons, instead of having to patch the
core kernel.

-- 
Chris

Linux-crypto:  cryptography in and on the Linux system
Archive:       http://mail.nl.linux.org/linux-crypto/