From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Sina Bahram" Subject: RE: Implementing split memory in Xen is annoyingly hard? Date: Fri, 12 Dec 2008 10:42:46 -0500 Message-ID: References: <49423FAF.5020307@cs.ubc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <49423FAF.5020307@cs.ubc.ca> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: 'Christopher Head' , xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org Can I get yours and other thought son this paper? ftp://ftp.cs.wisc.edu/paradyn/papers/Rosenblum08cspm.pdf Similar in some sense to what we've spoke of below. Take care, Sina -----Original Message----- From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Christopher Head Sent: Friday, December 12, 2008 5:41 AM To: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] Implementing split memory in Xen is annoyingly hard? -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sina Bahram wrote: [snip] > One potential work around: > > I could mark every single page of the guest's kernel as NX, and then when > that fault happens, I could then be privy to all executes from within Xen. [snip] I can see three possible arrangements you might try: (1) leave the data mapped normally and handle execution specially, (2) leave code mapped normally and handle data specially, or (3) leave neither one mapped normally and handle both specially. As far as I can tell, solution 2 wouldn't work at all, solution 1 has a chance of working, and solution 3 is rather pointless if either of the other two works. I don't think it would work to leave code mapped normally and map data specially, because execute permission implies read permission and hence you cannot make a page executable without making it also readable. HOWEVER, I think #1 could work. The page is normally set as readable, writable, and not executable. When the guest attempts to execute the page, a fault occurs. Taking a cue from the PaX patches, we observe that there are two separate TLBs: one for code and one for data. If we can "prime" the code TLB with the proper execution mapping and then change the page table back to the regular data mapping, we'll be in business. In PaX, it's the data TLB that gets primed, which is trivially easy: just touch the page. Priming the code TLB looks rather more difficult, since you clearly have to execute something on that page in order to do so. However, you don't want to execute arbitrary guest code, because you need to be able to remap the page table back to the data page after priming the TLB! The only way I can think of to do this is to set up the mapping as code and then stuff a specially-chosen faulting instruction into the code page, saving what was previously there. Return to the guest with interrupts disabled (so there's no way for control to transfer anywhere except the jump target). The guest sees the page table set for the code page, loads the code TLB, and then immediately hits the faulting instruction. The hypervisor takes over, changes the pagetable mapping back to the data page, replaces the faulting instruction with what was originally there, and lets the guest carry on. The code TLB now having been primed, no additional page faults occur; further, since the pagetable has been reset, any data accesses will load the data TLB with the data page mapping. This sounds really intrusive though. Chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: GnuPT 2.7.2 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAklCP64ACgkQiD2svb/jCb5ICgCfV3z3jdiSpt54o7pzCj48mi/m 4wQAnjTJKPNSitFwBx/th+nsXFmR5gKF =I0hp -----END PGP SIGNATURE----- _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel