linux-kernel - dm-crypt reordering BIOs across barriers?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 07 Jun 2013 23:47:33 -0400
From:	Richard Yao <ryao@...too.org>
To:	Kernel development list <linux-kernel@...r.kernel.org>
CC:	"gentoo-dev@...ts.gentoo.org" <gentoo-dev@...ts.gentoo.org>,
	kernel@...too.org, gentooligan@...il.com
Subject: dm-crypt reordering BIOs across barriers?

When you use dm-crypt, block IO requests to a dm-* device will invoke
dm_request_fn() -> map_request() -> crypt_map(). If a BIO is a write
barrier, crypt_map() will return DM_MAPIO_REMAPPED to map_request(),
which will immediately queue it to the device.

If a few dozen IOs are queued in rapid succession with multiple write
barriers, all write barriers will be executed before any actual write
BIOs occur because the write IOs will be processed asynchronously in a
work queue. Since the barriers will be long gone by the time the write
IOs are queued, they can be queued in any order.

Am I misunderstanding this or is dm-crypt ignoring proper write barrier
semantics?

Download attachment "signature.asc" of type "application/pgp-signature" (902 bytes)