external CD writer

[Olaf Klinke]

(Apologies for pestering this list with another newbie question.)

So I have this external DVD-RW drive (Asus SDRW-08U7M-U to be
specific). On my Debian stretch laptop, plugging in the USB drive
creates /dev/sr0 as well as several symlinks to it, e.g. /dev/cdrw,
/dev/dvd etc.

Plugging the drive into my Qubes desktop, I get notified of the
availability of this drive and can attach /dev/sr0 to a Debian buster
AppVM qube as /dev/xvdi. I can mount /dev/xvdi and read data from a CD
allright.

However, in contrast to my Debian laptop, brasero does not recognize
the drive as a writer, not even when I create the same /dev/cdrw
symlink. In addition to that, both commands
dvd+rw-mediainfo /dev/xvdi
cd-info -C /dev/xvdi
exit with an error (details below). Thus it seems that some crucial bit
did not get forwarded to/is not installed in the AppVM. Probably I'm
just lacking the knowledge how different writing to a CD is from
reading from CD, on the hardware level. Is there more to burning a CD
than a single block special device?

Any hints welcome.
Olaf


# dvd+rw-mediainfo /dev/xvdi
:-( unable to INQUIRY: Invalid argument
# cd-info -C /dev/xvdi
cd-info version 2.0.0 x86_64-pc-linux-gnu
Copyright (c) 2003-2005, 2007-2008, 2011-2015, 2017 R. Bernstein
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
CD location : /dev/xvdi
CD driver name: GNU/Linux
access mode: IOCTL

Error in getting drive hardware properties
Error in getting drive reading properties
Error in getting drive writing properties
__________________________________

Disc mode is listed as: Error in getting information
++ WARN: error in ioctl CDROMREADTOCHDR: Invalid argument

[dhorf-hfre...@hashmail.org]

On Sat, May 02, 2020 at 01:23:53AM +0200, Olaf Klinke wrote:
> just lacking the knowledge how different writing to a CD is from
> reading from CD, on the hardware level. Is there more to burning a CD
> than a single block special device?

try attaching it as a USB-device instead of a block device.
meaning "qvm-usb instead of qvm-block".
or "lower part instead of upper part of the device widget".

[Olaf Klinke]

On Sat, 2020-05-02 at 09:44 +0200, dhorf-hfre...@hashmail.org
wrote:

> On Sat, May 02, 2020 at 01:23:53AM +0200, Olaf Klinke wrote:
> > just lacking the knowledge how different writing to a CD is from
> > reading from CD, on the hardware level. Is there more to burning a
> > CD
> > than a single block special device?
>
> try attaching it as a USB-device instead of a block device.
> meaning "qvm-usb instead of qvm-block".

Thanks a lot, that might be the bit I was missing. Unfortunately qvm-
device does not seem to list any devices that are not attached to a VM,
so I have difficulties identifying the right name to use. When I attach
the drive to <domain>,
`qvm-device block list --all` yields
dom0:sr0 SDRW-08U7M () <domain> (read-only=yes, frontend-dev=xvdi)
After detaching, then trying
`qvm-device usb attach --verbose <domain> dom0:sr0` yields
qvm-device: error: backend vm 'dom0' doesn't expose device 'sr0'

I presume dom0 did not recognize the drive as a USB device and hence
refuses to attach as such? `qvm-usb` yields the empty list.

The usb-devices documentation recommends (or rather, lists as option)
to attach the PCI USB controller holding the external drive to a qube.
Following the procedure indeed results in brasero recognizing the drive
as writer. Thanks!
The only remaining question is: Did I buy a shitty drive or will any
external CD writer behave this way?

Olaf

[dhorf-hfre...@hashmail.org]

On Sat, May 02, 2020 at 11:01:06PM +0200, Olaf Klinke wrote:

> I presume dom0 did not recognize the drive as a USB device and hence
> refuses to attach as such? `qvm-usb` yields the empty list.

oh right, you just came full circle:
attaching USB devices is not going to work without a usbVM.

> The only remaining question is: Did I buy a shitty drive or will any
> external CD writer behave this way?

no, you just dont have your qubes setup properly.
once you have a sys-usb ... qvm-usb should work just fine.

for how to do that: see other thread. :P

[Olaf Klinke]

On Sat, 2020-05-02 at 23:25 +0200, dhorf-hfre...@hashmail.org
wrote:

> On Sat, May 02, 2020 at 11:01:06PM +0200, Olaf Klinke wrote:
>
> > I presume dom0 did not recognize the drive as a USB device and
> > hence
> > refuses to attach as such? `qvm-usb` yields the empty list.
>
> oh right, you just came full circle:
> attaching USB devices is not going to work without a usbVM.
>

Where in the documentation is that stated? The manpage of qvm-device
does not mention this. The only hint is that all examples of qvm-usb in
the documentation show sys-usb as backend.

>
> > The only remaining question is: Did I buy a shitty drive or will
> > any
> > external CD writer behave this way?
>
> no, you just dont have your qubes setup properly.
> once you have a sys-usb ... qvm-usb should work just fine.
>
> for how to do that: see other thread. :P
>
>
>

Okay, so let me try to get this straight, for the record.

1. USB generally is bad, it should be avoided or contained.
2. Putting the USB keyboard into one container together with other
untrusted USB devices is even worse, since whoever controls your
keyboard, controls your computer.
3. Putting the USB keyboard in a qube can and has locked users out of
their systems.
4. If possible, keep the input devices (and only those) attached to
dom0 while attaching all others to sys-usb.

Luckily I seem to have two USB controllers for my peripheral USB ports,
so I can easily separate input- from other USB-devices. Is (4)
possible/recommended? The documentation shows how to hide _all_ USB
controllers from dom0, so I assume one can also choose to hide _some_.

[dhorf-hfre...@hashmail.org]

On Mon, May 04, 2020 at 11:21:18PM +0200, Olaf Klinke wrote:

> Where in the documentation is that stated? The manpage of qvm-device
> does not mention this. The only hint is that all examples of qvm-usb in
> the documentation show sys-usb as backend.

for example in the documentation about usb devices:

https://www.qubes-os.org/doc/usb-devices/

"Note: you cannot pass through devices from dom0 (in other words: a USB
qube is required)."

