[GSoC 2026] Intro - System Health Monitor Project

[Sahil Kumar]

Hello Ben, Marta, Marek, and the Qubes Team,

My name is Sahil Kumar (GitHub: Sahilll10), and I am a Computer Science student. I am writing to express my interest in the System Health Monitor project for GSoC 2026 and to seek early feedback on my approach before drafting my formal proposal.

Over the past few weeks, I have been actively contributing to Qubes OS and familiarizing myself with its architecture:

• qubes-core-admin-client#450 — merged by @marmarek
  Fixed failing tests introduced by commit 84edd42 by identifying missing per-VM registration in MockQube._add_to_vm_list. Used git bisect to isolate the issue and resolved all failures with a minimal fix.

• qubes-desktop-linux-manager#300 — under review
  Implemented automatic file manager launch in DispVM on block device attach using qubes.StartApp + qubes-open-file-manager. Added a comprehensive test suite using MockQubesComplete.

• qubes-desktop-linux-manager#303 — under review
  Fixed a UI issue where a hyperlink inside a GtkRadioButton was not clickable. Verified via OpenQA and local GTK mock testing.

Through this work, I have gained hands-on experience with PyGTK widgets, qrexec services, the Qubes Admin API, and MockQubesComplete-based testing.

Initial Understanding & Direction

From my exploration, system health signals in Qubes OS appear to be fragmented and not centrally surfaced. Issues such as VM crashes, resource pressure (memory/storage), and insecure USB configurations are either logged internally or exposed indirectly across different components.

My current approach is to:

• Aggregate health signals from existing sources (e.g., update widget, qubesadmin API)

• Design a centralized background service to monitor system state

• Build a PyGTK tray widget that provides a concise overview and proactive notifications

• Ensure unit test coverage using MockQubesComplete

• Add integration tests and documentation

To ensure I am aligning with the intended design direction:

• Should the monitor primarily poll qubesadmin API properties from dom0, or is it preferred to leverage the event system (qubesadmin.events) for a more event-driven design?

• For detecting insecure USB configurations, is checking the presence of sys-usb and verifying whether any USB controller is assigned directly to dom0 via qubesadmin sufficient, or is there a more authoritative or recommended approach?

I want to make sure I align early with the expected design direction before formalizing my proposal.

Thank you for your time and guidance.

Best regards,
Sahil Kumar

GitHub: https://github.com/Sahilll10
Email: sahilkum...@gmail.com

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Tue, Mar 17, 2026 at 05:28:27AM -0700, Sahil Kumar wrote:
>
>
> Hello Ben, Marta, Marek, and the Qubes Team,

Hello!

> My name is Sahil Kumar (GitHub: Sahilll10), and I am a Computer Science

> student. I am writing to express my interest in the *System Health Monitor*

> project for GSoC 2026 and to seek early feedback on my approach before
> drafting my formal proposal.
>
> Over the past few weeks, I have been actively contributing to Qubes OS and
> familiarizing myself with its architecture:
>

> -
>
> *qubes-core-admin-client#450* — merged by @marmarek

> Fixed failing tests introduced by commit 84edd42 by identifying missing
> per-VM registration in MockQube._add_to_vm_list. Used git bisect to isolate
> the issue and resolved all failures with a minimal fix.

> -
>
> *qubes-desktop-linux-manager#300* — under review

> Implemented automatic file manager launch in DispVM on block device
> attach using qubes.StartApp + qubes-open-file-manager. Added a
> comprehensive test suite using MockQubesComplete.

> -
>
> *qubes-desktop-linux-manager#303* — under review

> Fixed a UI issue where a hyperlink inside a GtkRadioButton was not
> clickable. Verified via OpenQA and local GTK mock testing.
>
> Through this work, I have gained hands-on experience with PyGTK widgets,
> qrexec services, the Qubes Admin API, and MockQubesComplete-based testing.
>
> Initial Understanding & Direction
>
> From my exploration, system health signals in Qubes OS appear to be
> fragmented and not centrally surfaced. Issues such as VM crashes, resource
> pressure (memory/storage), and insecure USB configurations are either
> logged internally or exposed indirectly across different components.
>
> My current approach is to:
>

> -

>
> Aggregate health signals from existing sources (e.g., update widget,
> qubesadmin API)

> -
>
> Design a *centralized background service* to monitor system state
> -
>
> Build a *PyGTK tray widget* that provides a concise overview and
> proactive notifications

Marta surely will have more to say here, but IIUC we try to not
introduce any more widgets - if anything, there is a plan to
consolidate them at some point. So, presenting such information in a
tray widget is IMO desirable, but it should combine it into one of
existing ones (possibly re-purposing it to have broader scope). For
example disk space widget is already monitoring some part of the
system, so maybe it can gain more features?

> -
>
> Ensure *unit test coverage using MockQubesComplete*
> -
>
> Add *integration tests and documentation*

>
> To ensure I am aligning with the intended design direction:
>

> -
>
> Should the monitor primarily *poll qubesadmin API properties from dom0*,
> or is it preferred to *leverage the event system (qubesadmin.events)*

> for a more event-driven design?

Definitely events are preferred when possible. It's also possible to add
new events where needed. But, given the purpose of this tool, it might
want to send occasional ping, to verify if connection to qubesd still
works.

> -

>
> For detecting insecure USB configurations, is checking the presence of
> sys-usb and verifying whether any USB controller is assigned directly to
> dom0 via qubesadmin sufficient, or is there a more authoritative or
> recommended approach?

That's basically it. Plus ensuring relevant system qubes are running.
Note that some users may have more than one USB qube, for different
controllers, and such case should also be handled properly.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmm59zIACgkQ24/THMrX
1yyV2gf/XlPESIkqCuoW/9AFFNvUB0uP42NrXdbom10xlnsKQmlq1qnE7i/DfsAu
lv5Uuk4ObOjxnyPYTg+oEJJo+/Dljh+d13Uk43ue5OdEPTsppNo6fM9SjFCxp2fn
8iEv6E6CTxiCtySvxeCf9nZE8U0CzD9qAtZCw6EXFUOncKuHTDHGwYrx4nabWi7F
3aShSKhwd28jziMT4laFqOSftGOtfT2DsGQCbbIgnWEjCZnhtrGG8CZxc+qm3rv4
SXn0zZ9f4JAtcy3XziUJ2PWnQB5DazFJ0lFydqW+ycFzILBZ2UrC3iqdn4c2kQbD
ZBnjJQJgkljbzWDmeCfJ5m7WP+Hgwg==
=f+z/
-----END PGP SIGNATURE-----