[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] GNTTAB_copy
> This patch is required even for a "copy via grant reference" mechanism. > Patch contains changes to support both gmfn and gref copies. I'd guess you're referring to this hunk? > *** /home/vduvvuru/xen-3.3.0/xen/common/grant_table.c 2008-12-19 > 19:41:28.000000000 +0530 > --- xen/common/grant_table.c 2009-02-02 21:38:23.000000000 +0530 > *************** > *** 1300,1313 **** > for ( ; ; ) > { > /* If not already pinned, check the grant domid and type. */ > ! if ( !act->pin && > (((scombo.shorts.flags & GTF_type_mask) != > GTF_permit_access) || > (scombo.shorts.domid != current->domain->domain_id)) ) > PIN_FAIL(unlock_out, GNTST_general_error, > "Bad flags (%x) or dom (%d). (expected dom %d)\n", > scombo.shorts.flags, scombo.shorts.domid, > current->domain->domain_id); > > new_scombo = scombo; > new_scombo.shorts.flags |= GTF_reading; > --- 1301,1317 ---- > for ( ; ; ) > { > /* If not already pinned, check the grant domid and type. */ > ! /* if ( !act->pin && > (((scombo.shorts.flags & GTF_type_mask) != > GTF_permit_access) || > (scombo.shorts.domid != current->domain->domain_id)) ) > + { > + gdprintk(XENLOG_INFO, "Grant entry Info \n Domid=%d, Flags=%d, > Frame=%d\n",sha->domid,sha->flags,sha->frame); > PIN_FAIL(unlock_out, GNTST_general_error, > "Bad flags (%x) or dom (%d). (expected dom %d)\n", > scombo.shorts.flags, scombo.shorts.domid, > current->domain->domain_id); > + }*/ > > new_scombo = scombo; > new_scombo.shorts.flags |= GTF_reading; This effectively turns off access checking on grant references used in a copy operation, so that any domain is able to access any grant reference, regardless of who the granting domain originally granted access to. That's obviously not ideal from a security point of view. Are you sure you're setting up the grants correctly, and granting access to the right domain? Steven. > -----Original Message----- > From: Steven Smith [mailto:steven.smith@xxxxxxxxxx] > Sent: Thursday, February 05, 2009 4:38 PM > To: Kumar, Venkat > Cc: Steven Smith; xen-devel@xxxxxxxxxxxxxxxxxxx > Subject: Re: [Xen-devel] GNTTAB_copy > > > > Please find the patches attached with this email. > > > > The changes you are interested are in grant_table.patch > Ah, okay. It looks from the patch as if you're using the grant copy > hypercall to do direct MFN-to-MFN copies across a domain boundary, > without any actual grant references getting in the way. Is that > correct? If so, you may want to re-think your design; grant > references are Xen's principle access control mechanism for memory, > and if you're not using them then it's likely to be difficult to make > your design suitably secure. > > (Of course, if this is just a research prototype, you may decide you > don't care about such things, in which case best of luck to you.) > > Steven. > > > > -----Original Message----- > > From: Steven Smith [mailto:steven.smith@xxxxxxxxxx] > > Sent: Thursday, February 05, 2009 4:13 PM > > To: Kumar, Venkat > > Cc: Steven Smith; xen-devel@xxxxxxxxxxxxxxxxxxx > > Subject: Re: [Xen-devel] GNTTAB_copy > > > > > > > > > Atlast it worked out. I had to make some changes in Xen (it wasn't > > > > > allowing a copy across domains) to make it work apart from the patch > > > > > you sent. > > > > That's odd. Would you mind sending me your patch, please, so that I > > > > can see what's wrong with the existing implementation? > > > > > > > > Steven. > > > > > > > > > > > > > -----Original Message----- > > > > > From: Steven Smith [mailto:steven.smith@xxxxxxxxxx] > > > > > Sent: Friday, January 30, 2009 10:04 PM > > > > > To: Kumar, Venkat > > > > > Cc: Steven Smith; xen-devel@xxxxxxxxxxxxxxxxxxx > > > > > Subject: Re: [Xen-devel] GNTTAB_copy > > > > > > > > > > > Steve, > > > > > > > > > > > > I have ported the GNTTAB_copy part from netchannel2 xen-unstable to > > > > xen-unstable. But the hypercall is failing with a status -1. > > > > > > > > > > > > xm dmesg says > > > > > > =========================================== > > > > > > Bad flags (0) or dom (0). (expected dom 9) > > > > > > =========================================== > > > > > Okay, so Xen started processing the grant table operation, but found > > > > > that the grant entry in the granting domain's grant table was bad > > > > > (because it was full of zeroes). That probably indicates that it was > > > > > accessing completely the wrong gref. > > > > > > > > > > > I am granting the page with a flag ( GTF_reading | GTF_writing & > > > > GTF_permit_access ) but still it did not work. > > > > > > > > > > > > What could be wrong here? > > > > > I'm not sure. I'd suggest you put some printks in your guests (both > > > > > the granting one and the HVM one) to make sure that they agree on the > > > > > grant reference number, and some in Xen to make sure that it's reading > > > > > the hypercall arguments correctly. > > > > > > > > > > Steven. > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Steven Smith [mailto:steven.smith@xxxxxxxxxx] > > > > > > Sent: Friday, January 30, 2009 4:52 PM > > > > > > To: Kumar, Venkat > > > > > > Cc: Steven Smith; xen-devel@xxxxxxxxxxxxxxxxxxx > > > > > > Subject: Re: [Xen-devel] GNTTAB_copy > > > > > > > > > > > > That's unfortunate; the repository works fine for me. > > > > > > > > > > > > There aren't any other ways of downloading the entire repository, but > > > > > > the changes you need to make are pretty self-contained, so I've > > > > > > attached the relevant cset. You'll need to get rid of the > > > > > > GNTTABOP_set_version bits, but apart from that it should all be fairly > > > > > > obvious. > > > > > > > > > > > > Steven. > > > > > > > > > > > > > > > > > > > Steven - Thanks for the pointer. > > > > > > > I get an error while downloading the code. > > > > > > > > > > > > > > ======================================================================= > > > > > > > hg clone http://xenbits.xensource.com/ext/netchannel2/xen-unstable.hg > > > > > > > destination directory: xen-unstable.hg > > > > > > > requesting all changes > > > > > > > adding changesets > > > > > > > transaction abort! > > > > > > > rollback completed > > > > > > > abort: Connection reset by peer > > > > > > > ======================================================================= > > > > > > > > > > > > > > Do you know any alternate download? > > > > > > > > > > > > > > Venkat > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Steven Smith [mailto:steven.smith@xxxxxxxxxx] > > > > > > > Sent: Friday, January 30, 2009 4:18 PM > > > > > > > To: Kumar, Venkat > > > > > > > Cc: xen-devel@xxxxxxxxxxxxxxxxxxx > > > > > > > Subject: Re: [Xen-devel] GNTTAB_copy > > > > > > > > > > > > > > > Is GNTTAB_copy command in the Hypercall "HYPERVISOR_grant_table_op" > > > > > > > > supported between two HVM's? > > > > > > > It's not in xen-unstable, no, but it is if you use the netchannel2 > > > > > > > hypervisor (available from > > > > > > > http://xenbits.xensource.com/ext/netchannel2/xen-unstable.hg). It'd > > > > > > > be pretty easy to cross-port, if you wanted to have a go at that. The > > > > > > > interesting cset is this one: > > > > > > > > > > > > > > changeset: 19112:ea4b9c439ac3 > > > > > > > user: Steven Smith <steven.smith@xxxxxxxxxxxxx> > > > > > > > date: Thu Jan 22 09:53:12 2009 +0000 > > > > > > > files: xen/arch/x86/hvm/hvm.c xen/include/xen/hypercall.h > > > > > > > description: > > > > > > > Allow GNTABOP_copy to be used from HVM domains. > > > > > > > > > > > > > > Steven. > > > > Attachment:
signature.asc _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |