Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp4004810pxf; Tue, 6 Apr 2021 05:56:31 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx5HK0MaHm4yMXsGF7PMBxOoKkk8OBPPDk2JAUOhrNabmRcR2k54IO26YpVUCVjDlgiJLkR X-Received: by 2002:a17:906:298b:: with SMTP id x11mr4901610eje.43.1617713791511; Tue, 06 Apr 2021 05:56:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617713791; cv=none; d=google.com; s=arc-20160816; b=PMbTHcxNTR376K9MS4E6UVzpgz1SQFcWVSf8DkwX8Js0pIn0q0zlyrNcdm+ngihuIC vENZ0Hsf1gW3ObMSMDxeeGxuNtL+1wZtMK7d+B1omVPtS37C4vcji4g91zaOqKKgYO26 7lEF6AYTx5j0OPrquHPfJODF7WoU2n7dMeh48aDSL7YZP1zw+J1Ht8KM36NFuPrytDI6 OC+wVo2usaDOl0YdnsMp5fbNAhlPKQz4oVTo+OFnw2vm42mXBr51TqsquvtLwOHYtWUq UFr7MiwOhfGl+t9cPtsrEFB7rBVoJMsTWnfJ5kHVmPnLc6BhM2a8DKxa5yz8kZvG/E/j QtxQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=MgTD0vyfTeL5ZKSeUwhXvjK6cVFhmiQyJUVk/zqvL28=; b=jJjEGleRVtAcPatQKyBUam14yPcxrPtTmXv7LVfvqKP6L2jdeXcXzTWdpxtM75YUSz 154PzFfBpi3gSM80KKMxoiNCX+NepO4wejrsvJVaZBUFun6LZW8b8Y+eblNOJ+sFaT7o uOtpGUOuj4bOjvFsygDqTcYk/4Kn6ZuHb0A+GsRsu49LL8Ey+HkDtW4hyHfo0zTD37Kr 4vvSgO9v5WNr8gUnfF0NWBeQ70AHfXV7Pvo7G4F4wLTkB7Dq/C3Ixd3KmP3/9l3Yj/Sl qxdMkBYqrKV37L3/1scVZmcjAYtdzQ4U5iwoB0yTYuUcjRp4YRxDBGHSf2lvcoYvqZt0 Le5w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id de53si16012940ejc.358.2021.04.06.05.56.07; Tue, 06 Apr 2021 05:56:31 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243422AbhDFCik (ORCPT + 99 others); Mon, 5 Apr 2021 22:38:40 -0400 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:37812 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S243408AbhDFCij (ORCPT ); Mon, 5 Apr 2021 22:38:39 -0400 Received: from cwcc.thunk.org (pool-72-74-133-215.bstnma.fios.verizon.net [72.74.133.215]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 1362cNbi030846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 5 Apr 2021 22:38:24 -0400 Received: by cwcc.thunk.org (Postfix, from userid 15806) id 6C30615C3399; Mon, 5 Apr 2021 22:38:23 -0400 (EDT) Date: Mon, 5 Apr 2021 22:38:23 -0400 From: "Theodore Ts'o" To: Daniel Rosenberg Cc: Eric Biggers , Andreas Dilger , linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, Gabriel Krisman Bertazi , kernel-team@android.com Subject: Re: [PATCH v2 1/2] ext4: Handle casefolding with encryption Message-ID: References: <20210319073414.1381041-1-drosen@google.com> <20210319073414.1381041-2-drosen@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210319073414.1381041-2-drosen@google.com> Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Fri, Mar 19, 2021 at 07:34:13AM +0000, Daniel Rosenberg wrote: > 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. > > The hash is stored at the end of the directory entry for all entries > inside of an encrypted and casefolded directory apart from those that > deal with '.' and '..'. This way, the change is backwards compatible > with existing ext4 filesystems. > > Signed-off-by: Daniel Rosenberg Applied, thanks with the following addition so that tests, e2fsprogs, etc., can determine whether or not the currently running kernel has this feature enabled: diff --git a/fs/ext4/sysfs.c b/fs/ext4/sysfs.c index a3d08276d441..7367ba406e01 100644 --- a/fs/ext4/sysfs.c +++ b/fs/ext4/sysfs.c @@ -313,6 +313,7 @@ EXT4_ATTR_FEATURE(verity); #endif EXT4_ATTR_FEATURE(metadata_csum_seed); EXT4_ATTR_FEATURE(fast_commit); +EXT4_ATTR_FEATURE(encrypted_casefold); static struct attribute *ext4_feat_attrs[] = { ATTR_LIST(lazy_itable_init), @@ -330,6 +331,7 @@ static struct attribute *ext4_feat_attrs[] = { #endif ATTR_LIST(metadata_csum_seed), ATTR_LIST(fast_commit), + ATTR_LIST(encrypted_casefold), NULL, }; ATTRIBUTE_GROUPS(ext4_feat); Future versions of e2fsprogs may issue a warning if tune2fs or mke2fs tries to modify or create a file system such that both the encryption and casefold feature is enabled if it appears that the kernel won't support this combination. Daniel, if you could try to get this change into the Android kernels that are using encrypted casefold, that would be a good thing. - Ted