[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] Implementing split memory in Xen is annoyingly hard?
I'm not trying to make the page executable but not readable, as long as I can trap all reads, that's all. I'll be implementing a split TLB which will handle the fact that all executes get shunted to a "split page". Another way of saying that is that if someone looks up a virtual address, it gets translated to one physical address if it's for read/writes and to another one for executes. Sure one can execute the page that is read/write and someone could read/write to the page that is execute, but it will never happen because I'd never translate it that way in my code. Btw, this completely eliminates anything like lisp, javascript, or anything else from running, as they run code they have written all the time, but that's why I only plan on doing it for kernel pages which don't write things that they then execute. Hope that's more clear, and is this possible, do you think, or is my summary in the original email accurate in that it can't be done easily in xen? Take care, Sina -----Original Message----- From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx] Sent: Friday, December 12, 2008 4:20 AM To: Sina Bahram; xen-devel@xxxxxxxxxxxxxxxxxxx; xen-research@xxxxxxxxxxxxxxxxxxx Subject: Re: [Xen-devel] Implementing split memory in Xen is annoyingly hard? On 12/12/2008 06:47, "Sina Bahram" <sbahram@xxxxxxxxx> wrote: > #2: Xen absolutely does not, (can not?), cause a fault or other VM exit to > be generated upon an execute or a read of a page. It's not possible to make a page executable but not readable, so indeed I think you're stumped there, unless you can work out a hackish way to desynchronise the iTLB and the dTLB (an operation not supported architecturally by x86 of course). -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |