qubes-issues icon indicating copy to clipboard operation
qubes-issues copied to clipboard

Contents of screen sometimes revealed when screensaver is active

Open eloquence opened this issue 2 years ago • 5 comments

Qubes OS release

Qubes-4.2.202305221524-x86_64.iso

Brief summary

A recent Qubes OS 4.2 weekly sometimes reveals the contents of the screen behind the XScreenSaver dialog, even before the user has entered their password. This behavior was observed on a Lenovo T480.

Steps to reproduce

  1. Wait for screensaver to become active
  2. Press any key

Expected behavior

Only password dialog is visible

Actual behavior

Previous screen contents are visible behind password dialog

eloquence avatar May 25 '23 00:05 eloquence

Similar report (but about external monitors): #4394

andrewdavidwong avatar May 25 '23 04:05 andrewdavidwong

This should be fixed with https://github.com/QubesOS/updates-status/issues/3758. I'll close it for now, but please leave a comment if that still happens with that update installed.

marmarek avatar May 25 '23 07:05 marmarek

I'm no longer seeing the issue on 4.2RC1 :)

eloquence avatar Jun 06 '23 19:06 eloquence

I just had this happen on a 2 monitor desktop. Desktop contents fully visible behind lock screen after screen unblanking.

No additional guivm enabled.

amd-gpu-firmware      1:20250211-1
amd-ucode-firmware    1:20250211-1
lightdm               1.32.0-2
lightdm-gobject       1.32-0-2
lightdm-gtk           2.0.8-3
qubes-core-dom0       4.2.37-1
qubes-desktop-linux-common  4.2.12-1
qubes-gui-daemon      4.2.8-1
qubes-gui-dom0        4.2.8-1
qubes-release         4.2-12
xen-hypervisor        2001:4.17.5-6
xen-runtime           2001:4.17.5-6
xscreensaver-base     2:6.08-1.fc37
xscreensaver-gl-base  2:6.08-1.fc37
xfce4-sesssion        4.16.0-6
xfdesktop             4.16.1-1
xfwm4                 1000:4.16.1-4
xorg-x11-drv-amdgpu   23.0.0-1

Nothing really stands out in journalctl or Xorg.0.log.

In .xsession-errors, I see the following (possibly unrelated) error occasionally:

disp-always-the-same: Sending monitor layout
asyncio: Task exception was never retrieved
future: <Task finished name='Task-15498' coro=<DAEMONLauncher.send_monitor_layout() done, defined at /usr/lib/python3.11/site-packages/qubesadmin/tools/qvm_start_daemon.py:384> exception=FileNotFoundError(2, 'No such file or directory')>
Traceback (most recent call last):
  File "/usr/lib/python3.11/site-packages/qubesadmin/tools/qvm_start_daemon.py", line 407, in send_monitor_layout
    with open(self.guid_pidfile(vm.xid), encoding='ascii') as pidfile:
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
FileNotFoundError: [Errno 2] No such file or directory: '/var/run/qubes/guid-running.283'

3nprob avatar Apr 01 '25 23:04 3nprob

Had this happened again a few times on updates systems.

Additionally, when the display has been blanked and the screen locked, waking it up by keyboard will often have the unlocked desktop flash very briefly on the screen before the unlock screen appears (can be verified by HDMI capture). This is not as obviously observable but still an obvious security issue. More rarely, as described in the issue, the desktop gets "stuck" under the unlock-box instead of black overlay as described in issue.

3nprob avatar May 15 '25 02:05 3nprob

Observations: This occurs more frequently when using a particular (cheap, unpowered) HDMI switch or when connecting the machine directly to display, but very rarely on laptop if no external displays are connected and less commonly on a separate HDMI switch with external power. When using the HDMI switch I can almost always at least see the unlocked desktop briefly flash by on wake even when not resulting in the persistent-background effect.

So to summarize roughly:

  • Laptop, no external displays: Rare if ever
  • Laptop, external display by direct HDMI: Occasionally
  • Workstation, direct HDMI: Occasionally
  • Workstation, unpowered HDMI switch: Frequently
  • Workstation, powered HDMI switch: Rarely

Makes me suspect some form of race conditions with display outputs getting connected/disconnected on display wake in locked state.

Sometimes I get the impression that the different sides of the HDMI link "talk past each other" with detecting/triggering display signal on/off with a couple of rounds of on/off before it settles (sometimes resulting in undesired "off" requiring a display or switch input or power cycle). That by itself may not be Qubes-specific but could be a contributing factor.

3nprob avatar Jun 25 '25 04:06 3nprob

I am having this same problem on multiple devices, but today I finally got a video of it from my 4x monitor desktop. This is a workstation that I use multiple days a week, and has an uptime of about 50 days. Unfortunately, I do not have a plausible root cause yet.

This is about the third or fourth time I've seen this, and I think the second machine. I suspect this has only been in instances where I am using an external display(s), but I am not certain. However, this is the first time I caught it in the moment, and remembered to record a video: https://github.com/user-attachments/assets/27fb1543-f726-47aa-8a46-1381572befd5

I am on fully updated QubesOS 4.2.4, and in this case, I came back to my desk in the morning to find my workstation in this state, without any input from me or anyone else overnight

jmynes avatar Sep 09 '25 16:09 jmynes