From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4F593C433E1 for ; Mon, 24 Aug 2020 18:21:17 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 203662075B for ; Mon, 24 Aug 2020 18:21:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1598293277; bh=BPd9FqfRK57acJvZfHNixoCcKstFE02QTmcYRlfCq7s=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=aP0z7YJIIeFTN+XJBU+A+nuD9UFs1sKtfez9xca4zHEPExU6G8PEBaFFmOTiVCBKP N9v+GaPNlY40k63J5LVVI10+mR1UDjVTBMvbrVagMdoyudY2E+aH6qGvAnQLMQLGMg 445g3vDOh5DXUme9uTFbprfu2ueBhNk0OqutKjsk= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726853AbgHXSVR (ORCPT ); Mon, 24 Aug 2020 14:21:17 -0400 Received: from mail.kernel.org ([198.145.29.99]:57756 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726222AbgHXSVQ (ORCPT ); Mon, 24 Aug 2020 14:21:16 -0400 Received: from gmail.com (unknown [104.132.1.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 96FA820738; Mon, 24 Aug 2020 18:21:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1598293275; bh=BPd9FqfRK57acJvZfHNixoCcKstFE02QTmcYRlfCq7s=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=gSO2JDEBH2du9sVIqRO/ccvceJM7cC9d3CT0/1d7x0lyj5q9qdZRvB77EudGgmLBP DDXy3fjKwWLf31wIq1ym4KVx7/HdPpObHPD4gbEQTGggArK1CPr0EOlxDk/XQs4GGp MxEUAJwlx/5dWcs35/gGQek/09sGDl96J76TPivQ= Date: Mon, 24 Aug 2020 11:21:14 -0700 From: Eric Biggers To: Jeff Layton Cc: linux-fscrypt@vger.kernel.org, linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-mtd@lists.infradead.org, ceph-devel@vger.kernel.org Subject: Re: [RFC PATCH 1/8] fscrypt: add fscrypt_prepare_new_inode() and fscrypt_set_context() Message-ID: <20200824182114.GB1650861@gmail.com> References: <20200824061712.195654-1-ebiggers@kernel.org> <20200824061712.195654-2-ebiggers@kernel.org> <0cf5638796e7cddacc38dcd1e967368b99f0069a.camel@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0cf5638796e7cddacc38dcd1e967368b99f0069a.camel@kernel.org> Sender: linux-fscrypt-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fscrypt@vger.kernel.org On Mon, Aug 24, 2020 at 12:48:48PM -0400, Jeff Layton wrote: > > +void fscrypt_hash_inode_number(struct fscrypt_info *ci, > > + const struct fscrypt_master_key *mk) > > +{ > > + WARN_ON(ci->ci_inode->i_ino == 0); > > + WARN_ON(!mk->mk_ino_hash_key_initialized); > > + > > + ci->ci_hashed_ino = (u32)siphash_1u64(ci->ci_inode->i_ino, > > + &mk->mk_ino_hash_key); > > i_ino is an unsigned long. Will this produce a consistent results on > arches with 32 and 64 bit long values? I think it'd be nice to ensure > that we can access an encrypted directory created on a 32-bit host from > (e.g.) a 64-bit host. The result is the same regardless of word size and endianness. siphash_1u64(v, k) is equivalent to: __le64 x = cpu_to_le64(v); siphash(&x, 8, k); > It may be better to base this on something besides i_ino This code that hashes the inode number is only used when userspace used FSCRYPT_POLICY_FLAG_IV_INO_LBLK_32 for the directory. IV_INO_LBLK_32 modifies the encryption to be optimized for eMMC inline encryption hardware. For more details, see commit e3b1078bedd3 which added this feature. We actually could have hashed the file nonce instead of the inode number. But I wanted to make the eMMC-optimized format similar to IV_INO_LBLK_64, which is the format optimized for UFS inline encryption hardware. Both of these flags have very specific use cases; they make it feasible to use inline encryption hardware (https://www.kernel.org/doc/html/latest/block/inline-encryption.html) that only supports a small number of keyslots and that limits the IV length. You don't need to worry about these flags at all for ceph, since there won't be any use case to use them on ceph, and ceph won't be declaring support for them. - Eric From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 19AECC433E1 for ; Mon, 24 Aug 2020 18:21:31 +0000 (UTC) Received: from lists.sourceforge.net (lists.sourceforge.net [216.105.38.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D7DB320738; Mon, 24 Aug 2020 18:21:30 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=sourceforge.net header.i=@sourceforge.net header.b="OkFqD7fs"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=sf.net header.i=@sf.net header.b="I0udW8Pi"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="gSO2JDEB" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D7DB320738 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linux-f2fs-devel-bounces@lists.sourceforge.net Received: from [127.0.0.1] (helo=sfs-ml-4.v29.lw.sourceforge.com) by sfs-ml-4.v29.lw.sourceforge.com with esmtp (Exim 4.90_1) (envelope-from ) id 1kAH61-000149-P1; Mon, 24 Aug 2020 18:21:29 +0000 Received: from [172.30.20.202] (helo=mx.sourceforge.net) by sfs-ml-4.v29.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kAH60-000142-NT for linux-f2fs-devel@lists.sourceforge.net; Mon, 24 Aug 2020 18:21:28 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=In-Reply-To:Content-Type:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=bUOCoRGgX+TjrVs95R6YkR4vmbUM1GOdDiD67dZlusk=; b=OkFqD7fsins7atJOj9crmnDwzN nskHXCwDFL/i4wIoaYuubyyuCKNV0TIWAO0g8+2vuHdT3G4hMWfW4KsUrHc7n/gKdkpJ7g1zpQvea DzBmevGtOx+ULuOIj1m2PCdn4oIsaiXk32wrf3fqXpIwcDiAvjLNMKos1PSR2xvt8yXs=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To :From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=bUOCoRGgX+TjrVs95R6YkR4vmbUM1GOdDiD67dZlusk=; b=I0udW8Piw3KG/GuqCFyv6R+KQq sHqRsJFhgeVPgkj5THRDCW1I3pAS/F/1fB0iqRcNV4Kda2TTBGIkkQ6eb+KwUDs3b2ZrZalv09wVa IYWpQ8KjYeY0vihZqB13JQXFDm3jINpwE1wnkbaE1xNCLDgr6qXhrSF4c02ZxWba4rnI=; Received: from mail.kernel.org ([198.145.29.99]) by sfi-mx-1.v28.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.2) id 1kAH5x-00HHv3-VU for linux-f2fs-devel@lists.sourceforge.net; Mon, 24 Aug 2020 18:21:28 +0000 Received: from gmail.com (unknown [104.132.1.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 96FA820738; Mon, 24 Aug 2020 18:21:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1598293275; bh=BPd9FqfRK57acJvZfHNixoCcKstFE02QTmcYRlfCq7s=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=gSO2JDEBH2du9sVIqRO/ccvceJM7cC9d3CT0/1d7x0lyj5q9qdZRvB77EudGgmLBP DDXy3fjKwWLf31wIq1ym4KVx7/HdPpObHPD4gbEQTGggArK1CPr0EOlxDk/XQs4GGp MxEUAJwlx/5dWcs35/gGQek/09sGDl96J76TPivQ= Date: Mon, 24 Aug 2020 11:21:14 -0700 From: Eric Biggers To: Jeff Layton Message-ID: <20200824182114.GB1650861@gmail.com> References: <20200824061712.195654-1-ebiggers@kernel.org> <20200824061712.195654-2-ebiggers@kernel.org> <0cf5638796e7cddacc38dcd1e967368b99f0069a.camel@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <0cf5638796e7cddacc38dcd1e967368b99f0069a.camel@kernel.org> X-Headers-End: 1kAH5x-00HHv3-VU Subject: Re: [f2fs-dev] [RFC PATCH 1/8] fscrypt: add fscrypt_prepare_new_inode() and fscrypt_set_context() X-BeenThere: linux-f2fs-devel@lists.sourceforge.net X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-fscrypt@vger.kernel.org, linux-ext4@vger.kernel.org, linux-mtd@lists.infradead.org, ceph-devel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-f2fs-devel-bounces@lists.sourceforge.net On Mon, Aug 24, 2020 at 12:48:48PM -0400, Jeff Layton wrote: > > +void fscrypt_hash_inode_number(struct fscrypt_info *ci, > > + const struct fscrypt_master_key *mk) > > +{ > > + WARN_ON(ci->ci_inode->i_ino == 0); > > + WARN_ON(!mk->mk_ino_hash_key_initialized); > > + > > + ci->ci_hashed_ino = (u32)siphash_1u64(ci->ci_inode->i_ino, > > + &mk->mk_ino_hash_key); > > i_ino is an unsigned long. Will this produce a consistent results on > arches with 32 and 64 bit long values? I think it'd be nice to ensure > that we can access an encrypted directory created on a 32-bit host from > (e.g.) a 64-bit host. The result is the same regardless of word size and endianness. siphash_1u64(v, k) is equivalent to: __le64 x = cpu_to_le64(v); siphash(&x, 8, k); > It may be better to base this on something besides i_ino This code that hashes the inode number is only used when userspace used FSCRYPT_POLICY_FLAG_IV_INO_LBLK_32 for the directory. IV_INO_LBLK_32 modifies the encryption to be optimized for eMMC inline encryption hardware. For more details, see commit e3b1078bedd3 which added this feature. We actually could have hashed the file nonce instead of the inode number. But I wanted to make the eMMC-optimized format similar to IV_INO_LBLK_64, which is the format optimized for UFS inline encryption hardware. Both of these flags have very specific use cases; they make it feasible to use inline encryption hardware (https://www.kernel.org/doc/html/latest/block/inline-encryption.html) that only supports a small number of keyslots and that limits the IV length. You don't need to worry about these flags at all for ceph, since there won't be any use case to use them on ceph, and ceph won't be declaring support for them. - Eric _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7C568C433E3 for ; Mon, 24 Aug 2020 18:21:59 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 48A4220738 for ; Mon, 24 Aug 2020 18:21:59 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="eK9ZWgSK"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="gSO2JDEB" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 48A4220738 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-mtd-bounces+linux-mtd=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=7TwIL8TLu/8q0aDrUHhJicbOBfsJ7QaNkeVVfWTJzho=; b=eK9ZWgSKfgYu2RedyVbZhndpb OBnlUmfoHYyRuAoSZ80OEQLOZ4zyNLE9bGeSb3/oQiUQ1gxIKR8lFyZr4DScNNiO6QfMakzmT24DH JI0sJlU7t8VZClg9Rnc+uk9lZmpk/KulFTxc3ofU4ubnJdPmL7gqQOOsNZfR2ETNz6GxAMj4DTHV9 mR4qEoWrfcNrrMewljoi/VK3OAzx8PbTCtk7qrrNpUfQyQzFYRHxE8e6KN6ghLtGB91AoL3Pgmqlz aUZNh3o/MMnztoSwJibwtZseIYiBJGCBMitDCyxyiXgT2vY1gddNTBdMFt3sflPU153KL9bHDJ6QL vNKSYdntQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kAH5r-00007b-Ps; Mon, 24 Aug 2020 18:21:19 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kAH5o-00007A-EZ for linux-mtd@lists.infradead.org; Mon, 24 Aug 2020 18:21:17 +0000 Received: from gmail.com (unknown [104.132.1.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 96FA820738; Mon, 24 Aug 2020 18:21:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1598293275; bh=BPd9FqfRK57acJvZfHNixoCcKstFE02QTmcYRlfCq7s=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=gSO2JDEBH2du9sVIqRO/ccvceJM7cC9d3CT0/1d7x0lyj5q9qdZRvB77EudGgmLBP DDXy3fjKwWLf31wIq1ym4KVx7/HdPpObHPD4gbEQTGggArK1CPr0EOlxDk/XQs4GGp MxEUAJwlx/5dWcs35/gGQek/09sGDl96J76TPivQ= Date: Mon, 24 Aug 2020 11:21:14 -0700 From: Eric Biggers To: Jeff Layton Subject: Re: [RFC PATCH 1/8] fscrypt: add fscrypt_prepare_new_inode() and fscrypt_set_context() Message-ID: <20200824182114.GB1650861@gmail.com> References: <20200824061712.195654-1-ebiggers@kernel.org> <20200824061712.195654-2-ebiggers@kernel.org> <0cf5638796e7cddacc38dcd1e967368b99f0069a.camel@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <0cf5638796e7cddacc38dcd1e967368b99f0069a.camel@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200824_142116_590518_95164972 X-CRM114-Status: GOOD ( 18.23 ) X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-fscrypt@vger.kernel.org, linux-ext4@vger.kernel.org, linux-mtd@lists.infradead.org, ceph-devel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-mtd" Errors-To: linux-mtd-bounces+linux-mtd=archiver.kernel.org@lists.infradead.org On Mon, Aug 24, 2020 at 12:48:48PM -0400, Jeff Layton wrote: > > +void fscrypt_hash_inode_number(struct fscrypt_info *ci, > > + const struct fscrypt_master_key *mk) > > +{ > > + WARN_ON(ci->ci_inode->i_ino == 0); > > + WARN_ON(!mk->mk_ino_hash_key_initialized); > > + > > + ci->ci_hashed_ino = (u32)siphash_1u64(ci->ci_inode->i_ino, > > + &mk->mk_ino_hash_key); > > i_ino is an unsigned long. Will this produce a consistent results on > arches with 32 and 64 bit long values? I think it'd be nice to ensure > that we can access an encrypted directory created on a 32-bit host from > (e.g.) a 64-bit host. The result is the same regardless of word size and endianness. siphash_1u64(v, k) is equivalent to: __le64 x = cpu_to_le64(v); siphash(&x, 8, k); > It may be better to base this on something besides i_ino This code that hashes the inode number is only used when userspace used FSCRYPT_POLICY_FLAG_IV_INO_LBLK_32 for the directory. IV_INO_LBLK_32 modifies the encryption to be optimized for eMMC inline encryption hardware. For more details, see commit e3b1078bedd3 which added this feature. We actually could have hashed the file nonce instead of the inode number. But I wanted to make the eMMC-optimized format similar to IV_INO_LBLK_64, which is the format optimized for UFS inline encryption hardware. Both of these flags have very specific use cases; they make it feasible to use inline encryption hardware (https://www.kernel.org/doc/html/latest/block/inline-encryption.html) that only supports a small number of keyslots and that limits the IV length. You don't need to worry about these flags at all for ceph, since there won't be any use case to use them on ceph, and ceph won't be declaring support for them. - Eric ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/