> 3. Putting the USB keyboard in a qube can and has locked users out of
> their systems.

forgetting their luks passphrase and careless use of fdisk also can
and has locked people out of their systems.
doesnt mean we remove disk encryption or all tools that can write
to a disk in the wrong place.

disabling autostart for the usbvm that has your keyboard is a pretty
solid way to avoid locking yourself out hard.
and shooting your own foot with it every now and then tends to be
educational, just like remote administration of firewalls. :D

> 4. If possible, keep the input devices (and only those) attached to
> dom0 while attaching all others to sys-usb.

i would put _all_ usb controllers into usbvms, even the one(s) used
for privileged devices.
you still need to make sure that the kbd one is attached to dom0
during boot though.

> Luckily I seem to have two USB controllers for my peripheral USB ports,
> so I can easily separate input- from other USB-devices. Is (4)

i recommend you check if this is actualy the case.
there are some _really_ weird USB setups where it looks like different
controllers, but it is really just multiple pci devices on the same
physical controller. and usb devices plugged into the same usb port end
up on one or the other "controller" depending on speed negotiated.
my check would be to configure different usbvms for each controller,
then plug around some devices between physical ports and see in
which vm they end up, and keep notes on that.

> possible/recommended? The documentation shows how to hide _all_ USB
> controllers from dom0, so I assume one can also choose to hide _some_.

https://github.com/QubesOS/qubes-core-admin-linux/blob/master/dracut/modules.d/90qubes-pciback/qubes-pciback.sh

rd.qubes.hide_pci=01:23.3,05:67.8

google is hard? perhaps you should consult a data scientist or so? :P

[Manuel Amador (Rudd-O)]

On 02/05/2020 01.23, Olaf Klinke wrote:

(Apologies for pestering this list with another newbie question.)

So I have this external DVD-RW drive (Asus SDRW-08U7M-U to be
specific). On my Debian stretch laptop, plugging in the USB drive
creates /dev/sr0 as well as several symlinks to it, e.g. /dev/cdrw,
/dev/dvd etc.

Plugging the drive into my Qubes desktop, I get notified of the
availability of this drive and can attach /dev/sr0 to a Debian buster
AppVM qube as /dev/xvdi. I can mount /dev/xvdi and read data from a CD
allright. 

However, in contrast to my Debian laptop, brasero does not recognize
the drive as a writer, not even when I create the same /dev/cdrw
symlink. In addition to that, both commands 
dvd+rw-mediainfo /dev/xvdi
cd-info -C /dev/xvdi
exit with an error (details below). Thus it seems that some crucial bit
did not get forwarded to/is not installed in the AppVM. Probably I'm
just lacking the knowledge how different writing to a CD is from
reading from CD, on the hardware level. Is there more to burning a CD
than a single block special device?
 
Any hints welcome.
Olaf

You must attach your drive via USB to the target VM, rather than as a block device.  When attached as a block device, the Xen block device driver does not make your drive visible as a DVD/RW drive.

-- 
    Rudd-O
    http://rudd-o.com/

[Peter Funk]

dhorf-hfre...@hashmail.org wrote 05.05.2020 00:16:
...
> https://www.qubes-os.org/doc/usb-devices/
...

> there are some _really_ weird USB setups where it looks like different
> controllers, but it is really just multiple pci devices on the same
> physical controller. and usb devices plugged into the same usb port end
> up on one or the other "controller" depending on speed negotiated.
> my check would be to configure different usbvms for each controller,
> then plug around some devices between physical ports and see in
> which vm they end up, and keep notes on that.

I always thought that the column "Bus 00X" in the output of
the command ``lsusb`` shows me which controller chip a certain
device is connected to. For example I have an old external CHERRY
keyboard which I must connect using a PS/2 to USB adaptor to
my laptop because this machine from 2013 is lacking a PS/2
jack socket (which is probably even more true for more recent laptops)::

Bus 001 Device 015: ID 0a81:0205 Chesen Electronics Corp. PS/2 Keyboard+Mouse Adapter

A sys-usb VM which was not created by default during the install
of Qubes OS 4.0.1 at that time. I added one after my initial install.

I decided to put only the controllers of Bus 002 to Bus 004 into the
sys-usb VM. My only reason for the decision to leave Bus 001 out
was that I wanted to be able to enter the LUKS passphrase from the
external keyboard during boot.

This might have been a somewhat risky decision due to my lack
of knowledge at that time though.

After reading the document you pointed out in my citiation of your
post above I used these commands::

readlink /sys/bus/usb/devices/usb1
readlink /sys/bus/usb/devices/usb2
readlink /sys/bus/usb/devices/usb3
readlink /sys/bus/usb/devices/usb4

and discovered that both Bus 003 and Bus 004 are indeed connected to
the same controller which is on PCI 0000:00:14.0 in my case!

Luckily the ``Bus 001`` is exclusively used for the external keyboard.

Best Regards, Peter Funk
--
Peter Funk ✉:Oldenburger Str.86, 27777 Ganderkesee, Germany; 📱:+49-179-640-8878