As far as I know/understand:

* At start, all the PCI devices are assigned to dom0.
* When a qube with an attached PCI device starts, dom0 assigns the PCI device 
to the qube, so it is no longer attached to dom0. It never gets actually 
attached to dom0 automatically (until reboot). If it was, a malicious qube 
could for example flash a malicious firmware to a USB device and shut down in 
order to connect the malicious device to dom0.
* In order to have some additional protection, rd.qubes.hide_all_usb hides all 
USB devices. That is, the USB PCI device is attached to dom0, but Linux ignores 
it, maybe it blacklists related kernel modules.

The behavior you have observed suggests that both detached USB controller and 
ignored USB controller cause an issue. So, maybe the problem is not in the 
process of detaching a controller that is being used, but rather in not having 
the controller available.

Intel includes some USB controller in CPU and quick Googling suggests that so 
does AMD. Maybe there is some AMD-specific code in Linux kernel that expects 
the USB controller to be available for whatever weird reason. Yes, it sounds 
strange, but it is the least implausible explanation I was able to find.

Regards,
Vít Šesták 'v6ak'

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/744c4e79-efef-475a-a3dd-41fd3ded10b3%40googlegroups.com.

Reply via email to