Re: [PATCH] Paravirt framebuffer backend tools [2/5]

[Steven Smith <sos22-xen@srcf.ucam.org>]

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

> >>-- 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.
> >>    
> >Yes, this needs to be done.
> Sorry if I missed this previously, but how could a malicious frontend 
> 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 == SDL_MOUSEBUTTONDOWN,
> >>>+					3 - event.button.button);
> >>>      
> >>Why 3 - button?
> >>    
> >
> >Anthony speedcoding?  %-}
> >  
> I never expected this code to see the light of day :-)
> 
> Seems like every UI toolkit uses a different ordering for mouse 
> buttons.  In this case, SDL stores them backwards :-)
Okay.

Steven.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

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