From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joanna Rutkowska Subject: Re: Xen 4.0.0x allows for data corruption in Dom0 Date: Tue, 09 Mar 2010 01:20:57 +0100 Message-ID: <4B959469.7000002@invisiblethingslab.com> References: <4B922A89.2060105@invisiblethingslab.com><4B957914.4050408@goop.org><4B957B93.4060401@invisiblethingslab.com><4B958475.3050407@goop.org> <4B9586E0.2060005@invisiblethingslab.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0832674935==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: James Harper Cc: Jeremy Fitzhardinge , xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0832674935== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2B31D4AA496C04CC5A755582" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2B31D4AA496C04CC5A755582 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 03/09/2010 01:18 AM, James Harper wrote: >>> I can't think of a Xen failure-mode which would cause these symptoms >>> without also being massively obvious in other cases. (But "I can't >>> think of..." is where all the best bugs hide.) >>> >> >> But the corruptions always happen in 32-bytes chunks, which might >> suggest it's not a page-related problem (e.g. wrongly re-used page), > as >> in that case we would be observing (at least sometimes) much bigger >> chunks of corrupted data, I think. >=20 > Based on your hex dump output, it appears to be the first 32 bytes of a= > page, which does lend itself to the idea that it's a page allocated for= > something with only the first 32 bytes used. >=20 > You've stated that you are no longer set up to reproduce it, which is > unfortunate. If you find yourself in a position to try it again there > are bunch of things you could try to figure out on which end of the cop= y > the problem lies. >=20 But everybody can try it with the kernels I provided, right? I'm not the only one person, who can do this... j. --------------enig2B31D4AA496C04CC5A755582 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkuVlGkACgkQORdkotfEW84afgCg3E1uUlOj7cQxk7Iv3B13S6YF 0GIAoOUJ/pE8a13FWm+yqd5I1e0S/gmx =T3FO -----END PGP SIGNATURE----- --------------enig2B31D4AA496C04CC5A755582-- --===============0832674935== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0832674935==--