|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Xen 4.0.0x allows for data corruption in Dom0
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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |