colorful window icons not always passed to dom0, padlock showed instead

[marmarek]

It looks like sometimes colorful icon isn't set for a window. Most likely it is transferred before window in dom0 gets created, and simply discarded.
Dom0 part might monitor for new window events and have some (small) queue for such icons.

[marmarek]

1. When the icon is received but no matching window exists, it is
   discarded. That part of code is here:
   https://github.com/QubesOS/qubes-gui-daemon/blob/master/window-icon-updater/icon-receiver#L319-L324
2. Instead of discarding it should be cached for a short time, and then
   when new window appears icon from cache should be applied (if there is
   one). This part require watching for "CreateNotifyEvent", which isn't
   currently done. Instead X11 events are handled only when searching for
   some window:
   https://github.com/QubesOS/qubes-gui-daemon/blob/master/window-icon-updater/icon-receiver#L235
   Watching for such events is implemented on the sender part here:
   https://github.com/QubesOS/qubes-gui-agent-linux/blob/master/window-icon-updater/icon-sender#L134-L143
3. The icon cache should be done with security in mind, for example to
   not allow any VM use all dom0 memory. I think limiting its size to for
   example last 10 icons should be enough.

[marmarek]

1. When the icon is received but no matching window exists, it is
   discarded. That part of code is here:
   https://github.com/QubesOS/qubes-gui-daemon/blob/master/window-icon-updater/icon-receiver#L319-L324
2. Instead of discarding it should be cached for a short time, and then
   when new window appears icon from cache should be applied (if there is
   one). This part require watching for "CreateNotifyEvent", which isn't
   currently done. Instead X11 events are handled only when searching for
   some window:
   https://github.com/QubesOS/qubes-gui-daemon/blob/master/window-icon-updater/icon-receiver#L235
   Watching for such events is implemented on the sender part here:
   https://github.com/QubesOS/qubes-gui-agent-linux/blob/master/window-icon-updater/icon-sender#L134-L143
3. The icon cache should be done with security in mind, for example to
   not allow any VM use all dom0 memory. I think limiting its size to for
   example last 10 icons should be enough.

[v6ak]

Why not implement the logic in DomUs? For example, icon would be sent on window creation.

Pros:

• No need for such DoS prevention mechanisms.
• It should work in any load (compared to the “cached for a short time” best-effort mechanism)
• A simpler code, I guess. At least in dom0.

Cons:

• Maybe need to implement the logic in multiple agents. (But I am not sure if the issue also happens with QWT, maybe it is not needed there.)

[v6ak]

Why not implement the logic in DomUs? For example, icon would be sent on window creation.

Pros:

• No need for such DoS prevention mechanisms.
• It should work in any load (compared to the “cached for a short time” best-effort mechanism)
• A simpler code, I guess. At least in dom0.

Cons:

• Maybe need to implement the logic in multiple agents. (But I am not sure if the issue also happens with QWT, maybe it is not needed there.)

[marmarek]

On Thu, Feb 18, 2016 at 06:40:54AM -0800, Vít Šesták wrote:

Why not implement the logic in DomUs? For example, icon would be sent on window creation.

It is exactly what is currently done. In practice it looks like this:

1. Application create a window
2. Application set an icon
   3a. gui-agent notice new window and send it to dom0
   3b. icon-sender notice new window and send its icon to dom0
   4a. gui-daemon receive new window info and create it on dom0 X server
   4b. icon-receiver get new icon for a window and set the icon (if window
   exists)

The problem is that, we don't control order of 4a and 4b. To make things
even worse, it could be also another situation:
5. Application destroys the window
6. gui-agent send that event to dom0
7. gui-daemon destroys the window
and now 4b is happening.

VM have no direct confirmation when window is actually created in dom0.
So no simple point of synchronization...

Another idea (instead of caching) - add some feedback dom0->VM like "no
such window" info, so VM could retry some time later?

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[marmarek]

On Thu, Feb 18, 2016 at 06:40:54AM -0800, Vít Šesták wrote:

Why not implement the logic in DomUs? For example, icon would be sent on window creation.

It is exactly what is currently done. In practice it looks like this:

1. Application create a window
2. Application set an icon
   3a. gui-agent notice new window and send it to dom0
   3b. icon-sender notice new window and send its icon to dom0
   4a. gui-daemon receive new window info and create it on dom0 X server
   4b. icon-receiver get new icon for a window and set the icon (if window
   exists)

The problem is that, we don't control order of 4a and 4b. To make things
even worse, it could be also another situation:
5. Application destroys the window
6. gui-agent send that event to dom0
7. gui-daemon destroys the window
and now 4b is happening.

VM have no direct confirmation when window is actually created in dom0.
So no simple point of synchronization...

Another idea (instead of caching) - add some feedback dom0->VM like "no
such window" info, so VM could retry some time later?

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[najamelan]

