On Fri, Jan 17, 2020 at 05:58:08AM -0800, Christoph Hellwig wrote:
> On Wed, Dec 18, 2019 at 06:51:33AM -0800, Satya Tangirala wrote:
> > Wire up ufshcd.c with the UFS Crypto API, the block layer inline
> > encryption additions and the keyslot manager.
>
> I think this patch should be merged into
On Fri, Jan 17, 2020 at 12:32:21AM -0800, Christoph Hellwig wrote:
>
> File systems don't move data around all that often (saying that with my
> fs developer hat on). In traditional file systems only defragmentation
> will move data around, with extent refcounting it can also happen for
> dedup,
On Wed, Dec 18, 2019 at 06:51:33AM -0800, Satya Tangirala wrote:
> @@ -4654,6 +4686,8 @@ static int ufshcd_slave_configure(struct scsi_device
> *sdev)
> if (ufshcd_is_rpm_autosuspend_allowed(hba))
> sdev->rpm_autosuspend = 1;
>
> + ufshcd_crypto_setup_rq_keyslot_manager(h
If a directory isn't casefolded, it doesn't need the hash key. Skip
deriving it unless we enable it later.
Signed-off-by: Daniel Rosenberg
---
fs/crypto/keysetup.c | 2 +-
fs/crypto/policy.c | 25 +
2 files changed, 26 insertions(+), 1 deletion(-)
diff --git a/fs/cryp
This expands f2fs's casefolding support to include encrypted
directories. For encrypted directories, we use the siphash of the
casefolded name. This ensures there is no direct way to go from an
unencrypted name to the stored hash on disk without knowledge of the
encryption policy keys.
Additionall
With encryption and casefolding, we cannot simply take the hash of the
ciphertext because of case insensitivity, and we can't take the hash of
the unencrypted name since that would leak information about the
encrypted name. Instead we can use siphash to compute a keyed hash of
the file names.
When
Fscrypt supplies a no-key token in place of file names when the name is
encrypted and the key is not present. In the current scheme, the no-key
token is the base64 encoded ciphertext of the name, unless the name is
longer than a certain amount, after which it uses an alternative scheme
which includ
Casefolding currently requires a derived key for computing the siphash.
This is available for v2 policies, but not v1, so we disallow it for v1.
Signed-off-by: Daniel Rosenberg
---
fs/crypto/policy.c | 28
fs/inode.c | 3 ++-
include/linux/fscrypt.
Ext4 and F2fs are both using casefolding, and they, along with any other
filesystem that adds the feature, will be using identical dentry_ops.
Additionally, those dentry ops interfere with the dentry_ops required
for fscrypt once we add support for casefolding and encryption.
Moving this into the v
This adds support for encryption with casefolding.
Since the name on disk is case preserving, and also encrypted, we can no
longer just recompute the hash on the fly. Additionally, to avoid
leaking extra information from the hash of the unencrypted name, we use
siphash via an fscrypt v2 policy.
T
Switch over to using the struct entries added to the VFS
Signed-off-by: Daniel Rosenberg
---
fs/ext4/dir.c | 47 ---
fs/ext4/ext4.h | 4
fs/ext4/hash.c | 2 +-
fs/ext4/namei.c | 20
fs/ext4/super.c | 15 +--
Matching names with casefolded encrypting directories requires
decrypting entries to confirm case since we are case preserving. We can
avoid needing to decrypt if our hash values don't match.
Signed-off-by: Daniel Rosenberg
---
fs/ext4/ext4.h | 17 ---
fs/ext4/namei.c | 55 +
These patches are all on top of fscrypt's developement branch
Ext4 and F2FS currently both support casefolding and encryption, but not at
the same time. These patches aim to rectify that.
Since directory names are stored case preserved, we cannot just take the hash
of the ciphertext. Instead we u
On Fri, Jan 17, 2020 at 11:40:54AM -0500, Theodore Y. Ts'o wrote:
> On Fri, Jan 17, 2020 at 12:12:46AM -0800, Christoph Hellwig wrote:
> > On Thu, Jan 16, 2020 at 11:20:08AM -0800, Eric Biggers wrote:
> > > From: Eric Biggers
> > >
> > > Reserve flags for the hardware-wrapped keys feature which i
On Fri, Jan 17, 2020 at 12:12:46AM -0800, Christoph Hellwig wrote:
> On Thu, Jan 16, 2020 at 11:20:08AM -0800, Eric Biggers wrote:
> > From: Eric Biggers
> >
> > Reserve flags for the hardware-wrapped keys feature which is being
> > worked on [1]. FSCRYPT_POLICY_FLAG_HW_WRAPPED_KEY will denote t
On Wed, Dec 18, 2019 at 06:51:33AM -0800, Satya Tangirala wrote:
> Wire up ufshcd.c with the UFS Crypto API, the block layer inline
> encryption additions and the keyslot manager.
I think this patch should be merged into the previous patch, as the
previous one isn't useful without wiring it up.
>
> index 94c6c5d7334b..e88cdcde83fd 100644
> --- a/drivers/scsi/ufs/Makefile
> +++ b/drivers/scsi/ufs/Makefile
> @@ -12,3 +12,4 @@ obj-$(CONFIG_SCSI_UFSHCD_PLATFORM) += ufshcd-pltfrm.o
> obj-$(CONFIG_SCSI_UFS_HISI) += ufs-hisi.o
> obj-$(CONFIG_SCSI_UFS_MEDIATEK) += ufs-mediatek.o
> obj-$(CONFIG_S
On Wed, Dec 18, 2019 at 06:51:31AM -0800, Satya Tangirala wrote:
> Add the crypto registers and structs defined in v2.1 of the JEDEC UFSHCI
> specification in preparation to add support for inline encryption to
> UFS.
>
> Signed-off-by: Satya Tangirala
> ---
> drivers/scsi/ufs/ufshcd.c | 2 ++
>
> +struct keyslot_manager {
> + unsigned int num_slots;
> + struct keyslot_mgmt_ll_ops ksm_ll_ops;
> + unsigned int crypto_mode_supported[BLK_ENCRYPTION_MODE_MAX];
> + void *ll_priv_data;
> +
> + /* Protects programming and evicting keys from the device */
> + struct rw_sema
Hi Satya,
On Wed, Jan 08, 2020 at 10:43:05AM -0800, Satya Tangirala wrote:
> The fallback actually is in a separate file, and the software only fields
> are not allocated in the hardware case anymore, either - I should have
> made that clear(er) in the coverletter.
I see this now, thanks. Either
Hi Eric,
On Wed, Jan 08, 2020 at 09:26:29AM -0800, Eric Biggers wrote:
> The NVMe "key per I/O" draft is heavily flawed, and I don't think it will be
> useful at all in the Linux kernel context. The problem is that, as far as I
> can tell, it doesn't allow the encryption algorithm and IVs to be s
On Thu, Jan 16, 2020 at 11:20:08AM -0800, Eric Biggers wrote:
> From: Eric Biggers
>
> Reserve flags for the hardware-wrapped keys feature which is being
> worked on [1]. FSCRYPT_POLICY_FLAG_HW_WRAPPED_KEY will denote that the
> encryption policy needs a hardware-wrapped key to be unlocked.
> FS
If cluster has only one compressed page, race condition as below will
trigger NULL pointer dereference:
- f2fs_write_compressed_pages
- cic->rpages[0] = cc->rpages[0];
- f2fs_outplace_write_data
- f2fs_compress_write_end_io
23 matches
Mail list logo
