From: Theo de Raadt
> Virtualization seems to have a lot of security benefits.
You've been smoking something really mind altering, and I think you
should share it.
x86 virtualization is about basically placing another nearly full
kernel, full of new bugs, on top of a nasty x86 architecture which
barely has correct page protection. Then running your operating
system on the other side of this brand new pile of shit.
You are absolutely deluded, if not stupid, if you think that a
worldwide collection of software engineers who can't write operating
systems or applications without security holes, can then turn around
and suddenly write virtualization layers without security holes.
You've seen something on the shelf, and it has all sorts of pretty
colours, and you've bought it.
That's all x86 virtualization is.So... The others got it wrong, and you're gonna get it right! :-)
How do you justify the 1.3% share on servers[1]? There must be something GNU/Linux got right! There's not even a mention of OpenBSD[2], just Free and Net.
People must be stupid, right? :-)
Virtualisation technologies both hardware and software have improved a lot since then.
People do change their minds as they learn new things or the world changes.
That said, you could do a lot worse than just running OpenBSD out of the box on your servers connected to the Internet security wise, and be hard pressed to do better without a lot of training.
Additionally, he's still right. Don't rely on it to enforce security boundries (e.g. host untrusted systems and trusted systems on different tin) and his rant is totally congruent with virtualisation having a place in OpenBSD
http://www.cse.psu.edu/~trj1/cse543-f06/papers/vax_vmm.pdf
Allows easier enforcement of isolation-based policies, easier verification of TCB, compatibility with existing OS/applications/tools, and optional debugging of above OS. Attempts to build secure UNIX's totally failed because it was inherently insecure in so many ways and took many API modifications. Many VM's, separation kernels, etc were built with strong security. Abstraction helps if applied correctly.
/S
Anyway, if OpenBSD copies anyone, I'd say copy the Nizza Security or Genode Architectures. They leverage the kind of good components (eg Nitpicker/NOVA) and tactics (eg resource management) I mentioned to QubesOS. I see Qubes since adopted a similar tactic in their graphics system. Has a few novelties but mostly a rehash of virtualization and CMW stuff good against common malware. Need stronger TCB and methods to stop nation-states. Other work at least goes in that direction although not there yet either.
Nizza Security Architecture https://os.inf.tu-dresden.de/papers_ps/nizza.pdf
Genode http://genode.org/
EROS (example of one of best approaches) http://www.eros-os.org/papers/IEEE-Software-Jan-2002.pdf
http://www.tylerkrpata.com/2007/10/theo-de-raadt-on-x86-virt...
Or just x86's virtualization. Nothing different popped in my news feed until now. Has OpenBSD's position changed on the subject of virtualization? And is there a more recent post that explains their position?
It's also worth noting that OpenBSD has supported virtualization on some other platforms, too; for example, it can be used to manage SPARC logical domains (LDOMs).
Of course, I agree that VM's aren't necessary: one of many approaches one can use and don't get the job done by themselves. They are beneficial, though, as running security-critical components on a 4-12Kloc in kernel mode with mediated, simple interface should have way less impact than running it on 1Mloc+ with POSIX-style interface.
Snapshotting alone is a security necessity when patching too. Very easy to rollback to a "good" state.
This is from 2013: https://youtu.be/OXS8ljif9b8?t=395
Yes, people have repeated that line since 2008. Readers certainly saw the timestamp. It was main Q&A and search result, though. Hence asking for modern post.
"This is from 2013"
And that's a start. Appreciate the link. I don't see many of his interviews but that was the first one I saw him admit to being behind. Good they're changing their attitude a bit.
The expected and somewhat disappointing part is when he has no answer to what can be done to raise the bar past a few exploit mitigations. There's something like four decades of work (and worked examples) showing how to increase assurance of security in hardware, software, and systems. Especially in capability, microkernels, static analysis, covert channel analysis, and so on. He could... idk... apply some of that instead of mock and ignore it like most mainstream does. FreeBSD is ahead here with SEBSD and Capsicum work.
One project did port OpenBSD to L4 kernel to isolate it in a protection domain. The idea, as in Nizza Security Architecture, is to be able to split system into legacy, untrusted stuff in VM and trusted, highly-assured components running directly on microkernel. A proven model that would benefit OpenBSD by dramatically reducing attack surface. This is done in embedded space (eg INTEGRITY, PikeOS Hypervisor) for up to 8 ISA's each for those wondering about portability.
Just one of dozens of techs to draw on to increase assurance. Will be interesting to see if they draw on any of this or get left behind [again] by those that do.
https://www.ravellosystems.com/blog/legacy-freedom-choose-ru...
Haven't used them: just found them looking for OpenBSD on AWS.
- Kernel hangs when bringing online additional cpus--no working SMP
- PV drivers for net and disk needed. Probably easy to take from NetBSD
- System needs testing for stability
That gets you a lot of the way to KVM support.
AWS uses Xen and domU support is a lot more invasive - OpenBSD had supported it in the past but I believe it was dropped?
There was never enough interest in Linux/SPARC to make a Xen or KVM port feasible. But OpenBSD's community is a different animal.
"It is important to spread sparc64 around the development community, since it is the most strict platform for detecting non-portable or buggy code."
in a larger sense, it's because Oracle's support policies make the market-clearing price for used SPARC hardware very, very reasonable. The value of 3-year-old SPARC gear is essentially $1.
As a real Solaris/SPARC customer, it's cheaper to buy new than try to get a piece of used equipment into Oracle's good graces.
I don't get it. qemu does all of that already. All he needs to do is implement the same kernel ioctls for OpenBSD that KVM implements on Linux, and he gets all of that for free.
Essentially, vmm is to OpenBSD what KVM is to Linux. And yes, a KVM compatible interface can be built, as Mike mentioned.
By far most security bugs in modern hypervisors come from bugs in the emulation of legacy devices, because it's complicated and messy. This is why for example Red Hat's hypervisor solution has had a lot of work put into isolating the qemu process with SELinux.
It was hosted at http://shell.cse.ucdavis.edu/~bill/virt/virt.pdf
These seem to be the most popular ones that show up.