Linux-f2fs-devel Archive on lore.kernel.org
 help / color / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Christoph Hellwig <hch@infradead.org>
Cc: Jens Axboe <axboe@kernel.dk>,
	linux-ext4@vger.kernel.org, linux-scsi@vger.kernel.org,
	Kim Boojin <boojin.kim@samsung.com>,
	Kuohong Wang <kuohong.wang@mediatek.com>,
	Barani Muthukumaran <bmuthuku@qti.qualcomm.com>,
	Satya Tangirala <satyat@google.com>,
	linux-block@vger.kernel.org, linux-fscrypt@vger.kernel.org,
	linux-fsdevel@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [f2fs-dev] [PATCH v13 00/12] Inline Encryption Support
Date: Fri, 15 May 2020 10:00:59 -0700
Message-ID: <20200515170059.GA1009@sol.localdomain> (raw)
In-Reply-To: <20200515144224.GA12040@infradead.org>

On Fri, May 15, 2020 at 07:42:24AM -0700, Christoph Hellwig wrote:
> On Fri, May 15, 2020 at 12:25:40PM +0000, Satya Tangirala wrote:
> > One of the nice things about the current design is that regardless of what
> > request queue an FS sends an encrypted bio to, blk-crypto will be able to handle
> > the encryption (whether by using hardware inline encryption, or using the
> > blk-crypto-fallback). The FS itself does not need to worry about what the
> > request queue is.
> 
> True.  Which just makes me despise that design with the pointless
> fallback even more..

The fallback is actually really useful.  First, for testing: it allows all the
filesystem code that uses inline crypto to be tested using gce-xfstests and
kvm-xfstests, so that it's covered by the usual ext4 and f2fs regression testing
and it's much easier to develop patches for.  It also allowed us to enable the
inlinecrypt mount option in Cuttlefish, which is the virtual Android device used
to test the Android common kernels.  So, it gets the kernel test platform as
similar to a real Android device as possible.

Ideally we'd implement virtualized inline encryption as you suggested.  But
these platforms use a mix of VMM's (QEMU, GCE, and crosvm) and storage types
(virtio-blk, virtio-scsi, and maybe others; none of these even have an inline
encryption standard defined yet).  So it's not currently feasible.

Second, it creates a clean design where users can just use blk-crypto, and not
have to implement a second encryption implementation.  For example, I'd
eventually like to switch fscrypt over to just use blk-crypto.  That would
remove the duplicate code that you're concerned about.  It would also make it
much easier to implement direct I/O support in fscrypt which is something that
people have been requesting for a long time.

The reason the fscrypt conversion isn't yet part of the patchset is just that I
consider it super important that we don't cause any regressions in fscrypt and
that it doesn't use inline encryption hardware by default.  So it's not quite
time to switch over for real yet, especially while the current patches are still
pending upstream.  But I think it will come eventually, especially if we see
that most Linux distros are enabling CONFIG_BLK_INLINE_ENCRYPTION anyway.  The
inlinecrypt mount option will thten start controlling whether blk-crypto is
allowed to to use real hardware or not, not whether blk-crypto is used or not.

Also, in the coming months we're planning to implement filesystem metadata
encryption that is properly integrated with the fscrypt key derivation so that
file contents don't have to be encrypted twice (as would be the case with
dm-crypt + fscrypt).  That's going to involve adding lots of encryption hooks to
code in ext4, f2fs, and places like fs/buffer.c.  blk-crypto-fallback is super
helpful for this, since it will allow us to simply call
fscrypt_set_bio_crypt_ctx() everywhere, and not have to both do that *and*
implement a second case where we do all the crypto work scheduling, bounce page
allocation, crypto API calls, etc. at the filesystem level.

- Eric


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

  reply index

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-14  0:37 Satya Tangirala via Linux-f2fs-devel
2020-05-14  0:37 ` [f2fs-dev] [PATCH v13 01/12] Documentation: Document the blk-crypto framework Satya Tangirala via Linux-f2fs-devel
2020-05-14  0:37 ` [f2fs-dev] [PATCH v13 02/12] block: Keyslot Manager for Inline Encryption Satya Tangirala via Linux-f2fs-devel
2020-05-14  0:37 ` [f2fs-dev] [PATCH v13 03/12] block: Inline encryption support for blk-mq Satya Tangirala via Linux-f2fs-devel
2020-05-14  0:37 ` [f2fs-dev] [PATCH v13 04/12] block: Make blk-integrity preclude hardware inline encryption Satya Tangirala via Linux-f2fs-devel
2020-05-14  0:37 ` [f2fs-dev] [PATCH v13 05/12] block: blk-crypto-fallback for Inline Encryption Satya Tangirala via Linux-f2fs-devel
2020-05-14  0:37 ` [f2fs-dev] [PATCH v13 06/12] scsi: ufs: UFS driver v2.1 spec crypto additions Satya Tangirala via Linux-f2fs-devel
2020-05-15  3:55   ` Stanley Chu
2020-05-14  0:37 ` [f2fs-dev] [PATCH v13 07/12] scsi: ufs: UFS crypto API Satya Tangirala via Linux-f2fs-devel
2020-05-15  6:35   ` Stanley Chu
2020-05-14  0:37 ` [f2fs-dev] [PATCH v13 08/12] scsi: ufs: Add inline encryption support to UFS Satya Tangirala via Linux-f2fs-devel
2020-05-14  5:12   ` Eric Biggers
2020-05-15  7:37   ` Stanley Chu
2020-05-14  0:37 ` [f2fs-dev] [PATCH v13 09/12] fs: introduce SB_INLINECRYPT Satya Tangirala via Linux-f2fs-devel
2020-05-14  0:37 ` [f2fs-dev] [PATCH v13 10/12] fscrypt: add inline encryption support Satya Tangirala via Linux-f2fs-devel
2020-05-28 21:54   ` Eric Biggers
2020-06-03  2:07   ` Eric Biggers
2020-05-14  0:37 ` [f2fs-dev] [PATCH v13 11/12] f2fs: " Satya Tangirala via Linux-f2fs-devel
2020-05-14  0:37 ` [f2fs-dev] [PATCH v13 12/12] ext4: " Satya Tangirala via Linux-f2fs-devel
2020-05-14  5:10 ` [f2fs-dev] [PATCH v13 00/12] Inline Encryption Support Eric Biggers
2020-05-14 15:48   ` Jens Axboe
2020-05-15  7:41     ` Christoph Hellwig
2020-05-15 12:25       ` Satya Tangirala via Linux-f2fs-devel
2020-05-15 14:42         ` Christoph Hellwig
2020-05-15 17:00           ` Eric Biggers [this message]
2020-05-18 16:50             ` Christoph Hellwig
2020-05-15  1:04   ` Martin K. Petersen

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=20200515170059.GA1009@sol.localdomain \
    --to=ebiggers@kernel.org \
    --cc=axboe@kernel.dk \
    --cc=bmuthuku@qti.qualcomm.com \
    --cc=boojin.kim@samsung.com \
    --cc=hch@infradead.org \
    --cc=kuohong.wang@mediatek.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-fscrypt@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.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

Linux-f2fs-devel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-f2fs-devel/0 linux-f2fs-devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-f2fs-devel linux-f2fs-devel/ https://lore.kernel.org/linux-f2fs-devel \
		linux-f2fs-devel@lists.sourceforge.net
	public-inbox-index linux-f2fs-devel

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/net.sourceforge.lists.linux-f2fs-devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git