desktop suspend breaks sys-usb/ CPU bug present

[Jon deps]

Hello, using the suspend function, when I awake the desktop, the usb
mouse non longer functions.

have a PS2 keyboard so was able to qvm-kill sys-usb and do qvm-start
sys-usb but it complained couldn't connect to qrexec or so and failed.

so qvm-start sys-usb a 2nd time and then the mouse functions again


is this to be expected, or is there something to fix ?


---
looking around journalctl I didn't find much but did find this

un 12 07:52:01 dom0 kernel: sd 5:0:0:0: [sdb] Starting disk
Jun 12 07:52:01 dom0 kernel: sd 1:0:0:0: [sda] Starting disk
Jun 12 07:52:01 dom0 kernel: pcieport 0000:00:1d.7: Intel SPT PCH root
port ACS workaround enabled
Jun 12 07:52:01 dom0 kernel: pcieport 0000:00:1d.3: Intel SPT PCH root
port ACS workaround enabled
Jun 12 07:52:01 dom0 kernel: ACPI: Waking up from system sleep state S3
Jun 12 07:52:01 dom0 kernel: CPU3 is up
Jun 12 07:52:01 dom0 kernel: cache: parent cpu3 should not be sleeping
Jun 12 07:52:01 dom0 kernel: cpu 3 spinlock event irq 147
Jun 12 07:52:01 dom0 kernel: installing Xen timer for CPU 3
Jun 12 07:52:01 dom0 kernel: CPU2 is up
Jun 12 07:52:01 dom0 kernel: MDS CPU bug present and SMT on, data leak
possible. See
https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html for
more details.
Jun 12 07:52:01 dom0 kernel: cache: parent cpu2 should not be sleeping
Jun 12 07:52:01 dom0 kernel: cpu 2 spinlock event irq 140
Jun 12 07:52:01 dom0 kernel: installing Xen timer for CPU 2
Jun 12 07:52:01 dom0 kernel: CPU1 is up
Jun 12 07:52:01 dom0 kernel: cache: parent cpu1 should not be sleeping
Jun 12 07:52:01 dom0 kernel: cpu 1 spinlock event irq 133
Jun 12 07:52:01 dom0 kernel: installing Xen timer for CPU 1
Jun 12 07:52:01 dom0 kernel: Enabling non-boot CPUs ...


went to the URL says something like I should be "enable CPU buffer
clearing"

but can't find how to do that, curious if it's actual needed ?



....moral of the story don't suspend your qubes desktop ?

[Daniel Moerner]

On Wednesday, June 12, 2019 at 2:29:12 PM UTC-4, Jon deps wrote:
> Hello, using the suspend function, when I awake the desktop, the usb
> mouse non longer functions.
>
> have a PS2 keyboard so was able to qvm-kill sys-usb and do qvm-start
> sys-usb but it complained couldn't connect to qrexec or so and failed.
>
> so qvm-start sys-usb a 2nd time and then the mouse functions again

This is a long-standing issue for some, resolved for some but not for others at different times. See https://github.com/QubesOS/qubes-issues/issues/4042

The situation has improved for me by getting kernel 4.19.43-1 from qubes-dom0-security-testing. You could try the new kernel. (But note that our problems might be a bit different, I never had a qrexec problem when restarting sys-usb after resume.)

If you need to automate restarting of sys-usb because you can't avoid this problem, you can add commands in /usr/lib64/pm-utils/sleep.d/52qubes-pause-vms for suspend and resume, e.g., qvm-shutdown sys-usb and qvm-start sys-usb. You might need to qvm-kill sys-usb before suspend to get this to work reliably.

Daniel

[Jon deps]

.....any idea on the "data leak possible" journal entry?

sounds a bit scary, maybe I need to look around in my UEFI to disable
some cache-ing ?


BTW, kudos to qubes team for the dom0 copy to clipboard widget , sure
makes it easier to get dom0 notes out !

[awokd]

Jon deps:

> On 6/12/19 8:14 AM, Jon deps wrote:

>> Jun 12 07:52:01 dom0 kernel: MDS CPU bug present and SMT on, data leak
>> possible. See
>> https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html
>> for more details.

>

> .....any idea on the  "data leak possible"    journal entry?
>
> sounds a bit scary,  maybe I need to  look around in my UEFI  to disable
>  some cache-ing ?

