Security concern while checking FLR (Function Level Reset) for PCI passthrough to Xen HVM guest
34 views
Skip to first unread message
npdflr
Jun 17, 2019, 3:48:49 PM6/17/19
to 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.
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.
awokd
Jun 17, 2019, 9:14:16 PM6/17/19
to qubes...@googlegroups.com
'npdflr' via qubes-users:
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. 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.
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. 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.
npdflr
Jun 20, 2019, 11:55:55 AM6/20/19
to awokd, qubes-users
---- On Tue, 18 Jun 2019 18:40:34 -0700 awokd <aw...@danwin1210.me> wrote ----
> npdflr:
> > ---- On Mon, 17 Jun 2019 18:13:02 -0700 'awokd' via qubes-users <qubes...@googlegroups.com> 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"?
> > > > 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.
> >
> > 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 qubes-users...@googlegroups.com.
> > > To post to this group, send email to qubes...@googlegroups.com.
> > > 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.
> > >
> >
>
awokd
Jun 22, 2019, 3:07:25 AM6/22/19
to qubes...@googlegroups.com
'npdflr' via qubes-users:
> 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***??."
That's not right. The guest wouldn't know about it yet, since it's not
passed through.
> 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?
Yes, you would have to, but if you suspect a device is compromised it is
better to dispose of the computer and get a different one. If it's not
compromised, having dom0 load drivers for it a couple times isn't going
to hurt. You could also disable or remove the device before install.
> 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***??."
passed through.
> 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?
better to dispose of the computer and get a different one. If it's not
compromised, having dom0 load drivers for it a couple times isn't going
to hurt. You could also disable or remove the device before install.
brenda...@gmail.com
Jun 22, 2019, 10:34:36 AM6/22/19
to qubes-users
On Saturday, June 22, 2019 at 3:07:25 AM UTC-4, awokd wrote:
> 'npdflr' via qubes-users:
> > 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***??."
>
> That's not right. The guest wouldn't know about it yet, since it's not
> passed through.
> 'npdflr' via qubes-users:
> > 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***??."
>
> That's not right. The guest wouldn't know about it yet, since it's not
> passed through.
Maybe this is just due to confusing terminology or lack of specificity? dom0 is a guest from the xen point of view.
B
Reply all
Reply to author
Forward
0 new messages