Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <20a5802d-424d-588a-c497-1d1236c52880@veeam.com>
Date:   Tue, 13 Jun 2023 12:12:19 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.2
Subject: Re: [PATCH v5 00/11] blksnap - block devices snapshots module
Content-Language: en-US
To:     Eric Biggers <ebiggers@kernel.org>
CC:     "axboe@kernel.dk" <axboe@kernel.dk>,
        "hch@infradead.org" <hch@infradead.org>,
        "corbet@lwn.net" <corbet@lwn.net>,
        "snitzer@kernel.org" <snitzer@kernel.org>,
        "viro@zeniv.linux.org.uk" <viro@zeniv.linux.org.uk>,
        "brauner@kernel.org" <brauner@kernel.org>,
        "dchinner@redhat.com" <dchinner@redhat.com>,
        "willy@infradead.org" <willy@infradead.org>,
        "dlemoal@kernel.org" <dlemoal@kernel.org>,
        "linux@weissschuh.net" <linux@weissschuh.net>,
        "jack@suse.cz" <jack@suse.cz>,
        "ming.lei@redhat.com" <ming.lei@redhat.com>,
        "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
        "linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
References: <20230612135228.10702-1-sergei.shtepa@veeam.com>
 <20230612161911.GA1200@sol.localdomain>
From:   Sergei Shtepa <sergei.shtepa@veeam.com>
In-Reply-To: <20230612161911.GA1200@sol.localdomain>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: bulk


On 6/12/23 18:19, Eric Biggers wrote:
> This is the first time you've received an email from this sender 
> ebiggers@kernel.org, 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.

But I don't see any obstacles in the way of blksnap and blk-crypto
compatibility. If DM implements support for blk-crypto, then the same
principle can be applied for blksnap. I think that the integration of
blksnap with blk-crypto may be one of the stages of further development.

The dm-crypto should work properly. 

It is noteworthy that in 7 years of using the out-of-tree module to take
a snapshot, I have not encountered cases of such problems.
But incompatibility with blk-crypto is possible, this is already a pain
for some users. I will request this information from our support team.

> 
> It looks like blksnap hooks into the block layer directly, via the new
> "blkfilter" mechanism. I'm concerned that it might ignore ->bi_crypt_context
> and write data to the disk in plaintext, when it is supposed to be encrypted.

No. The "blkfilter" mechanism should not affect the operation of blk-crypto.
It does not change the bio.
Only a module that has been attached and provides its own filtering algorithm,
such as blksnap, can violate the logic of blk-crypto.
Therefore, until the blksnap module is loaded, blk-crypto should work as before.