I know this is somewhat old, but I feel this feature is not stabilized. I still see lock icons and so do others in Q4.

In terms of implementation described by @marmarek, something seems off. I would say that here the vm is the model and the gui agent in dom0 is the view. For that it should not be up to the model to send data to the view. It should be the view that requests it.

Example:
Model sends an event to dom0 (new window created, handle:xxx)
dom0 requests extra data for handle xxx: vm, please give me window title, position, icon...

This way the control over data that flows to dom0 is in the hands of dom0 and not the vm. The vm cannot send more icons than requested. This is better from a security perspective. All you have to do is sanitize and then validate the data you get back. Is the icon a valid image, not exceeding a certain size? Is the window title a valid utf-8 string, with min and max lengths, without forbidden characters, etc.

This also solves synchronization issues. dom0 will always be ready when it receives any data, because it has requested it.

It also means you don't need several different services. One gui manager in dom0 and one in each vm, no need for something separate for icons, or anything else that we should send, like mouse cursor? This should simplify the architecture.

I have not had a look at the implementation in Qubes, but obviously there is one area in which we have the vm initiate comms: Events. It is just important to sanitize and validate all data send by events, and formalize the format. It can then be used by stuff other than gui related as well. It should be a fixed transport protocol. It can help users to make safe extensions as well, when using something strictly typed.

[najamelan]

I know this is somewhat old, but I feel this feature is not stabilized. I still see lock icons and so do others in Q4.

In terms of implementation described by @marmarek, something seems off. I would say that here the vm is the model and the gui agent in dom0 is the view. For that it should not be up to the model to send data to the view. It should be the view that requests it.

Example:
Model sends an event to dom0 (new window created, handle:xxx)
dom0 requests extra data for handle xxx: vm, please give me window title, position, icon...

This way the control over data that flows to dom0 is in the hands of dom0 and not the vm. The vm cannot send more icons than requested. This is better from a security perspective. All you have to do is sanitize and then validate the data you get back. Is the icon a valid image, not exceeding a certain size? Is the window title a valid utf-8 string, with min and max lengths, without forbidden characters, etc.

This also solves synchronization issues. dom0 will always be ready when it receives any data, because it has requested it.

It also means you don't need several different services. One gui manager in dom0 and one in each vm, no need for something separate for icons, or anything else that we should send, like mouse cursor? This should simplify the architecture.

I have not had a look at the implementation in Qubes, but obviously there is one area in which we have the vm initiate comms: Events. It is just important to sanitize and validate all data send by events, and formalize the format. It can then be used by stuff other than gui related as well. It should be a fixed transport protocol. It can help users to make safe extensions as well, when using something strictly typed.

[najamelan]

Not sure whether this helps, but in fedora-26 template, I get this in ~/.xsession-errors:

Traceback (most recent call last):
  File "/usr/lib/qubes/icon-sender", line 155, in <module>
    retriever.watch_and_send_icons()
  File "/usr/lib/qubes/icon-sender", line 136, in watch_and_send_icons
    [xproto.EventMask.SubstructureNotify])
  File "/usr/lib64/python2.7/site-packages/xcb/xproto.py", line 1400, in ChangeWindowAttributesChecked
    for elt in xcb.Iterator(value_list, 15, 'value_list', False):
xcb.Exception: Too few items in 'value_list' list (expect 15).

[najamelan]

Not sure whether this helps, but in fedora-26 template, I get this in ~/.xsession-errors:

Traceback (most recent call last):
  File "/usr/lib/qubes/icon-sender", line 155, in <module>
    retriever.watch_and_send_icons()
  File "/usr/lib/qubes/icon-sender", line 136, in watch_and_send_icons
    [xproto.EventMask.SubstructureNotify])
  File "/usr/lib64/python2.7/site-packages/xcb/xproto.py", line 1400, in ChangeWindowAttributesChecked
    for elt in xcb.Iterator(value_list, 15, 'value_list', False):
xcb.Exception: Too few items in 'value_list' list (expect 15).

[marmarek]

This helps a lot, thanks!

[marmarek]

This helps a lot, thanks!

[qubesos-bot]

Automated announcement from builder-github

The package qubes-gui-dom0-4.0.7-1.fc25 has been pushed to the r4.0 testing repository for dom0.
To test this update, please install it with the following command:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-gui-dom0-4.0.7-1.fc25 has been pushed to the r4.0 testing repository for dom0.
To test this update, please install it with the following command:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-gui-dom0-4.0.7-1.fc25 has been pushed to the r4.0 stable repository for dom0.
To install this update, please use the standard update command:

sudo qubes-dom0-update

Or update dom0 via Qubes Manager.

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-gui-dom0-4.0.7-1.fc25 has been pushed to the r4.0 stable repository for dom0.
To install this update, please use the standard update command:

sudo qubes-dom0-update

Or update dom0 via Qubes Manager.

Changes included in this update