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 DFFEAC77B7A for ; Tue, 13 Jun 2023 05:50:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234158AbjFMFub (ORCPT ); Tue, 13 Jun 2023 01:50:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53092 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240095AbjFMFu1 (ORCPT ); Tue, 13 Jun 2023 01:50:27 -0400 Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2607:7c80:54:3::133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 18C5693; Mon, 12 Jun 2023 22:50:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=pv13t75OeaLi0Wnedj8EISboR7Hj3/TyA2pQxdDC4e8=; b=hXcSNk2KPdcQyfjrbkKlXoE5A8 zHE+DOIDMV94Qeo3me/ZgOieikMcg1ilrc+v5wbdLQ9JogD4Tp+qS4GVyG7b8qYngNk7BsRW5aLFb tF6rnwSpJ51d2rtfmaVN4nxRoZavhXjKNyyEMaMSFDaeFxlomjvwlAmZFXmPUtZaaAAorhnJBIm+H vblo1Smiv8csEcFKVVkhbdxBms8UhjBa35xnir36Rqty6Zt38WM/zYPriU2n5rYkNd6gXeWDW+X9R tGgf9hgo8YIeMREAWS7aGdCIMOh/tnWsg+y63di0f0e7kAWjMdnQ7L24EHgCMLczmFIF9jQXwmDb2 fN0lqz+Q==; Received: from hch by bombadil.infradead.org with local (Exim 4.96 #2 (Red Hat Linux)) id 1q8wuy-0070IZ-2V; Tue, 13 Jun 2023 05:50:12 +0000 Date: Mon, 12 Jun 2023 22:50:12 -0700 From: Christoph Hellwig To: Eric Biggers Cc: Sergei Shtepa , axboe@kernel.dk, hch@infradead.org, corbet@lwn.net, snitzer@kernel.org, viro@zeniv.linux.org.uk, brauner@kernel.org, dchinner@redhat.com, willy@infradead.org, dlemoal@kernel.org, linux@weissschuh.net, jack@suse.cz, ming.lei@redhat.com, linux-block@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH v5 00/11] blksnap - block devices snapshots module Message-ID: References: <20230612135228.10702-1-sergei.shtepa@veeam.com> <20230612161911.GA1200@sol.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230612161911.GA1200@sol.localdomain> X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org On Mon, Jun 12, 2023 at 09:19:11AM -0700, Eric Biggers wrote: > 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 > > 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. Yeah. Same for integrity. I guess for now the best would be to not allow attaching a filter to block devices that have encryption or integrity enabled and then look into that as a separate project fully reviewed by the respective experts.