Re: Xen 4.0.0x allows for data corruption in Dom0

[Joanna Rutkowska <joanna@invisiblethingslab.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2195 bytes --]

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@iki.fi> 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 #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 226 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel