From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mail.saout.de (Postfix) with ESMTP for ; Sat, 19 Sep 2009 21:00:40 +0200 (CEST) Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n8JJ0dgn005536 for ; Sat, 19 Sep 2009 15:00:39 -0400 Received: from [10.36.8.19] (vpn2-8-19.ams2.redhat.com [10.36.8.19]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id n8JJ0WiF016454 for ; Sat, 19 Sep 2009 15:00:38 -0400 Message-ID: <4AB52A50.1060503@redhat.com> Date: Sat, 19 Sep 2009 21:00:32 +0200 From: Milan Broz MIME-Version: 1.0 References: <200909182039.44953.dmcrypt-list@tpesonen.net> <4AB3CE76.5040502@redhat.com> <20090919165148.GA5619@fancy-poultry.org> In-Reply-To: <20090919165148.GA5619@fancy-poultry.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dm-crypt] Question on LUKS master key digest and its effect on security List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de Heinz Diehl wrote: > On 18.09.2009, Milan Broz wrote: > > As reported some weeks ago, the buffer i/o errors are still present with > the latest svn code (from today): > > [....] > Sep 19 18:33:05 liesel kernel: Buffer I/O error on device dm-4, logical block 32 This is not cryptsetup bug but interference with badly written udev rules or programs reacting to uevents (like DeviceKit etc) which tries to open/scan temporary/keyslot cryptstetup devices (I see this messages too with dracut in Fedora). (In 1.0.7 was 1 sec timeout which was removed, that caused these messages to appear more often. But this timeout slowed down keyslot scan unnecessarily.) You can easily verify that - run command which produces this messages like cryptsetup luksOpen with --debug, and if you see WARNING: other process locked internal device ... it is this problem. These messages are ugly, but there is actually no problem - if cryptsetup detects that someone locks internal keyslot device by opening it (usually it is blkid), it remaps it to error target, so that program receives io errors on read and quickly closes it. (unfortunately kernel log this read error to syslog.) (I hope that udev problems will be solved soon by switching device-mapper to use udev directly and maintain its own, correctly written, rules.) Milan