From mboxrd@z Thu Jan  1 00:00:00 1970
From: Anthony Liguori <aliguori@cs.utexas.edu>
Subject: Re: [PATCH] Paravirt framebuffer backend tools [2/5]
Date: Wed, 04 Oct 2006 09:57:56 -0500
Message-ID: <4523CBF4.6060703@cs.utexas.edu>
References: <20060904090150.GC4812@cam.ac.uk>	<87y7s168k2.fsf@pike.pond.sub.org>
	<20061002090145.GA3576@cam.ac.uk>
	<87y7rwyy6q.fsf@pike.pond.sub.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xensource.com>
In-Reply-To: <87y7rwyy6q.fsf@pike.pond.sub.org>
List-Unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com
To: Markus Armbruster <armbru@redhat.com>
Cc: aliguori <aliguori@mail.utexas.edu>, Jeremy Katz <katzj@redhat.com>, xen-devel <xen-devel@lists.xensource.com>, sos22@srcf.ucam.org
List-Id: xen-devel@lists.xenproject.org

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