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

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

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

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

Sounds like a design flaw to me.


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


Anthony Liguori

Xen-devel mailing list



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