About ClockVM:
This setting tells dom0 which qube to take the time from and then distribute it to all the other qubes (so they all have the same time). Even if you set ClockVM to none, which means dom0 doesn’t get the time from anywhere … it will still use whatever time is kept locally to synchronize all the other qubes to the same time.
The fact that all your qubes use the exact same time can theoretically be used to correlate your qubes to each other. Think two online qubes interacting with the same server and communicating their local time. If both have the exact same time, it makes it more likely that the origin is the same.
Whonix has sdwdate, which first establishes a Tor connection and then uses multiple sources over Tor to get the time. It then also applies a random diff to it, so different Whonix instances on the same Qubes OS computer have slightly different times.
If you set ClockVM to sys-whonix, the time was gathered via Tor … but all your (non-Whonix) qubes will still have the same (randomly offset) time.
When it comes to time the much bigger concern is your timezone. If you want to reduce fingerprinting, use UTC in dom0 and all qubes instead of your local timezone. Whonix instances use UTC. Personally I do not see time correlation nor timezone as something I worry about (it’s really a privacy and not a security issue), but your situation might be different.
About sys-net, security/compartmentalization and clockvm/time
sys-net is where your PCI hardware (Ethernet and WiFi) are connected, which also means that the virt_mode used is HVM. Standard PVH mode is more secure but cannot be used to connect hardware. This means that it has more attack surface though the hardware interfaces, their firmware and also the virt_mode used (I suppose the last point is rather academic).
So in sys-net is where you compartmentalize the risk of dealing with direct hardware access. Some folks (like me) go so far to configure sys-net as disposable. This will rid any qube compromise after restart, but it will not protect against compromised firmware (nothing will). But as long as all traffic that hits sys-net is TLS encrypted, this is not different from any other network access point. Bottom-line: sys-net is absolutely untrusted.
When sys-net is set as clockvm, dom0 get’s its time from sys-net which in turn runs a standard systemd-timesyncd.service to get the time from the network. So the worst thing that could happen is that you get a wrong time if sys-net is compromised, which has some security implications (e.g. Tor won’t connect if your local time is off too much).
The advantage in selecting sys-net as clockvm, is that usually it’s one of the very first qubes that starts. So it already acquired the time over the network, when asked by dom0. Every other qube gets it’s time from dom0 at startup and then every 6 hours I believe.
About sys-firewall
sys-firewall typically uses the preferred PVH virt_mode, doesn’t contain any data and is not interacted with by the operator. It’s one and only job is to enforce firewall rules configured for the qubes that connect to it using it as netvm. So even if those qubes are compromised, sys-firewall will still enforce those rules. If you set it as clockvm, your time will be updated a few seconds later but the NTP/UDP traffic observable from the outside will still be the same.