Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp22214746ybl; Mon, 6 Jan 2020 21:17:39 -0800 (PST) X-Google-Smtp-Source: APXvYqyBZ4K9CvrwEmO9QqbGR8PQ5Dvbj/ljh1XRRsVS9L6ESei1LSl148rtY8vBmbFus2wE1Buo X-Received: by 2002:a9d:402:: with SMTP id 2mr58810017otc.357.1578374258928; Mon, 06 Jan 2020 21:17:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1578374258; cv=none; d=google.com; s=arc-20160816; b=QuFezNiy91UofQZ11fq+hi7YWcWUQx8qt8cvuI6/U1Ok3wzA47n1nfK0nPyxUy21Tx /KOrBkfCD6kLLJhOw5ChXKkeyW+qckPeqot2OK/FviIZxid8wxE8/nPx91XmXebVmGuH cIScQaDFkbiiR6hBBlNio8ZW02XSu4ze0kSs7BKP4apXgOEkngbhJnM/nwzrUA62sJpu ZUhKOQOpTasAnlRTYlRYUgl71a85tnLC1W/iYjzu6Nxi/NbzrhYFGp4Np6H57sPs62KB LfgrVXN7OK6tvmcvWDwkf/yKTQJBl+yLTBkB3hawOomtWKP8t5li4UlXdUN6q/c7ieSw EUFQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:from:subject:mime-version :message-id:date:dkim-signature; bh=cfX1tvKpjBFaGwVknnvW2VBwxewGwbcoGgPS02CBSEM=; b=tLG7gA4EMFC00eH8xUSKoXyTYYDRrLB1jAjDMMSwKVFNq+x9GjEr/vC+nEMNAUo7V3 M3zl1CBMd9BIPLneKzpvcilCkepUMcdMXWrfi5Sv1HONVOgIAGD9eAkyOrSjVif8040G Z75RwOfBRFOaDW76pCTg+DyQlEk9NoY0bByA3A8buW8qMBX+kkhC6OhGej8IJTOJLofk 46WEWasJdshVM3qVfgi/NYIdwaoq0kQH3m7893c7weppVyhZ0G7HxJsEBs6KYhxi8nUu v1J+YsAbEyYJZJ9/5IjcIGHc+kJJNC/fiVJ/gb7s8hHcN9db9LaOZwDhHN/ql6dgskWK sMRA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=Q40BGR+M; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z12si21507968oto.125.2020.01.06.21.17.26; Mon, 06 Jan 2020 21:17:38 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=Q40BGR+M; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726556AbgAGFQr (ORCPT + 99 others); Tue, 7 Jan 2020 00:16:47 -0500 Received: from mail-ua1-f73.google.com ([209.85.222.73]:57009 "EHLO mail-ua1-f73.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725781AbgAGFQq (ORCPT ); Tue, 7 Jan 2020 00:16:46 -0500 Received: by mail-ua1-f73.google.com with SMTP id b15so6011295uas.23 for ; Mon, 06 Jan 2020 21:16:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:message-id:mime-version:subject:from:to:cc; bh=cfX1tvKpjBFaGwVknnvW2VBwxewGwbcoGgPS02CBSEM=; b=Q40BGR+McgMbCgqtKK+XRsRmJJBj/BH4LjOY1inQamlLz1Onc25gJfKSbGCbLp3BV6 kKbmIcg1Qs8OlNWNQNQVhlpP5eQeWpb8bdcg/T1uA1M21Nwy3AmiDfyWJt0tvnczfV4l F5+GHxcTVIFp5EjxqoKHbB5BR5AscstZMpWufBT8/BJSWPsoka2tUFUerrjyIkmcUjjK wZ3VxyoNX/QvFD5IuLtoVSHr99qrCNN1Y+s01aUz0lsnsY4sqo6j8cw1VnQNt7bNfDGH /9+qGi2HEFX3SqvMkNy9rSPpAhx5BvUPP3MMTK/c1L92gGjvYGn+U5QaEIouLcVwROXe FVsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:message-id:mime-version:subject:from:to:cc; bh=cfX1tvKpjBFaGwVknnvW2VBwxewGwbcoGgPS02CBSEM=; b=WzFmL4n0RJCArxhYni0Bd/s4221g9oNwH2J400cTTHayJlFCgvTcTxeGC3iulYPid4 JvN6fOsP6edc1wEtLjO8/1DUbd/y777gNIfMSHuU+2JCR0/nKqoVBaO7joZrNQK2Jg8i yuDMCidKzH1e59DDipuSIMntfb8W184A4PqSoOxMcxOZ/ziyxbdRdwiE9+mDl45YOWbl neiCed+c1AjxG6YNY5bMxhgQO32e+tat1MG58mZ1jGlGBAV9VkUiEbdRznx77Jr2LYzx beum+NKYGm7jfhsCwbG/uNQ4Xj6ZxW9eJ+v2GFDifw1vyz6qBWaZ0T1mKGLxq2OJYMQV Jwew== X-Gm-Message-State: APjAAAU7o/21+DcqTsiMZi60AKlw+PFdh0YcgBuF9HfOFaBtdNSpADTN nHK0/Gigy6UP58j8qeSfwLszfuhFsQA= X-Received: by 2002:a1f:8d57:: with SMTP id p84mr56402733vkd.65.1578374205529; Mon, 06 Jan 2020 21:16:45 -0800 (PST) Date: Mon, 6 Jan 2020 21:16:32 -0800 Message-Id: <20200107051638.40893-1-drosen@google.com> Mime-Version: 1.0 X-Mailer: git-send-email 2.24.1.735.g03f4e72817-goog Subject: [PATCH v2 0/6] Support for Casefolding and Encryption From: Daniel Rosenberg To: "Theodore Ts'o" , linux-ext4@vger.kernel.org, Jaegeuk Kim , Chao Yu , linux-f2fs-devel@lists.sourceforge.net, Eric Biggers , linux-fscrypt@vger.kernel.org, Alexander Viro Cc: Andreas Dilger , Jonathan Corbet , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, Gabriel Krisman Bertazi , kernel-team@android.com, Daniel Rosenberg Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 use the siphash of the casefolded name. With this we no longer have a direct path from an encrypted name to the hash without the key. To deal with this, fscrypt now always includes the hash in the name it presents when the key is not present. There is a pre-existing bug where you can change parts of the hash and still match the name so long as the disruption to the hash does not happen to affect lookup on that filesystem. I'm not sure how to fix that without making ext4 lookups slower in the more common case. I moved the identical dcache operations for ext4 and f2fs into the VFS, as any filesystem that uses casefolding will need the same code. This will also allow further optimizations to that path, although my current changes don't take advantage of that yet. For Ext4, this also means that we need to store the hash on disk. We only do so for encrypted and casefolded directories to avoid on disk format changes. Previously encryption and casefolding could not live on the same filesystem, and we're relaxing that requirement. F2fs is a bit more straightforward since it already stores hashes on disk. I've updated the related tools with just enough to enable the feature. I still need to adjust their respective fsck's, although without access to the keys, they won't be able to verify the hashes of casefolded and encrypted names. changes: fscrypt moved to separate thread to rebase on fscrypt dev branch addressed feedback, plus some minor fixes Daniel Rosenberg (6): TMP: fscrypt: Add support for casefolding with encryption vfs: Fold casefolding into vfs f2fs: Handle casefolding with Encryption ext4: Use struct super_blocks' casefold data ext4: Hande casefolding with encryption ext4: Optimize match for casefolded encrypted dirs Documentation/filesystems/ext4/directory.rst | 27 ++ fs/crypto/Kconfig | 1 + fs/crypto/fname.c | 234 ++++++++++--- fs/crypto/fscrypt_private.h | 9 + fs/crypto/keysetup.c | 32 +- fs/crypto/policy.c | 45 ++- fs/dcache.c | 28 ++ fs/ext4/dir.c | 75 +---- fs/ext4/ext4.h | 87 +++-- fs/ext4/hash.c | 26 +- fs/ext4/ialloc.c | 5 +- fs/ext4/inline.c | 41 ++- fs/ext4/namei.c | 326 ++++++++++++------- fs/ext4/super.c | 21 +- fs/f2fs/dir.c | 114 +++---- fs/f2fs/f2fs.h | 14 +- fs/f2fs/hash.c | 25 +- fs/f2fs/inline.c | 9 +- fs/f2fs/super.c | 17 +- fs/f2fs/sysfs.c | 8 +- fs/inode.c | 7 + fs/namei.c | 41 ++- include/linux/fs.h | 10 + include/linux/fscrypt.h | 96 ++---- include/linux/unicode.h | 14 + 25 files changed, 835 insertions(+), 477 deletions(-) -- 2.24.1.735.g03f4e72817-goog