|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] Academic Project
I'm absolutely not sure I follow what you are trying to do, but if what you want to do is "hide" a device in a particular domain, and give the memory "behind" that device to the domain, then that is not likely to work. You can only "get to" memory hidden behind a PCI device if you can turn the PCI device off. Turning the device off is of course a valid option if the device is not needed at all by the system. If it is needed, then you have no option but to leave it enabled, and the physical memory behind the device will be hidden by the PCI device. There are certain memory controller chipsets (e.g. the memory controller integrated into the Athlon64/Opteron/etc models after Rev E or so) that have "hidden memory hoisting", which essentially means that you can tell the memory controller that "take the memory behind the PCI device in this range, and move it up a bit", which means that if you have (say) 4GB of RAM, and a PCI bus hole of 768MB, the system will appear to have memory from 0-3.25GB, then PCI devices for 0.75GB, and then another 0.75GB of RAM. -- Mats At 19:54 03/03/2009, dinesh chandrasekaran wrote: Can some one tell me how to go about achieving this. How to allocate real memory (which is behind a PCI device) to guests? I need to modify Xen source to achieve the above. where exactly in the source I should do so? Thanks, Dinesh C ---------- From: dinesh_chan8@xxxxxxxxxxx To: xen-devel@xxxxxxxxxxxxxxxxxxx Subject: [Xen-devel] Academic Project Date: Mon, 23 Feb 2009 22:11:53 +0530Absolutly. This could be achieved through xen hooks which informs the device about the currently scheduled domain.This would prevent the guest memory from compromised dom0. Dinesh C ---------- Date: Mon, 23 Feb 2009 11:16:22 -0500 Subject: Re: [Xen-devel] Academic Project From: zephyr.zhao@xxxxxxxxx To: dinesh_chan8@xxxxxxxxxxxOne more thing is that the device should be able to tell if the access is from the owner of protected domain or from others (like dom0). If the dom0 is compromised, it may mimic the request from that domU.WeimingOn Mon, Feb 23, 2009 at 11:07 AM, dinesh chandrasekaran <<mailto:dinesh_chan8@xxxxxxxxxxx>dinesh_chan8@xxxxxxxxxxx> wrote: Yes. It will appear to be another PCI device sitting between the CPU and guest memory.To achieve this I need to make sure that xen allocates guest memory from memory behind the crypto coprocessor.This is the implementation issue I need to solve to get the project going.I did try modifying common/memory.c : populate_physmap(), but I am afraid this is not the right place.Since I have allocate real memory to domU, I am clueless. Thanks, Dinesh C ---------- Date: Mon, 23 Feb 2009 10:44:34 -0500 Subject: Re: [Xen-devel] Academic Project From: <mailto:zephyr.zhao@xxxxxxxxx>zephyr.zhao@xxxxxxxxx To: <mailto:dinesh_chan8@xxxxxxxxxxx>dinesh_chan8@xxxxxxxxxxx CC: <mailto:xen-devel@xxxxxxxxxxxxxxxxxxx>xen-devel@xxxxxxxxxxxxxxxxxxxI'm curious about the crypto coprocessor. Does it work like a memory controller? So every memory read/write will be encrypted/decrypted by it?Thanks, WeimingOn Mon, Feb 23, 2009 at 10:31 AM, dinesh chandrasekaran <<mailto:dinesh_chan8@xxxxxxxxxxx>dinesh_chan8@xxxxxxxxxxx> wrote:---------- From: <mailto:dinesh_chan8@xxxxxxxxxxx>dinesh_chan8@xxxxxxxxxxx To: <mailto:michal@xxxxxxxxx>michal@xxxxxxxxx Subject: RE: [Xen-devel] Academic Project Date: Mon, 23 Feb 2009 00:46:01 +0530 Essentially, first step towards minimizing the trusted computing base.Assuming the VMM is not compromised (after a secure boot), domU doesnt have to trust dom0.For example, the following command issued from dom0 would dump the guest memory in dom0 hard disk, _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |