[GSoC] Project: Qubes logs management system

[notmuchtohide]

Hey all,

I've been a passionate Qubes user for a few years and I'm looking forward to apply for Google Summer of Code.

I would like to get feedback from the Qubes team on the following project proposal :)

Project: Qubes logs management system

Brief explanation: This proposal consolidates two project ideas: Log VM(s) and Reduce Logging of Disposable.
The goal is to develop a centralized VM logging system, using qrexec. On one hand, any VM logs will now be sent to a dedicated VM. AppVM logs will survive VM shutdown and be immune to altering past entries. Logs previously stored in dom0 will now be sent to a dedicated VM and suppressed from previous locations (e.g.: /var/log/xen/console).
On the other hand, Disposable VM logs will be minimized by simply denying logging via qrexec policy.
This design is flexible to various configurations such as storing logs in the LogVM, or even use dom0/guivm as the default LogVM (e.g.: to save RAM).

Expected results:
• Add installation option to create LogVM.
• Deny sending DisposableVM logs to LogVM.
• Suppress VM logs stored in dom0.
• Design a simple protocol for transferring logs. The less metadata (parsed in log-collecting VM) the better.
• Implement log collecting service. Besides logs itself, should save information about logs origin (VM name) and timestamp. The service should not trust sending VM in any of those.
• Implement log forwarder compatible with systemd-journald and rsyslog. A mechanism (service/plugin) fetching logs in real time from those and sending to log-collecting VM over qrexec service.
• Document the protocol.
• Write unit tests and integration tests.

Difficulty: medium

Knowledge prerequisite:
• Python
• C
• Bash
• syslog
• systemd

Size of the project: 350 hours

Mentor: Marek or Piotr (?)

Thank you for your time,

notmuchtohide

[Marek Marczykowski-Górecki]

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

On Tue, Mar 17, 2026 at 10:20:22PM +0000, 'notmuchtohide' via qubes-devel wrote:
> Hey all,

Hi,

> I've been a passionate Qubes user for a few years and I'm looking forward to apply for Google Summer of Code.
>
> I would like to get feedback from the Qubes team on the following project proposal :)

> > Project: Qubes logs management system
> >
>
> > Brief explanation: This proposal consolidates two project ideas: Log VM(s) and Reduce Logging of Disposable.
> > The goal is to develop a centralized VM logging system, using qrexec. On one hand, any VM logs will now be sent to a dedicated VM. AppVM logs will survive VM shutdown and be immune to altering past entries. Logs previously stored in dom0 will now be sent to a dedicated VM and suppressed from previous locations (e.g.: /var/log/xen/console).

This is interesting idea, but I'm not sure if abandoning any logs in
dom0 is a good idea, from system reliability point of view. Imagine you
have some issue with with starting such logvm, it should not prevent
saving for example information what that issue is...
But I agree it can be significantly limited as part of the project.

> > On the other hand, Disposable VM logs will be minimized by simply denying logging via qrexec policy.

Note that plain system logs (journal) is only part of the original
"Reduce Logging of Disposables". It isn't a problem, just observation
that it doesn't invalidate the other project.

> > This design is flexible to various configurations such as storing logs in the LogVM, or even use dom0/guivm as the default LogVM (e.g.: to save RAM).

Good idea.

Take a look also at my previous answer regarding logvms: https://groups.google.com/d/msgid/qubes-devel/aZ2vu7v2rHVqgvot%40mail-itl

> > Expected results:
> > • Add installation option to create LogVM.
> > • Deny sending DisposableVM logs to LogVM.
> > • Suppress VM logs stored in dom0.

In practice, I imagine this point would rather be "redirect logs
produced in dom0, to the new logging service". Maybe even use existing
logging solution (systemd-journald? rsyslog?) and configure it for
this purpose. I specifically list rsyslog, because it's quite flexible
in ways it can store/distribute logs.
And then, adjust services logging to plain files, to log to such service
instead. That last part will be likely most of the work.

> > • Design a simple protocol for transferring logs. The less metadata (parsed in log-collecting VM) the better.
> > • Implement log collecting service. Besides logs itself, should save information about logs origin (VM name) and timestamp. The service should not trust sending VM in any of those.
> > • Implement log forwarder compatible with systemd-journald and rsyslog. A mechanism (service/plugin) fetching logs in real time from those and sending to log-collecting VM over qrexec service.

Right, you added it already here too :)

> > • Document the protocol.
> > • Write unit tests and integration tests.
> >
>
> > Difficulty: medium
> >
>
> > Knowledge prerequisite:
> > • Python
> > • C
> > • Bash
> > • syslog
> > • systemd
> >
>
> > Size of the project: 350 hours
> >
>
> > Mentor: Marek or Piotr (?)

I guess Piotr would be appropriate person here, as he worked in related
areas recently.

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmm59R8ACgkQ24/THMrX
1yw+UAf/QfebeFg0SUyUs2GUk6FU/E0I5fKB4HvJoF6r2EZcxqJ/m1A+ngJwB3Qr
0YUeSa5HB9od4ck6/zwbgHz/3D1VbRHFYoVq7eTYOwuYarxSQiA3DbOpam9rrfwM
TTBUu2s9LCA7BOYi+DDNjNzJCW5fwCVPNOuZTzuMu80DZKXEfW1boTPOsFssBQjm
/4wYdgt06Dlr9cLIzbb6tANUQw6NOi9Hu6aQRGUjYId8/rjt4lOHJlWkouwZGu4g
LTLTLqGTAtb//qB0uTiX4dOq34+RQbvduiMz7psrcDFabPr8cttTPAzjfwW5bSSt
MEhJ3DVpQws1dAF2Ncd4sRUzyaS/xQ==
=i/Gr
-----END PGP SIGNATURE-----

[notmuchtohide]

On Wednesday, March 18th, 2026 at 12:43 AM, Marek Marczykowski-Górecki wrote:
> This is interesting idea, but I'm not sure if abandoning any logs in
> dom0 is a good idea, from system reliability point of view. Imagine you
> have some issue with with starting such logvm, it should not prevent
> saving for example information what that issue is...
> But I agree it can be significantly limited as part of the project.

That make sense. Dom0 essential logs such as logs from LogVM or VM logs
happening before VMs can send them to the LogVM should remain in dom0.

> Note that plain system logs (journal) is only part of the original
> "Reduce Logging of Disposables". It isn't a problem, just observation
> that it doesn't invalidate the other project.

True, the proposal doesn't fully merge both projects. The focus is on the

"LogVM(s)" project but it also helps the "Reduce Logging of Disposables" in
some ways.

> In practice, I imagine this point would rather be "redirect logs
> produced in dom0, to the new logging service".

Agree!

> Maybe even use existing
> logging solution (systemd-journald? rsyslog?) and configure it for
> this purpose. I specifically list rsyslog, because it's quite flexible
> in ways it can store/distribute logs.
> And then, adjust services logging to plain files, to log to such service
> instead. That last part will be likely most of the work.

Thanks for the advice. I'd be happy to explore existing solutions :)

> I guess Piotr would be appropriate person here, as he worked in related
> areas recently.

Perfect, thanks!


Best regards,
notmuchtohide