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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 886ACC28B2B for ; Thu, 18 Aug 2022 22:08:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345773AbiHRWIN (ORCPT ); Thu, 18 Aug 2022 18:08:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43386 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345991AbiHRWIA (ORCPT ); Thu, 18 Aug 2022 18:08:00 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 27AB0D34DD; Thu, 18 Aug 2022 15:07:44 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 2A59F616DF; Thu, 18 Aug 2022 22:07:43 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 41DFEC433D6; Thu, 18 Aug 2022 22:07:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1660860462; bh=bF6E7rwf4W/eliNrX/PqB1xRAfnmpiSmpBTay/JS+2w=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=EzdKlxWHBkH2wonFsC2EgwNv+8yUHoQ9rgPUPwB7hguOMRHrcoWzNPg9o8DbxKGa2 VqUAlRcki41kCoxrLFhmigop3F9nAvkzIpbmPvRHLZOsZ8wARsi/Dw/csqM5SZxnF0 WLFCx9z88xjdZRUYRYiTElRRJf2kDX18C6lUWenHCTmFufoNJhZ9j7/F274yhNmFeC lb4rkpvykvSoXRgQYiZBuOzAquOVnlzD046GVfFxYHXFDniQGalkY2X2v1GaL8ULf0 GhjjDf9/7X4EgyeF6eRhbUSj202+NosTs1wCPMwry0Tte6c9vFSCNSUBeaOwZ3xsCd +p+0bfMd+rLUg== Date: Thu, 18 Aug 2022 15:07:40 -0700 From: Eric Biggers To: Sweet Tea Dorminy Cc: Chris Mason , Josef Bacik , David Sterba , "Theodore Y . Ts'o" , Jaegeuk Kim , linux-fscrypt@vger.kernel.org, linux-btrfs@vger.kernel.org, kernel-team@fb.com Subject: Re: [PATCH 05/21] fscrypt: add new encryption policy for btrfs. Message-ID: References: <66fcd64620c0c0711bbe80aa85e92f04d539bd83.1660744500.git.sweettea-kernel@dorminy.me> <89d9ff01-c405-ec25-736a-bfba4c03e72c@dorminy.me> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <89d9ff01-c405-ec25-736a-bfba4c03e72c@dorminy.me> Precedence: bulk List-ID: X-Mailing-List: linux-fscrypt@vger.kernel.org On Wed, Aug 17, 2022 at 11:54:56AM -0400, Sweet Tea Dorminy wrote: > > > On 8/17/22 10:49, Sweet Tea Dorminy wrote: > > Encryption for btrfs must be extent-based, rather than fscrypt's > > inode-based IV generation policies. In particular, btrfs can have > > multiple inodes referencing a single block of data, and moves logical > > data blocks to different physical locations on disk; these two features > > mean inode or physical-location-based IV generation policies will not > > work for btrfs. Instead, btrfs can store an IV per extent, generated by > > fscrypt and iterated per block within the extent, and provide that IV to > > fscrypt for encryption/decryption. > > > > Plumbing filesystem internals into fscrypt for IV generation would be > > ungainly and fragile. Thus, this change adds a new policy, IV_FROM_FS, > > and a new operation function pointer, get_fs_derived_iv. btrfs will > > require this policy to be used, and implements get_fs_derived_iv by > > getting the IV stored with the relevant file extent and iterating the IV > > to the appropriate block number. Thus, each individual block has its own > > IV, but all blocks within a file extent have iterated IVs according to > > their block number, similarly to the IV_INO_LBLK* policy iterating IVs > > for a given inode by lblk number. > > > > The IV buffer passed to get_fs_derived_iv() is pre-populated with the > > inode contexts' nonce, as not all data to be encrypted is associated > > with a file extent: for btrfs, this is used for filename encryption. > > > > Filesystems implementing this policy are expected to be incompatible > > with existing IV generation policies, so if the function pointer is set, > > only dummy or IV_FROM_FS policies are permitted. If there is a > > filesystem which allows other policies as well as IV_FROM_FS, it may be > > better to expose the policy to filesystems, so they can determine > > whether any given policy is compatible with their operation. > > > > Signed-off-by: Sweet Tea Dorminy > > --- > > I realized after sending that this doesn't have Documentation/ updates for > the new policy, still; apologies, and it remains on my queue. It looks like you also didn't address my feedback about IV_FROM_FS at https://lore.kernel.org/linux-fscrypt/YuBAiRg9K8IrlCqV@gmail.com ? - Eric