[vbox-dev] VirtualBox customized frontend support

[Klaus Espenlaub]

On 21.05.2014 15:56, quickbooks office wrote:
> Would be interesting to see the VirtualBox frontend GUI (the VirtualBox
> Manager GUI) using Qemu / Libvirt / KVM on the backend

Definitely not something into which we'll invest time :)

Would be a hell of a job to get all VM settings out of the VirtualBox 
API and convert it into whatever format some 3rd party virtualizer 
wants. Only to use the VirtualBox VM Manager...

> End result being I could use SecureBoot feature on the host  which only
> allows signed kernel modules from being loaded.
>
> Plus the kernel wont become 'tainted' with out of tree modules like
> vboxdrv etc.

We explained many times why we went this way (don't believe in forcing 
users to upgrade to get new features), and we keep the kernel module 
sources open. Sure, in the linux world everything outside the kernel is 
considered a 2nd class citizen, but upstreaming simply is no solution 
unless we'd immediately stop innovating.

In the much more controlled server virtualization world the pace of 
required kernel module functionality changes is definitely far lower. 
Not hinting that KVM is doing anything wrong, it's simply dealing with 
different requirements.

I've been always wondering why some Linux distros which are embracing 
UEFI Secure Boot go to far more extremes than Windows with regards to 
the acceptable signatures (essentially everything must be signed by a 
single key which only the distro owner has). Windows accepts drivers as 
long as they're signed by someone who has enough $$ to get the 
appropriate certificate from the short list of CAs which Microsoft gave 
the special privilege. Of course in the Linux world binary drivers 
aren't really possible, so we couldn't ship signed kernel modules which 
would work beyond the next kernel upgrade.

Sorry for going quite a bit off topic :)

Klaus
>
>
> On Tue, May 20, 2014 at 11:29 PM, Karoline Haus <karolinehaus at yahoo.de
> <mailto:karolinehaus at yahoo.de>> wrote:
>
>     Hi Klaus,
>
>     Thanks for your reply.
>
>     I'm not really building a "random" frontend. After all, it is fully
>     built into VBox and it even has a hardened profile. It is also
>     integrated into /usr/lib/virtualbox/VBox - I have a fully modified
>     VBox source code version to allow this. So you can see this frontend
>     as being trusted just as VBoxSDL. (In fact, even more, because it
>     has a much smaller code base :-)
>
>     If I added my frontend in MachineImpl.cpp, would that be sufficient
>     to make things work? Or does the SDK have to be modified as well?
>     (I'm using the Python API, for connecting to VBox, but I guess that
>     just goes through the same hooks as VBoxManage)
>
>     Thanks for your help,
>     Karoline
>
>     Klaus Espenlaub <klaus.espenlaub at oracle.com
>     <mailto:klaus.espenlaub at oracle.com>> schrieb am 15:17 Dienstag,
>     20.Mai 2014:
>
>
>     Karoline,
>
>     On 20.05.2014 07:23, Karoline Haus wrote:
>      > Hi,
>      > I’ve developed a custom VBox graphics frontend, replacing VBoxSDL or
>      > VBoxHeadless. It’s working well when I call it from the command line
>      > using “VBoxMyFrontend –startvm VM” and so on. I have built the
>     frontend
>      > my modifying the VBox source code which I downloaded from the
>     official
>      > website. Here I have added another frontend under src/VBox/Frontends
>      > where I now have a folder VBoxMyFrontend. The compilation works
>     fine and
>      > as I said I can start the frontend as well.
>
>     Sounds good so far, everything as expected.
>
>      > Now what does not work is to start the VM using VBoxManage when I
>     try to
>      > set the default frontend of that VM to my own one. Like this:
>      > # VBoxManage modifyvm Test2 --defaultfrontend MyFrontend
>      > # VBoxManage startvm Test2
>      > VBoxManage: error: Invalid frontend name: 'MyFrontend'
>      > VBoxManage: error: Details: code NS_ERROR_INVALID_ARG (0x80070057),
>      > component Machine, interface IMachine, callee nsISupports
>      > VBoxManage: error: Context: "LaunchVMProcess(a->session,
>      > sessionType.raw(), env.raw(), progress.asOutParam())" at line 592 of
>      > file VBoxManageMisc.cpp
>
>     Again this is expected behavior... the "defaultfrontend" setting isn't
>     sanity checked immediately, but it is matched against a list of known
>     frontends which today can't be extended:
>     "gui", "GUI/Qt": start VirtualBox
>     "sdl", "GUI/SDL": start VBoxSDL
>     "headless", "capture", "vrdp": start VBoxHeadless
>
>     If you search for those strings in MachineImpl.cpp you'll find the code
>     which triggers the launching of a VM process.
>
>     Note that this code deliberately doesn't allow starting random
>     executables - who knows, someone might manage to construct a security
>     issue out of it. Even starting random executables from the VirtualBox
>     subdirectory can be used to cause trouble.
>
>     That said - if you have a good idea how to make it more flexible
>     without
>     completely ignoring the potentially dangerous start of random things,
>     let us know. We're interested, for exactly the reason you need it: to
>     allow people to implement their own frontends.
>
>      > How can I make this work, and register my frontend with
>     VBoxManage? Is
>      > this possible at all, or would I have to change the VBox API bindings
>      > somewhere?
>
>     No support for this yet, as described...
>
>     Klaus
>
>      > Any help would be greatly appreciated.
>      > Thanks!