<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
<br>
In my opinion, it's easier to lock down COM, such as running as
dedicated user. With XPCOM, it's even easier, as all XPCOM transport
logic is fully opensourced (and available in VBox tree),<br>
so one can perform even more complex logic to ensure protection.<br>
Generally, doing yet another frontend is feasible, but very time
consuming and giving no clear benefits. To get what it looks you
need, somewhat different approach is needed.<br>
Running multiple VMs will have no problems with kernel driver, no
matter which frontend you'll use.<br>
<br>
Nikolay<br>
<br>
10.05.2011 20:03, Ribhi Kamal пишет:
<blockquote
cite="mid:BANLkTi=5D=0cenzQ700OvGfD-W=jVtz-Ew@mail.gmail.com"
type="cite">Thanks,<br>
I think that in my case I will have two binaries and each is
responsible of starting a specific type of virtual machine.
Everything will be hard coded, the network interfaces, the ISO
location, guest controllers... etc<br>
<br>
I'm worried about starting two virtual machines at the same time,
is there going to be some conflicts when calling the kernel driver
(vboxdrv) ? I guess my question is, is there some danger from
starting two VMs using VBoxBFE (without COM)?<br>
<br>
Finally, does anyone know if Oracle has something similar to what
I'm doing -- No COM/XML? Money is not a problem (not yet anyway).
<br>
<br>
Thanks again<br>
<br>
<div class="gmail_quote">On Tue, May 10, 2011 at 9:10 AM, Alexey
Eromenko <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:al4321@gmail.com">al4321@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div class="im">On Tue, May 10, 2011 at 3:34 PM, Ribhi Kamal
<<a moz-do-not-send="true"
href="mailto:rbhkamal@gmail.com">rbhkamal@gmail.com</a>>
wrote:<br>
> The problem with COM (XPCOM too?) is that its very hard
to lock down.<br>
> Especially when %50+ of people run everything with
admin privs. So I'm<br>
> trying to reduce the attack vectors that can be done
from the host OS on the<br>
> virtualvbox installation it self.<br>
><br>
> Can you please explain a bit about the "VM
synchronization point" issue?<br>
<br>
</div>
"VM synchronization point" is a single host management layer.<br>
<br>
The biggest difference between Qemu and VirtualBox engines,
from<br>
programmer's point of view, is that if you write any program
for Qemu,<br>
you must reimplement management layer yourself.<br>
<br>
VirtualBox already provides single-host management layer (via<br>
VBoxSVC). Registered VMs. Each VM remembers it's parameters,
such as<br>
RAM, HDDs assigned, Network adapters (along with MAC
addresses),<br>
etc...<br>
<font color="#888888"><br>
--<br>
-Alexey Eromenko "Technologov"<br>
</font>
<div>
<div class="h5"><br>
_______________________________________________<br>
vbox-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:vbox-dev@virtualbox.org">vbox-dev@virtualbox.org</a><br>
<a moz-do-not-send="true"
href="http://vbox.innotek.de/mailman/listinfo/vbox-dev"
target="_blank">http://vbox.innotek.de/mailman/listinfo/vbox-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
-- Ribhi<br>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
vbox-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:vbox-dev@virtualbox.org">vbox-dev@virtualbox.org</a>
<a class="moz-txt-link-freetext" href="http://vbox.innotek.de/mailman/listinfo/vbox-dev">http://vbox.innotek.de/mailman/listinfo/vbox-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>