[Ksummit-discuss] [TECH TOPIC] Inline Encryption Support

[Ksummit-discuss] [TECH TOPIC] Inline Encryption Support

[Theodore Ts'o]

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.

Re: [Ksummit-discuss] [TECH TOPIC] Inline Encryption Support

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1576 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [Ksummit-discuss] [TECH TOPIC] Inline Encryption Support

[Ard Biesheuvel]

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.