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

On Mon, 2010-03-08 at 18:56 -0500, Joanna Rutkowska wrote:
> 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'm not considering the device drivers, rather everything on top of
that. Also I didn't understand the issue is present in dom0 by the time
I wrote that.

Still, it'd help to figure it of the corruption came in on the way up
from /dev/zero or down to the disk.

That dd crossing the page cache means it's still got a long way to go. 

For now I'm most of all glad to hear it's not in the backends, so far
thanks for that :o)

Daniel


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

<Prev in Thread] Current Thread [Next in Thread>