From: "Theodore Ts'o" <tytso@mit.edu>
To: ksummit-discuss@lists.linuxfoundation.org
Cc: Satya Tangirala <satyat@google.com>
Subject: [Ksummit-discuss] [TECH TOPIC] Inline Encryption Support
Date: Thu, 30 May 2019 02:07:27 -0400 [thread overview]
Message-ID: <20190530060727.GA31283@mit.edu> (raw)
From: Satya Tangirala <satyat@google.com>
[ Note: The following abstract was submitted via the Linux Plumbers
Conference website. Per the instructions that were posted for the
Maintainer's / Kernel Summit Call for Proposals[1], the proposal
should also be posted on the ksummit-discuss list, so that people
can comment on the proposal, and perhaps start a discussion before
the summit.
[1] https://lwn.net/Articles/788378/
Please note that topic proposals for both the Kernel Summit and the
Maintainer's Summit are still welcome, and the deadline has been
extended to June 3rd. -- Ted ]
Storage hardware with built-in “inline” encryption support is becoming
increasingly common, especially on mobile SoCs running Android; it's
also now part of the UFS and eMMC standards. These devices en/decrypt
data between the application processor and disk without generating
disk latency or cpu overhead. Inline encryption hardware can be
programmed to hold multiple encryption keys simultaneously and can be
dynamically reprogrammed to use any of these programmed encryption
keys to en/decrypt a particular request. This makes this new class of
storage ideal for supporting fscrypt (file-based
encryption). Unfortunately, there isn’t currently a unified approach
for supporting inline encryption hardware in the Linux kernel.
We’ve sent out an RFC patchset to add support for inline encryption to
the block subsystem, UFS driver, f2fs, and fscrypt
(https://www.spinics.net/lists/linux-block/msg40330.html). We’ll
discuss our approach including:
How the filesystem communicates an encryption key to inline encryption
hardware for each struct bio it submits. How to add support for
inline encryption to storage drivers. Support for layered devices
like device mapper. A software crypto fallback. How this work can
make future encryption tasks cleaner - like metadata encryption,
file-based encryption on removable storage and the possibility of
unifying how fscrypt, dm-crypt, and eCryptfs implement encryption.
next reply other threads:[~2019-05-30 6:07 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-30 6:07 Theodore Ts'o [this message]
2019-06-03 18:30 ` [Ksummit-discuss] [TECH TOPIC] Inline Encryption Support Mark Brown
2019-06-07 10:07 ` Ard Biesheuvel
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=20190530060727.GA31283@mit.edu \
--to=tytso@mit.edu \
--cc=ksummit-discuss@lists.linuxfoundation.org \
--cc=satyat@google.com \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).