All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: linux-fscrypt@vger.kernel.org
Cc: Daniel Rosenberg <drosen@google.com>,
	kernel-team@android.com, linux-kernel@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net,
	linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org,
	Gabriel Krisman Bertazi <krisman@collabora.com>,
	linux-mtd@lists.infradead.org,
	Richard Weinberger <richard@nod.at>
Subject: Re: [PATCH v5 0/6] fscrypt preparations for encryption+casefolding
Date: Wed, 22 Jan 2020 15:06:50 -0800	[thread overview]
Message-ID: <20200122230649.GC182745@gmail.com> (raw)
In-Reply-To: <20200120223201.241390-1-ebiggers@kernel.org>

On Mon, Jan 20, 2020 at 02:31:55PM -0800, Eric Biggers wrote:
> This is a cleaned up and fixed version of the fscrypt patches to prepare
> for directories that are both encrypted and casefolded.
> 
> Patches 1-3 start deriving a SipHash key for the new dirhash method that
> will be used by encrypted+casefolded directories.  To avoid unnecessary
> overhead, we only do this if the directory is actually casefolded.
> 
> Patch 4 fixes a bug in UBIFS where it didn't gracefully handle invalid
> hash values in fscrypt no-key names.  This is an existing bug, but the
> new fscrypt no-key name format (patch 6) made it much easier to trigger;
> it started being hit by 'kvm-xfstests -c ubifs -g encrypt'.
> 
> Patch 5 updates UBIFS to make it ready for the new fscrypt no-key name
> format that always includes the dirhash.
> 
> Patch 6 modifies the fscrypt no-key names to always include the dirhash,
> since with the new dirhash method the dirhash will no longer be
> computable from the ciphertext filename without the key.  It also fixes
> a longstanding issue where there could be collisions in the no-key
> names, due to not using a proper cryptographic hash to abbreviate names.
> 
> For more information see the main patch series, which includes the
> filesystem-specific changes:
> https://lkml.kernel.org/linux-fscrypt/20200117214246.235591-1-drosen@google.com/T/#u
> 
> This applies to fscrypt.git#master.
> 
> Changed v4 => v5:
>   - Fixed UBIFS encryption to work with the new no-key name format.

I've applied this series to fscrypt.git#master; however I'd still like Acked-bys
from the UBIFS maintainers on the two UBIFS patches, as well as more
Reviewed-bys from anyone interested.  If I don't hear anything from anyone, I
might drop these to give more time, especially if there isn't an v5.5-rc8.

- Eric

WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers@kernel.org>
To: linux-fscrypt@vger.kernel.org
Cc: Daniel Rosenberg <drosen@google.com>,
	Gabriel Krisman Bertazi <krisman@collabora.com>,
	linux-kernel@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net,
	linux-mtd@lists.infradead.org,
	Richard Weinberger <richard@nod.at>,
	linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org,
	kernel-team@android.com
Subject: Re: [f2fs-dev] [PATCH v5 0/6] fscrypt preparations for encryption+casefolding
Date: Wed, 22 Jan 2020 15:06:50 -0800	[thread overview]
Message-ID: <20200122230649.GC182745@gmail.com> (raw)
In-Reply-To: <20200120223201.241390-1-ebiggers@kernel.org>

On Mon, Jan 20, 2020 at 02:31:55PM -0800, Eric Biggers wrote:
> This is a cleaned up and fixed version of the fscrypt patches to prepare
> for directories that are both encrypted and casefolded.
> 
> Patches 1-3 start deriving a SipHash key for the new dirhash method that
> will be used by encrypted+casefolded directories.  To avoid unnecessary
> overhead, we only do this if the directory is actually casefolded.
> 
> Patch 4 fixes a bug in UBIFS where it didn't gracefully handle invalid
> hash values in fscrypt no-key names.  This is an existing bug, but the
> new fscrypt no-key name format (patch 6) made it much easier to trigger;
> it started being hit by 'kvm-xfstests -c ubifs -g encrypt'.
> 
> Patch 5 updates UBIFS to make it ready for the new fscrypt no-key name
> format that always includes the dirhash.
> 
> Patch 6 modifies the fscrypt no-key names to always include the dirhash,
> since with the new dirhash method the dirhash will no longer be
> computable from the ciphertext filename without the key.  It also fixes
> a longstanding issue where there could be collisions in the no-key
> names, due to not using a proper cryptographic hash to abbreviate names.
> 
> For more information see the main patch series, which includes the
> filesystem-specific changes:
> https://lkml.kernel.org/linux-fscrypt/20200117214246.235591-1-drosen@google.com/T/#u
> 
> This applies to fscrypt.git#master.
> 
> Changed v4 => v5:
>   - Fixed UBIFS encryption to work with the new no-key name format.

I've applied this series to fscrypt.git#master; however I'd still like Acked-bys
from the UBIFS maintainers on the two UBIFS patches, as well as more
Reviewed-bys from anyone interested.  If I don't hear anything from anyone, I
might drop these to give more time, especially if there isn't an v5.5-rc8.

- Eric


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

WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers@kernel.org>
To: linux-fscrypt@vger.kernel.org
Cc: Daniel Rosenberg <drosen@google.com>,
	Gabriel Krisman Bertazi <krisman@collabora.com>,
	linux-kernel@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net,
	linux-mtd@lists.infradead.org,
	Richard Weinberger <richard@nod.at>,
	linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org,
	kernel-team@android.com
