[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



> >>-- 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: signature.asc
Description: Digital signature

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.