Is using xen as the hypervisor makes as much sense now as it made before?

So, I decided to check if any employers care about sysadmins who know how to work with xen. Especially because it’s my daily driver. But I wasn’t able to find any. I also wasn’t able to find any certifications for xen (at least in my location). So then I checked where xen was and is currently used. Apparently when Qubes-os was initially released xen as a hypervisor choice was a no brainer. Not only it’s a microkernel with security by compartmentalization. It was used by all major cloud and vps providers. Nowdays most of them are using customized implementations of kvm. And there are really a lot of those. Or vmware/locally made closed source software by the same company. The only vps provider which claimed to use xen as their hypervisor was linode. Which is somewhat reassuring but it was the only big one I could find. But xen has it’s uses in smart cars sector. And this is about it

Issue is - when Qubes-os was created there was really a lot of attention to it’s hypervisor. So bugs were way less likely to stay hidden for long. Nowdays this attention is focused on kvm and the linux kernel itself

How does this really affects Qubes-os security? Wouldn’t it make kvm based solutions a bit more secure from attention to the source code factor?

2 Likes

Although I suspect many here could answer these questions, and correct some misunderstandings, I am not surprised that nobody has rushed to do so.

At times like this, the best advice may be to go and have a read of the FAQ.

2 Likes

The FAQ and linked document explaining Qubes architecture does not answer my question

Yes, Xen provides more secure architecture by default. Yes KVM is just a kernel module and way bigger then Xen. But the attention to Xen decreased tremendously in the last 16 years. In 2010 when the linked pdf was made Xen was the go to solution for cloud providers. Meaning it had really a lot of people looking at the code each day. Nowdays Xen receives way less attention due to KVM taking over it’s place

1 Like

For me, it IS the architecture that makes any extra attention to the Linux kernel almost irrelevant.

Maybe StubDoms, vchan and the other requirements are just around the corner for KVM, but it will take quite a lot more for me to want to trade up to all that extra code.

As far as I can see, many of the extra pairs of eyeballs - that are making the linux bugs shallow - come with an extra 10 fingers adding new code.

The fact that the last time a QSB forced me to reboot was about 6 months ago seems to back my suspicions - although I’m ready to accept that AMD-related code may get less attention in Qubes. If I was on Intel, I think I would have had two reboots in that time. I think most baremetal Linux machines see a lot more than that.

Xen is still winning in my book, although I’m open to persuasion.

1 Like

Thank you

What do you mean by QSB forcing you to reboot one time on AMD. And possibly two times on Intel? I am not sure how it is related

I also don’t seek to persuade anyone. I am trying to figure out how those changes in the last 16 years affect things. More secure design by default or more attention to the source code? I seemingly can’t find an answer

Hi Tokaso,

I should have added some links…

I am only giving my own ideas, I am not in Qubes team, and I am very interested to know more about how KVM could replace Xen. I put some ‘*’ in the places where I am really guessing…

First, for my QSB mention:

I see it was not clear.

Of course, there are sometimes discovery of problems in Xen. These are announced in XSA - Xen Security Announcements. Most of them do not affect the security properties of Qubes-OS. Any such problems that do touch Qubes are announced as a QSB, in the list at https://www.qubes-os.org/security/qsb/. The two most recent ones are only for Intel processors, so the latest one for my Ryzen processors is dated in July 2025.

These “security properties” are quite limited, but also are very strong:

  • All qubes are fully isolated from each other and from the outside…
  • …except for when they are specially allowed to communicate.

The Dom0 qube, which gives this promise, surely contains many problems which would be very bad in a system exposed to the world, but the very tiny Xen code makes them quite irrelevant.

For my uses, my data is threatened mostly by a “problem” which knows how to find my secure data qubes, to open some Xen channels and then to damage or export my data through a qube with network. Such a problem must probably be hidden in a Dom0 update, but it would be difficult to hide.

The other possibility is an isolation problem is present in Xen, so that a hacker can take over my browser qube, and escape from it to touch my data. The very small number of QSB and XSA shows that such problems are very unusual.

I do not really understand how Qubes/KVM could work, but if a linux kernel is in place of Xen, then how can we know what changes are affecting the isolation? Linux kernel is always changing, and I do not see which parts can affect KVM isolation*. I am quite sure it is not only the ~10000 lines of the KVM module. Even if there are no device drivers, it is still a lot of code.*

For the attention - there is the old saying about it. The wikipedia page explains some reasons why the number of people/users may not be so relevant. Most of the eyes are not looking at the parts which are important for our Xen-like isolation. Good analysis requires specialist experts.
And, the extra complexity of joining the hypervisor part to a general purpose OS is sure to make the analysis harder*. So it is more difficult for the extra attention to give us assurance.*

[ ‘*’ is in the places where I am really guessing…

It would be fun to know some more viewpoints.]

1 Like

Just to add:

I suspect that you underestimate use of Xen [guessing].

It is true that VPS use has exploded, but most VPS is anyway running on the internet, so the extra risk of a virtualization escape is not such a big thing for many users.

As users are leaving VMware, it seems like Xen is being used more, but it does not grow as fast as use of KVM. I think I saw an article about it. It is a performance/security calculation.

For the use-cases where secure vm isolation is important, I suspect that many are still using Xen, not KVM. [guessing].

I notice that Amazon do not go either way for AWS… they seem to be using a hardware hypervisor - it sounds even smaller than the microkernel-like Xen, and I am guessing it is formally validated (i.e. it is proven mathematically).

Most likely people who are working with KVM professionally know a lot how exactly it works. Meaning their understanding isn’t shallow. Each vulnerability in KVM will be extremely expensive if exploited because of most open source cloud infrastructure using it

I feel I overestimated Xen usage great deal when I first got interested in Qubes. If you will watch Xen conferences, Xen is mostly interesting for smart cars developers. Xen is also used on some legacy systems in AWS

1 Like