WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Xen 4.0.0x allows for data corruption in Dom0

To: Daniel Stodden <daniel.stodden@xxxxxxxxxx>
Subject: Re: [Xen-devel] Xen 4.0.0x allows for data corruption in Dom0
From: Joanna Rutkowska <joanna@xxxxxxxxxxxxxxxxxxxxxx>
Date: Tue, 09 Mar 2010 00:56:22 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <Keir.Fraser@xxxxxxxxxxxxx>
Delivery-date: Mon, 08 Mar 2010 15:56:58 -0800
Dkim-signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=message-id:date:from:mime-version:to:cc:subject:references:in-reply-to:content-type; s=smtpout; bh=Y5uVmkt0WfTmE6Ry9ltpeGburqI=; b=PqTO++BeMQD+Bc3IFEfqsK9t4olfAu7hhk+JXx2UpHOYrlTz/sP73UbzWIKR6YsxiGsCpkxP0gPzwqMBUq+jrCIpTNNxauTGtqEIl3gG8zoNMoTKP4vJnXlCDtZ/XjYxSnlxps+aKsrKdIXWYBx1Jr9e+0pTilQmEIzzz501/jA=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1268092325.27980.318.camel@xxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20100307143631.GO2580@xxxxxxxxxxx> <C7B96B0D.C62C%keir.fraser@xxxxxxxxxxxxx> <20100307161256.GQ2580@xxxxxxxxxxx> <1268090552.27980.288.camel@xxxxxxxxxxxxxxxxxxxxxxx> <4B958896.4090004@xxxxxxxxxxxxxxxxxxxxxx> <1268092325.27980.318.camel@xxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.8) Gecko/20100301 Fedora/3.0.3-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.3
On 03/09/2010 12:52 AM, Daniel Stodden wrote:
> On Mon, 2010-03-08 at 18:30 -0500, Joanna Rutkowska wrote:
>> On 03/09/2010 12:22 AM, Daniel Stodden wrote:
>>> On Sun, 2010-03-07 at 11:12 -0500, Pasi Kärkkäinen wrote:
>>>> On Sun, Mar 07, 2010 at 02:39:09PM +0000, Keir Fraser wrote:
>>>>> On 07/03/2010 14:36, "Pasi Kärkkäinen" <pasik@xxxxxx> wrote:
>>>>>
>>>>>>> Tried a few times and no luck reproducing so far. I hope some other 
>>>>>>> people
>>>>>>> on the list also will give it a go, since it's so easy to try it out.
>>>>>>>
>>>>>>
>>>>>> I'm able to reproduce this with xen/master 2.6.31.6 dom0 kernel (from
>>>>>> 2010-02-20),
>>>>>> but I'm not able to reproduce it with the current xen/stable 2.6.32.9.
>>>>>>
>>>>>> I'll try with the most recent 2.6.31.6 dom0 kernel aswell..
>>>>>
>>>>> Thanks Pasi!
>>>>>
>>>>
>>>> It seems to happen with the latest xen/master 2.6.31.6 aswell!
>>>
>>> Does this look to you like we're corrupting memory or on-disk storage?
>>>
>>> E.g. does a
>>> $ dd if=/dev/zero bs=1M | hexdump -C 
>>> have the same issue?
>>>
>>
>> I think there might be a chance that the above executes correctly, even
>> if we have memory corruption -- this might be e.g. because the actual
>> "dest" buffer here would be much smaller than the fs cache buffer used
>> when we copy onto disk. And so our small dest buffer might just not be
>> so likely to be hit with this presumably random corruption.
>>
>> Perhaps dd'ing onto /dev/shm would be a better way to check this?
> 
> I agree that a negative doesn't mean much. I'm just poking around there
> because the positive would have mattered: If we still get to see it,
> we're out of the storage discussion and can focus on memory corruption.
> 

If you're thinking about a potential Dom0 disk-driver problem, then I
think we can rule this out. This is because I have tried this on both
encrypted and non-encrypted filesystems, but the pattern of corruptions
was exactly the same. If the disk driver was feeding LUKS (the crypto
driver) with a wrong data, the corruptions would definitely look
differently.

I also tried ext4 and ext3 filesystems, but same results.

j.


Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
<Prev in Thread] Current Thread [Next in Thread>