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

[Anthony Liguori <aliguori@xxxxxxxxxxxxx>]

Markus Armbruster wrote:
> > -- 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?  And where else in Xen are we safe from this? :-)
> > -- 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.

> > > +                       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 :-)
> >                  What happens if someone has a four, five, six button
> > mouse?
> >     
>   
> > Irritatingly, map_foreign_batch doesn't actually return success or
> > failure through its return value, but by setting the high bits on the
> > failed entry in the array you pass in.  If the array is mapped
> > readonly, or is shared with a remote domain, there's no way to detect
> > failure.
> >     
> Sounds like a design flaw to me.
>   
Wow.

Thanks again Markus for taking on this code!  I hope it's not too 
painful :-)
Regards,

Anthony Liguori

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