Regards,
Ray
________________________________________________________
To: aem@netcom.ca@INTERNET; linux-kernel@vger.rutgers.edu@INTERNET
From: Andries.Brouwer@cwi.nl@INTERNET on Wed, May 14, 1997 1:32 PM
Subject: z-Re: Loop Encryption
Andrew E. Mileski:
: I've been looking over the code for loop encryption (always a wise
: idea if you are paranoid). So far everything looks fine - the
: implementation is pretty simple.
: I seem to remember there were some comments made that it was
: "completely broken", and that it is no longer maintained.
: Could somebody fill me in on the details please? I hope I'm
: completely wrong about this.
I have some 1-line patches, and a grep on my mail archives
seems to indicate that I never submitted these to Linus,
maybe because at some moment it looked like Nicholas Leon
wanted to handle encryption stuff for the loop device.
That is the category `trivial bugs'.
But there is also the category `fundamental problems'.
For ordinary simple use the loop device is stable enough,
and since it is very useful indeed, it is good to have it.
But if you torture-test it, the kernel will crash or panic or deadlock.
One problem is for example that the loop device violates the
assumption made elsewhere that memory can be freed by writing
dirty buffers to disk. Indeed, the loop device does an additional
copy, and might first need additional memory before it can progress.
> no longer maintained
Well, Ted wrote it. I fixed some deadlock and corruption problems
until it did what I needed it for and put it in the kernel.
Ray Van Tassle fixed several more (mainly deadlock) problems.
As far as I can see that is the present situation:
a relatively stable loop device for simple use, that will surely crash
your system if you try fancy multiple mounting, or anything else that
drives your system out of memory. (But maybe Ray has a more optimistic
view?)
Since I put this thing into the kernel I feel somewhat responsible,
and I am quite willing to fix the simple bugs that people may report.
But some of the fundamental problems require much more work, and I
must leave them to someone with more time.
Andries