Re: partially encrypted filesystem

[Linus Torvalds <torvalds@osdl.org>]

On Wed, 3 Dec 2003, Jörn Engel wrote:
>
> Haven't heard about anything working yet, but it shouldn't be too hard
> to change something existing.  For jffs2, I would guesstimate one or
> two month to add the necessary bits, but jffs2 is not first choice as
> a hard drive filesystem.  Not sure about other filesystems.

Encryption is not that easy to just tack on to most existing filesystems
for one simple reason: for performance (and memory footprint) reasons,
most of the filesystems out there are doing "IO in place". In other words,
they do IO directly into and directly from the page cache.

With an encrypted filesystem, you can't do that. Or rather: you can do it
if the filesystem is read-only, but you definitely CANNOT do it on
writing. For writing you have to marshall the output buffer somewhere
else (and quite frankly, it tends to become a lot easier if you can do
that for reading too).

And that in turn causes problems. You get all kinds of interesting
deadlock schenarios when write-out requires more memory in order to
succeed. So you need to get careful. Reading ends up being the much easier
case (doesn't have the same deadlock issues _and_ you could do it in-place
anyway).

So encryption per se isn't hard. But adding the extra indirect buffer
layer _can_ be pretty nasty, and makes it nontrivial to retrofit later.

** NOTE NOTE NOTE **

If you don't need to mmap() the files, writing becomes much easier.
Because then you can make rules like "the page cache accesses always
happen with the page locked", and then the encryption layer can do the
encryption in-place.

So it is potentially much easier to make encrypted files a special case,
and disallow mmap on them, and also disallow concurrent read/write on
encrypted files. This may be acceptable for a lot of uses (most programs
still work without mmap - but you won't be able to encrypt demand-loaded
binaries, for example).

		Linus