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

Re: [Xen-devel] [PATCH] xen: add gntdev



On 05/12/12 14:11, Thor Lancelot Simon wrote:
> On Wed, Dec 05, 2012 at 11:20:06AM +0100, Roger Pau Monn? wrote:
>> On 05/12/12 11:15, Manuel Bouyer wrote:
>>> On Tue, Dec 04, 2012 at 03:07:39PM -0500, Thor Lancelot Simon wrote:
>>>> On Tue, Dec 04, 2012 at 04:26:19PM +0100, Roger Pau Monn? wrote:
>>>>>
>>>>> Independently of what we end up doing as default for handling raw file
>>>>> disks, could someone review this code?
>>>>>
>>>>> It's the first time I've done a device, so someone with more experience
>>>>> should review it.
>>>>
>>>> I am not sure I entirely follow what this code's doing, but it seems to
>>>> me it may allow arbitrary physical pages to be exposed to userspace
>>>> processes in dom0 -- or in a domU, albeit only if dom0 userspace says so.
>>>>
>>>> Is that a correct understanding of one of its effects?  If so, there's
>>>> a problem, since not being able to do precisely that is one important
>>>> assumption of the 4.4BSD security model.
>>>
>>> If I read it properly, It allows only to map pages that are part of a
>>> grant. You provide the ioctl a grant reference, and this is what
>>> the driver uses to find the physical pages. So it should be limited to
>>> pages that are referenced by a grant.
>>
>> Yes, it should be limited to grant pages, you are not able to map
>> arbitrary mfns.
> 
> So, can dom0 give away arbitrary physical pages to a domU which can
> then hand them back as a "grant", or is there other protection
> against that?  That was my concern.  I'm sorry I don't understand
> some of the fundamental terminology very well.

All this "grants" thing is done at the hypervisor level, the hypervisor
is the one that assigns and manages grant pages, so the Dom0 is only
able to map certain pages that the remote DomU has permited the Dom0 to
map, and all this is done using HYPERVISOR_grant_table_op calls.

The code that does this is already inside the NetBSD kernel (because it
is used by the backends inside the NetBSD kernel). What this patch does
is allowing userspace processes to also map this grants into their own
virtual address space.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

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