On Tue, Jun 13, 2023 at 12:12:19PM +0200, Sergei Shtepa wrote: > On 6/12/23 18:19, Eric Biggers wrote: > > This is the first time you've received an email from this sender > > ebiggers@xxxxxxxxxx, please exercise caution when clicking on links or opening > > attachments. > > > > > > On Mon, Jun 12, 2023 at 03:52:17PM +0200, Sergei Shtepa wrote: > > > Hi all. > > > > > > I am happy to offer a improved version of the Block Devices Snapshots > > > Module. It allows to create non-persistent snapshots of any block devices. > > > The main purpose of such snapshots is to provide backups of block devices. > > > See more in Documentation/block/blksnap.rst. > > > > How does blksnap interact with blk-crypto? > > > > I.e., what happens if a bio with a ->bi_crypt_context set is submitted to a > > block device that has blksnap active? > > > > If you are unfamiliar with blk-crypto, please read > > Documentation/block/inline-encryption.rst > > Thank you, this is an important point. Yes, that's right. > The current version of blksnap can cause blk-crypto to malfunction while > holding a snapshot. When handling bios from the file system, the > ->bi_crypt_context is preserved. But the bio requests serving the snapshot > are executed without context. I think that the snapshot will be unreadable. Well not only would the resulting snapshot be unreadable, but plaintext data would be written to disk, contrary to the intent of the submitter of the bios. That would be a security vulnerability. If the initial version of blksnap isn't going to be compatible with blk-crypto, that is tolerable for now, but there needs to be an explicit check to cause an error to be returned if the two features are combined, before anything is written to disk. - Eric
