linux-kernel - Re: [PATCH 2/3] fscrypt: Add metadata encryption support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20201008170551.GB1869638@gmail.com>
Date:   Thu, 8 Oct 2020 10:05:51 -0700
From:   Eric Biggers <ebiggers@...nel.org>
To:     Satya Tangirala <satyat@...gle.com>
Cc:     "Theodore Y . Ts'o" <tytso@....edu>,
        Jaegeuk Kim <jaegeuk@...nel.org>, Chao Yu <chao@...nel.org>,
        linux-kernel@...r.kernel.org, linux-fscrypt@...r.kernel.org,
        linux-f2fs-devel@...ts.sourceforge.net
Subject: Re: [PATCH 2/3] fscrypt: Add metadata encryption support

On Wed, Oct 07, 2020 at 11:28:06PM +0000, Satya Tangirala wrote:
> > This needs Kconfig help text to describe what this feature is and why anyone
> > would want to enable it.  It also needs an update to
> > Documentation/filesystems/fscrypt.rst, and a test in xfstests that tests that
> > the encryption is being done correctly.
> > 
> Sure. I forgot to mention, fwiw I did hack xfstests to enable metadata
> encryption on each device to try to test the code, and also some other
> informal tests, but as you point out, I should send out actual xfstests
> to test this.

To be clear, I'm asking for tests which verify the actual ciphertext written to
disk.  So similar to _verify_ciphertext_for_encryption_policy() in xfstests, or
to vts_kernel_encryption_test in Android's VTS.

> > Perhaps fscrypt_set_bio_crypt_ctx() should call this?  It seems there should be
> > a single function that filesystems can call that handles setting the
> > bio_crypt_ctx for both file contents and metadata encryption.
> > 
> I mistakenly dismissed this idea when I was coding this up :( - I'll do
> this for the next version... I think it'll also make supporting direct I/O
> easier in future :) . Also, I might require FS_ENCRYPTION_INLINE_CRYPT
> when enabling FS_ENCRYPTION_METADATA to maybe make the code slightly
> cleaner (unless there's a reason we want to support metadata encryption
> without FS inline encryption being enabled?).

Since metadata encryption would already depend on FS_ENCRYPTION and
BLK_INLINE_ENCRYPTION, I think it would be fine to require
FS_ENCRYPTION_INLINE_CRYPT too, in order to reduce the number of combinations.

- Eric