---- On Tue, 18 Jun 2019 18:40:34 -0700 awokd <[email protected]> wrote ---- > npdflr: > > ---- On Mon, 17 Jun 2019 18:13:02 -0700 'awokd' via qubes-users > > <[email protected]> wrote ---- > > > 'npdflr' via qubes-users: > > > > Hello all, > > > > As stated in the link: > > https://wiki.xen.org/wiki/Xen_PCI_Passthrough#How_can_I_check_if_PCI_device_supports_FLR_.28Function_Level_Reset.29_.3F > > > > "For checking if PCI device supports FLR (Function Level Reset) one > > has to Run "lspci -vv" (in dom0) and check if the device has "FLReset+" in > > the DevCap field" > > > > > > > > Does one have to attach a pci device to dom0 to run the command > > "lspci -vv"? If yes, then would there be any security issues because PCI > > devices are to be attached to domU (guests). [except some of them which > > are strictly required in dom0 (e.g., the host bridge) as stated in: > > https://www.qubes-os.org/doc/pci-devices/ ] > > > > > > > > Please correct me if I have understood this incorrectly. > > > > > > > > Thank you. > > > > > > > PCI devices are connected enough to dom0 that "sudo lspci -vv" will > > > work. > > > If they are "hidden", they get claimed by the pciback Xen driver > > > so dom0 drivers don't try to initialize them. They don't actually > > > disappear from lspci. The hardware sits there inert, and only gets > > > initialized once the VM they are assigned to loads drivers for them. > > > When the VM shuts down, dom0 again won't recognize it. > > > If you want to make sure dom0 won't load drivers for a newly added PCI > > > device, add pciback.hide=(BDF) to your kernel options line, where BDF > > is > > > the format 01:00.0. > > > > Can you clarify what you mean by "PCI devices are connected enough to > > dom0"? > > Do internal PCI devices such as network card, sound card and video card > > get automatically *connected* to dom0 without doing any PCI passthrough? > > Does *connected* to dom0 mean that it is just discovered by dom0 (not > > actually attached and availabe for use in dom0)? > > Right, this. It parks devices with the pciback driver. > > > By saying "won't load drivers for a newly added PCI device" if you mean > > that the pci device won't be attached but just discovered by dom0 (and > > after being discovered can be assigned to pciback and then attached to a > > domU) then I think this would answer my question. > > It depends on the device. Without a pciback.hide command, dom0 will see > and load appropriate drivers for many of them. Video and sound cards are > ones it will. Network controllers will not- Qubes blocks those from dom0 > by default. However, they still show in lspci -v, for example: > > 01:00.0 Ethernet controller: Qualcomm Atheros QCA8172 Fast Ethernet (rev 10) > Kernel driver in use: pciback Thank you for your reply.
There is a little confusion on the Xen PCI Passthrough page: The section: Overview of Passthrough (https://wiki.xenproject.org/wiki/Xen_PCI_Passthrough#Overview_of_passthrough) states that: "You can determine the BDF for the device by running lspci in ***domain 0***." while the section: Preparing a device for passthrough (https://wiki.xenproject.org/wiki/Xen_PCI_Passthrough#Preparing_a_device_for_passthrough) states that: "First, determine the BDF of the device you wish to pass through. This is usually done by running lspci in the ***guest***??." I haven't installed Qubes OS yet as I am trying to understand the security measures and steps before installation. (Although I have experience of being a Debian user) Does one have to "add pciback.hide=(BDF) to your kernel options line" through the GRUB2 bootloader splash screen --> dom0 linux kernel (classic kernel) at boot time immediately after installation of Qubes OS to prevent automatic loading of PCI drivers? Thank you again. > > > It will be difficult to predict this in advance, so > > > use some type of live boot and lspci to see where the device gets > > assigned. > > > FLR is nice because it resets the hardware device before and after it > > > gets handed back to dom0. However, not having FLR is somewhat of a > > > theoretical vulnerability because a malicious device can't do much to > > > dom0 without a driver it can interact with. Am leaving hardware level > > > attacks out of scope of this, as FLR capability wouldn't matter as much > > > as IOMMU containment. > > > Hope that helps more than it confuses. I welcome corrections to any of > > > my misunderstandings as well. > > > > > > -- > > > 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 [email protected]. > > > To post to this group, send email to [email protected]. > > > To view this discussion on the web visit > > https://groups.google.com/d/msgid/qubes-users/f843bcc7-3bfa-69cc-9644-2909d5dfb7c3%40danwin1210.me. > > > For more options, visit https://groups.google.com/d/optout. > > > > > > -- 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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/16b7599c095.11af2201538034.3437501428300814319%40zoho.com. For more options, visit https://groups.google.com/d/optout.
