Re: [qubes-users] HCL - Dell Inspiron 15 5000 (5575) AMD Ryzen 5 2500U w/ Vega 8 Graphics

2019-12-22 Thread Claudia
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

2019-12-22 Thread Claudia
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

2019-12-22 Thread Vít Šesták
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

2019-12-21 Thread Claudia
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

2019-12-20 Thread Claudia
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

2019-12-20 Thread brendan . hoar
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

2019-12-20 Thread Claudia
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.