Re: [qubes-users] Problems with debian-11 after VM update attempt
On Mon, 8 Aug 2022, Ulrich WIndl wrote: > Hi! > > I have a problem 8-( > > After using Qubes OS after a longer break, I tried to install all updates. > That worked for all template VMs except debian-11. Even when re-trying after > all the rest was updated and the system rebooted, it won't work. > > Even worse I can start a debian-11-based app VM, but I cannot launch any > program there. Even "qvm-run debian-11 gnome-terminal" fails. > > I have saved the lengthy protocol of the first attempt, however (attached). > > It seems the problem was: > > Unpacking thunderbird (1:91.12.0-1~deb11u1) over (1:91.8.0-1~deb11u1) ... > dpkg: error processing archive > /tmp/apt-dpkg-install-GfbHjN/38-thunderbird_1%3a91.12.0-1~deb11u1_amd64.deb > (--unpack): > cannot copy extracted data for > './usr/share/thunderbird/omni.ja' to > '/usr/share/thunderbird/omni.ja.dpkg-new': failed to write (No space left on > device) > dpkg-deb: error: paste subprocess was killed by signal > (Broken pipe) > > Note: It's not pool00 that is full. How can I recover from this? The system volume of debian-11 is full? It might be possible to revert the changes to the template if there's an earlier snapshot of it. Otherwise, you'll need to recover things manually. You can access the vm's console with xl console. You'll likely need to make some space first (perhaps by deleting something you can easily recreate). As soon as the template works almost normally, I'd try to enlarge system volume and then reinstall all packages that were part of the failing upgrade. -- i. > (I'm still at Qubes OS 4.0. I wanted to install the last updates, then backup, > then try upgrading to 4.1) > > > Regards, > > Ulrich > > -- 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/alpine.DEB.2.21.2208090857460.31454%40lakka.kapsi.fi.
Re: [qubes-users] Re: QSB-063: Multiple Xen issues (XSA-115,XSA-325,XSA-350)
On Wed, 16 Dec 2020, haaber wrote: > On 12/16/20 10:55 AM, 'Ilpo Järvinen' via qubes-users wrote: > > On Wed, 16 Dec 2020, haaber wrote: > > > > > Dear Andrew, > > > > > > > For Qubes 4.0: > > > > - Xen packages, version 4.8.5-28 > > > > - Linux kernel packages, versions 5.9.14-1, 5.4.83-1, 4.19.163-1 > > > > > > how do I fetch 4.19.163-1 for example? I tried > > > > > > sudo dnf install kernel-1000:4.19.163-1.pvops.qubes.x86_64 > > > > > > but this gives "no package available". Same happens for 5.9.14-1. Also > > > > > > sudo qubes-dom0-update --action=install > > > kernel-1000:4.19.163-1.pvops.qubes.x86_64 > > > > > > fails. What am I missing?? Thank you. > > > > The packages are likely still in security testing, not in the stable repo. > > You need the enablerepo parameter. From the original announcement: > > > > > > For updates from the security-testing repository: > > > > $ sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing > > right! Thank you. That brought indeed 4.19.163. But still > > sudo qubes-dom0-update --action=install > kernel-1000:5.9.14-1.qubes.x86_64 --enablerepo=qubes-dom0-security-testing > > does not work. The main question seems: how do you get the correct > package name? Since a simple "update" does not install 5.9.14 but only > 5.4.83 I have to ask for it "by hand", it seems. I think the package is called kernel-latest- not just kernel- for 5.9 kernels. -- i. -- 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/alpine.DEB.2.20.2012161202090.10884%40whs-18.cs.helsinki.fi.
Re: [qubes-users] Re: QSB-063: Multiple Xen issues (XSA-115, XSA-325,XSA-350)
On Wed, 16 Dec 2020, haaber wrote: > Dera Andrew, > > > For Qubes 4.0: > > - Xen packages, version 4.8.5-28 > > - Linux kernel packages, versions 5.9.14-1, 5.4.83-1, 4.19.163-1 > > how do I fetch 4.19.163-1 for example? I tried > > sudo dnf install kernel-1000:4.19.163-1.pvops.qubes.x86_64 > > but this gives "no package available". Same happens for 5.9.14-1. Also > > sudo qubes-dom0-update --action=install > kernel-1000:4.19.163-1.pvops.qubes.x86_64 > > fails. What am I missing?? Thank you. The packages are likely still in security testing, not in the stable repo. You need the enablerepo parameter. From the original announcement: > > For updates from the security-testing repository: > > $ sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing -- i. -- 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/alpine.DEB.2.20.2012161154240.10884%40whs-18.cs.helsinki.fi.
Re: [qubes-users] Kernel development on a qube
On Tue, 5 May 2020, 'kvb4eu' via qubes-users wrote: > Hi everybody. I am becoming interested in Linux kernel development. > I have read tutorials on using qemu. On a Fedora qube I could not install > qemu due to broken packages during the installation; the template was > vanilla. > Is it possible and how to install qemu or do kernel development using > QubesOS? You can create a new template for kernel testing and install the test kernels there. Then set the kernel of the appvm used for the tests to pvgrub2-pvh (you need to install grub2-xen-pvh package into dom0 to do be able to do that). -- i. -- 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/alpine.DEB.2.20.2005060111330.23426%40whs-18.cs.helsinki.fi.
Re: [qubes-users] Build USB install with kernel 5+
On Sat, 28 Mar 2020, max via qubes-users wrote: > Hi everyone, > > Any help appreciated. > > I managed to install a Qubes 4.0.3 on an Intel NUC10FNK. No VM's can start > due to an error like: Internal error: Unable to reset PCI device > :00:1f:6:no FLR, PM rset or bus reset available. Test setting permissive mode for that PCI device. -- i. -- 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/alpine.DEB.2.20.2003282036430.8497%40whs-18.cs.helsinki.fi.
Re: [qubes-users] Re: [4.0] Intel Wi-Fi 6 AX200 adapter
On Thu, 19 Mar 2020, Vít Šesták wrote: > Well, maybe it would be better to just compile some newer StubDom. > > Also, I have realized that there is some similar discussion on Github: > https://github.com/QubesOS/qubes-issues/issues/5615 Yes, multiple person have reported this same issue also on this list. I even saw one report in some in some external bug tracker. In that case it was mixed up with some other issue within the same issue. The Intel devs chose to prioritize the other issue over the one that seems to occur in case of Qubes. It is very obvious that this HW was out when the driver still had very subpar quality (Intel claimed support but many found out the device just doesn't work, this wasn't at all Qubes specific at start) so I wouldn't be surprised if it has something to do with the driver. -- i. > > Regards, > Vít Šesták 'v6ak' > > On Thursday, March 19, 2020 at 10:42:00 PM UTC+1, Ilpo Järvinen wrote: > On Thu, 19 Mar 2020, Vít Šesták wrote: > > > Hello, > > I have some interesting updates. I have tried to: > > > > a. Boot Fedora 31 on the laptop (Live version from USB drive) > – adapter is > > detected and finds Wi-Fi networks. It just works. > > b. Boot Fedora 31 Live (from the same USB drive) in a HVM with > attached > > Wi-Fi card. It had 2000MiB of RAM. It fails in the same way as > my previous > > attempts, not sure why. > > > > This looks like the AppVM is fine, but there is some glitch in > the PCI > > handling. It might be related to Xen or to the DM, not sure. > > > > HVM: > https://gist.github.com/v6ak/76f2c089c63b1fe184f3717d5bd5254e > > sys-net with Fedora 31: > > https://gist.github.com/v6ak/30ecc502d1ce7508953eb3d505564668 > > > > I have also resolved the chicken-egg problem – I can connect > to the Internet > > via USB. This is not a permanent solution, but it was good > enough for > > updating dom0. However, the update (+ subsequent reboot) has > not changed > > anything. > > One option would be compile a kernel with CONFIG_IWLWIFI_TRACING > (or > something like that) and try to provide the trace log to iwlwifi > devs. > ...It might not help though if it's not a HW/driver issue but > xen/dm/pci > related thing. -- 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/alpine.DEB.2.20.2003200020320.5256%40whs-18.cs.helsinki.fi.
Re: [qubes-users] Re: [4.0] Intel Wi-Fi 6 AX200 adapter
On Thu, 19 Mar 2020, Vít Šesták wrote: > Hello, > I have some interesting updates. I have tried to: > > a. Boot Fedora 31 on the laptop (Live version from USB drive) – adapter is > detected and finds Wi-Fi networks. It just works. > b. Boot Fedora 31 Live (from the same USB drive) in a HVM with attached > Wi-Fi card. It had 2000MiB of RAM. It fails in the same way as my previous > attempts, not sure why. > > This looks like the AppVM is fine, but there is some glitch in the PCI > handling. It might be related to Xen or to the DM, not sure. > > HVM: https://gist.github.com/v6ak/76f2c089c63b1fe184f3717d5bd5254e > sys-net with Fedora 31: > https://gist.github.com/v6ak/30ecc502d1ce7508953eb3d505564668 > > I have also resolved the chicken-egg problem – I can connect to the Internet > via USB. This is not a permanent solution, but it was good enough for > updating dom0. However, the update (+ subsequent reboot) has not changed > anything. One option would be compile a kernel with CONFIG_IWLWIFI_TRACING (or something like that) and try to provide the trace log to iwlwifi devs. ...It might not help though if it's not a HW/driver issue but xen/dm/pci related thing. -- i. -- 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/alpine.DEB.2.20.2003192334390.5256%40whs-18.cs.helsinki.fi.
Re: [qubes-users] Intel ax200, wifi 6, 2723 on X1 gen2 extreme
On Wed, 22 Jan 2020, Scott Russell wrote: > HI, So, since I have no networking, I decided to install the networking > via a usb pen drive. However, I seem unable to mount the usb drives in any > vm, tried the fedora-29 template, and also the work vm, or sys-firewall. > But each time I click the icon to attach, it reports successfully attached, > but when I go to the vm, it does not show up. I can see from qvm-block that > is is attached from dom0, also tried manually attaching via command line, > but again, it reports attached, but cannot see in the work vm that it is > thre. but when I do a "df -h" or try to list the devices in /dev/xvdi, it > is not there on the work vm. It seems like a pretty simple thing to > attach the pendrive. I have tried several pen drives, but seem unable to > mount them in any vm. Have re-read the docs several times, and no-one seems > to have this issue, so I am probably doing something fundamentally wrong? > Any advice or hints greatly appreciated?. I have some problem in understanding what exactly you're doing here as your description seems to mix "attaching" and "mounting". In addition to attaching the block device, you may have to mount the block device mount /dev/xvdi /home/user/somepath as a separate step to get it to appear under /home/user/somepath (and df will only show mounted drives). Or did you try to say there's no /dev/xvdi device? ...In that case, check the dmesg if the device is detected by the kernel. -- i. > On Tue, 14 Jan 2020 at 13:14, Ilpo Järvinen > wrote: > On Tue, 14 Jan 2020, Scott Russell wrote: > > > Hi, I am installing qubes to an X1 gen2 extreme. Gone well > so far, but > > then I stumbled into a problem with wifi. Unfortunately the > intel ax200 is > > not supported in linux kernel till after kernel5-1+. > (https://www.intel.com/content/www/us/en/support/articles/05511/ > networ > > k-and-i-o/wireless-networking.html). > > I didn't get AX 200 to work myself and I just use a stop-gap USB > WLAN > dongle solution currently. I tried with latest kernels, various > firmware > versions, and even went to dkms backport of iwlwifi but none of > those > worked. > > It just seems the iwlwifi driver, despite claims of AX 200 being > supported > since 5.1, may not work for all (some have gotten it to work but > I'm not > sure if anyone among them with Qubes). > > > So, I was wondering on what my options would be. My first > thought having > > reviewed a few posts, was that I would need to compile the > latest kernel and > > use this in the sys-net. > > Then, I thought, maybe there is already a "latest kernel" > somewhere that I > > could just install without the need for compiling a new one. > > Yes, kernel-latest package is already available using > qubes-dom0-update. > Certainly worth a test. > > > As an aside, does this mean I should change the underlying > template for > > sys-net and logically the sys-firewall, or should I keep the > sys-net as a > > custom kernel version only. If there are other ways, any > advice is > > appreciated. A lot to learn here, but happy to work through > any > > suggestions. > > Kernel version, when provided from dom0, is independent of the > template. > It is possible to use the kernel from the template if you set > "kernel" > of the VM to empty (for HVMs). > > > So, the question is ,can I upgrade the kernel from 4.4.x to > 5.1+ in an easy > > and safe way, or am I driven to playing with the > kernel compilation? > > > -- > i. > > > -- 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/alpine.DEB.2.20.2001221219130.25645%40whs-18.cs.helsinki.fi.
Re: [qubes-users] Intel ax200, wifi 6, 2723 on X1 gen2 extreme
On Sun, 19 Jan 2020, man...@andaztech.com wrote: > I downloaded and ran RebornOS from a live USB, the Intel AX200 gets > picked up be default and works (used it for two hours with no issues) > The only difference I could see wa the firmware file loaded was > iwlwifi-cc-a0-50.ucode instead of the iwlwifi-cc-a0-46.ucode > > Will try that firmware on a qubes VM and update. > > Anyone tried that firmware file? Yes, I've tried also with -50 firmware (with a number combinations of kernel versions; firmwares -46, -48, and -50; and also with and w/o dkms backport). My problems did not go away with it nor was there any notable change. I've not tested is baremetal myself (and have no intention to). Perhaps the problems are related to having Xen in the equation (but that's just a guess). -- i. -- 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/alpine.DEB.2.20.2001191226470.26882%40whs-18.cs.helsinki.fi.
Re: [qubes-users] Intel ax200, wifi 6, 2723 on X1 gen2 extreme
On Tue, 14 Jan 2020, Scott Russell wrote: > Hi, I am installing qubes to an X1 gen2 extreme. Gone well so far, but > then I stumbled into a problem with wifi. Unfortunately the intel ax200 is > not supported in linux kernel till after kernel 5-1+. > (https://www.intel.com/content/www/us/en/support/articles/05511/networ > k-and-i-o/wireless-networking.html). I didn't get AX 200 to work myself and I just use a stop-gap USB WLAN dongle solution currently. I tried with latest kernels, various firmware versions, and even went to dkms backport of iwlwifi but none of those worked. It just seems the iwlwifi driver, despite claims of AX 200 being supported since 5.1, may not work for all (some have gotten it to work but I'm not sure if anyone among them with Qubes). > So, I was wondering on what my options would be. My first thought having > reviewed a few posts, was that I would need to compile the latest kernel and > use this in the sys-net. > Then, I thought, maybe there is already a "latest kernel" somewhere that I > could just install without the need for compiling a new one. Yes, kernel-latest package is already available using qubes-dom0-update. Certainly worth a test. > As an aside, does this mean I should change the underlying template for > sys-net and logically the sys-firewall, or should I keep the sys-net as a > custom kernel version only. If there are other ways, any advice is > appreciated. A lot to learn here, but happy to work through any > suggestions. Kernel version, when provided from dom0, is independent of the template. It is possible to use the kernel from the template if you set "kernel" of the VM to empty (for HVMs). > So, the question is ,can I upgrade the kernel from 4.4.x to 5.1+ in an easy > and safe way, or am I driven to playing with the kernel compilation? -- i. -- 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/alpine.DEB.2.20.2001141301040.13479%40whs-18.cs.helsinki.fi.
Re: [qubes-users] My bluetooth device appears in sys-usb but itsmodule (wifi) is in sys-net
On Thu, 9 Jan 2020, Guerlan wrote: > I'm trying to understand something. My bluetooth device is a PCI device that > is also a wifi device. The wifi PCI device is mounted to sys-net, so > bluetooth should appear there as well. However: > > [user@sys-usb ~]$ hcitool dev > Devices: > hci0 9C:86:C0:1D:41:E1 > > [user@sys-net ~]$ hcitool dev > Devices: > > Even though sys-usb has a bluetooth device scanning returns nothing, so I > don't know if it really is a bluetooth device. However sys-net should have > it. > > Here are lspci for both VMs: > > [user@sys-usb ~]$ lspci > 00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02) > 00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] > 00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton > II] > 00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03) > 00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device (rev > 01) > 00:03.0 VGA compatible controller: Device 1234: (rev 02) > 00:04.0 USB controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 > EHCI Controller (rev 10) > 00:06.0 USB controller: Intel Corporation Sunrise Point-LP USB 3.0 xHCI > Controller (rev 21) > > [user@sys-net ~]$ lspci > 00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02) > 00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] > 00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton > II] > 00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03) > 00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device (rev > 01) > 00:03.0 VGA compatible controller: Device 1234: (rev 02) > 00:04.0 USB controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 > EHCI Controller (rev 10) > 00:06.0 Network controller: Qualcomm Atheros QCA6174 802.11ac Wireless > Network Adapter (rev 32) <<< controller that has bluetooth The bluetooth is likely an USB device and it may have very little to do with the PCI device despite being part of the "same" network adapter. -- i. -- 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/alpine.DEB.2.20.2001092012540.26233%40whs-18.cs.helsinki.fi.
Re: [qubes-users] Qubes/Xen doesn't comply with IOMMU grouping rulesfor PCI passthru
On Sun, 29 Dec 2019, 'awokd' via qubes-users wrote: > Claudia: > > December 26, 2019 12:59 PM, "awokd' via qubes-users" > > wrote: > > > >> Claudia: > >> > >> TLDR; check bottom of https://community.amd.com/thread/241650, looks > >> like there was a recently released related updated. Not sure if > >> applicable to your situation. > > > > Thanks for the link! I'm not sure if it affects me or not. I did > > install a Dell BIOS update dated March 2019, so it sounds like that > > could have contained this Agesa update. So downgrading might fix the > > grouping issue, but this update also contained an "urgent" security > > update which I'd have to look into before downgrading. > > I'd assumed AGESA version numbers were from a common code base, but > apparently not. The one mentioned in that thread was released around > Oct. 2019, but may not be applicable to your hardware. They also don't > specifically reference USB controller grouping in that thread, so it > might do nothing for you even if it is applicable. > > > I sort of blame Xen for not enforcing IOMMU grouping, especially > > considering that it hides that > > info from the OS. KVM does enforce IOMMU grouping rules, so I don't see why > > Xen wouldn't. Xen > > leaves it up to the user software to be careful what it passes where, but > > that's kind of hard when > > you don't have /sys/kernel/iommu_groups for a hint. > > I am a bit fuzzy here too. It seems like if ACS is working correctly, > you can get better granularity within IOMMU groups. It would be > disappointing if it does not on recently released hardware. In your > case, the USB controller appears as a different function of the same PCI > device, which could be the case from a hardware perspective. This is > even worse for a passthrough scenario than IOMMU grouping. There is a > Realtek controller that often comes up on the list that makes people > passthrough the SD card controller to their sys-net along with WIFI for > the same reason. I got an impression from somewhere, that AMD platform itself should support really good IOMMU grouping but that there's then a BIOS option to enable it (like "IOMMU: auto/enabled", where "auto" got you the default conflicting groups; I read two lspcis from the same HW somewhere with very different PCI dev layouting where the other was with the "enabled" setting but I guess it was a desktop MB). I suspect, however, laptop vendors may not be putting that much effort on including such options. -- i. -- 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/alpine.DEB.2.20.1912291951080.10565%40whs-18.cs.helsinki.fi.
Re: [qubes-users] Hyperthreading is turned off by Qubes
On Sun, 29 Dec 2019, trueriver wrote: > > HT is turned off intentionally for security purposes. Some of the > Intel CPU vulnerabilities demonstrated within the recent years depend on > the side channels within the resources shared by the threads of the same > physical core. Thus it's advisable to not enable it > > Thanks for that explanation - yes that's sensible. > > With the option set to allow HT, I'm now wondering if there is a Xen > setting to force Xen to allocate both virtual cores in the same physical > core together? I don't know but I wouldn't expect one to appear in an old xen. Given R4.0 is 4.8 so if such feature is there, most likely that's not available until some future Qubes version. > That would mean you'd always get an even number of virtual cores, they > would always be "core buddies", and this it's only that VMs own code > that can attempt those exploits. That would give almost the same level > of security but allow the extra performance. > > Or am I missing some nasty potential exploit? -- i. -- 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/alpine.DEB.2.20.1912291947290.10565%40whs-18.cs.helsinki.fi.
Re: [qubes-users] Hyperthreading is turned off by Qubes
On Fri, 27 Dec 2019, trueriver wrote: > Running a new install of Qubes r4.0.1 on an ultrabook based on the > m5-6Y54 processor / SOC. Xentop shows it as having only 2 cores. > > When the same machine boots into Debian on bare metal, with no BIOS > changes, top shows it as having four. > > The Intel spec is 2 cores running 4 threads, so the difference is > clearly about hyperthreading. > > Is it possible to get Xen in Qubes to enable hyperthreading? > > And if so how? There's smt xen command-line parameter. > Are there any obvs pitfalls or technical issues to explain why Xen turns > it off? Yes, HT is turned off intentionally for security purposes. Some of the Intel CPU vulnerabilities demonstrated within the recent years depend on the side channels within the resources shared by the threads of the same physical core. Thus it's advisable to not enable it. -- i. -- 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/alpine.DEB.2.20.1912272328150.22137%40whs-18.cs.helsinki.fi.
Re: [qubes-users] Re: [Advanced] Enabling nested virtualization in Qubes/HVM
On Thu, 18 Jul 2019, lastpoke...@gmail.com wrote: > On Sunday, 7 February 2016 23:12:25 UTC, he...@ruggedinbox.com wrote: > > Input from the developers would be especially welcome. > > > > I've been trying to enable nested virtualization in Qubes, which should be > > possible without modifications, since Xen requires only the addition of > > two lines to a conf file: > > > > --- > > Make sure you have the right support > > Xen 4.4 or later > > Intel CPU with EPT support > > > > Add the following to your config file: > > > > hap=1 > > nestedhvm=1 > > > > (Cite: http://wiki.xenproject.org/wiki/Nested_Virtualization_in_Xen) > > --- > > > > 1) What's the preferred way to accomplish this in Qubes? > > > > 2) It looks like the template packages qubes-gui-vm, xen-qubes-vm, and > > xen-libs are set up to block installation of other in-guest virtualization > > packages like qemu/libvirt (requiring the former to be removed for any > > experimentation to proceed). It happens on both the fedora and debian. > > Removing those packages would cause problems interacting with dom0. What's > > going on here? > > > > Thank you. > > Cool but where is that config file located??? IIRC, the xen package is built in Qubes with nested virtualization disabled by default to reduce attack surface so you'd need to compile it yourself. -- i. -- 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/alpine.DEB.2.20.1907182257310.5157%40whs-18.cs.helsinki.fi.
Re: [qubes-users] New Install of Qubes OS 4.0.2 RC1 Dom0 Doesnt Update
On Sat, 13 Jul 2019, alexw8...@gmail.com wrote: > The Issue I am having is that When I try and update Dom0 in the Terminal > using "sudo qubes-dom0-update" I am getting this. > > Fedora 25 - x86_64 - Updates > Fedora 25 - x86_64 > Qubes Dom0 Repository (updates) > determining the fastest mirror (15 hosts)..done.. > Qubes Templates repo138% > Qubes Templates repository > Last metadata expiration check: > Dependencies resolved. > > Reinstalling: > python3-blivet noarch 2:2.1.6-5.fc25 qubes-dom0-current > python3-kickstart noarch 1000:2.32-4.fc25 qubes-dom0-current > qubes-release noarch 4.0-8 qubes-dom0-current > qubes-release-notes noarch 4.0-8 qubes-dom0-current > > It downloads these updates and then says: > > Complete! > The downloaded packages were saved in cashe until the next successful > transaction. The problem is that they're effectively the same version of the installed package so nothing gets updated but the update process realizes that too late. > After I restart the computer this just keeps repeating. Is there a way > to fix this? You can force reinstalling these package if you want to prevent the repeat. -- i. -- 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/alpine.DEB.2.20.1907131807050.22676%40whs-18.cs.helsinki.fi. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] CVE-2019-11477
On Tue, 18 Jun 2019, Dominique St-Pierre Boucher wrote: > Good day Qubes user, > > Is qubes affected by CVE-2019-11477? AppVMs depending on kernel (most likely yes). But this attack is limited to DoS (triggering a BUG_ON assert that stops the kernel) from the peers (+on-path attackers) you're communicating with (that is, some random source cannot just send a "magic packet" to trigger it. -- i. -- 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/alpine.DEB.2.20.1906182012230.24383%40whs-18.cs.helsinki.fi. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] How to create a new User in Qubes OS 4?
On Sun, 2 Jun 2019, n6-w6...@tuta.io wrote: > I need help to create a new user in Qubes OS 4.0. > > I went to “System Tools - Xfce Terminal” > > I did: > > useradd -m user > passwd user > > usermod -a -G sudo user = ERROR > > I can’t login with my my new user. > Login don’t accept my new created user and password. > > I can't find user+groups manager into Qubes OS 4.0. > > What to do? You want to put the new user into wheel and qubes groups. The other issue might be that your login manager could launch more than one X server behind your back and some gui stuff has some challenges in handling that. ...Then, next you will face issues with the menu I guess. ;-) I have a working multi-user qubes system myself (the other users have only a locked down view to dom0). It works about ok for my use case but requires some trickery with tags (and current one patch which I've not yet sent out). -- i. -- 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/alpine.DEB.2.20.1906020119120.24401%40whs-18.cs.helsinki.fi. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: [qubes-devel] QSB #49: Microarchitectural Data Sampling speculative side channel (XSA-297)
On Thu, 16 May 2019, g80vmgm...@riseup.net wrote:
> From XSA297:
> """
> Work is ongoing on xen-devel to develop core-aware scheduling, which
> will mitigate the cross-domain leak by ensuring that vcpus from
> different domains are never concurrently scheduled on sibling threads.
> However, this alone will not prevent cross-privilege level leakage from
> within the same domain, including leakage from Xen.
> """
>
> I'm sorry, I'm not subscribed to xen-devel and am too lazy to go through
> its archives. Is anyone from the Qubes team monitoring this--or better,
> participating in it?
>
> I can imagine a few Qubes-specific mitigations that might use some Xen
> scheduling features to defend against future types of side-channel info
> leaks in CPUs:
>
> 1) Schedule each domain in a given security label ('color') on a
> specific CPU. If there are not enough CPUs, make clear to the user
> which colors might be scheduled on the same physical CPU core.
>
> 2) Most (all?) CPUs that support Qubes have at least 2 cores. Assign
> the first core the 'high' security label. Assign all other cores the
> 'low' security label. Assign dom0, possible future AdminVM, and any
> user-designated VMs the 'high' security label. Schedule high-labeled
> VMs exclusively on high-labeled CPU cores, and never schedule a
> low-labeled VM on a high-labeled CPU core.
>
> Information could still leak through e.g. shared caches, and special
> attention obviously must be paid there, but this might be a useful
> mitigation for similar kinds of attacks discovered in the future.
>
> It could be worthwhile to sketch out what kinds of features Qubes might
> need from Xen in order to accomplish this kind of thing and work with
> them while they develop this new scheduler.
There is also some L3 cache region masking feature (CAT, which is also
supported by Xen) onwards from Broadwell (but it might be only available
for Xeons). And whether it could really close the L3 side-channels or
not probably depends on internal L3 architecture (if an off-masked L3
region contains the attacked data, whether it is retrieved by CPU or not).
--
i.
--
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/alpine.DEB.2.20.1905162013440.30836%40whs-18.cs.helsinki.fi.
For more options, visit https://groups.google.com/d/optout.
[qubes-users] R4.0 fails to start VMs (mount root from xvda) due to 4kB sectors?
Hi, I installed R4.0 into a machine with sda (for /boot only) & NVMe drives (I had to use manual partitioning for this but I followed the custom installation instructions on qubes-os.org except I used a larger metadata size). It turns out that Qubes fails to start any VM successfully because it fails to correctly detect partitions on /dev/xvda and therefore has no root to mount (and bails out). I've tried to track down the cause and it looks as if the problem is caused by the 4kB/4kB sector size of the NVMe drive which causes misinterpretation of the partition table(?). If I use fdisk on the /dev/qubes_dom0/vm-debian-9-root directly, I don't see the correct partitions (and that is then -snap'ed into the vm's xvda) but if I 'dd' it into a local file, the three partitions show up correctly so the data itself on LV seems ok. Is this expected behavior with R4.0 (I think R3.2 worked just fine with a similar 4kB/4kB SSD drive)? Does somebody know a way to workaround this problem (other than changing the SSD's logical sector size to 512B which, I guess, might have some performance implications). The R4.0 I used is self-build but I've installed a working system from the very same copy successfully on other machines so I doubt some misbuild alone can explain the problem (but those working systems did not have a 4kB/4kB drive). -- i. -- 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/alpine.DEB.2.20.1904122329440.8972%40whs-18.cs.helsinki.fi. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: PS/2 Keyboard and Mouse via USB?
On Thu, 11 Apr 2019, jrsmi...@gmail.com wrote:
> On Wednesday, April 10, 2019 at 3:25:34 AM UTC-7, unman wrote:
> > On Tue, Apr 09, 2019 at 11:45:02AM -0700, jrsmi...@gmail.com wrote:
> > > If there is no signal on PS/2 ground or I can eliminate it, is this the
> > > more secure route or is it worth doing the USB shuffle? I have 4 USB
> > > controllers available.
> > >
> >
> > If you really have 4 USB controllers I would allocate one to dom0 and 3
> > to sys-usb (or more than one sys-usb).
> > Depending on your level of paranoia you might want to permanently attach
> > the devices to the usb port in dom0 - I mean physically.
>
> I see now why you phrased it the way you did ("If you really have 4 USB
> controllers..."). After running `sudo lspci -vv | grep -i usb` and getting
> back only two hits as dom0 I began digging. After all, my mobo docs and box
> says:
>
> Chipset+Intel ® Thunderbolt TM 3 Controller:
> - 2 x USB Type-C TM ports on the back panel, with USB 3.1 Gen 2 support
> Chipset+ASMedia ® USB 3.1 Gen 2 Controller:
> - 1 x USB Type-C TM port with USB 3.1 Gen 2 support, available through the
> internal USB header
> Chipset+Realtek ® USB 3.1 Gen 1 Hub:
> - 4 x USB 3.1 Gen 1 ports on the back panel
> Chipset:
> - 4 x USB 3.1 Gen 1 ports available through the internal USB headers
> - 6 x USB 2.0/1.1 ports (2 ports on the back panel, 4 ports available through
> the internal USB headers)
>
> so *obviously* there are four USB controllers, right? I can account for one
> of them not showing up, that's the controller in the Tunderbolt chipset.
> This shows up in Ubuntu as one of three USB controllers seen by lspci, but
> Qubes doesn't see it. The fourth could be the USB 3.1 Gen 2 front panel
> controller, which I haven't populated yet.
>
> Some of the docs I ran across describing lsusb looked promising, but
> then they would say something like, "you can see from the output above
> that there are two controllers", but it wasn't clear to me which were
> controllers vs hubs. I did learn that some controllers have multiple
> hubs (say USB 2.0 and USB 3.0), but it's much less straightforward to
> clearly identify the USB controllers than I thought it would be. I'm no
> longer sure that even that is the correct way to look at it since there
> could be multiple controllers on the same PCIe bus and the level of
> granularity we have to work with in Qubes is at the PCIe level.
You could see if your bios allows disabling USB3/XHCI for the chipset
USB controllers. There are some USB combining tricks on some MBs that
might eat away (two) ehci controllers (and output only one xhci
controller).
--
i.
--
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/alpine.DEB.2.20.1904112156280.13646%40whs-18.cs.helsinki.fi.
For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Hijacking Threads
On Sat, 2 Feb 2019, pru...@riseup.net wrote: > I have been thinking of joining qubes users for long time but am put off > by large number of threads being hijacked. > It is bad etiquette to hijack somebody elses thread - see wikipedia > entry here https://en.wikipedia.org/wiki/Etiquette_in_technology > "avoiding multiposting, cross-posting, off-topic posting, hijacking > a discussion thread, and other techniques .". ...That's very selective quoting from you ;-). Perhaps it is a tactic to deflect attention away from the previous sentence on that page? ;-) > Many times hijacking is used by a minority, as tactic to deflect > attention away from or avoid answering the original > question/comment/query. That's a quite bold claim. While I could agree that many discussing might not know an answer (if there even is a question in the thread), stating that it's being done on those purposes you claim is quite an arrogant one, IMHO. Also, often this kind of spinoffs seem occur with discussion rather than clear questions threads so it seems just naturally way discussion works (and yes I know, some oppose natural way how natural discussions work because they want to _dictate how others_ are allowed to participate in public discussions). There are plenty of counter-examples to your claim when a thread has a clearly defined technical question. But if there isn't such a question made, then it's an open loop really and your "avoid answering" part doesn't really apply. > Me thinks the qubes user community works better if they control tighter It would be nice though if people would change the subject when they clearly spinoff but I can understand it's often hard to draw a line or realize that the discussion has drifted off far enough to warrant that so the problem is likely to stay. -- i. -- 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/alpine.DEB.2.20.1902021338310.25518%40whs-18.cs.helsinki.fi. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] QSB #46: APT update mechanism vulnerability
On Tue, 29 Jan 2019, Alexandre Belgrand wrote: > Le mardi 29 janvier 2019 à 00:59 +0200, Ilpo Järvinen a écrit : > > There are many technical reasons raising from plain > > physics/electronics > > which make an attack chip of that size with the described > > capabilities to > > seem quite utopistic (and the article therefore bogus). ...But of > > course > > you can choose to believe what you want. > > The Chinese chip has been found and exists, no doubt about it. It was > found on thousands of servers, so I believe it is being analyzed. Yeah yeah, the only modification was that chip as claimed in the article? Magically all the necessary signal pins were routed to its location but nothing else was changed (and you cannot have that many pins in that sized chip anyway which will seriously limit the possible functionality and processing speed). ...But it must all be true and present in thousands of servers because a sensational article so claims (funny though that the so claimed victims of the attack consistently denied presence of such a chip in their servers but I guess you'll anyway think they must be lying for the benefit of the Chinese, damage control, because of the "investigation", or whatever reason). -- i. -- 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/alpine.DEB.2.20.1901290940250.13141%40whs-18.cs.helsinki.fi. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] QSB #46: APT update mechanism vulnerability
On Mon, 28 Jan 2019, Alexandre Belgrand wrote: > Le lundi 28 janvier 2019 à 13:08 -0800, goldsm...@riseup.net a écrit : > > I'm intrigued how you know can catagorically state "CAs and GNU/Linux > > distributions are #1 targets for national > > China: > https://www.bloomberg.com/news/features/2018-10-04/the-big-hack-how-china-used-a-tiny-chip-to-infiltrate-america-s-top-companies > > China uses a tiny chip to intercept data. Read Bloomberg article. > > "A chip can also steal encryption keys for secure communications, block > security updates that would neutralize the attack, and open up new > pathways to the internet." There are many technical reasons raising from plain physics/electronics which make an attack chip of that size with the described capabilities to seem quite utopistic (and the article therefore bogus). ...But of course you can choose to believe what you want. -- i. -- 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/alpine.DEB.2.20.1901290037280.13141%40whs-18.cs.helsinki.fi. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] About X.Org vulnerability and Qubes
On Mon, 29 Oct 2018, Sphere wrote: > https://threatpost.com/x-org-flaw-allows-privilege-escalation-in-linux-systems/138624/ > > > It is said that leveraging the vulnerability is possible from a remote > SSH session. Say an attacker was able to successfully gain a remote SSH > session in an untrusted VM, do you think it would be possible to gain > full control through qubes' implementation of X.org? This is a built-in assumption in Qubes OS design. That is, that VMs may/will get compromized due to bugs like this... > I checked around and if I understand it right, qubes utilizes X.org in > order to integrate the display of PVH VM applications to what the user > can/must see. > > Because of this, what's in my mind right now is that it's possible to > leverage this vulnerability to gain full control but since I don't have > an idea of the codes or how exactly qubes' implementation of X.org > works, I would like to kindly ask for your thoughts about this matter. ...but it does not lead to dom0 or cross-VM compromize because of how the GUI isolation works (the GUI isolation does not run over X.org but is implemented using a very simple protocol based on memcpy from X.org buffers). > Earlier I was about to remove setuid of Xorg but I thought it has a good > chance of breaking my desktop environment altogether and that would be > alot of trouble for me. If you're worried about the VMs themselves having being compromised, you can backup everything and use the "paranoid restore" mode after a clean reinstall of Qubes. -- i. -- 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/alpine.DEB.2.20.1810300735590.21103%40whs-18.cs.helsinki.fi. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: qubes-dom0-update borked laptop
On Fri, 3 Aug 2018, jm wrote: > On Friday, 3 August 2018 13:02:03 UTC-4, steve.coleman wrote: > > On 08/03/18 12:46, jm wrote: > > > /var/log/dnf.log tells me that this morning dom0 update > > > > > > Removed: > > > kernel.x86_64 1000:4.9.35-20.pvops.qubes > > > kernel-qubes-vm.x86_64 1000:4.9.35-20.pvops.qubes > > > > > > Installed: > > > kernel.x86_64 1000:4.14.57-1.pvops.qubes > > > kernel-qubes-vm.x86_64 1000:4.14.57-1.pvops.qubes > > > > > > > Check to see if your VM's are set to the latest Kernel just installed. > > If it is try setting it to the previous version vm. > > > > Also I once had a problem where kernels were being installed and > > uninstalled while the settings for the VM's never got updated to point > > each to a newer valid kernel. > > yes, this worked. I have to manually downgrade every vm by hand using > > qvm-prefs vm kernel -s oldkernelnumber > > ouch. half a day's work lost to a botched dom0 update. I will have to be more > wary of immediately installing dom0 updates in the future. It probably doesn't help for this particular problem any more but there would have been a global default for the kernel in the qubes manager "global settings". Also, now that you've manually set the kernel for all those vms into the older kernel, the vms will not automatically get a new kernel into those vms when you update kernel in the future but you need to do that operation once more. It will be it's quite easy with a simple bash for loop to avoid doing it manually though: for i in $(qvm-ls --raw-list); do qvm-prefs $i kernel -s ...; done ...You might want to set them all to default instead of a specific kernel version once you've a working kernel set as the default kernel. -- i. -- 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/alpine.DEB.2.20.1808032021350.13783%40whs-18.cs.helsinki.fi. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Critical PGP bugs. Do they possibly affect Split-GPG in Qubes?
On Wed, 16 May 2018, taii...@gmx.com wrote: > On 05/15/2018 01:22 AM, john wrote: > > > On 05/14/18 14:58, Ángel wrote: > >> This paper is most interesting for the discovery of multiple ways email > >> client leak information on visualization. > >> (not clearly stated in the paper: some of them are already fixed, while > >> in other cases the developers are still working on providing them) > >> > >> Luckily, with Qubes it is easy to set a firewall rule so that your email > >> AppVM can only contact with your email server. > >> NB that some of these leaks are dns-based, so ideally you would not > >> allow it to perform any dns query, either. > >> > >> Best regards > >> > > can you give an example to the steps to make such a fw rule, if > > it's that simple please ? > I would suggest simply only allowing the ports you need for your email > client. It's much less secure approach than blocking all but the email server address. With a port filter, the attacker only needs to use that same port for the attack to succeed. -- i. -- 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/alpine.DEB.2.20.1805170016590.32415%40whs-18.cs.helsinki.fi. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] split-gpg export QUBES_GPG_DOMAIN doesnt survive the reboot
On Thu, 10 May 2018, qubes-...@tutanota.com wrote: > I set up the split-gpg with vault-safe VM, where my private keys are stored, > and the work VM, with pub keys and server communication. > > All runs well after executing the > [user@work ~]$ export QUBES_GPG_DOMAIN=vault-safe > > The issue is, that the export doesnt survive rebooting the work VM, and I > need to export it again. Is it a Qubes preset, and needs to be executed > every reboot, or am I missing something? Put that export into the startup file of the shell. -- i. -- 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/alpine.DEB.2.20.1805101853480.1344%40whs-18.cs.helsinki.fi. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Mainboard buying advice :: Should we still avoid mainboards with Intel vPro ??
On Wed, 14 Mar 2018, taii...@gmx.com wrote: > On 03/13/2018 11:05 PM, brendan.h...@gmail.com wrote: > > > If I pull the WiFi card out and don’t connect the Ethernet port to anything, > > then I configure qubes to use only a usb WiFi adapter (as I indicated > > above), I’m pretty sure that the ME engine won’t be able to use any of the > > three network interfaces to phone home. For ME to work over a network, it > > has to have a driver for the network adapter. It is unlikely to have one for > > the USB adapter. > I would re-read what I stated before - a hypothetical backdoor can easily use > simple P2P DMA writes it doesn't need drivers. Given that should attack should make sure that device won't crash when such a hypotetical backdoor is using DMA while something else is using the device through the normal driver at the same time, I'd seriously consider removing at least the "simple" qualifier from there. Alternatively, the attack needs synchronization besides DMA which also invalidates your claim that simple P2P DMA is enough. -- i. -- 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/alpine.DEB.2.20.1803140939280.5829%40whs-18.cs.helsinki.fi. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] reboot sys-net
On Fri, 2 Feb 2018, Bernhard wrote: > Did by chance someone write a dom0-script that > > a) fetches a list of all (running) appvm's that use sys-net. > > b) setting their net-vm to "none" > > c) reboot sys-net > > d) undoes step (b) > > That would allow to confortably reboot sys-net (same ideas apply to > sys-firewall & sys-whonix) and could help many people in many > situations. I am not a bash hero, and before losing half a day on this > useful script, I prefer asking if someone did it already :) I didn't have it already but it wasn't too difficult to do so I wrote one as it seems somewhat useful. -- i. -- 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/alpine.DEB.2.20.1802021230410.15025%40whs-18.cs.helsinki.fi. For more options, visit https://groups.google.com/d/optout. #!/bin/sh vm="sys-net" [ $# -ge 1 ] && vm="$1" echo "Restarting $vm..." explicitlist=$(qvm-ls --raw-data state netvm name-raw | \ grep -e "^Running|$vm|" | cut -d '|' -f 3) defaultlist=$(qvm-ls --raw-data state netvm name-raw | \ grep -e "^Running|[*]$vm|" | cut -d '|' -f 3) for i in $explicitlist $defaultlist; do qvm-prefs -s $i netvm none done qvm-shutdown --wait "$vm" qvm-start "$vm" for i in $explicitlist; do qvm-prefs -s $i netvm "$vm" done for i in $defaultlist; do qvm-prefs -s $i netvm default done
Re: [qubes-users] Re: Slow network speed outside netvm
On Fri, 2 Feb 2018, Jarle Thorsen wrote: > Ilpo Järvinen: > > Can you try if you get better throughput between a proxy vm and an appvm > > using this kind of topology? > > > > sys-net <-> iperf-srv (proxyvm) <-> iperf-cli (appvm) > > > > I could push ~10Gbps with one flow and slightly more with more parallel > > flows between them. > > Great find Ilpo! Did you have to do some iptables-trickery for this > testing? I have ping working between proxy and appvm, but iperf and nc > both tell me no route to host? Yes, I did (it replies with ICMP by default). You'll need to fill in the vif IP-address to this command: sudo iptables -I INPUT 1 -i vif+ -p tcp -d ***proxyvmIPhere*** -j ACCEPT -- i. -- 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/alpine.DEB.2.20.1802021026390.13281%40whs-18.cs.helsinki.fi. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Slow network speed outside netvm
Can you try if you get better throughput between a proxy vm and an appvm using this kind of topology? sys-net <-> iperf-srv (proxyvm) <-> iperf-cli (appvm) I could push ~10Gbps with one flow and slightly more with more parallel flows between them. But between sys-net and iperf-srv vms I've a lower cap like you for some reason. I also tried to use similar parameter for the kernel too but 10Gbps result was still achievable. -- i. -- 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/alpine.DEB.2.20.1802012359200.6266%40whs-18.cs.helsinki.fi. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Slow network speed outside netvm
On Thu, 1 Feb 2018, Jarle Thorsen wrote: > Ilpo Järvinen: > > I'd next try to tweak the txqueuelen (at the netvm side): > > sudo ifconfig vifxx.0 txqueuelen > > > > Appvm side (eth0) seems to have 1000 but the other side (vifxx.0) has > > only 64 by default that seems a bit small for high-performance transfers. > > Thanks a lot for your help so far! > > Unfortunately setting txqueuelen to 1000 did not make any difference... I found this: https://wiki.xenproject.org/wiki/Xen-netback_and_xen-netfront_multi-queue_performance_testing It might be that roughly 4Gbps might be what you can get for cross-vm with one flow (but those results are quite old). I guess that there are by default two queues per vif (based on the kernel thread naming) which would explain why going beyond 2 VCPUs didn't help any. ...Now we only just need to figure out how to configure the number of queues to see if that has some impact on performance (ethtool seems to be unable to do that). ...And of course you'll need to use more than one flow to utilize all those queues anyway but I guess you tested also the inter-vm test with more than one flow? -- i. -- 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/alpine.DEB.2.20.1802011102270.18034%40whs-18.cs.helsinki.fi. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Slow network speed outside netvm
On Wed, 31 Jan 2018, Jarle Thorsen wrote: > Mike Keehan: > > > It sounds a bit ambitious to run 10gb per sec from one VM through > > another and onto the wire. I suspect you are memory speed limited > > if you are using a straightforward desktop pc. > > I'm not sure what is the limiting factor (memory speed, xen overhead?), > but I just did an iperf test between netvm and appvm only, and I still > maxed out at 4 Gbit/s. This test takes the network card out of the > equation and only tests the speed between the vms. Maybe somebody can do > similar tests on their system? > > > Do you know if anyone has achieved this? > > I don't know. I'd next try to tweak the txqueuelen (at the netvm side): sudo ifconfig vifxx.0 txqueuelen Appvm side (eth0) seems to have 1000 but the other side (vifxx.0) has only 64 by default that seems a bit small for high-performance transfers. -- i. -- 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/alpine.DEB.2.20.1802011018110.18034%40whs-18.cs.helsinki.fi. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Slow network speed outside netvm
On Wed, 31 Jan 2018, Jarle Thorsen wrote: > Ilpo Järvinen: > > Scatter-Gather. > > > > > Are you talking about enabling sg on the virtual network device in the > > > netvm? > > > > > > Something like "sudo ethtool -K vif12.0 sg on" ? > > > > Yes. For both that and the eth0 in appvm. > > This made a huge performance boost! (single threaded iperf went from > 1.34 Gbit/sec to 3.75 Gbit/sec in appvm after enabling SG) Please also check that GSO (generic-segmentation-offload) is on at the sending appvm eth0 (I don't remember if the depency logic causes it to get toggled off when SG was off'ed and cannot check it ATM myself). > I'm still far away from the speed I get inside the netvm though... Maybe > the netvm needs more than 2 vcpus to handle the stress from appvms? Could be. I'm not sure how your appvm is connected to netvm if there's firewall vm in between that would also be relevant. I guess you can try e.g. vmstat 1 in all vms through which the traffic passes through to see if any of them is saturating CPU. -- i. -- 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/alpine.DEB.2.20.1801311425510.29120%40whs-18.cs.helsinki.fi. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Slow network speed outside netvm
On Wed, 31 Jan 2018, Jarle Thorsen wrote: > onsdag 31. januar 2018 11.12.33 UTC+1 skrev Ilpo Järvinen følgende: > > On Wed, 31 Jan 2018, Jarle Thorsen wrote: > > > onsdag 31. januar 2018 10.50.09 UTC+1 skrev Jarle Thorsen følgende: > > > > My netvm (Fedora 26 template) has a 10gbe network card, and from > > > > within the netwm I have no problem saturating the 10Gbit link using > > > > iperf to an external server. > > > > However, in any vm sending traffic through this netvm I can only get > > > > around 2Gbit max using the same iperf command against the same server. > > > > > > > > I have this problem both with appvms using the *same* Fedora template > > > > as the netvm, and also in Windows HVM. > > > > > > > > Anybody have experience with Qubes in a 10Gbe network? > > > > > > I do notice the the process ksoftirqd in the netvm is running at 100% > > > cpu during the iperf test from the appvm. I'm guessing this is related > > > to my problem? > > > > SG being disabled for the qubes inter-vm interfaces (due to an unknown > > reason as Marek didn't anymore remember the details for that change) might > > have some(/huge?) impact on performance as it prevents using some > > high-speed features of the kernel. > > Not quite sure what "SG" is in this context. Is there any settings I can > experiment with? Scatter-Gather. > Are you talking about enabling sg on the virtual network device in the > netvm? > > Something like "sudo ethtool -K vif12.0 sg on" ? Yes. For both that and the eth0 in appvm. -- i. -- 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/alpine.DEB.2.20.1801311355370.29120%40whs-18.cs.helsinki.fi. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] ERROR: Device attach failed
On Sat, 27 Jan 2018, beso wrote: > On Saturday, January 27, 2018 at 4:33:47 PM UTC+2, awokd wrote: > > On Sat, January 27, 2018 2:20 pm, beso wrote: > > > > >> On Sat, January 27, 2018 6:31 am, beso wrote: > > >> > > >>> ERROR: Device attach failed: /usr/lib/qubes/usb-import: 37: [: > > >>> Illegal > > >>> number: stash: printf: I/O error. > > >>> How to solve this problem? > > >>> > > > > > Sorry, > > > > No trouble! > > > > > Qubes - 3.2; > > > Attached device - Samsung M3 Portable 1TB; > > > Command I used to attach to one of my appVm - qvm-usb -a appvm > > > sys-net:3-1; > > > > I'm assuming the ";" at the end of sys-net:3-1 is a separator and not > > actually part of the command you are entering, right? Has this device > > worked before on your system or is this the first time you are trying it? > > If it was working before, when did it start giving you the error? > > Yes, that is separator here. No, it never worked. I'd recommend you use qvm-block instead of qvm-usb (for block capable devices such as external HDDs). qvm-block should work even with usb3 connected devices. This particular error message you see is caused by a formating change in usbip status file for 4.9 kernels that is incompatible what qubes-usb-proxy expects. There's an updated version for qubes-usb-proxy in R3.2 testing repo that is capable of getting past this error (but ironically, even there there is inconsistency between assumed status file format and what 4.9 prints but it luckily affects only unused variables). However, qvm-usb will fail in R3.2 with even if this error is fixed based on the testing I did yesterday: usbip doesn't seem to, e.g., fall-back to highspeed but attempts to use superspeed that is only supported starting 4.13 kernel and you just get a different error message. -- i. -- 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/alpine.DEB.2.20.1801272200590.9381%40whs-18.cs.helsinki.fi. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: USB3 attach problem
On Wed, 24 Jan 2018, beso wrote: > On Thursday, January 25, 2018 at 5:01:00 AM UTC+2, cooloutac wrote: > > On Wednesday, January 24, 2018 at 2:35:14 PM UTC-5, beso wrote: > > > ERROR: Device attach failed: USB SuperSpeed require kernel >= > > > 4.13/usr/lib/qubes/usb-import: line 71: printf: write error: Invalid > > > argument > > > > I don't have this issue on 3.2. are you using 4.0? > > No, I use 3.2. Qubes usb-proxy recently gained support for USB3 [1] but perhaps it might need to check that the kernel is new enough to support it? R3.2 stable repo only has 4.9 series kernel in stable repo, whereas testing has new enough kernel. Perhaps these different experiences you see come from different kernel / usb-proxy versions installed? -- i. [1] https://github.com/QubesOS/qubes-app-linux-usb-proxy/commit/5f94e1064fd5946f127e1257062756be75f92f99 -- 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/alpine.DEB.2.20.1801251338050.29120%40whs-18.cs.helsinki.fi. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)
On Wed, 17 Jan 2018, Lorenzo Lamas wrote: > On Thursday, January 11, 2018 at 3:57:50 PM UTC+1, Andrew David Wong wrote: > > ## Qubes 3.2 > > > > For Qubes 3.2, we plan to release an update that will make almost all > > VMs run in a fully-virtualized mode. Specifically, we plan to backport > > PVH support from Qubes 4.0 and enable it for all VMs without PCI > > devices. After this update, all VMs that previously ran in PV mode (and > > that do not have PCI devices) will subsequently run in PVH mode, with > > the exception of stub domains. Any HVMs will continue to run in HVM > > mode. > > Is this the shim-based approach from XSA-254? No, it won't be a shim-based approach (see also the Marek's mail in this thread). > Then it should be made clear that the VM's will be more vulnerable to > Meltdown: Even if shims would be used, that "more" claim is false as Meltdown against the host hypervisor from PVs that are currently used in R3.2 expose both host and also the guest through the host hypervisor (its memory). With shims only the guest is still vulnerable, this time through the intermediate xen instance running in the HVM/PVH encapsulating the PV guest. Clearly it's "less" vulnerable rather than "more". Qubes has been trying to migrate away from PVs altogether (rather than e.g., placing PVs into those shims) due to PV vulnerabilities in general. In fact, even before these HW vulnerabilities were discovered, the process towards PVH was ongoing which is why R4.0 rcs as is are much better protected already. These vulnerabilities only accelerated this process. There will be, unfortunately, be one limitation to this migration still due to PCI passthrough: VMs with PCI devices need to remain PV (or their stubdoms in R4.0). > "Note this shim-based approach prevents attacks on the host, but leaves > the guest vulnerable to Meltdown attacks by its own unprivileged > processes; this is true even if the guest OS has KPTI or similar > Meltdown mitigation." > https://xenbits.xen.org/xsa/xsa254/README.which-shim Also, note that one of the fundamental assumption with Qubes security model is that the VMs _will get compromised_ (regardless of HW exploits). What Qubes aims to protect against is escalation from a compromised VM to host or to another VM. -- i. -- 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/alpine.DEB.2.20.1801172252250.29076%40whs-18.cs.helsinki.fi. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] sys-usb starts, but custom-usb vm fails with "Unable to reset PCI device..." (4.x-rc3)
On Wed, 3 Jan 2018, Dave C wrote: > I'd like to leave sys-usb as is, but create another usb vm for attaching > a keyboard (without networking). > > My problem is that my new "usb-keyboard" vm fails to start. With "Start > failed: internal error: Unable to reset PCI device :00:14.0: no FLR, > PM reset or bus reset available" > > I've tried the -o no-string-reset=True option, that had no effect. Is this just a typo in the email or was there one also in the command? It should be "strict", not "string". -- i. -- 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/alpine.DEB.2.20.1801032247190.16067%40whs-18.cs.helsinki.fi. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Installing screen-recorder in Dom0
On Mon, 30 Oct 2017, corpk...@gmail.com wrote: >I am aware of the security risks, but I need to be able to do screen > recordings of my work in Qubes OS. And as I understand it, the recorder needs > to run out of Dom 0. > > I have tried to use the following command to copy the installation files from > an AppVM to Dom0: > > qvm-run --pass-io personal '/home/user/Downloads/kazam.tar.gz' > > /home/myuser/Downloads/kazam.tar.gz cat is missing: qvm-run --pass-io personal 'cat /home/user/Downloads/kazam.tar.gz' > ... -- i. -- 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/alpine.DEB.2.20.1710301554240.3749%40whs-18.cs.helsinki.fi. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 3.2 dnsmasq update?
On Wed, 4 Oct 2017, Ron Hunter-Duvar wrote: > Saw the news earlier today about the major dnsmasq vulnerabilities (remote > code execution), and already received the update for the debian-8 template, > but not for the fedora-23 template or dom0. > > Anyone know of an ETA for this? dom0 does not have network connectivity. FC23 has been EOL'ed for long time, you should upgrade your template to FC25 or later (as FC24 likewise, is EOL'ed). The easiest alternative is to install fedora-25 template that is nowadays included to qubes repositories (IIRC). Then change your AppVMs having fedora-23 as their template to use fedora-25 template. -- i. -- 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/alpine.DEB.2.20.1710051049040.30385%40whs-18.cs.helsinki.fi. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Help finetuning i3status in Qubes dom0
On Tue, 3 Oct 2017, 'One7two99' via qubes-users wrote:
> Hello,
>
> [ ...snip...]
>
> 2) Extracted only the column which includes the RAM with
> [USER@dom0 ~]$ xl list | awk '{print $3}'
> Mem
> 4061
> 297
> 1424
> 1023
> 4095
> 44
> 3999
> **
> QUESTION: How can I remove the first line?
> **
| tail -n +2
--
i.
--
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/alpine.DEB.2.20.1710040011190.24024%40whs-18.cs.helsinki.fi.
For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Xorg and Oom killer, i3
On Sat, 15 Jul 2017, cyrinux wrote: > By VM, i mean Virtual Machine (we can say Qubes), I have at minimum 15 Qubes > running. > It is xorg in dom0 which is killed, I type 'dmesg' in dom0 terminal and see > it is killed. > I will retry to play with xentop. In idle my dom0 use 700MB (and 2200MB > cache)/~3000MB. > About reconnect to guid, before i use 'qvm-run --all true' to reconnect to > them, but after this OOM this doesn't work. Do you have an idea? You can increase maximal dom0 memory by tweaking grub cmdline to see if it helps. By default, dom0 is limited by dom0_mem=max:4096M. You should still try keep it less than what you have physically available (e.g., try 6G or 8G rather than going to some large number to avoid starving appvms from memory). -- i. -- 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/alpine.DEB.2.20.1707152215270.4611%40whs-18.cs.helsinki.fi. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] RAM available
On Sun, 11 Jun 2017, nimrod@gmail.com wrote: > I just upgrade the RAM on my laptop from 8GB to 16GB. > > But when i run cat /proc/meminfo in my terminal dom0, reports of 4GB. > The Qubes VM manager RAM column seems to sum to more than 8GB, however. Dom0 memory is intentionally limited to 4GB (and actually even less than that if your physical RAM would be smaller). Do you see some issue due to this limitation or you just noticed that it's limited? > Is there any way that can guarantee the total amount of RAM available > for my system Qubes? Qubes "system" has access to more memory than dom0 alone. Anyway, it's possible to tweak the 4GB limit from grub cmdlines but unless you have some issues, you probably shouldn't increase it. -- i. -- 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/alpine.DEB.2.20.1706112248260.21248%40whs-18.cs.helsinki.fi. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Does Bleachbit securely erase all data?
On Thu, 4 May 2017, Alex45 wrote: > have appvms where I store some of my banking data. > > bleachbit (as root) comes pre-installed with debian-8 > > > how do I make sure all my data is ERASED 100% ? > > Bleachbit > General Tab , shows me only one option to select > 'overwrite files to hide content' > > check this , select files in your trash bin and my unwanted files are > gone forever? If you have SSD, there's unfortunately little an AppVM can do to really erase its data as the SSD controller is free to relocate AppVM's data blocks elsewhere on the physical device when you overwrite to them. In contrast to HDDs, the SSD controllers really do that relocating whole the time to increase the lifespan of the drive and at least some forensics may still reveal the previous version of the data. -- i. -- 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/alpine.DEB.2.20.1705042205080.16190%40melkinpaasi.cs.helsinki.fi. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Intel ME exploitable
On Mon, 1 May 2017, Vít Šesták wrote: > * I wonder what does “exploitable locally” mean. If physical access is > required, I am not sure what would attacker gain (AEM bypass at most, I > guess). If it allows unprivileged user to elevate privileges, this might > be interesting for Qubes, depending on the attack vector: If it requires > attack over network interface, then sys-net can perform it. If it > involves ME software for the OS (maybe for accessing the MEI PCI > device), we should be adequately isolated on Qubes. I hope that Qubes > adds some protection in any case and it is not exploitable from other > VMs than sys-net. The PDF from Intel linked earlier was pretty clear on this locally exploitable thing (when one connects the dots). It states "Disable LMS services" which according to description listens on some ports and forwards that traffic to ME/AMT (supposedly using the PCI interface). The reason for that is that ME/AMT has a fancy filter in NIC that automatically captures only incoming packets to enable remote administration (without host OS knowing anything about them) BUT a local machine/user cannot send incoming packets as it would require loopbacking eth cable. To make (some?) ME/AMT capabilities available locally, LMS seems to provide a cludge that forwards those local requests to ME/AMT using the local PCI device which allows an attacker to reach the vulnerable ME/AMT. The document also stated that one should prevent re-enabling LMS and that admin has necessary rights to exploit so it doesn't matter whether such user can reinstall LMS or not (LMS is a Windows service anyway but without much doubt, the attack would also work in Linux too if the attacker can access the MEI PCI device). However, it remains unclear how an ME/AMT exploit adds to what admin already can do (probably nothing that significant really). -- i. -- 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/alpine.DEB.2.20.1705021006180.2118%40melkinpaasi.cs.helsinki.fi. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Intel ME exploitable
On Mon, 1 May 2017, 'Lolint' via qubes-users wrote: > Confirmation by Shintel: > https://downloadmirror.intel.com/26754/eng/INTEL-SA-00075%20Mitigation%20Gu > ide%20-%20Rev%201.1.pdf So it requires either network connection to an ME aware NIC or, unsuprisingly, access to some local HW interface of ME (that is used by LMS that is a Windows thing). It's somewhat doubtful that such HW interface would be available for other than dom0 under Qubes. Thus it doesn't sound too bad, except for laptops with any kind of wireless wired to ME (wired NICs need not to be connected - ever, use USB device for providing ethernet instead if you want to avoid this kind of issues). -- i. -- 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/alpine.DEB.2.20.1705020031160.18054%40melkinpaasi.cs.helsinki.fi. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Severe Lagging after latest dom0 , seeking backup solution
On Wed, 26 Apr 2017, Mike ru q fed wrote: > Update of qubes.foo.* and Xen-4.6.4-26.fc23 x86_64 packages in Dom0 -> slow > lagging mouse and window behavior ; luckily I new qube user and just kept > reinstalling, which fixed the behaviour, I've update debian and fedora and > whonix now and all is well, however, I'd like to update dom0 but don't > trust it, after specifically updating only the packages labeled qubes-xxx > and Xen-xxx , rebooting and confirming the problem. > > I was told on reddit that this is a known issue, however, reviewing the > newsgroup I don't see any mention of lag after dom0 updates, I not expert > level with linux , but used Debian back in the day , so can handle a certain > level of tweaking only Now that you mention, I've also recently seen some GUI lagging I've not experienced before. However, also the combination of vms/applications I'm using while the lag appears is something I've not used before so I cannot be sure if it's new or not. If it is a new issue, I don't think xen has much to do with it since I've run 4.6.4 for quite long time already. And before somebody suggests, this GUI lagging is unrelated to the VM freeze issue that is known to be caused by the gui-agent changes (and a fixed version of it is already in -testing repo). No freezing occurs, just slow to draw and somewhat lagging input side. -- i. -- 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/alpine.DEB.2.20.170427100.522%40whs-18.cs.helsinki.fi. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: [qubes-devel] Announcement: Qubes OS Begins Commercialization and Community Funding Efforts
On Wed, 30 Nov 2016, Andrew David Wong wrote: > Commercial editions of Qubes OS will be customized to meet special corporate > requirements. For example, two features that might be particularly > attractive to corporate customers are (1) "locking down" dom0 in order > to separate the user and administrator roles I suppose this implies there is unlikely to be support for multi-user environment for a shared computer any time soon except for commercial users (e.g., within a family with one of the user effectively having a sort of "administator role" and the other users would have less priviledges)? If yes, are the core devs/maintainers going to actively oppose inclusion of feature(s) which would make the multi-user case easier/feasible if it is provided by somebody from community? I suppose it could be seen overlapping functionality and therefore rejected on technical grounds (or it might be even thought to deincentivize from getting the commercial version). I understand the economical realities, so please don't take this as complaining of any sort, I'm just asking what is the expected position here. -- i.
Re: [qubes-users] detecting malicious usb devices
On Tue, 25 Oct 2016, Vít Šesták wrote: > I am not sure if the devices can sniff both directions. I've believed > that a device can sniff only inbound data and cannot communicate with > other devices. I've tried to look for some document that would allow me > to be sure about this, but I've found nothing. Well, the official > documentation would likely contain enough information, but it seems to > be quite large. USB2 downstream traffic (towards device) seems to be broadcasted and USB3 is routed only to the particular device due to power considerations. Some exceptions to that USB2 rule based on different USB speeds. The speed restrictions seem quite safe electrically too - assuming firmware level only compromizes - because of different signalling voltage levels (a dual speed capable sniffing transreceiver does not seem too convincing threat as possibility deploying them to a victim probably should allow much easier to accomplish attacks too). The USB2 upstream is different and is seen only by the hubs on the path towards the host and the host itself. Whether upstream isolation and USB3 downstream routing is really safe w.r.t. firmware attacks, I don't know (do hubs use firmware or not?). Based on information here: http://www.totalphase.com/support/articles/200349256-USB-Background In general, USB is a full "bus" only logically, not electrically due to tiered-star topology. -- i. -- 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/alpine.DEB.2.10.1610252145090.18027%40melkinpaasi.cs.helsinki.fi. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Switch of DMA altogether..?
On Sat, 8 Oct 2016, neilhard...@gmail.com wrote: > DMA allows network card to read/write RAM. > > DMA attack allows one already-compromised VM to read the RAM of another > VM, thus breaching Qubes isolation... unless you use VT-D, although > flaws in VT-D have been shown. > > Remote DMA attack allows packets sent to the network card directly over > the web, not even having to compromise your VM first... as demonstrated > in the paper by the French intel agency. > > That is what I understand so far. Hence, why I am asking if using PIO > rather than DMA would prevent such attacks. So if a driver won't use DMA, how that would prevent device itself from initiating DMA transactions? I'm somewhat doubtful that it would be so simple as I suspect the compromized device need not to care what the driver uses, be it PIO or DMA (but I'm not a PCI expert so I could be wrong too). -- i.
Re: [qubes-users] Re: Benefits of running Qubes on server-grade hardware?
On Sat, 3 Sep 2016, Andrew David Wong wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On 2016-09-03 04:58, grzegorz.chodzi...@gmail.com wrote: > > W dniu sobota, 3 września 2016 13:37:27 UTC+2 użytkownik pixel > > fairy napisał: > >> On Saturday, September 3, 2016 at 2:32:54 AM UTC-7, > >> grzegorz@gmail.com wrote: > >> > >>> Can it take advantage of ECC RAM? Server hardware that is few > >>> years old can be bought for dirt cheap (Xeon E5-2670 has 8 > >>> cores and costs about 75$). > >>> > >>> I'll be upgrading from my current PC and I'm seriously > >>> considering building a rig around a Xeon processor and a > >>> motherboard with ECC RAM but if there is no real benefit then > >>> what's the point? > >> > >> apparently price is the advantage, but think of your ears! > >> server hardware is loud. > >> > >> if your willing to spend more on good hardware, go for a good > >> ssd, and good ddr4 ram (G.Skill or Geil) in case bitflipping > >> attacks start showing up. > >> > >> http://news.softpedia.com/news/rowhammer-attack-now-works-on-ddr4-mem > ory-501898.shtml > > > > Xeon it is then. As for the rowhammering attack as far as I know > > ECC RAM is not vulnereable to that. Sandy Bridge (E5-2670) does not support DDR4. All DDR3 designs probably predate rowhammer discovery, so I wouldn't really trust them to properly mitigate rowhammer attacks as it was not a factor when the chips were designed. Obviously rehashing old products is even less likely to occur due to cost and soon to be obsoleted products. When considering rowhammer, TRR (targeted row refresh) is much more important feature than ECC actually, and Xeons at least should supports TRR (probably since Ivy Bridge although that bit of information is based on sources I wouldn't fully trust, i.e., some random vendor marketing material, IIRC). AFAIK, there is no publically available official confirmation from Intel that Xeons really do support TRR, however, there are some errata entries that indicate that TRR with LRDIMMs won't work which indicates that it likely works with RDIMMs at least. Thus, it seems mainly as a problem of finding RDIMM that actually implements TRR properly and likely also a motherboard which enables CPU's TRR functionality is needed. AFAIK, there is no information whether non-E5/E7 CPUs would support TRR or not. > Unfortunately, that's not true: > > "Tests show that simple ECC solutions, providing single-error > correction and double-error detection (SECDED) capabilities, are not > able to correct or detect all observed disturbance errors because some > of them include more than two flipped bits per memory word." > > https://en.wikipedia.org/wiki/Row_hammer#Mitigation While I don't doubt a second that there are vulnerable ECC memories too (especially DDR3 ones), I noticed one interesting oddity in the recent DRAMA attack paper: The paper first mentions that their dual E5-2630 v3 system is fitted with Samsung DDR4 ECC RDIMM when they did the address bits reverse engineering part. However, later in the paper when they actually exploited rowhammer bugs, the dual E5-2630 v3 system is, for some reason, reconfigured to use Crucial DDR4s. Could it perhaps indicate that they (while not reporting it), didn't succeed in rowhammer against Samsung ones so they tried to other ones just to prove a point... It would make things very interesting if that would be true. In the last Spring rowhammer paper, Micron-based DIMMs seemed to be particularly bad (close to magnitude worse than the other brands mostly, IIRC) so the ability to trigger rowhammer issues with Micron-based DDR4 ECCs in particular doesn't surprise me that much. I know that Micron mem chip specs indicate as if they would have some non-TRR based solution built-in but that doesn't seem to help (or work). Other vendors information I've come across: * Samsung: DDR4 specs mention TRR support and have timing diagrams on how that is performed. One presentation with a high ranked Samsung person as the author claims that rowhammer is mitigated in their DDR4s (or it might have mentioned TRR directly, I don't remember anymore the wording) * IIRC, both Hynix and Intel have a patent related to rowhammer but that won't prove anything about real products > > t's a shame that the more powerful Xeon CPUs don't come with a > > built in GPU, I'll have to make do with a current one. Added > > benefit here is that pretty much all Xeons support technologies > > necessary for Qubes 4.0 compliance. Wonder why they aren't more > > popular among desktop users. Indeed. Given how much effort Intel has put into GPU virtualization, it's really shame that there aren't any more than 4 core CPUs with iGPU in the first place and as far as the leaks about upcoming ones can be trusted, there won't be any in the near future either (but take this with a grain of salt obviously). It would be quite interesting product especially as Intel seems to really put
Re: [qubes-users] Re: VM CPU mapping - countermeasurements against covert channels via cpu caches?
On Tue, 28 Jun 2016, 12384013418489'14'810'4 wrote: > would be the Intel Skylake Technology SGX a solution, so that the keys > cannot be read from the crypto processes? In these covert attacks, the keys are not "read" but leaked. Those leaks are unlikely to be solved by SGX as it's not the threat it is used to counter (i.e., SGX prevents reading of those DRM keys directly from RAM in plain text form :-)). With SGX, the memory is encrypted so that it cannot be "read", however, the CPU still does calculations of an SGX enclave the same way as without them which creates the opportunity for the very same covert channels to form. Other interesting technology in this domain is ability to somehow control cache allocations that is available at least with Broadwell Xeons. However, I'm not convinced it can fully remove cache-based covert channels either. -- i.
Re: [qubes-users] SUCCESS: GPU passthrough on Qubes 3.1 (Xen 4.6.1) / Radeon 6950 / Win 7 & Win 8.1 (TUTORIAL + HCL)
Great to hear you got it working! I've done some googling related to techniques you mention below and I want to share some thoughts / information related to them. On Wed, 22 Jun 2016, Marcus at WetwareLabs wrote: > If you still don't get passthrough working, make sure that it is even > possible with you current hardware. Most of the modern (<3 years old) > working GPU PT installations seem to using KVM (I got even my grumpy NVidia > GTX 980 functional!), so you should at least try creating bare-metal Arch > Linux installion and then following instructions here: > https://bufferoverflow.io/gpu-passthrough/ > or Arch wiki entry here: > https://wiki.archlinux.org/index.php/PCI_passthrough_via_OVMF > or a series of tutorials here: > http://vfio.blogspot.se/2015/05/vfio-gpu-how-to-series-part-1-hardware.html > > > Most of the instructions are KVM specific, but there's lot of great > non-hypervisor specific information there as well, especially in the latter > blog. Note that all the info about VFIO and IOMMU groups can be misleading > since they are KVM specific functionality and not part of Xen (don't ask me > how much time I spent time figuring out why I can't seem to find IOMMU group > entries in /sys/bus/pci/ under Qubes...) This contradicts what I've understood about PCI ACS functionality. IOMMU groups may be named differently for Xen or not exist (I don't know, it's news to me that they don't exist), but lack of PCI ACS functionality is still a HW thing and according to my understanding the same limit on isolation applies regardless of hypervisor. ACS support relates how well, that is, how fine-grained, those "IOMMU groups" were partitioned. Each different group indicates a boundary were IOMMU is truly able separate PCIe devices and are based on HW limitation not on a hypervisor feature. Unfortunately mostly high-end, server platforms have true support of ACS (some consumer oriented ones support it only inofficially, see drivers/pci/quirks.c for the most current known to support list). Lack of ACS may not be a big deal to many. But it may limit isolation in some cases, most notably having storage on PCIe slot connected SSDs and GPU passthrough. And passing through more than a single GPU to different VMs might have some isolation related hazards too because of the usual PCIe slot arrangement. But one likely needs deep pockets to have such arrangements anyway, so going to server or high-end platform may be less of a issue to begin with :-). > One thing about FLReset (Function Level Reset): There's quite general > misconception about FLR being a requirement in order to do GPU passthrough, > but this isn't true. As a matter of fact, not even the NVidia Quadros have > FLR+ in PCI DevCaps, and not many non-GPU PCI devices do either. So even > though the how-to here (http://wiki.xen.org/wiki/VTd_HowTo) states > otherwise, the missing FLR capability will not necessarily mean that device > can't be used in VM, but could only make it harder to survive DomU boot. > I've seen in my tests that both Win 7 and Win8 VMs can be in fact booted > several times without a requirement to boot Dom0 (but hopping BETWEEN the > two Windows versions will result in either BSOD or Code 43). But again, this > may wary a lot with GPU models and driver versions. But anyway, if you see > this message during VM startup: > lbxl: error: The kernel doesn't support reset from sysfs for PCI > device ... > ... you can safely ignore it FLR is "needed" for reseting the device "safely" (after first init, if a reset is needed), not for the passthrough. But there seem to be some other ways which can usually result good enough reset and don't depend on FLR support. I've not yet come across any indication that there would be _any_ GPU that would even claim support FLR (whether that would work is yet another big question mark :-)). As you have noted, the issues seem to occur more frequently when trying to reassign the PCI device to another VM which has practical implications only to subset of usage scenarios. But also rebooting a VM may obviously fail due to too incomplete reset of PCI device state. And this same reset limitation applies to non-GPU devices too, USB controllers being the most important I can immediately think off. Luckily 3.2 with support for USB passthrough will make this less of a issue. Again, the FLR support of other devices seems better with server/high-end platforms. -- i. -- 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/alpine.DEB.2.10.160644230.2800%40melkinpaasi.cs.helsinki.fi. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 3.2RC1: number of issues
On Tue, 21 Jun 2016, Dima Puntus wrote: > 3. Dom0 is only seeing 3.8GB RAM. Is this by design? I can still allocate > 10GB+ for individual VMs so the RAM must be visible by Xen. It's by design. However, this same limit was already implemented at least for 3.1 that uses 1-4GB dom0 memory depending on how much memory the machine has. Is there some particular issue associated to this question or you just noticed the limit? IIRC, there's some parameter for this limit on some of the boot related commandlines. -- i. -- 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/alpine.DEB.2.10.1606221320300.3737%40whp-28.cs.helsinki.fi. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] clarification on usb qubes
On Mon, 6 Jun 2016, raahe...@gmail.com wrote: > In order to have 3 usb controllers the only board I have found where > this might be possible is with a 2011 socket board, and a board that > has a bios that gives the ability to manually route the controllers. > But who knows how compatible with linux the newer boards are at the > moment, might run into other problems since not many people using them > yet. Can you point me to some example motherboard? I've looked more than dozen X99/C612 board manuals recently but I've not come across one so far with such options. I'd be interested in seeing the bios part of the motherboard's manual. Or do you refer to Sandybridge/Ivybridge MBs with the "2011 socket"? If such a board really exists, it would further reinforce that it may be possible also for the OS to play with the forwarding (such forwarding forcing code already exists in Linux XHCI driver anyway, it's just a question if the supported mask has any/all bits enabled or not). If forwarding can be manipulated successfully, then superspeed would not need to be disabled to differentiate the USB ports to different controllers. Usually the manuals I've seen list only "legacy USB support", etc. toggleable options. Although given the naming, I wouldn't be surprised if some of those more standard bios options could be used to disable the auto-forwarding. According to my understanding the reason behind the forwarding is that if OS doesn't have necessary device drivers for one of the controllers some of the ports wouldn't work, which would be too confusing to many users. -- i.
Re: [qubes-users] clarification on usb qubes
On Sun, 5 Jun 2016, Marek Marczykowski-Górecki wrote:
> On Sat, Jun 04, 2016 at 06:13:45PM -0700, pixel fairy wrote:
>
> > Is it possible to have multiple usb qubes, one
> > for each controller?
>
> Yes, if you have multiple USB controllers. Which is quite rare
> nowadays...
At least for recent desktop motherboards, that seems slightly incorrect
statement according to my research. Few desktop PCH datasheets I've
looked, indicate that there are two USB controllers (EHCI and XHCI),
however, it seems that typically on a modern MB the ports are
forwarded/routed by default so that they appear under a single controller
due to ease of use reasons (also Linux device driver code forces
forwarding all ports which allow forwarding). XHCI PCI config has XUSB2PR
register that might allow disabling the forwarding for a selected set of
registers.
I'm yet to test if the forwarding/routing works for real because I lack
such a motherboard (I'll likely get one sooner than later though) but I
see no particular reason why it wouldn't work as documented. Probably
laptop PCH have similar arrangement and I might be able to test that one
soon if I find enough time to play with the usbvm kernel. Another thing
that needs testing, even if routing is configurable, is whether PCHs
really support EHCI and XHCI in different VMs or if there's some
other limiting depency between them.
I've attached potentially working patch for Linux kernel. The mapping
between PCI register ports might not be consistent though so that the
patch might not exactly do what intented as is (usb3/superspeed port
might unintentionally be routed to EHCI, the docs are unclear on this
point). However, if any USB port would successfully appear as EHCI one
when using a kernel with that patch in usb vm, it is great success in
itself on truly separating the ports.
At least X99/C612 and some recent Series X PCH datasheets listed the
required register (in case somebody is interested in testing this).
I suspect that for a secure implementation Xen would need to somehow
arbitrate that PCI register as otherwise the xhci usb VM might be able
to steal the usb ports from the ehci VM. But this is already way beyond
my current level of understanding about Xen and PCI passthrough.
--
i.
--
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/alpine.DEB.2.10.1606052218040.12951%40melkinpaasi.cs.helsinki.fi.
For more options, visit https://groups.google.com/d/optout.
diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index 26cb8c8..87fca0f 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -867,6 +867,7 @@ static int handshake(void __iomem *ptr, u32 mask, u32 done,
void usb_enable_intel_xhci_ports(struct pci_dev *xhci_pdev)
{
u32 ports_available;
+ u32 ports_usb3;
bool ehci_found = false;
struct pci_dev *companion = NULL;
@@ -920,6 +921,7 @@ void usb_enable_intel_xhci_ports(struct pci_dev *xhci_pdev)
pci_read_config_dword(xhci_pdev, USB_INTEL_USB3_PSSEN,
_available);
+ ports_usb3 = ports_available;
dev_dbg(_pdev->dev,
"USB 3.0 ports that are now enabled under xHCI: 0x%x\n",
ports_available);
@@ -931,6 +933,8 @@ void usb_enable_intel_xhci_ports(struct pci_dev *xhci_pdev)
pci_read_config_dword(xhci_pdev, USB_INTEL_USB2PRM,
_available);
+ /* Only switch ports that are truly SuperSpeed capable. */
+ ports_available &= ports_usb3;
dev_dbg(_pdev->dev, "Configurable USB 2.0 ports to hand over to xCHI: 0x%x\n",
ports_available);
