| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
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
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
|
|
|
| |
|
Home