From: Dave Hansen <dave.hansen@intel.com>
To: lsf-pc@lists.linux-foundation.org
Cc: linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Linux-MM <linux-mm@kvack.org>,
"Williams, Dan J" <dan.j.williams@intel.com>,
"Shutemov, Kirill" <kirill.shutemov@intel.com>,
"Schofield, Alison" <alison.schofield@intel.com>,
Dave Chinner <david@fromorbit.com>,
"Darrick J. Wong" <darrick.wong@oracle.com>,
Jan Kara <jack@suse.cz>, Christoph Hellwig <hch@infradead.org>
Subject: [LSF/MM TOPIC] Memory Encryption on top of filesystems
Date: Tue, 12 Feb 2019 08:55:57 -0800 [thread overview]
Message-ID: <788d7050-f6bb-b984-69d9-504056e6c5a6@intel.com> (raw)
Multi-Key Total Memory Encryption (MKTME) [1] is feature of a memory
controller that allows memory to be selectively encrypted with
user-controlled key, in hardware, at a very low runtime cost. However,
it is implemented using AES-XTS which encrypts each block with a key
that is generated based on the physical address of the data being
encrypted. This has nice security properties, making some replay and
substitution attacks harder, but it means that encrypted data can not be
naively relocated.
Combined with persistent memory, MKTME allows data to be unlocked at the
device (DIMM or namespace) level, but left encrypted until it actually
needs to be used. However, if encrypted data were placed on a
filesystem, it might be in its encrypted state for long periods of time
and could not be moved by the filesystem during that time.
The “easy” solution to this is to just require that the encryption key
be present and programmed into the memory controller before data is
moved. However, this means that filesystems would need to know when a
given block has been encrypted and can not be moved.
We would like to discuss an early proposal for the tooling, APIs and
on-disk changes necessary to implement this feature and ensure we have
not overlooked the interactions with complementary features like
existing software-driven encryption (eCryptfs and fscrypt).
1. https://patchwork.kernel.org/cover/10592621/
next reply other threads:[~2019-02-12 16:55 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-12 16:55 Dave Hansen [this message]
2019-02-12 23:51 ` [LSF/MM TOPIC] Memory Encryption on top of filesystems Dave Chinner
2019-02-13 0:27 ` Dan Williams
2019-02-13 2:13 ` Dave Chinner
2019-02-13 3:31 ` Dan Williams
2019-02-13 15:43 ` Theodore Y. Ts'o
2019-02-13 15:51 ` Dave Hansen
2019-02-13 20:21 ` Dave Chinner
2019-02-13 20:29 ` Dave Hansen
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=788d7050-f6bb-b984-69d9-504056e6c5a6@intel.com \
--to=dave.hansen@intel.com \
--cc=alison.schofield@intel.com \
--cc=dan.j.williams@intel.com \
--cc=darrick.wong@oracle.com \
--cc=david@fromorbit.com \
--cc=hch@infradead.org \
--cc=jack@suse.cz \
--cc=kirill.shutemov@intel.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lsf-pc@lists.linux-foundation.org \
/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).