Re: [qubes-users] HCL - Dell Inspiron 15 5000 (5575) AMD Ryzen 5 2500U w/ Vega 8 Graphics
December 22, 2019 5:45 PM, "Vít Šesták" wrote: > Helllo, > > Dec 22, 2019 15:17:27 Claudia : > > >> I don't know which step -- unbinding xhci_pci, or binding pciback -- >> actually causes the crash in > this case. I can say, however, that one of them does cause an immediate > crash, before sys-usb ever > starts or has a chance to take over the USB controllers. > > That (and the specific script) is an interesting finding. Maybe it would be > possible to run the > commands one-by-one to see which one crashes the system. > I think I might try that sometime, just out of curiosity. > BTW, could you confirm that the USB Controller is an AMD one? This could be > helpful for anyone > wanting a Qubes laptop with AMD. > Yes, as far as I can tell. 03:00.3 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] Raven USB 3.1 [1022:15e0] 03:00.4 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] Raven USB 3.1 [1022:15e1] -- 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/bdc095fbe5db7ccce547c6d1e09c%40disroot.org.
Re: [qubes-users] HCL - Dell Inspiron 15 5000 (5575) AMD Ryzen 5 2500U w/ Vega 8 Graphics
December 22, 2019 10:33 AM, "Vít Šesták"
wrote:
> As far as I know/understand:
>
> * At start, all the PCI devices are assigned to dom0.
> * When a qube with an attached PCI device starts, dom0 assigns the PCI device
> to the qube, so it is
> no longer attached to dom0. It never gets actually attached to dom0
> automatically (until reboot).
> If it was, a malicious qube could for example flash a malicious firmware to a
> USB device and shut
> down in order to connect the malicious device to dom0.
> * In order to have some additional protection, rd.qubes.hide_all_usb hides
> all USB devices. That
> is, the USB PCI device is attached to dom0, but Linux ignores it, maybe it
> blacklists related
> kernel modules.
>
> The behavior you have observed suggests that both detached USB controller and
> ignored USB
> controller cause an issue. So, maybe the problem is not in the process of
> detaching a controller
> that is being used, but rather in not having the controller available.
>
> Intel includes some USB controller in CPU and quick Googling suggests that so
> does AMD. Maybe there
> is some AMD-specific code in Linux kernel that expects the USB controller to
> be available for
> whatever weird reason. Yes, it sounds strange, but it is the least
> implausible explanation I was
> able to find.
>
> Regards,
> Vít Šesták 'v6ak'
Thanks for the info. Yes, that sounds correct from what I could tell, too. More
specifically, what rd.qubes.hide_all_usb actually does is looks for USB
controllers device files in /sys/bus/pci, and then calls their driver/unbind,
driver/new_slot, and driver/bind functions. So basically, it forces the Linux
USB driver (xhci_pci, in my case) to detach from the USB controller, and then
attaches it to Xen's pciback driver so that it can be used by sys-usb later
(although I don't know if this step is actually necessary, since starting
sys-usb without hide_all_usb works just fine). I'm assuming this step happens
before udev trigger, which probes devices including USB devices. Maybe that's
why the hook assigns pciback instead of just unbinding the USB driver - so udev
doesn't see that the device has no driver and attempt to bind the USB driver to
it again. Or maybe the act of binding pciback is what actually places the USB
controller under IOMMU isolation by Xen (otherwise the USB controller could
still perform a DMA attack even with no driver bound to it).
I don't know which step -- unbinding xhci_pci, or binding pciback -- actually
causes the crash in this case. I can say, however, that one of them does cause
an immediate crash, before sys-usb ever starts or has a chance to take over the
USB controllers.
The same hook does the same thing for networking devices as well, so that those
are never exposed. In my case this doesn't cause a problem because both network
cards are their own devices on their own busses and have their own IOMMU
groups, unlike my USB controllers.
Here's the actual code from
/usr/lib/dracut/modules.d/99qubes-pciback/qubes-pciback.sh
#!/usr/bin/sh
type getarg >/dev/null 2>&1 || . /lib/dracut-lib.sh
# Find all networking devices currenly installed...
HIDE_PCI="`lspci -mm -n | grep '^[^ ]* "02'|awk '{print $1}'`"
# ... and optionally all USB controllers...
if getargbool 0 rd.qubes.hide_all_usb; then
HIDE_PCI="$HIDE_PCI `lspci -mm -n | grep '^[^ ]* "0c03'|awk '{print $1}'`"
fi
HIDE_PCI="$HIDE_PCI `getarg rd.qubes.hide_pci | tr ',' ' '`"
modprobe xen-pciback 2>/dev/null || :
# ... and hide them so that Dom0 doesn't load drivers for them
for dev in $HIDE_PCI; do
BDF=:$dev
if [ -e /sys/bus/pci/devices/$BDF/driver ]; then
echo -n $BDF > /sys/bus/pci/devices/$BDF/driver/unbind
fi
echo -n $BDF > /sys/bus/pci/drivers/pciback/new_slot
echo -n $BDF > /sys/bus/pci/drivers/pciback/bind
done
As for USB controllers being on the CPU, yes that's what I found as well; all
current CPUs bundle their integrated USB controllers right on the chip. I don't
think code in the Linux kernel expects the USB controllers to be available.
Rather I think it has to do with IOMMU grouping, which tends to be structured
differently for AMD than Intel. I'm going to start a new thread about that here
soon.
--
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/7b07608331097f1747144fff3291f423%40disroot.org.
Re: [qubes-users] HCL - Dell Inspiron 15 5000 (5575) AMD Ryzen 5 2500U w/ Vega 8 Graphics
As far as I know/understand: * At start, all the PCI devices are assigned to dom0. * When a qube with an attached PCI device starts, dom0 assigns the PCI device to the qube, so it is no longer attached to dom0. It never gets actually attached to dom0 automatically (until reboot). If it was, a malicious qube could for example flash a malicious firmware to a USB device and shut down in order to connect the malicious device to dom0. * In order to have some additional protection, rd.qubes.hide_all_usb hides all USB devices. That is, the USB PCI device is attached to dom0, but Linux ignores it, maybe it blacklists related kernel modules. The behavior you have observed suggests that both detached USB controller and ignored USB controller cause an issue. So, maybe the problem is not in the process of detaching a controller that is being used, but rather in not having the controller available. Intel includes some USB controller in CPU and quick Googling suggests that so does AMD. Maybe there is some AMD-specific code in Linux kernel that expects the USB controller to be available for whatever weird reason. Yes, it sounds strange, but it is the least implausible explanation I was able to find. Regards, Vít Šesták 'v6ak' -- 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/744c4e79-efef-475a-a3dd-41fd3ded10b3%40googlegroups.com.
Re: [qubes-users] HCL - Dell Inspiron 15 5000 (5575) AMD Ryzen 5 2500U w/ Vega 8 Graphics
December 20, 2019 9:13 PM, "Claudia" mailto:claud...@disroot.org?to=%22Claudia%22%20)> wrote:
December 20, 2019 6:05 PM, brendan.h...@gmail.com
(mailto:brendan.h...@gmail.com) wrote:
On Friday, December 20, 2019 at 9:29:55 AM UTC-5, Claudia wrote:December 19,
2019 12:13 AM, "Claudia" wrote:
> This is R4.1 build 20191013
>
> It works pretty well, definitely better than 4.0, but there are some weird
> boot issues. If I let it
> boot with everything as default, it will boot loop before reaching the disk
> password screen. I
...Looks like rd.qubes.hide_all_usb is what's causing it to crash. When I
remove it, it boots fine with the graphical splash and passphrase prompt.
Another AMD Ryzen user mentioned having the same problem a while back.
Something about AMD's IOMMU grouping of USB controllers, or something.
Unfortunately, (my understanding is) that exposes the dom0 to the USB ports.
Even if you have a sys-usb, dom0 is still exposed temporarily on boot.
Thanks for the tip. I actually thought removing that parameter just simply
disabled USB Qube functionality and attached all devices to dom0, but I guess
that's only when sys-usb is not running. Once sys-usb is running, it takes over
the USB controllers from dom0, I guess. It's just that they're exposed before
sys-usb starts, in that case.
It would be nice to have working, but I've never had a USB Qube before, even on
my old machine, so I haven't lost anything. I don't use a lot of USB devices,
and it's not a big part of my threat model. I'll play around with it when I
have a chance.
I realized I had disabled autostart for all VMs including sys-usb to speed up
boot time (systemctl disable sys-{net,usb,firewall,whonix}@qubesvm.se
(mailto:whonix...@qubesvm.se)rvice), and I hadn't actually run sys-usb at all
since then. I decided to start sys-usb while the system was running, and
everything went to hell: the screen froze, audio stopped, even the caps lock
light wouldn't come on.
So this isn't limited to hide_all_usb, just USB controller passthru in general
on this machine.
So I reinstalled 4.0.2-rc3, once again, this time without USB Qube, and
everything works (except suspend/resume which doesn't work anywhere except
Fedora 30, not even F29 iirc), including audio and amdgpu without nomodeset.
All this time I was blaming it on the old-ness of 4.0, but it was hide_all_usb
all along. The only reason I tried getting rid of hide_all_usb in 4.1 is
because the nomodeset trick didn't work in 4.1 so I had to continue
troubleshooting, whereas in 4.0 it worked and I moved on. And also grub makes
it way more convenient to modify boot options.
So in summary, for 4.0 and 4.1 alike, everything works except suspend/resume,
as long as you don't set up a USB Qube. I attached updated HCL reports to
reflect this, and will update them as I do more testing.
I'm going to try and figure out some of this IOMMU grouping stuff and start
another thread about this issue. But like I said, I never had a USB Qube
before, so I'm not going to miss it.
--
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/bbdf183debac9338e0f46d32bbcb%40disroot.org.
Qubes-HCL-Dell_Inc_-Inspiron_5575-20191220-220355.yml
Description: Binary data
Qubes-HCL-Dell_Inc_-Inspiron_5575-20191221-021654.yml
Description: Binary data
Re: [qubes-users] HCL - Dell Inspiron 15 5000 (5575) AMD Ryzen 5 2500U w/ Vega 8 Graphics
December 20, 2019 6:05 PM, brendan.h...@gmail.com (mailto:brendan.h...@gmail.com) wrote: On Friday, December 20, 2019 at 9:29:55 AM UTC-5, Claudia wrote: December 19, 2019 12:13 AM, "Claudia" wrote: > This is R4.1 build 20191013 > > It works pretty well, definitely better than 4.0, but there are some weird > boot issues. If I let it > boot with everything as default, it will boot loop before reaching the disk > password screen. I ...Looks like rd.qubes.hide_all_usb is what's causing it to crash. When I remove it, it boots fine with the graphical splash and passphrase prompt. Another AMD Ryzen user mentioned having the same problem a while back. Something about AMD's IOMMU grouping of USB controllers, or something. Unfortunately, (my understanding is) that exposes the dom0 to the USB ports. Even if you have a sys-usb, dom0 is still exposed temporarily on boot. Thanks for the tip. I actually thought removing that parameter just simply disabled USB Qube functionality and attached all devices to dom0, but I guess that's only when sys-usb is not running. Once sys-usb is running, it takes over the USB controllers from dom0, I guess. It's just that they're exposed before sys-usb starts, in that case. It would be nice to have working, but I've never had a USB Qube before, even on my old machine, so I haven't lost anything. I don't use a lot of USB devices, and it's not a big part of my threat model. I'll play around with it when I have a chance. -- 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/de0f6b78201db24d5474eeb050e09650%40disroot.org.
Re: [qubes-users] HCL - Dell Inspiron 15 5000 (5575) AMD Ryzen 5 2500U w/ Vega 8 Graphics
On Friday, December 20, 2019 at 9:29:55 AM UTC-5, Claudia wrote: > > December 19, 2019 12:13 AM, "Claudia" > > wrote: > > > This is R4.1 build 20191013 > > > > It works pretty well, definitely better than 4.0, but there are some > weird boot issues. If I let it > > boot with everything as default, it will boot loop before reaching the > disk password screen. I > ...Looks like rd.qubes.hide_all_usb is what's causing it to crash. When I > remove it, it boots fine with the graphical splash and passphrase prompt. > Another AMD Ryzen user mentioned having the same problem a while back. > Something about AMD's IOMMU grouping of USB controllers, or something. > Unfortunately, (my understanding is) that exposes the dom0 to the USB ports. Even if you have a sys-usb, dom0 is still exposed temporarily on boot. B -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/6269800c-11c5-4907-a63e-eca2ca5dfbf2%40googlegroups.com.
Re: [qubes-users] HCL - Dell Inspiron 15 5000 (5575) AMD Ryzen 5 2500U w/ Vega 8 Graphics
December 19, 2019 12:13 AM, "Claudia" wrote: > This is R4.1 build 20191013 > > It works pretty well, definitely better than 4.0, but there are some weird > boot issues. If I let it > boot with everything as default, it will boot loop before reaching the disk > password screen. I > found I can get it to boot successfully if I add to the Xen commandline > noreboot=1 loglvl=all > and remove from the linux commandline > rhgb quiet rd.qubes.hide_all_usb > > Still working on narrowing down which of those is/are responsible for fixing > the problem (I can't > figure out why any of them would). Looks like rd.qubes.hide_all_usb is what's causing it to crash. When I remove it, it boots fine with the graphical splash and passphrase prompt. Another AMD Ryzen user mentioned having the same problem a while back. Something about AMD's IOMMU grouping of USB controllers, or something. I'm planning on installing kernel-latest and I'll test it again when I do. -- 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/0b276a64d383722c4057879b527f261c%40disroot.org.
[qubes-users] HCL - Dell Inspiron 15 5000 (5575) AMD Ryzen 5 2500U w/ Vega 8 Graphics
This is R4.1 build 20191013 It works pretty well, definitely better than 4.0, but there are some weird boot issues. If I let it boot with everything as default, it will boot loop before reaching the disk password screen. I found I can get it to boot successfully if I add to the Xen commandline noreboot=1 loglvl=all and remove from the linux commandline rhgb quiet rd.qubes.hide_all_usb Still working on narrowing down which of those is/are responsible for fixing the problem (I can't figure out why any of them would). Improvements since 4.0: Screen power management works - brightness controls, and screen poweroff after inactivity (in 4.0 it would just blank but not power off) Audio works, which it did not work in 4.0 even after many days of troubleshooting amdgpu works correctly - doesn't freeze when booting without nomodeset Multimedia keys - not sure if they worked in 4.0 or not Still working: UEFI mode wifi touchpad keyboard Still NOT working: Suspend/resume Not tested (yet): Legacy mode HDMI audio & video USB Qube SD card reader Microphone Webcam Wired networking I'll try to do some more testing and update this thread when I have a chance. Just putting this out there for now. -- 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/ae710f3839c46261d257d7d188da32b9%40disroot.org. Qubes-HCL-Dell_Inc_-Inspiron_5575-20191218-015203.yml Description: Binary data
