Hacker News Reader

Comment by zorpner | Hacker News Reader

(Compared to, running the same software on the same hardware using a single OS). I don't think so.

If you had been running an OpenBSD instance on hardware as a single OS, you would not be vulnerable to having your system's memory read by this hypervisor bug. So... yes.

View on HN

I'll take the world where we have the odd hypervisor vulnerability over the world where we have to increase power output by multiple orders of magnitudes and pave the planet with datacentres to run every service as a single-instance, non-virtualised server.

I guess Theo prefers runaway global warming to the odd data breach. Which makes him the idiot, to use his own language.

This is nonsense.

A single OpenBSD kernel on bare metal can do whatever it pleases.

A Linux kernel on Xen HVM could, due to this bug, do slightly more than it ought to have been able to do.

(In this sense, the LLDT bug was worse.)

You have an incoherent mental threat model of this. Those two systems are functionally identical to the end user to which they are being sold, but one is vulnerable (in this specific way) to the actions of other customers with the same service provider.

This has nothing to do with threat models and everything to do with usecases that make no sense on OpenBSD.

With OpenBSD on bare metal, you are not vulnerable to other users of the same bare metal, because there aren't any.

With Linux on bare metal, you are not vulnerable to other users of the same bare metal, because there aren't any.

With Linux on Xen, you are reasonably resistant to other users of the same bare metal (and XSA-108 wasn't even all that severe).

With OpenBSD on Xen... oh, wait.

Usecases with multiple users on one piece of hardware make no sense? Is there a reason (besides the previous question) you are ignoring the ability to use containers as an alternative to virtualization for all of the perks they provide?

I'm not ignoring containers at all. Linux, FreeBSD, and OpenBSD all have some form of user mode containers. All POSIX systems also have user ids. Linux containers are probably the most functional (no citation here -- I know lots about Linux containers and very little about FreeBSD jails) and are also probably the least secure, because of the aforementioned functionality and because they're rather new. (On the other hand, a really well designed Linux seccomp sandbox is probably the most secure option of all.)

Linux on Xen also allows you to have multiple Linuxes on the same Xen machine. This is the most functional of all and probably also the most secure of all, XSA-108 notwithstanding.

(Also, I find this all rather odd. If you want to compare Linux+Xen to OpenBSD, XSA-105 and XSA-106 much bigger deals. They allow code in a Linux container or other sandbox to break out by exploiting a Xen bug to take control of their Linux host.)

You mean containers where you all share the same kernel? Oh yes, no attack surface there.

Every kernel (not named seL4) has vulnerabilities. The question is not whether OpenBSD would have been vulnerable to this specific issue, but whether Xen generally has fewer bugs than the OpenBSD kernel - or, for that matter, the Linux kernel, since the grandparent mentioned a bunch of Linux sandboxing technologies.

edit: To be absolutely clear, per the grandparent, I'm assuming an environment where unrelated people are running software on the same hardware, either using their own kernel under Xen or user processes under jails.

And if any thinks that the awesome perfection of OpenBSD's authors outweighs the vastly smaller attack surface of something like Xen, I think that they're deluding themselves.

"the vastly smaller attack surface of something like Xen"

Um, citation needed. The exact behaviour of the entire x86 supervisor mode instruction set is not remotely a "small attack surface".

The attack surface of incorrect use of the admittedly complicated x86 privilege transition and protection mechanisms is shared in its entirety by all x86 operating systems (except, to a limited extent, by those that turn off some of these mechanisms, which AFAIK none do).

Flipside is that with hardware virtualization, a lot of that behavior is protected in hardware which, for whatever reason, seems to be extremely secure in practice. You don't see a lot of erratum-based exploits... the recent SYSRET bug was severe but only counts somewhat ("instruction does something different than what it does on another vendor's processors, and is technically documented to do so" is bad, but it's not like there was some sequence of instructions that would just get you arbitrary memory access without interacting with the hypervisor).

Reply on news.ycombinator.com