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

[Anthony Liguori <aliguori@cs.utexas.edu>]

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