From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steven Smith Subject: Re: [PATCH] Paravirt framebuffer backend tools [2/5] Date: Thu, 5 Oct 2006 19:41:06 +0100 Message-ID: <20061005184106.GC4998@cam.ac.uk> References: <20060904090150.GC4812@cam.ac.uk> <87y7s168k2.fsf@pike.pond.sub.org> <20061002090145.GA3576@cam.ac.uk> <87y7rwyy6q.fsf@pike.pond.sub.org> <4523CBF4.6060703@cs.utexas.edu> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0303987556==" Return-path: In-Reply-To: <4523CBF4.6060703@cs.utexas.edu> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Mime-version: 1.0 Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Anthony Liguori Cc: xen-devel , Jeremy Katz , aliguori , Markus Armbruster , sos22@srcf.ucam.org List-Id: xen-devel@lists.xenproject.org --===============0303987556== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Pk6IbRAofICFmK5e" Content-Disposition: inline --Pk6IbRAofICFmK5e Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > >>-- The backend still isn't proof against a malicious frontend. This > >> (might) mean that root in an unprivileged domain can get root in > >> dom0, which is a fairly major problem. Fixing this should be > >> fairly easy. > >> =20 > >Yes, this needs to be done. > Sorry if I missed this previously, but how could a malicious frontend=20 > attack a backend? This protocol places various bits of control data in a page shared between the the frontend and backend. The backend continues to read things like the resolution out of this buffer while it's operating, and I was worried that the frontend could cause the backend to misbehave by changing them while the buffer was live. > And where else in Xen are we safe from this? :-) In theory, everywhere, since frontends are explicitly not trusted code. If you know of any places in which a frontend can cause a backend to run arbitrary code, or panic, or anything like that then please report it as a bug. > >>-- The setup protocol doesn't look much like the normal xenbus state > >> machine. There may be a good reason for this, but I haven't heard > >> one yet. I know the standard way is badly documented and > >> non-trivial to understand from the existing implementations; sorry > >> about that. > This was written before we even had the xenbus state machine. Okay. > >>>+ case SDL_MOUSEBUTTONDOWN: > >>>+ case SDL_MOUSEBUTTONUP: > >>>+ xenfb_send_button(xenfb, > >>>+ event.type =3D=3D SDL_MOUSEBUTTONDOWN, > >>>+ 3 - event.button.button); > >>> =20 > >>Why 3 - button? > >> =20 > > > >Anthony speedcoding? %-} > > =20 > I never expected this code to see the light of day :-) >=20 > Seems like every UI toolkit uses a different ordering for mouse=20 > buttons. In this case, SDL stores them backwards :-) Okay. Steven. --Pk6IbRAofICFmK5e Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFJVHCO4S8/gLNrjcRAhIjAJ91bhUR4a7NmOvWYPBEGitHchTtjgCgwsGr LVtPOMzQetyMp0L3kCMpgwc= =h3CF -----END PGP SIGNATURE----- --Pk6IbRAofICFmK5e-- --===============0303987556== 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 --===============0303987556==--