Subject: Re: [PATCH v5 0/6] fscrypt preparations for encryption+casefolding
Date: Wed, 22 Jan 2020 15:06:50 -0800	[thread overview]
Message-ID: <20200122230649.GC182745@gmail.com> (raw)
In-Reply-To: <20200120223201.241390-1-ebiggers@kernel.org>

On Mon, Jan 20, 2020 at 02:31:55PM -0800, Eric Biggers wrote:
> This is a cleaned up and fixed version of the fscrypt patches to prepare
> for directories that are both encrypted and casefolded.
> 
> Patches 1-3 start deriving a SipHash key for the new dirhash method that
> will be used by encrypted+casefolded directories.  To avoid unnecessary
> overhead, we only do this if the directory is actually casefolded.
> 
> Patch 4 fixes a bug in UBIFS where it didn't gracefully handle invalid
> hash values in fscrypt no-key names.  This is an existing bug, but the
> new fscrypt no-key name format (patch 6) made it much easier to trigger;
> it started being hit by 'kvm-xfstests -c ubifs -g encrypt'.
> 
> Patch 5 updates UBIFS to make it ready for the new fscrypt no-key name
> format that always includes the dirhash.
> 
> Patch 6 modifies the fscrypt no-key names to always include the dirhash,
> since with the new dirhash method the dirhash will no longer be
> computable from the ciphertext filename without the key.  It also fixes
> a longstanding issue where there could be collisions in the no-key
> names, due to not using a proper cryptographic hash to abbreviate names.
> 
> For more information see the main patch series, which includes the
> filesystem-specific changes:
> https://lkml.kernel.org/linux-fscrypt/20200117214246.235591-1-drosen@google.com/T/#u
> 
> This applies to fscrypt.git#master.
> 
> Changed v4 => v5:
>   - Fixed UBIFS encryption to work with the new no-key name format.

I've applied this series to fscrypt.git#master; however I'd still like Acked-bys
from the UBIFS maintainers on the two UBIFS patches, as well as more
Reviewed-bys from anyone interested.  If I don't hear anything from anyone, I
might drop these to give more time, especially if there isn't an v5.5-rc8.

- Eric

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

  parent reply	other threads:[~2020-01-22 23:06 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-20 22:31 [PATCH v5 0/6] fscrypt preparations for encryption+casefolding Eric Biggers
2020-01-20 22:31 ` Eric Biggers
2020-01-20 22:31 ` [f2fs-dev] " Eric Biggers
2020-01-20 22:31 ` [PATCH v5 1/6] fscrypt: don't allow v1 policies with casefolding Eric Biggers
2020-01-20 22:31   ` Eric Biggers
2020-01-20 22:31   ` [f2fs-dev] " Eric Biggers
2020-01-20 22:31 ` [PATCH v5 2/6] fscrypt: derive dirhash key for casefolded directories Eric Biggers
2020-01-20 22:31   ` Eric Biggers
2020-01-20 22:31   ` [f2fs-dev] " Eric Biggers
2020-01-20 22:31 ` [PATCH v5 3/6] fscrypt: clarify what is meant by a per-file key Eric Biggers
2020-01-20 22:31   ` Eric Biggers
2020-01-20 22:31   ` [f2fs-dev] " Eric Biggers
2020-01-22  1:16   ` Daniel Rosenberg
2020-01-22  1:16     ` Daniel Rosenberg
2020-01-22  1:16     ` [f2fs-dev] " Daniel Rosenberg via Linux-f2fs-devel
2020-01-20 22:31 ` [PATCH v5 4/6] ubifs: don't trigger assertion on invalid no-key filename Eric Biggers
2020-01-20 22:31   ` Eric Biggers
2020-01-20 22:31   ` [f2fs-dev] " Eric Biggers
2020-01-22  0:30   ` Eric Biggers
2020-01-22  0:30     ` Eric Biggers
2020-01-22  0:30     ` [f2fs-dev] " Eric Biggers
2020-01-24 20:14     ` Eric Biggers
2020-01-24 20:14       ` Eric Biggers
2020-01-24 20:14       ` [f2fs-dev] " Eric Biggers
2020-01-20 22:32 ` [PATCH v5 5/6] ubifs: allow both hash and disk name to be provided in no-key names Eric Biggers
2020-01-20 22:32   ` Eric Biggers
2020-01-20 22:32   ` [f2fs-dev] " Eric Biggers
2020-01-20 22:32 ` [PATCH v5 6/6] fscrypt: improve format of " Eric Biggers
2020-01-20 22:32   ` Eric Biggers
2020-01-20 22:32   ` [f2fs-dev] " Eric Biggers
2020-01-22 23:06 ` Eric Biggers [this message]
2020-01-22 23:06   ` [PATCH v5 0/6] fscrypt preparations for encryption+casefolding Eric Biggers
2020-01-22 23:06   ` [f2fs-dev] " Eric Biggers
2020-01-23 21:35   ` Daniel Rosenberg
2020-01-23 21:35     ` Daniel Rosenberg
2020-01-23 21:35     ` [f2fs-dev] " Daniel Rosenberg via Linux-f2fs-devel

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=20200122230649.GC182745@gmail.com \
    --to=ebiggers@kernel.org \
    --cc=drosen@google.com \
    --cc=kernel-team@android.com \
    --cc=krisman@collabora.com \
    --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-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=richard@nod.at \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.