From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jacob Gorm Hansen Subject: Re: Fw: Xen on /. again Date: Thu, 20 Jan 2005 15:30:32 -0800 Message-ID: <41F03F18.4060204@diku.dk> References: <41F02C8B.5010304@diku.dk> <200501202241.06631.maw48@cl.cam.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <200501202241.06631.maw48@cl.cam.ac.uk> Sender: xen-devel-admin@lists.sourceforge.net Errors-To: xen-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: Mark Williamson Cc: Xen-devel@lists.sourceforge.net List-Id: xen-devel@lists.xenproject.org Mark Williamson wrote: > Well domains are not aware of each other's memory usage, so I wouldn't have > thought that allocation / exposing real page tables would matter. (Except > dom0 can of course see everything if it wants). Microkernel people like to make the argument that you could create a low-bandwidth covert channel by systematically allocating and freeing a set of pages, and because domains see real page frame numbers they can learn the state of the other guy by looking at what pages they get in return from an alloc call. I suppose you could randomize the page-allocator, but then you will have to leave a certain amount of pages unused at all times, to have enough random pages to choose from. (For myself, I would much rather have the real page tables and find a way to live with the covert channels, but I am not building military-grade systems). Jacob ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl