publication croisée depuis : https://lemmy.world/post/16156662
To be completely open, this is not a question about XCP-ng vs Proxmox. I’m open to doing everything in the cli, comparing two platforms is not my intention here.
I’m very interested in the security benefits one has over the other though. AFAIK Xen has a dedicated for security? I’d like to think that both are reasonably secure by default, but I do not get many hits for “KVM hardening”, for example, only OS-level hardening advice.
Do both protect equally against attacks that try to escape the VM? Is there anything in terms of security that one has and the other doesn’t?
I know this is not the usual kind of question that is asked on this sub, any help is greatly appreciated!
From the FAQ of Qubes OS (i.e. most secure desktop OS for general use):
“Why does Qubes use Xen instead of KVM or some other hypervisor?”
“In short: we believe the Xen architecture allows for the creation of more secure systems (i.e. with a much smaller TCB, which translates to a smaller attack surface). We discuss this in much greater depth in our Architecture Specification document.”
Thanks!
Searching for “XenTCB” already brings a lot of useful results
- TCB
- breaking up Hypervisors into smaller parts
- Xen 4.11 release info
- TCB overview
- [scientific paper about some more stuff])https://link.springer.com/content/pdf/10.1007/978-3-319-11203-9_18.pdf)
- security in a commodity hypervisor
Xen has a much smaller attack surface so it’s probably better for security. It doesn’t really do much other than enable creating virtual machines. KVM is much easier to use, but usually comes with a full Linux installation.
I used KVM in my last Hackintosh attempt and while Arch ran KVM quite happily with something like 512MB of RAM and all hardware I could think of forwarded, that’s still a full Arch install I needed to kept updated separately.
Unfortunately, Xen kernels didn’t work on two of my devices. I assume something was being logged to some display that wasn’t connected to the Xen kernel, but I couldn’t get it to work.
Both do attempt to block virtual machine escapes, and both have been victims of successful VM escapes in the past. You can prevent a lot of them by disabling hyperthreading in the UEFI config, but every year a new Intel/AMD/ARM hardware bug seems to be discovered that allows breaking the boundaries of the VM. Perhaps AMD’s encrypted memory can help, but I believe it didn’t last time (as the memory leaked was already decrypted inside the CPU).
I haven’t seen many KVM exploits, but if you want to be as secure as possible, I’d stick with Xen, as that’s what all the security professionals seem to be using. Generic virtualisation (proxmox etc.) seems to use KVM just fine as well, so if you’re just hosting normal VMs, I don’t think you need to particularly worry about security at this level.
I’m just being a bit paranoid with my attempts, and yes just KVM on Debian would work perfectly fine for my purposes but I’d like to take the more secure alternative if possible. Another comment about kernel hardening was a good one for KVM, and unfortunately AMD SEV is not available on most of their consumer chips (especially the older generations).
If I were to switch off multi-threading but assign vCPUs to my VM assuming multi-threaded capacity (I.e. assign 12 vCPUs to my lab cluster after switching of SMT for my 6 core CPU), would I face performance issues? I wonder
The biggest problem for paranoid virtualisation is that you need to disable the cores on those host, or other VMs will still be able to access memory if your CPU is affected by the next speculative execution bug. That goes for both KVM and Xen, as the problem lies within the hardware.
You’d lose half your threads. It’s not an exact 50% performance loss, but it’d definitely have a sizable impact.
Personally, I trust my CPU enough to work well as long as I install all the firmware updates and kernel patches, but speculative execution bugs have proven so common that I doubt they’ve all been discovered. If you’re afraid of getting exploited by bugs like these, disabling SMT seems to be the only effective preventative measure you can take (and even then there are potential security threads!)
Is there an estimate of the loss in performance that I’m looking at, at full load?
As KVM is part if the Linux kernel, I assume you’ll have to look into kernel hardening instead, next to OS hardening. Hardware is also important to consider when talking about VM escaping. A CPU that supports better VM isolation features and encrypted memory
