Linux-Fsdevel Archive on
 help / color / Atom feed
From: Milan Broz <>
To: Mikulas Patocka <>,
	Damien Le Moal <>
Cc: Jens Axboe <>,
	"" <>,
	Mike Snitzer <>,
	Johannes Thumshirn <>,
	"" <>,
	"" <>,
	Shinichiro Kawasaki <>,
	"" <>,
	"Martin K . Petersen" <>,
	"" <>,
	Christoph Hellwig <>
Subject: Re: [dm-devel] [PATCH v2 0/3] Fix dm-crypt zoned block device support
Date: Mon, 19 Apr 2021 16:31:39 +0200
Message-ID: <> (raw)
In-Reply-To: <>

On 19/04/2021 15:55, Mikulas Patocka wrote:
> On Mon, 19 Apr 2021, Damien Le Moal wrote:
>>> I would say that it is incompatible with all dm targets - even the linear 
>>> target is changing the sector number and so it may redirect the write 
>>> outside of the range specified in dm-table and cause corruption.
>> DM remapping of BIO sectors is zone compatible because target entries must be
>> zone aligned. In the case of zone append, the BIO sector always point to the
>> start sector of the target zone. DM sector remapping will remap that to another
>> zone start as all zones are the same size. No issue here. We extensively use
>> dm-linear for various test environment to reduce the size of the device tested
>> (to speed up tests). I am confident there are no problems there.
>>> Instead of complicating device mapper with imperfect support, I would just 
>>> disable REQ_OP_ZONE_APPEND on device mapper at all.
>> That was my initial approach, but for dm-crypt only since other targets that
>> support zoned devices are fine. However, this breaks zoned block device
>> requirement that zone append be supported so that users are presented with a
>> uniform interface for different devices. So while simple to do, disabling zone
>> append is far from ideal.
> So, we could enable it for the linear target and disable for all other 
> targets?
> I talked with Milan about it and he doesn't want to add more bloat to the 
> crypt target. I agree with him.

This is all fine even for dm-crypt IF the tweaking is unique for the sector position
(it can be something just derived from the sector offset in principle).

For FDE, we must never allow writing sectors to different positions with the same
tweak (IV) and key - there are real attacks based on this issue.

So zones can do any recalculation and reshuffling it wants if sector tweak
in dm-crypt is unique.
(Another solution would be to use different keys for different areas, but that
is not possible with dm-crypt or FDE in general, but fs encryption can do that.)

If you want dm-crypt to support zones properly, there is a need for emulation
of the real sector offset - because that is what IV expects now.

And I think such emulation should be in DM core, not in dm-crypt itself, because other
targets can need the same functionality (I guess that dm-integrity journal
has a problem with that already, Mikulas will know more).

For online reencryption we also use multiple targets in the table that dynamically moves
(linear combined with dm-crypt), so dm-crypt must support all commands as
dm-linear to make this work.

I hope I understand the problem correctly; all I want is to so avoid patching
the wrong place (dmcrypt crypto) because that problem will appear elsewhere later.
Also for security it would be nice to not add exceptions to encryption
code - it is always recipe for disaster.


      reply index

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-17  2:33 Damien Le Moal
2021-04-17  2:33 ` [PATCH v2 1/3] dm: Introduce zone append support control Damien Le Moal
2021-04-17  2:33 ` [PATCH v2 2/3] dm crypt: Fix zoned block device support Damien Le Moal
2021-04-17 10:39   ` Johannes Thumshirn
2021-04-18 11:00   ` [dm-devel] " Milan Broz
2021-04-17  2:33 ` [PATCH v2 3/3] zonefs: fix synchronous write to sequential zone files Damien Le Moal
2021-04-19  6:45   ` Christoph Hellwig
2021-04-19  7:08     ` Damien Le Moal
2021-04-19  7:10       ` Christoph Hellwig
2021-04-20  1:20     ` Douglas Gilbert
2021-04-20  1:35       ` Damien Le Moal
2021-04-19 12:52 ` [dm-devel] [PATCH v2 0/3] Fix dm-crypt zoned block device support Mikulas Patocka
2021-04-19 13:02   ` Damien Le Moal
2021-04-19 13:55     ` Mikulas Patocka
2021-04-19 14:31       ` Milan Broz [this message]

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-Fsdevel Archive on

Archives are clonable:
	git clone --mirror linux-fsdevel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-fsdevel linux-fsdevel/ \
	public-inbox-index linux-fsdevel

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone