linux-kernel - Re: [gentoo-dev] 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-prev] [day] [month] [year] [list]

Date:	Sat, 08 Jun 2013 05:17:08 -0400
From:	Richard Yao <ryao@...too.org>
To:	gentoo-dev@...ts.gentoo.org
CC:	Sergei Trofimovich <slyfox@...too.org>,
	Kernel development list <linux-kernel@...r.kernel.org>,
	kernel@...too.org, gentooligan@...il.com
Subject: Re: [gentoo-dev] dm-crypt reordering BIOs across barriers?

On 06/08/2013 02:11 AM, Sergei Trofimovich wrote:
> On Fri, 07 Jun 2013 23:47:33 -0400
> Richard Yao <ryao@...too.org> wrote:
> 
>> 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?
>>
> http://www.saout.de/pipermail/dm-crypt/2012-April/002441.html
> http://lwn.net/Articles/400541/
> 

It might be worth stating that I thought flush was a synonym for
barrier. It still looks like there is an issue, despite my incorrect
terminology.


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