
A native hypervisor is coming to OpenBSD - mariusz79
https://marc.info/?l=openbsd-tech&m=144104398132541&w=2
======
nickpsecurity
Good to see OpenBSD in process of getting one. I previously thought that
OpenBSD, or at least Theo, hated virtualization based on this rant:

[http://www.tylerkrpata.com/2007/10/theo-de-raadt-
on-x86-virt...](http://www.tylerkrpata.com/2007/10/theo-de-raadt-
on-x86-virtualization.html)

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?

~~~
DArcMattr
Theo is objecting to the view that VMs are a security necessity.

~~~
wcfields
Aren't they though? With 0-days it makes sense to be able to snapshot non
mission-critical systems, bring them offline, until a patch is found.

Snapshotting alone is a security necessity when patching too. Very easy to
rollback to a "good" state.

~~~
metalliqaz
I haven't read it, but I assume the discussion was about sandboxing clients.
From that perspective, any additional security would be defeated as soon as a
client is able to affect the hypervisor or the host OS. So (according to Theo)
if you can't write a secure host and/or client, the VM doesn't improve
security.

~~~
yellowapple
While I agree with him on a lot of things, this isn't one of them; security is
all about layers, and it's not like OpenBSD hasn't steered clear of other
forms of sandboxing (like chroots and systrace). This doesn't mean that
virtualization should be relied on _exclusively_ or even _near_ -exclusively
as a defense (which is what I suspect Theo was more objecting to, along with
the point of "well if you can't write a secure operating system, what makes
you think you can write a secure hypervisor?"), but rather that it should be
used as an additional layer on top of (or rather, underneath) a bunch of
others.

It's like bulkheads on modern ships. Yeah, if you get a hole in your hull,
you're gonna be in some (literally) deep water, but that bulkhead (so long as
it's built right) could mean the difference between limping to the nearest
harbor or sinking to the nearest seafloor.

~~~
tedunangst
Somehow back when Amazon had to reboot every EC2 server to fix a Xen bug, my
"insecure" hypervisor-less server didn't require such action. I think I'll
prefer to keep sailing without that particular bulkhead.

~~~
Sanddancer
The reboots were because Amazon cuts a lot of corners in their Xen setup
because instances are supposed to be "disposable". A proper VM cluster would
use dedicated storage nodes that export over something like iscsi, which would
require just transferring a memory snapshot, or would use the native, slower,
disk snapshotting migration. But that's just one of many ways AWS is rather
broken from an operations standpoint.

~~~
oblio
Thing is, the AWS philosophy of considering everything short of data sources
"disposable" leads to a lot more robust engineering.

Yes, it makes Ops work more difficult, but as someone smart said regarding
software: if something hurts, you're not going it often enough :)

~~~
yellowapple
I'm pretty sure "if something hurts, you're not doing it often enough" doesn't
apply to, say, arm-breakage or self-immolation :)

------
walterbell
In addition to a new VMM, why not enable OpenBSD to run as a guest VM on
AWS/Xen?

~~~
tedunangst
Indeed. Why not?

