The attack surface of Xen is much smaller than a traditional kernel like linux. I'm guessing the same can be said for OpenBSD after looking at the number of system calls.
Absolutely. It should also be mentioned that many of the Xen vulnerabilities are actually due to qemu and that emulation can mostly be avoided by using PV/PVH.
The number of hypercalls isn't a good indicator of the attack surface area.
As examples:
There is a full x86 instruction decoder which is technically not part of the hypercall interface. x86 instruction encoding is surprisingly complicated. There was a vulnerability in that code: http://xenbits.xen.org/xsa/advisory-123.html
Handling x86 page tables and all of the various feature bits is also surprisingly complicated. This is part of the hypercall interface, but there was also a vulnerability in that code: http://xenbits.xen.org/xsa/advisory-148.html
You might enjoy the fact that my early critiques to Qubes told Joanna Xen was a security problem she should've avoided in favor of separation kernels w/ user-mode Linux virtualization, user-mode drivers, and a trusted GUI subsystem. She vigorously argued against that on the mailing list. Years later, they now have some kind of trusted GUI schemes and she's griping at Xen for being insecure. I don't know if she reduced privilege of drivers or has since learned why that's a good idea. The 180 was hilarious.
I'm sure their product will have plenty more vulnerabilities as she lacked foundational knowledge in building secure systems. Meanwhile, with little labor, GenodeOS was incorporating many well-designed components from the start such as L4 work, Muen, seL4, Nova microhypervisor, Nitpicker GUI, etc. They're still alpha quality due to clean-slate work needed in that approach but moving on steadily. Check them out.
Note: For appliances and embedded, JX Operating System is also worth Googling. Remember that JVM can be replaced with Ada, Go, etc runtime or Rust.
She censored my critiques from that point on. All I have is a cached copy of what I sent in response to her dismissing my comments on the mailing list. Fortunately, I often quote relevant points before countering them. You can easily see what each of us pushed. Her Mac OS X claim makes me laugh to this day.
"and the GUI has always been in DOM0 with no networking."
I'm clearly not a Qubes user. I'm basing my statement on what articles or comments here described as relatively recent work isolating the GUI stack further from attack. If that didn't happen, I retract it. The Xen, Dom0, and driver risks she ignored and countered directly so I was sure they'd be a problem.
EDIT to add: Btw, she later did a one-side rebuttal countering various things here on her blog while censoring my rebuttal of course. One real problem she identified was my use of "military-grade:" commonly a buzzword indicating snake oil. I read lots of defense stuff back then but forgot to translate. I meant Type 1 certified by NSA for high-assurance use in military. It's a rigorous process identifying and often preventing... many issues people found in proprietary and FOSS products designed without high assurance practices. ;) So, I started saying NSA Type 1 certified from that point on to avoid confusion.
Thanks for taking the time to post that. Many of those statements are surprising given how well designed Qubes looks on the surface. I wish more people nitpicked projects like this. Please consider trying Qubes 3.1 out and posting a review. I'd love to read it.
I'm down to a few pieces of hardware and wary of doing anything heavyweight with them. I do want to try it out esp it's usability and such. What's resource usage like for it on single or dual core hardware?
I've only used it on mid-high end systems though. You should easily be able to launch a few small VMs (each AppVM is tunable) on a dual core machine with 4 GB of RAM though.
Xen is worse than Linux in terms of quality, and therefore security. That Linux is much bigger doesn't make Xen any better.
What de Raadt means to say is, generally speaking, you can't build security on top of bad code. No amount of patching, sandboxing, or whatever will help. Security comes from quality and Xen (like Linux) is very lacking in quality.
The attack surface of Xen is much smaller than a traditional kernel like linux. I'm guessing the same can be said for OpenBSD after looking at the number of system calls.