The choice for dom0 to inject the update agent each time is deliberate. It allows shipping fixes to templates, even if the update mechanism itself is affected (including fixes to the update agent itself). We used this functionality several times already, also to apply security mitigations to the update tool itself (happened both to Debian and Fedora ).
Yes, it’s not nice (to say the least), but it’s on purpose.
That said, it should be okay to have dom0 support also an update agent for Windows (I guess send a different version of it, based on the os feature set on the VM).
This means we need a separate dom0 script for every OS with explicit support. Maybe it should be a backup mechanism, not a primary one? OS population is diverse. Did you see the depth of abomination i had to go to make this work on Windows? :)) And there is NixOS, Alpine, *BSD and so on and someday we want to support more.
There may be a generic backup mechanism, but the agent-injecting one is the primary for a reason, as said above.
It surely is awful trying to wrangle commands targeting Linux to work on Windows VM. It would be much simpler if you’d add relevant support to qubes-vm-update tool itself.
But it would require me to touch dom0 stuff and care MUCH more about security implications. Keeping stuff entirely on guest side allows me to be more relaxed about what I write there – and not to wait for my contributions to be accepted upstream to become useful. Xen network drivers give me enough pain with it already
I’m open for a fallback generic mechanism Maybe a qrexec service (qubes.UpdateVM?) which has the same interface over stdout/stderr (log messages on stdout, and progress in percentages as one-float-per-line on stderr)? And update status reported as exit code:
Yep, something like that! Maybe OS could report available package managers / update channels / other capabilities and accept custom payloads from dom0 side when something non-generic is required.
There is already os , os-distribution, and os-version features that VM can report (Windows already report os=Windows). VM can also report supported qrexec services (announce features supported-rpc.<service-name>). That should be enough for qubes-vm-update to decide if it knows how to handle it, or wants to try a fallback generic service.
Description of some of it looks nice, and coming back of the driver (IIUC it’s based on some new sample? when we looked for a sample using new API few years ago, there wasn’t any) is a welcome change. Abandoinig zero-copy approach a bit less so (based on what Omeg said to me, it might be possible to keep zero-copy with that driver).
But also, that’s a lot of code, and a huge pile of powershell scripts. That doesn’t exactly look like a maintainable solution long term… Based on a random sample, it feels like at least some of it could be simplified a lot.
I’ve seen your talk submission for the qubes summit. Omeg (maintainer of QWT) also will be there. It sounds like a good place for some coordination, maybe even a topic for hackathon?
The pile could be reduced – most of it is genuinely required, but I have to admit I keep stacking stuff one atop of another to get decent user experience in hope to sort everything properly later
A couple more things to implement (notification bridge and window header tweaks) and I think I go for feature freeze and focus on code quality issues. The PoC phase is almost finished, time to make it truly production ready.
Notification bridge is in testing: most windows toasts will go to qubes-native notification pop-ups (except those that require in-system user action, those will remain)
I created a standalone from a Windows 11 template, and so far, everything seems to work well. It can be started, and applications like Explorer can be started via the Qubes menu or, using the Windows key, via the Windows menu.
There’s just one small inconsistency: The icons shown for Downloads and Documents still point to Drive Q: instead of C:. This can be fixed manually by detaching and then reattaching these icons, i.e., the links represented by them..
Probably can tidy this up, too. But I thought standalone converted from appVM still has two volumes, it is just root is no longer volatile? Then it is correct bevahior.
Meanwhile, experimental notification bridge feature is shipped, configurable via qvm-features as usual, please check how it works for you. Also win11 is fully “desliced” (a full viewport-size desktop map lives nowhere in the driver, every window is mapped individually). For win10 it is not quite feasible within current architecture, but the performance impact is close to zero either side, it is more about “tidying things up”.
– and not to wait for my contributions to be accepted upstream to become useful. Xen network drivers give me enough pain with it already 