From: David Howells <dhowells@redhat.com>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: dhowells@redhat.com, "Muntz, Daniel" <Dan.Muntz@netapp.com>,
Andrew Morton <akpm@linux-foundation.org>,
Stephen Rothwell <sfr@canb.auug.org.au>,
Bernd Schubert <bernd.schubert@fastmail.fm>,
nfsv4@linux-nfs.org, linux-kernel@vger.kernel.org,
steved@redhat.com, linux-next@vger.kernel.org,
linux-fsdevel@vger.kernel.org, rwheeler@redhat.com
Subject: Re: Pull request for FS-Cache, including NFS patches
Date: Wed, 31 Dec 2008 11:15:02 +0000 [thread overview]
Message-ID: <29970.1230722102@redhat.com> (raw)
In-Reply-To: <1230679056.11508.37.camel@heimdal.trondhjem.org>
Trond Myklebust <trond.myklebust@fys.uio.no> wrote:
> Unless you _are_ root and can check every executable, after presumably
> rebooting into your own trusted kernel, then those requirements won't
> mean squat. If you're that paranoid, then you will presumably also be
> using a cryptfs-encrypted partition for cachefs, which you unmount when
> you're not logged in.
Actually... Cachefiles could fairly trivially add encryption. It would have
to be simple encryption but you wouldn't have to store any keys locally.
Currently cachefiles _copies_ data between the backingfs and the netfs pages
because the direct-IO code is only usable to/from userspace. Rather than
copying, encrypt/decrypt could be called.
A key could be constructed at the point a cache file is looked up. It could
be constructed from the coherency data. In the case of NFS that would be
mtime, ctime, isize and change_attr. The coherency data would be encrypted
with this key and then stored on disk, as would the contents of the file.
It might be possible to chuck the cache key (NFS fh) into the encryption key
too and also encrypt the cache key before it is turned into a filename, though
we'd have to be careful to avoid collisions if each filename is encrypted with
a different key.
We'd probably have to be careful about the coherency data decrypting with a
different key showing up as the wrong but valid thing.
The nice thing about this is that the key need not be retained locally since
it's entirely constructed from data fetched from the netfs.
David
next prev parent reply other threads:[~2008-12-31 11:15 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-18 0:30 Pull request for FS-Cache, including NFS patches David Howells
2008-12-18 11:44 ` Stephen Rothwell
2008-12-18 14:24 ` Christoph Hellwig
2008-12-18 20:36 ` Andrew Morton
2008-12-18 23:07 ` Bernd Schubert
2008-12-18 23:26 ` Andrew Morton
2008-12-19 0:05 ` Stephen Rothwell
2008-12-29 3:45 ` Stephen Rothwell
2008-12-29 4:01 ` Andrew Morton
2008-12-29 14:30 ` Trond Myklebust
2008-12-29 14:54 ` Ric Wheeler
2008-12-29 23:05 ` Muntz, Daniel
2008-12-30 18:44 ` Trond Myklebust
2008-12-30 22:15 ` Muntz, Daniel
2008-12-30 22:36 ` Trond Myklebust
2008-12-30 23:00 ` Muntz, Daniel
2008-12-30 23:17 ` Trond Myklebust
2009-01-01 4:11 ` Muntz, Daniel
2009-01-01 8:09 ` Arjan van de Ven
2009-01-01 18:40 ` Kyle Moffett
2008-12-31 11:15 ` David Howells [this message]
2008-12-31 9:49 ` Arjan van de Ven
2008-12-29 4:07 ` Andrew Morton
2008-12-29 5:26 ` Stephen Rothwell
2008-12-29 15:01 ` David Howells
2008-12-29 15:04 ` David Howells
2008-12-29 14:26 ` David Howells
2008-12-19 2:27 ` David Howells
2008-12-19 2:44 ` Andrew Morton
2008-12-19 3:10 ` Ric Wheeler
2008-12-19 12:33 ` Trond Myklebust
2008-12-19 16:48 ` Gabor Gombas
2008-12-19 13:32 ` David Howells
2008-12-19 3:45 ` Muntz, Daniel
2008-12-19 4:09 ` J. Bruce Fields
2008-12-19 13:20 ` David Howells
2008-12-19 18:08 ` Muntz, Daniel
2008-12-19 18:24 ` David Howells
2008-12-19 19:53 ` Bryan Henderson
2008-12-20 1:20 ` David Howells
2008-12-20 6:05 ` Muntz, Daniel
2008-12-19 13:22 ` David Howells
2008-12-19 13:03 ` David Howells
-- strict thread matches above, loose matches on Subject: below --
2008-12-20 6:06 Muntz, Daniel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=29970.1230722102@redhat.com \
--to=dhowells@redhat.com \
--cc=Dan.Muntz@netapp.com \
--cc=akpm@linux-foundation.org \
--cc=bernd.schubert@fastmail.fm \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=nfsv4@linux-nfs.org \
--cc=rwheeler@redhat.com \
--cc=sfr@canb.auug.org.au \
--cc=steved@redhat.com \
--cc=trond.myklebust@fys.uio.no \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).