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 B9080C25B08 for ; Wed, 17 Aug 2022 15:55:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237604AbiHQPzB (ORCPT ); Wed, 17 Aug 2022 11:55:01 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35672 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234850AbiHQPzA (ORCPT ); Wed, 17 Aug 2022 11:55:00 -0400 Received: from box.fidei.email (box.fidei.email [71.19.144.250]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 63A1896742; Wed, 17 Aug 2022 08:54:59 -0700 (PDT) Received: from authenticated-user (box.fidei.email [71.19.144.250]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by box.fidei.email (Postfix) with ESMTPSA id 173C781150; Wed, 17 Aug 2022 11:54:57 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dorminy.me; s=mail; t=1660751699; bh=PCq741HCIYiBTSDmQL6BV/iOo1sZ2Z3I+aX8vIQZme4=; h=Date:Subject:To:References:From:In-Reply-To:From; b=g8D2N8EXW0TmK9TxyXb/HsTDdFw5F/X8qMYbsJl1Hl2vvCEXYqdTvBJc5We82vtz9 fOx2TqUHBeeBwm0FnDJ7KLADLEsM/DTovsLRExIodE44vRn8knIuFFXBGquJBH1Vim KD58Vp5U5BdRW+xSmSG+jkZ+8qT9vVmqWU1p1rkcrf+P28vVg3FP6pB1O5LWHOKuC1 O7c7EVQfjOfGmnqEeNRdDk/jhEhDiB2b6/CMp1MvON4mUxQW1HOUaZB6c4MGnP/3MY oLBYQP34pdza8vsGniBsQ7s3lwYn1nyGiHvdP/8q3TSg6w8QOnVzYjThEo2Eq0ZGEq ru53aiX3O6ing== Message-ID: <89d9ff01-c405-ec25-736a-bfba4c03e72c@dorminy.me> Date: Wed, 17 Aug 2022 11:54:56 -0400 MIME-Version: 1.0 Subject: Re: [PATCH 05/21] fscrypt: add new encryption policy for btrfs. Content-Language: en-US To: Chris Mason , Josef Bacik , David Sterba , "Theodore Y . Ts'o" , Jaegeuk Kim , Eric Biggers , linux-fscrypt@vger.kernel.org, linux-btrfs@vger.kernel.org, kernel-team@fb.com References: <66fcd64620c0c0711bbe80aa85e92f04d539bd83.1660744500.git.sweettea-kernel@dorminy.me> From: Sweet Tea Dorminy In-Reply-To: <66fcd64620c0c0711bbe80aa85e92f04d539bd83.1660744500.git.sweettea-kernel@dorminy.me> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-fscrypt@vger.kernel.org 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.