Burning a DVD with qubes-os / Storage domain implementation

[Sebastian Hültenschmidt]

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.

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.
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.

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.

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?

Best regards,

s.hueltenschmidt

[Joanna Rutkowska]

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.
>

Hello,

> 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
about it...

> 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
StorageVM).

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
recorder. Sorry.

> 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:

http://www.qubes-os.org/files/doc/arch-spec-0.3.pdf

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).

Cheers,
joanna.

[Sebastian Hültenschmidt]

On 06/09/12 00:25, Joanna Rutkowska wrote:

> 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.
>>
> Hello,
>
>> 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
> about it...

It seems Opticals are old fashioned, no one is using them here ;-)
To be honest, i usually switch the bay for a second ssd :D

>
>> 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 expected...

>> 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
> StorageVM).

or argumenting the other way around: in the_other_os you have to install
software to deny dvd recording, qubes-os has data-leak-prevention by
default :D

Yes, i remember i read that, so i was wondering how the first boot phase
would be done.
Really with a huge initrd?

> http://www.qubes-os.org/files/doc/arch-spec-0.3.pdf
>
> 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).
>
> Cheers,
> joanna.
>

Thanks for considering my remarks,

Best regards,

s.hueltenschmidt

[Radoslaw Szkodzinski]

On Sat, Jun 9, 2012 at 2:44 AM, Sebastian Hültenschmidt
<s.huelte...@kernel-consulting.de> wrote:
> On 06/09/12 00:25, Joanna Rutkowska wrote:
>>

>> On 06/09/12 02:00, Sebastian Hültenschmidt wrote:
>>> 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
>> about it...
>
> It seems Opticals are old fashioned, no one is using them here ;-)
> To be honest, i usually switch the bay for a second ssd :D

This could be possible using pvscsi soon.
I remember Konrad has a branch that might be useful to test and develop further:
https://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=shortlog;h=refs/heads/devel/xen-scsi.v1.0

You might want to test it right now regardless... assuming this builds
and/or is easy to forward port to 3.4.

--
Radosław Szkodziński