From: Christoph Hellwig <hch@infradead.org> To: Christoph Hellwig <hch@infradead.org>, Satya Tangirala <satyat@google.com>, linux-scsi@vger.kernel.org, Kim Boojin <boojin.kim@samsung.com>, Kuohong Wang <kuohong.wang@mediatek.com>, Barani Muthukumaran <bmuthuku@qti.qualcomm.com>, linux-f2fs-devel@lists.sourceforge.net, linux-block@vger.kernel.org, linux-fscrypt@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH v5 7/9] fscrypt: add inline encryption support Date: Mon, 4 Nov 2019 16:15:54 -0800 [thread overview] Message-ID: <20191105001554.GA24056@infradead.org> (raw) In-Reply-To: <20191031222500.GB111219@gmail.com> On Thu, Oct 31, 2019 at 03:25:03PM -0700, Eric Biggers wrote: > It's more important to clean up the IS_ENCRYPTED(inode) && > S_ISREG(inode->i_mode) checks that are duplicated in fs/{ext4,f2fs}/, so I've > been thinking of adding a helper: > > static inline bool fscrypt_needs_contents_encryption(const struct inode *inode) > { > return IS_ENABLED(CONFIG_FS_ENCRYPTION) && IS_ENCRYPTED(inode) && > S_ISREG(inode->i_mode); > } Sounds fine. > I don't think combining these things is a good idea because it would restrict > the use of inline encryption to filesystems that allow IV_INO_LBLK_64 encryption > policies, i.e. filesystems that have stable inode numbers, 32-bit inodes, and > 32-bit file logical block numbers. > > The on-disk format (i.e. the type of encryption policy chosen) and the > implementation (inline or filesystem-layer crypto) are really two separate > things. This was one of the changes in v4 => v5 of this patchset; these two > things used to be conflated but now they are separate. Now you can use inline > encryption with the existing fscrypt policies too. > > We could use two separate SB_* flags, like SB_INLINE_CRYPT and > SB_IV_INO_LBLK_64_SUPPORT. Yes, I think that is a good idea. > However, the ->has_stable_inodes() and > ->get_ino_and_lblk_bits() methods are nice because they separate the filesystem > properties from the question of "is this encryption policy supported". > Declaring the filesystem properties is easier to do because it doesn't require > any fscrypt-specific knowledge. Also, fs/crypto/ could use these properties in > different ways in the future, e.g. if another IV generation scheme is added. I don't really like writing up method boilerplates for something that is a simple boolean flag.
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@infradead.org> To: Christoph Hellwig <hch@infradead.org>, Satya Tangirala <satyat@google.com>, linux-scsi@vger.kernel.org, Kim Boojin <boojin.kim@samsung.com>, Kuohong Wang <kuohong.wang@mediatek.com>, Barani Muthukumaran <bmuthuku@qti.qualcomm.com>, linux-f2fs-devel@lists.sourceforge.net, linux-block@vger.kernel.org, linux-fscrypt@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [f2fs-dev] [PATCH v5 7/9] fscrypt: add inline encryption support Date: Mon, 4 Nov 2019 16:15:54 -0800 [thread overview] Message-ID: <20191105001554.GA24056@infradead.org> (raw) In-Reply-To: <20191031222500.GB111219@gmail.com> On Thu, Oct 31, 2019 at 03:25:03PM -0700, Eric Biggers wrote: > It's more important to clean up the IS_ENCRYPTED(inode) && > S_ISREG(inode->i_mode) checks that are duplicated in fs/{ext4,f2fs}/, so I've > been thinking of adding a helper: > > static inline bool fscrypt_needs_contents_encryption(const struct inode *inode) > { > return IS_ENABLED(CONFIG_FS_ENCRYPTION) && IS_ENCRYPTED(inode) && > S_ISREG(inode->i_mode); > } Sounds fine. > I don't think combining these things is a good idea because it would restrict > the use of inline encryption to filesystems that allow IV_INO_LBLK_64 encryption > policies, i.e. filesystems that have stable inode numbers, 32-bit inodes, and > 32-bit file logical block numbers. > > The on-disk format (i.e. the type of encryption policy chosen) and the > implementation (inline or filesystem-layer crypto) are really two separate > things. This was one of the changes in v4 => v5 of this patchset; these two > things used to be conflated but now they are separate. Now you can use inline > encryption with the existing fscrypt policies too. > > We could use two separate SB_* flags, like SB_INLINE_CRYPT and > SB_IV_INO_LBLK_64_SUPPORT. Yes, I think that is a good idea. > However, the ->has_stable_inodes() and > ->get_ino_and_lblk_bits() methods are nice because they separate the filesystem > properties from the question of "is this encryption policy supported". > Declaring the filesystem properties is easier to do because it doesn't require > any fscrypt-specific knowledge. Also, fs/crypto/ could use these properties in > different ways in the future, e.g. if another IV generation scheme is added. I don't really like writing up method boilerplates for something that is a simple boolean flag. _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
next prev parent reply other threads:[~2019-11-05 0:15 UTC|newest] Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-10-28 7:20 [PATCH v5 0/9] Inline Encryption Support Satya Tangirala 2019-10-28 7:20 ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel 2019-10-28 7:20 ` [PATCH v5 1/9] block: Keyslot Manager for Inline Encryption Satya Tangirala 2019-10-28 7:20 ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel 2019-10-31 18:04 ` Christoph Hellwig 2019-10-31 18:04 ` [f2fs-dev] " Christoph Hellwig 2019-10-28 7:20 ` [PATCH v5 2/9] block: Add encryption context to struct bio Satya Tangirala 2019-10-28 7:20 ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel 2019-10-31 18:16 ` Christoph Hellwig 2019-10-31 18:16 ` [f2fs-dev] " Christoph Hellwig 2019-10-28 7:20 ` [PATCH v5 3/9] block: blk-crypto for Inline Encryption Satya Tangirala 2019-10-28 7:20 ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel 2019-10-31 17:57 ` Christoph Hellwig 2019-10-31 17:57 ` [f2fs-dev] " Christoph Hellwig 2019-10-31 20:50 ` Theodore Y. Ts'o 2019-10-31 20:50 ` [f2fs-dev] " Theodore Y. Ts'o 2019-10-31 21:22 ` Christoph Hellwig 2019-10-31 21:22 ` [f2fs-dev] " Christoph Hellwig 2019-11-05 2:01 ` Eric Biggers 2019-11-05 2:01 ` [f2fs-dev] " Eric Biggers 2019-11-05 15:39 ` Christoph Hellwig 2019-11-05 15:39 ` [f2fs-dev] " Christoph Hellwig 2019-10-28 7:20 ` [PATCH v5 4/9] scsi: ufs: UFS driver v2.1 spec crypto additions Satya Tangirala 2019-10-28 7:20 ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel 2019-10-28 7:20 ` [PATCH v5 5/9] scsi: ufs: UFS crypto API Satya Tangirala 2019-10-28 7:20 ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel 2019-10-31 18:23 ` Christoph Hellwig 2019-10-31 18:23 ` [f2fs-dev] " Christoph Hellwig 2019-10-28 7:20 ` [PATCH v5 6/9] scsi: ufs: Add inline encryption support to UFS Satya Tangirala 2019-10-28 7:20 ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel 2019-10-31 18:26 ` Christoph Hellwig 2019-10-31 18:26 ` [f2fs-dev] " Christoph Hellwig 2019-10-28 7:20 ` [PATCH v5 7/9] fscrypt: add inline encryption support Satya Tangirala 2019-10-28 7:20 ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel 2019-10-31 18:32 ` Christoph Hellwig 2019-10-31 18:32 ` [f2fs-dev] " Christoph Hellwig 2019-10-31 20:21 ` Eric Biggers 2019-10-31 20:21 ` [f2fs-dev] " Eric Biggers 2019-10-31 21:21 ` Christoph Hellwig 2019-10-31 21:21 ` [f2fs-dev] " Christoph Hellwig 2019-10-31 22:25 ` Eric Biggers 2019-10-31 22:25 ` [f2fs-dev] " Eric Biggers 2019-11-05 0:15 ` Christoph Hellwig [this message] 2019-11-05 0:15 ` Christoph Hellwig 2019-11-05 1:03 ` Eric Biggers 2019-11-05 1:03 ` [f2fs-dev] " Eric Biggers 2019-11-05 3:12 ` Eric Biggers 2019-11-05 3:12 ` [f2fs-dev] " Eric Biggers 2019-10-28 7:20 ` [PATCH v5 8/9] f2fs: " Satya Tangirala 2019-10-28 7:20 ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel 2019-10-31 17:14 ` Jaegeuk Kim 2019-10-31 17:14 ` [f2fs-dev] " Jaegeuk Kim 2019-10-28 7:20 ` [PATCH v5 9/9] ext4: " Satya Tangirala 2019-10-28 7:20 ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20191105001554.GA24056@infradead.org \ --to=hch@infradead.org \ --cc=bmuthuku@qti.qualcomm.com \ --cc=boojin.kim@samsung.com \ --cc=kuohong.wang@mediatek.com \ --cc=linux-block@vger.kernel.org \ --cc=linux-f2fs-devel@lists.sourceforge.net \ --cc=linux-fscrypt@vger.kernel.org \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-scsi@vger.kernel.org \ --cc=satyat@google.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.