|
|
|
|
|
|
|
|
|
|
xen-devel
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.
signature.asc
Description: Digital signature
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|