This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] create shadow pages

To: Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Subject: Re: [Xen-devel] create shadow pages
From: ding baozeng <baozengding@xxxxxxxxx>
Date: Thu, 11 Nov 2010 16:43:47 +0800
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 11 Nov 2010 00:44:38 -0800
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=agJLMC4yoQ/QzsULGk2AkByEkhvbreZHRJiFIh25h00=; b=f0fUS5OFVejaA3CXIuyKQtsOnIZKyTAzUBnZMsWrPG9so4haS55onwibwPMNemMzXy KNiGkFbu29qzYMLTNFMVBp+8GPuhJFOGz08prHw0rjR0in7T2oDoPH21bNxR47diNUve omIVPomppnlrJIowmS3hjLepQEDajPTZqwlDw=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=hvh8Up2IKmfJhhOxhCg5X9eJot4BIuh+ep4P807o/0MqePb7sucOLDfo1QNfJ80j+s WjS2l11oxaWuGWp7HP2aDg75cSGOTFORqOFxFkkQ0YF0YUwVcxl1vjcF3ni7x5iaTDbH PRpG2ENw1fRRHBNoya7uDRWaxE9UicA956dIA=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <AANLkTi=3GiTwOpRuckTsJV0ehOtkuT4u2ViQ94LF1pBT@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <AANLkTim3OqBOcw2KtpT9rfNj5ZKuqcBup3tJktCmddJc@xxxxxxxxxxxxxx> <20101104124401.GH11016@xxxxxxxxxxxxxxxxxxxxxxx> <AANLkTinEcDcEOcALoTRss7PBWQ67XFj+=Cj3mgbeo9o=@xxxxxxxxxxxxxx> <20101105102510.GI11016@xxxxxxxxxxxxxxxxxxxxxxx> <AANLkTi=hHcqrhvqA=vDcpthUd3WinFpHpadX6vRmt=x_@xxxxxxxxxxxxxx> <20101105120900.GJ11016@xxxxxxxxxxxxxxxxxxxxxxx> <AANLkTi=3GiTwOpRuckTsJV0ehOtkuT4u2ViQ94LF1pBT@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
   I wrote a module test.c in hvm domU, simple as the following:
  struct page * pg;
  unsigned long *vaddr;
  pg = alloc_pages(GFP_HIGHUSER, 1);
  if (!pg) return 0;
  vaddr = page_address(pg);
  if (!vaddr) return 0;
  printk("The address allocated is %lx\n", (unsigned long)vaddr);
  printk("The value at the address is %lx\n", *vaddr);
  __free_pages(pg, 1);
 return 1;
After compile and insmod the module, the result is:
The address allocated is fab3d000;
 The value at the address is 3125
 I have a few questions about it:
As we could obtain the value at the address fab3d000, does that means the shadow pages for it has been built? When is the shadow page for the built, at "alloc_pages" or "page_address " or is not built at all?

Best  Regards,
                           Baozeng  Ding

2010/11/6 ding baozeng <baozengding@xxxxxxxxx>

2010/11/5 Tim Deegan <Tim.Deegan@xxxxxxxxxx>

At 11:42 +0000 on 05 Nov (1288957359), ding baozeng wrote:
> I use the SPT to obtain security effect and the overhead is also
> small. I would disable EPT. When putting the security code in-vm, I
> further use the VT-d technology, CR3_TARGET_LIST to decrease the
> overhead. As we know, when processes switch, it would update CR3, and
> so trap into xen, which bring up a lot of overhead.  But after we
> write the value of CR3 into the CR3_TARGET_LIST, it would not trap
> into xen when process switch. So I would create another address space
> to put the security code and put the address of its shadow page into
> CR3_TARGET_LIST. (when you have time, please take look at the paper in
> attachment, thx)

I've read the paper ("Secure In-VM Monitoring Using Hardware
Virtualization", from Proc. CCS '09, for anyone reading along) and the
thing they do there will be difficult in the Xen shadow pagetables
because Xen shadows individual frames of memory rather than %CR3 values,
so if the guest kernel shares pagetables between the secure and
non-secure %CR3s they will always see exactly the same mappings in the
We do not share pagetables. Is it possible that we just create our own shadow pagetables for SIM address space?(The guest pagetables for SIM may be not needed). This may consume some memory in xen, but i think it is a way to implement it. If it is possible, how to implement it?
It would take quite a lot of work to make Xen's shadow pagetables treat
one process differently from all the others.  Have you tried asking the
authors for their KVM code?
I asked, but they said their code is not opened. 



Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Principal Software Engineer, Xen Platform Team
Citrix Systems UK Ltd.  (Company #02937203, SL9 0BG)

Xen-devel mailing list