SMT should be off. Do you see that same message if you do a cold power
on? Also, in "sudo cat /boot/efi/EFI/qubes/xen.cfg", do you see
"smt=off" in the Xen options lines?

I wonder if there is a Xen bug making SMT re-enable after a resume.
Please check the above, then look in your UEFI options to disable
Hyperthreading/SMT.

[Mike Keehan]

There has been a thread on the Linux Kernel mailing list recently,
discussing the need to re-enable the SMT chips during resume else
something breaks, and then turn them off again. You may be one
of the unlucky ones to heave this affecting your system. I'm not
sure which new kernel the fix is in - may not be until 5.2 comes
out.

Mike.

[awokd]

Mike Keehan:

> There has been a thread on the Linux Kernel mailing list recently,
> discussing the need to re-enable the SMT chips during resume else
> something breaks, and then turn them off again. You may be one
> of the unlucky ones to heave this affecting your system. I'm not
> sure which new kernel the fix is in - may not be until 5.2 comes
> out.

Did they happen to mention if disabling it in UEFI config works around
the problem?

[Jon deps]

in my case turns out, I have an Intel i5 which apparently doesn't have
multithreading,

I did look around the UEFI anyway, and see no references to it

sudo cat /boot/efi/EFI/qubes/xen.cfg
has 4.19.43-1 smt=off


on cold reboot I don't see the kernel vuln journal entry



so I guess its as I suspected qubes isn't going to suspend well and
may break various things ??

[awokd]

Jon deps:

>
> in my case turns out, I have an Intel i5  which apparently doesn't have
> multithreading,
>
> I did look around the UEFI anyway, and see no references to it
>
> sudo cat /boot/efi/EFI/qubes/xen.cfg
> has 4.19.43-1   smt=off
>
>
> on cold reboot  I don't see  the  kernel vuln  journal entry

If your system doesn't even have multithreading, that warning on resume
from suspend must be a bug and is safe for you to ignore.

> so I guess its as I suspected  qubes isn't  going to suspend well and
> may break  various things   ??

Yes, the threading warning is unrelated to the sys-usb suspend issues
you were having. Did you try Daniel's suggestions up thread?

[Jon deps]

well Daniel said

--

This is a long-standing issue for some, resolved for some but not for
others at different times. See
https://github.com/QubesOS/qubes-issues/issues/4042

The situation has improved for me by getting kernel 4.19.43-1 from
qubes-dom0-security-testing. You could try the new kernel. (But note
that our problems might be a bit different, I never had a qrexec problem
when restarting sys-usb after resume.)

If you need to automate restarting of sys-usb because you can't avoid
this problem, you can add commands in
/usr/lib64/pm-utils/sleep.d/52qubes-pause-vms for suspend and resume,
e.g., qvm-shutdown sys-usb and qvm-start sys-usb. You might need to
qvm-kill sys-usb before suspend to get this to work reliably.

--


but curiously, AFAIK per dom0 uname -a I am already using

Linux dom0 4.19.43-1.pvops.qubes.x86_64 #1 SMP


but I shouldn't be on security-testing





otherwise I don't see much advantage to doing the 2nd paragraph and
maybe potential for badthings so ...

[Mike Keehan]

On Thu, 13 Jun 2019 19:28:38 +0000

"'awokd' via qubes-users" <qubes...@googlegroups.com> wrote:

Disabling doesn't help. I'm not sure why it hasn't affected more
systems than it has, it seems odd that it only appeared recently.

Suspend/resume has always been a bit iffy on my laptops, so I don't
use it much.

I think all you can do is try whatever options are available to you
and see if anything helps.

Mike.

[Mike Keehan]

On Thu, 13 Jun 2019 19:28:38 +0000

"'awokd' via qubes-users" <qubes...@googlegroups.com> wrote:

I think the kernel issue was with hibernation and resume, not with
suspend to memory and resume. So it is probably a different issue
with the Qubes suspend/resume problems.

I often have to restart the NetVM after suspend (even with the net
modules on the blacklist), and occasionally the usbVM.

Oddly enough, those two VMs sometimes don't work properly at boot
time, but very rarely. Could be a race condition or something.

Mike.

[Jon deps]

don't suppose it matter than my active kernel says #1 SMP but my
i5-6500 doesn't have SMT ? if xen.cfg says smt=off


maybe
the UEFI is smart enough to not show me what my CPU doesn't have, as I
saw no references to SMT multithreading at all ?

this is a Z170 Asrock UEFI