From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: Mark Brown <broonie@kernel.org>
Cc: ksummit-discuss@lists.linuxfoundation.org,
Satya Tangirala <satyat@google.com>
Subject: Re: [Ksummit-discuss] [TECH TOPIC] Inline Encryption Support
Date: Fri, 7 Jun 2019 12:07:44 +0200 [thread overview]
Message-ID: <CAKv+Gu_TrH4z0s10nhuBJROjDx+o1DVhixz_wUsZ7NbbqqUbCg@mail.gmail.com> (raw)
In-Reply-To: <20190603183050.GB2456@sirena.org.uk>
On Mon, 3 Jun 2019 at 20:31, Mark Brown <broonie@kernel.org> wrote:
>
> On Thu, May 30, 2019 at 02:07:27AM -0400, Theodore Ts'o wrote:
>
> > 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.
> > 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.
>
> There was some related work done by Linaro on this, specifically for
> adding support for offloading ESSIV in dm-crypt using crypto engines
> (rather than something directly in block hardware) through the existing
> crypto API. It does seem like something where there's hardware out
> there but no clear idea how to implement support for it in the kernel,
> the big blockers there were IIRC benchmarking requirements and in the
> case of ESSIV handling the fact that everything is in dm-crypt at
> present.
Yeah. There's a bit of a debate whether having separate drivers for
storage/network on the one hand and async crypto on the other hand can
scale up sufficiently in performance, and what we're bound to see more
of is things like this, for storage as well as networking.
Interestingly, that might still mean a smart NIC with a wimpy core
that offloads the crypto to an ASIC but from the OS pov, it is all
done by the hardware.
prev parent reply other threads:[~2019-06-07 10:07 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-30 6:07 [Ksummit-discuss] [TECH TOPIC] Inline Encryption Support Theodore Ts'o
2019-06-03 18:30 ` Mark Brown
2019-06-07 10:07 ` Ard Biesheuvel [this message]
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=CAKv+Gu_TrH4z0s10nhuBJROjDx+o1DVhixz_wUsZ7NbbqqUbCg@mail.gmail.com \
--to=ard.biesheuvel@linaro.org \
--cc=broonie@kernel.org \
--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).