| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: Fw: [Xen-devel] Xen on /. again
> 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.
Oh, I suppose you could do this using the balloon driver to relinquish /
reclaim physical memory - I hadn't thought of that. You could just restrict
domain's ability to do these operations and retain the ability to see the
real page tables. Ballooning probably isn't that important...
The mechanisms for the network driver donating pages to the backend would be
the other place where restrictions might be needed in this respect.
> (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).
Yes, it's worth being able to limit these things as much as possible whilst
still retaining functionality - ideally I guess there'd be a sliding scale of
covert channel bandwidth vs. performance / functionality.
Cheers,
Mark
-------------------------------------------------------
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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel
|
|
|
| |
|
Home