~~~
walterbell
This March 2015 post lists some known work items,
[http://www.joelroberts.org/openbsd/](http://www.joelroberts.org/openbsd/)

    
    
      - 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
    

An old (2012?) comparison of 4 BSDs on Xen and KVM:
[https://gmplib.org/~tege/virt.html](https://gmplib.org/~tege/virt.html)

~~~
dfsfcv
From the link above comparing BSDs on Xen:

"OpenBSD probably works poorly by design, since its lead developer despises
virtualisation."

I have seen this before. Can someone summarise the reasons why Theo de Raadt
hates virtualisation?

~~~
wmf
Basically he thinks any hypervisor that isn't OpenBSD is not secure.

"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." [http://marc.info/?l=openbsd-
misc&m=119318909016582](http://marc.info/?l=openbsd-misc&m=119318909016582)

(I see justinsaccount already posted this below.)

~~~
archimedespi
That's quite true, except that _even OpenBSD_ is not _necessarily_ secure as a
hypervisor.

------
rwmj
_" For example, I've been baking in support for things that the other
implementations don't care about (namely i386 support, shadow paging, nested
virtualization, support for legacy peripherals, etc) and trying to backfit
support for those things into another hypervisor would probably have been just
as hard as building it from the ground up."_

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.

~~~
stsp
qemu runs as a userspace process so it is relatively slow.

Essentially, vmm is to OpenBSD what KVM is to Linux. And yes, a KVM compatible
interface can be built, as Mike mentioned.

~~~
throwaway7767
So, is this thing going to run all the IO emulation in the kernel? That sounds
like a horrible architecture security-wise, very much not what I would have
expected from OpenBSD, which always seemed to pick security over performance.

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.

------
BrainInAJar
Great to see more competition for kvm & FreeBSD's bhyve

~~~
metalliqaz
And Xen :) NetBSD runs it well

~~~
pyvpx
arguable. Xen has become more and more Linux-centric and there seemingly has
been less and less interest in the NetBSD developer community to keep abreast.
see stub-domains

------
hapless
I wonder how reusable this will be on the SPARC64 port.

There was never enough interest in Linux/SPARC to make a Xen or KVM port
feasible. But OpenBSD's community is a different animal.

~~~
makmanalp
If you don't mind me asking, I've always wondered - what do you / people use
SPARC for?

~~~
hapless
for me, personally, it's perverse historical interest.

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.

~~~
tbirdz
If you don't mind me asking, where are you finding such cheap SPARC hardware?
Even 5-year old hardware still goes for thousands of dollars on the second-
hand market.

~~~
nickpsecurity
He's full of crap. Any of them that are obviously in good condition go for
thousands of dollars with T1 processors. Some of those without HD's, used, and
in unknown condition go for several hundred. Not apples to apples, though, as
no business will depend on such unknowns for mission-critical stuff that SPARC
is best used for.

Interesting enough, even the AlphaServers still sell for good money on eBay.
Certainly they were great servers in their day but performance is _way_
behind. While faster Itaniums from SGI you can get for $100-200. Old hardware
market isn't linear or predictable. Personally, though, I think those
AlphaServers are still worth if if one understands OpenVMS clusters or
PALcode. ;)

------
Animats
Unclear what this means. Is this a hypervisor that runs under OpenBSD? Or a
hypervisor under which OpenBSD runs? Or an attempt to kludge OpenBSD into a
hypervisor? Or some kind of Docker-like container system for OpenBSD?

~~~
justincormack
Hypervisor that runs under openbsd, and which can run openbsd.

------
ananomouse
Was doing some digging into the research. Perhaps someone happens to have a
copy of Bill Broadley's 2007 IT Security Symposium presentation/paper?

It _was_ hosted at
[http://shell.cse.ucdavis.edu/~bill/virt/virt.pdf](http://shell.cse.ucdavis.edu/~bill/virt/virt.pdf)

~~~
anw
[http://www.lugod.org/presentations/virt-
lugod.pdf](http://www.lugod.org/presentations/virt-lugod.pdf) and
[http://taviso.decsystem.org/virtsec.pdf](http://taviso.decsystem.org/virtsec.pdf)

These seem to be the most popular ones that show up.

------
justinsaccount
[https://marc.info/?l=openbsd-
misc&m=119318909016582](https://marc.info/?l=openbsd-misc&m=119318909016582)

    
    
      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.

~~~
Sanddancer
The past several years have brought many additions to the x86 architecture
that makes it more than shit atop shit. When he wrote it, things like Xen
required you to build a kernel with special options for it to run, with all
kinds of new and exciting bugs to discover. Things like page table
virtualization, which provide a lot better page protection, or being able to
shadow the vm control structures, which allow for nested VMs, or IOMMUs, which
allow vms to access explicit pieces of hardware, just didn't exist. x86 is in
a better condition for virtualization now, and layouts can finally done in a
semi-sane way.

~~~
jnky
Yeah, but on the other hand one might argue that there is no reason to believe
Intel's hardware implementation of such features is more correct and less
prone to errors than Xen's implementation in software.

