Very Computer

Has there been any discussion here about where the most efficient
place is in the kernel is to put an encryption layer.

I would want it to work for all block devices. (i.e. all mountable
filesystems, both  current and future).

I think one such place might be the cache buffers, any comments
on that ? "linux/fs/buffer.c"

--
 RIKHARDUR EGILSSON
 echo '[q]sa[ln0=aln80%Pln80/snlbx]16isb15CB32EF3AF9C0E5D7272C3AF4F2snlbxq'|dc

Quote:>Has there been any discussion here about where the most efficient
>place is in the kernel is to put an encryption layer.

>I would want it to work for all block devices. (i.e. all mountable
>filesystems, both  current and future).

The proper place might be in the block device loopback driver. I believe
that this already exists.

On 12 Aug 1999 15:17:19 GMT,

Quote:>Has there been any discussion here about where the most efficient
>place is in the kernel is to put an encryption layer.

>I would want it to work for all block devices. (i.e. all mountable
>filesystems, both  current and future).

>I think one such place might be the cache buffers, any comments
>on that ? "linux/fs/buffer.c"

>--
> RIKHARDUR EGILSSON
> echo '[q]sa[ln0=aln80%Pln80/snlbx]16isb15CB32EF3AF9C0E5D7272C3AF4F2snlbxq'|dc

You could look at what people have done already.  There's
linux-crypt-kernelpatches, which are for 2.0.11 kernel, or tcfs, which is
distributed with crypt patches for the kernel, I don't know what version.

Chris G.

If I understand correctly, the loopback driver sits on top of a character
"device" (file) that itself sits on top of a block device (disk).  All
that the loopback devie does is to "simulate" a block device thru system
calls and buffering.

So when you have created a filesystem and put some files on this loopback
device you have FOUR (4) layers between the actual data on the disk and
your applications (f.ex sendmail)

This is hell for performance !

--
 RIKHARDUR EGILSSON
 echo '[q]sa[ln0=aln80%Pln80/snlbx]16isb15CB32EF3AF9C0E5D7272C3AF4F2snlbxq'|dc

... Although when you consider that there's an encryption algorithm
getting in the way, and throwing in a whole lot of CPU work, the extra
couple of layers Probably Don't Matter.

Keep the costs in perspective...  Even Twofish isn't costless...
--
Windows '95 - A 32 bit patch for a 16 bit interface to an 8 bit OS
designed for a 4 bit chip.

Quote:

>... Although when you consider that there's an encryption algorithm
>getting in the way, and throwing in a whole lot of CPU work, the extra
>couple of layers Probably Don't Matter.

I have been looking a litle thru the kernel source and found that
another drawback of the loopback device is that you get each
buffer cached twice, once encrypted from the disk file and
another time unencrypted from the loopback device.  
This greatly reduces your available cach-buffer performance.

I.e. the encryption is now even more a drawback than it should be
because you have less memory for caching and thus possibly have to
decrypt the same blocks over and over again.

Different subject :

Does anybody know if I can safely implement a read-only-decryption in
ll_rw_blk.c in the function "make_request".

That would mean I could encypt a filesystem (a floppy f.ex) with a external
utility, then mount it (ro) and have the kernel read it.

My idea (just to get it working) is to check MAJOR(dev) and MINOR(dev)
and decrypt whatever data is returned, before it is passed to the
calling function.
('dev' is not passed to the function directly but it is available in
the buffer_header).

If I only work with READ(A) requests it should work, right ??

--
 RIKHARDUR EGILSSON
 echo '[q]sa[ln0=aln80%Pln80/snlbx]16isb15CB32EF3AF9C0E5D7272C3AF4F2snlbxq'|dc

: On 12 Aug 1999 15:17:19 GMT,

:    
:    
:>Has there been any discussion here about where the most efficient
:>place is in the kernel is to put an encryption layer.
:>
:>I would want it to work for all block devices. (i.e. all mountable
:>filesystems, both  current and future).
:>
:>I think one such place might be the cache buffers, any comments
:>on that ? "linux/fs/buffer.c"
:>
:>
:>--
:> RIKHARDUR EGILSSON
:> echo '[q]sa[ln0=aln80%Pln80/snlbx]16isb15CB32EF3AF9C0E5D7272C3AF4F2snlbxq'|dc

: You could look at what people have done already.  There's
: linux-crypt-kernelpatches, which are for 2.0.11 kernel, or tcfs, which is
: distributed with crypt patches for the kernel, I don't know what version.

: Chris G.

--

        there is also also the STEGANOGRAPHIC FILE SYSTEM (sfs)
        which comes with a set of patches for the kernel (2.0.36-2.2.10)
        as well as a tool-set.  there is a little info at

                http://www.linux-security.org/sfs/

        im not sure how if it is what you want, but its worth
        looking through their code...

                                                kyomu