Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GUI Resources #22

Open
nrgaway opened this issue Sep 16, 2020 · 0 comments
Open

GUI Resources #22

nrgaway opened this issue Sep 16, 2020 · 0 comments

Comments

@nrgaway
Copy link
Contributor

nrgaway commented Sep 16, 2020

I started this issue to discuss what is required to get the gui-(daemon,agent} implemented. I know your plan is to start working on this at some point and you mentioned upstream changes may be required after some brief discussions you had with @marmarek. I am not sure if those discussions were in relation to adding libvchan_setup_connection and libvchan_cleanup_connection or something else within gui-agent.

Are changes required for libvchan?

The discussion in issue #1 talked about implementing some features within both libkvmchan and upstream Qubes libvchan. Since that time you have made various changes to libkvmchan so I am wondering is those changes are still required to get the gui-agent working. I guess that is up to you and @marmarek to figure out.

Are changes required for libkvmchand?

Does libkvmchand already have the ability to handle shared memory or is something else required like kernel drivers. When researching ivshmem I can across the LookingGlass site which captures the GUI frame buffer and shares its output with the host or other guest VM using ivshmem. They have a kernel module that could serve as an example.

As you may have a busy schedule, I am willing to assist implementing any changes to Qubes components I can as well as any work required to get shared memory working for the gui-agent running in a KVM environment.

I had started gathering reference material to assist you but after coming across the work you completed within the qubes-gui-daemon repo it appears you have a good handle on what is required so I'll just post what I have so far in hopes it may be helpful to someone. My comments are my understanding of how the gui-{daemon,agent} currently communicates.

gui-agent-linux (qubes-gui-agent) Overview

On boot within the multi-user.target qubes-gui-agent.service is responsible for preparing and setting up a graphical session for the default user using an Xorg or Xephyr (if guivm-gui-agent qubes-service enabled) server. For our use case we will only be initializing the Xorg server.

The qubes-gui-agent service unit file performs some initial pre-configuration then executes /usr/bin/qubes-gui with options contained within '/var/run/qubes-service-environment' that were set within the /usr/lib/qubes/qubes-gui-agent-pre.sh pre-configuration script.

When /usr/bin/qubes-gui is executed, it connects using port 6000 to qubes-guid on the host. After connecting it sets some environment variables after requesting some Xorg configuration details (screen width, height, depth and memory as well as the $GUI_DOMID), and then calls /usr/bin/qubes-run-xorg to start the default users x-windows session. Using the environment variables set by qubes-gui, the qubes-run-xorg script creates a Xorg configuration file '/etc/X11/xorg-qubes.conf' from a template '/etc/X11/xorg-qubes.conf.template' and then calls /usr/bin/qubes-gui-runuser to start the x-server as the default user add a graphical session through PAM.

During x-windows startup various other qrexec serverices are started such as qrexec-fork-server, and qrexec-policy-agent. Note that for the host to be able to communicate with the guest VM using Qubes tools such as qvm-run --pass-io fc32 'cat /home/user/log' > log, it is required that the qrexec-fork-server has been started as the default user.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant