Re: [qubes-users] Security concern while checking FLR (Function Level Reset) for PCI passthrough to Xen HVM guest

2019-06-22 Thread brendan . hoar
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.

Maybe this is just due to confusing terminology or lack of specificity? dom0 is 
a guest from the xen point of view.

B

-- 
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/68274d0b-15b6-42d7-834e-58e8574a5f93%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Security concern while checking FLR (Function Level Reset) for PCI passthrough to Xen HVM guest

2019-06-22 Thread 'awokd' via qubes-users

'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.


--
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/1df6bea4-d1a5-47cd-ea52-8c39c65222ef%40danwin1210.me.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Security concern while checking FLR (Function Level Reset) for PCI passthrough to Xen HVM guest

2019-06-20 Thread 'npdflr' via qubes-users


  On Tue, 18 Jun 2019 18:40:34 -0700 awokd  wrote 
 > npdflr:
 > >    On Mon, 17 Jun 2019 18:13:02 -0700 'awokd' via qubes-users 
 > >  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 qubes-users+unsubscr...@googlegroups.com.
 > >   > To post to this group, send email to qubes-users@googlegroups.com.
 > >   > To view this discussion on the web visit 
 > > 

Re: [qubes-users] Security concern while checking FLR (Function Level Reset) for PCI passthrough to Xen HVM guest

2019-06-17 Thread 'awokd' via qubes-users

'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. 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+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@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.


[qubes-users] Security concern while checking FLR (Function Level Reset) for PCI passthrough to Xen HVM guest

2019-06-17 Thread '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.

-- 
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/16b66084317.c88c1c1b34355.471238384780140%40zoho.com.
For more options, visit https://groups.google.com/d/optout.