concept to always use PV USB to avoid hardware contamination / Qubes installer itself using PV USB

[adrelanos]

The premise behind PVUSB is that one's USB stack could be or become compromised. In such situations, the main/rest of the system should not get in contact with the USB stack to prevention contamination, i.e. to prevent a compromised USB stack to compromise the full system. Therefore it is the goal to contain possible USB stack contamination by putting the USB stack into a specialized PV USB VM.

So far so good.

Given that premise it follows that the PV USB must consistently always be used.

• What in case the user reinstalls Qubes?
  • Qubes installer itself should be based on Qubes and using PVUSB. Otherwise the USB stack and all other hardware would run within the same kernel and cross contaminate.
  • Alternatively, Qubes installer should boot the system with the USB stack disabled. (USB stack disabled default, with an option to enable it boot menu if some users are forced to do so.)
• What in case of dualboot?
  • Qubes documentation should advice to abstain from using dualboot. One the user made the decision to use PVUSB it should be avoided to ever not use PVUSB. (Otherwise it would contaminate.)
• What in case of booting Live operating systems?
  • Qubes documentation should advice to avoid booting live operating systems such as for partitioning, S.M.A.R.T., hdd health checking, Tails and so forth should be avoided.
  • Alternatively, is it possible to reliably disable the USB stack in from grub boot menu so such Live operating systems could still be used?

[marmarek]

Generally good idea, but unfortunately impossible with the current hardware - namely lack of reliable trusted boot.
If you boot from USB, you don't have any place to verify boot code with. If your USB VM got compromised during installation, it can feed the installed with malicious packages. And you don't have any way to detect this, because public key used for verification come from the same source (that USB stick) and also can be replaced by compromised USB VM.
Implementation of this idea would require having some other way to reliably get verification key, without using the code from USB stick itself (or after some other verification of it).

In theory UEFI Secure Boot could be used, but in practice we don't consider it being trustworthy technology. For example: http://blog.cr4.sh/2016/06/exploring-and-exploiting-lenovo.html

[marmarek]

Generally good idea, but unfortunately impossible with the current hardware - namely lack of reliable trusted boot.
If you boot from USB, you don't have any place to verify boot code with. If your USB VM got compromised during installation, it can feed the installed with malicious packages. And you don't have any way to detect this, because public key used for verification come from the same source (that USB stick) and also can be replaced by compromised USB VM.
Implementation of this idea would require having some other way to reliably get verification key, without using the code from USB stick itself (or after some other verification of it).

In theory UEFI Secure Boot could be used, but in practice we don't consider it being trustworthy technology. For example: http://blog.cr4.sh/2016/06/exploring-and-exploiting-lenovo.html

[andrewdavidwong]

But there's still the matter of documenting this. For example, if it's feasible that USB controller firmware will become compromised while the USB controller is assigned to a USB qube (and persist across Qubes OS reinstallations), then we should (presumably) recommend against upgrading to new Qubes versions by reinstalling from an ISO on a USB drive. (Unfortunately, this probably leaves no reinstallation path available to laptops users who don't have non-USB optical drives.)

Similar guidance can (should?) be given regarding the use of live USB OSes on the same hardware as Qubes, as @adrelanos points out above.

[andrewdavidwong]

But there's still the matter of documenting this. For example, if it's feasible that USB controller firmware will become compromised while the USB controller is assigned to a USB qube (and persist across Qubes OS reinstallations), then we should (presumably) recommend against upgrading to new Qubes versions by reinstalling from an ISO on a USB drive. (Unfortunately, this probably leaves no reinstallation path available to laptops users who don't have non-USB optical drives.)

Similar guidance can (should?) be given regarding the use of live USB OSes on the same hardware as Qubes, as @adrelanos points out above.