On 06/09/12 02:00, Sebastian Hültenschmidt wrote:
> Hi all,
> i am new to this list, so please let me know if i am making any mistakes.
> I am using qubes-os every day since Beta2 on an Lenovo Thinkpad W510
> with core I7 Q820, with proprietary Nvidia driver, you might add that to
> the HCL.
Nice to hear that :) HCL updated.
> Recently i wanted to burn a DVD and failed.
> Afaik the DVD is connected to the one and only SATA controller in that
> notebook. So it can not be passthrough-ed to a AppVM.
> The dom0 lacks software support for burning, data transfer to dom0 is
> cumberstone and not really what i want.
All correct. In fact we've been wondering when somebody will complain
> Apparently a storage domain will be the solution, if it would be
> equipped like an AppVM, with all software. As a ServiceVM it would not
> be possible again, if no special XEN commands / channels are developed.
It's unlikely that we would like to equip the StorageVM with any
user-controllable software, such as a DVD burning software...
> As of now i do not see any solution except using an external, usb DVD
> recorder and pass the according PCI-USB Controller to a AppVM.
A possible solution (easier to implement) would be if the block backend
supported DVD recorders interface. I'm not sure how complex is an
interface to a DVD recorder, but if it's not too complex, it might be a
somehow acceptable solution (of course, the price one pays is the
increasing of the attack surface over the dom0 backend, unless we had
Anyway, as of now (Qubes 1.0) we don't plan to support DVD burning.
Neither we plan to implement StorageVM anytime soon... And the best one
can do currently, as you suggested, is to use an USB-based external
> Anyway i wanted to understand the implementation of a storage domain.
> The concept, as i understand it, should be to centralize all storage
> related devices to one domain. So all PCI SATA controllers, USB
> controllers etc. get passed to the storage domain. All AppVM get their
> discs exported from that domain. All AppVM discs are encrypted, the
> storage domain is unaware of the keys, only the dom0 and the AppVM know
> their respective keys. What i dont understand is the boot proedure. The
> dom0 has to mount root from somewhere, basically the storage domain, as
> it own all storage. But dom0 has to start before the storage domain, no?
> The only solution i see is to boot the dom0 from its initrd, as it is
> available to grub on system start. The dom0 initrd must contain a kernel
> and initrd for the storage domain to boot. After the storage domain is
> available and exports the storage, dom0 might mount its root and
> continue the boot process. I am wildly guessing, but i can not imagine
> that this is the way it is planned, so i am curious how you plan to
> implement such a feature?
You're mostly on track, except that this scheme also requires some form
of trusted boot, such as Intel TXT, as otherwise it would make no sense
to separate StorageVM from Dom0 (and also that we need not only
encrypted, but also signed filesystems). This has been discussed more
thoroughly in the Qubes original architecture spec document, chapter 7:
I'm really sorry I cannot offer any viable solution (apart from buying
an USB based DVD recorder, but that you already figured out) -- it's
just that we have other priorities right now :/ (which currently are:
release of the "1.0" version, and the work on the Windows support).