This is just FUD and in the usual insulting De Raadt style of communicating.
'barely has correct page protection' is just a way of saying 'has correct page protection, but I want to be really snotty about it'. So, highlighting a non-problem.
No-one is claiming that virtualization makes a system magically completely secure, but do people actually believe that it makes it less secure? (Compared to, running the same software on the same hardware using a single OS). I don't think so.
Not really. He's right. The memory, paging and protection model for X86 is fugly at best. It's very easy to hang yourself as demonstrated.
You can be as insulting as you like if you compare X86 (and X86-64) to SPARC and POWER which is what I assume he is doing here considering he provides operating systems for multiple architectures. We're talking about an architecture that started with the 8086 and despite changes to the underlying microcode architecture, the front end ISA and system interface is still plagued with poorly designed extensions hacked on.
Regarding virtualization, any sharing of resources, particularly at a hardware level is an attack vector if not implemented correctly. Whether or not it is implemented correctly or is exploitable is merely a matter of time and effort as demonstrated here. That is unless mathematically verified, which it isn't and based on the evolved x86 architecture probably isn't possible so it can't be more secure and is unlikely to be as secure. That leaves only less secure.
I implement high-performance software systems in C++ as my day job. The software has to compile and run on Linux, Solaris, and AIX. The same code is 2x slower on AIX (Power) and 3x-5x slower on Solaris (Sparc) than on Linux (x86). So say whatever you want about theoretical differences in architectures, but in the real world Sparc and Power systems are absolutely not competitive, both on price (absolute $$, and per CPU) and performance (per CPU - they do have more cpu cores, usually).
That's just a circular way of saying "x86 is more popular, therefore better." Which doesn't address the person aboves' point that x86 is inferior in terms of its design.
Of course x86 is going to be faster per dollar spent. One is mass market (x86-64) and the other two are hugely niche (Sparc and Power). Plus the Linux kernel has by far the most human-hours spent on its development relative to every other operating system in the world.
There's also a reason why some of x86's market share has been eaten up by ARM. Moving from x86 to ARM was hugely expensive by all measures, but it was worthwhile because x86 was so wasteful.
It's not just "x86 is more popular, therefore better." It's that the performance of x86 was better than SPARC or Power. Regardless of the cost of the chip, performance is what is really important here. In some instances, performance per watt is more important, but either way... it's performance that's key, not market forces driving cost savings.
I haven't had much experience with SPARC, but I've done some work on Power systems (long ago). Back then (10-ish years ago), Power chips were more powerful than their x86 contemporaries. But at some point, that relationship switched.
However, I wonder how much of this is the chip, and how much is the tooling. Its been awhile since I've needed to think about C/C++ compiling, but from what I remember, the Intel compiler produced (slightly) faster binaries than gcc. Now this is where popularity could prove to be decisive... if the compiler that the OP uses works for x86, SPARC, and Power, how much do you suspect each of those architectures has been optimized? Even if the non-x86 chip itself is capable of running faster than x86, if the toolchain isn't similarly optimized, they could end up having worse performance.
It might well be fugly but it works. That's the key point.
I'm sure Intel (or anyone else), if they could develop x86 again from scratch, and with the benefit of hindsight, would create a much nicer mechanism. But that's just speculation and wishful thinking.
Haven't they? I thought x86 was now basically just a legacy compatibility layer on top of significantly more streamlined and optimized RISC-like operations.
(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.
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.
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.
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).
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).
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.
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.)
In which AMD defines a new instruction, and Intel copies it with a subtle difference which trips up everyone (AMD's way is better IMO, and it came first).
He's just very dramatically pointing out that, oh, there are some changes we now need to account for, and Intel didn't tell us poor open source developers about them, and that's (supposedly) totally unreasonable. Besides the fact that Intel does not owe De Raadt anything (other software makers pay a hefty sum to be partners, while OpenBSD developers insult anyone who doesn't give them free shit), these bugs are a given in any production process. I don't care if you're Ikea or Exxon or Apple, you don't adopt new shit into your product and not expect shit to break. So his outrage is both presumptuous and facile.
No, you're moving the goalposts. DeRaadt pointed out that x86 "barely" has a working paging system. A commenter on HN said there was no basis for that statement, that he was picking on something that wasn't broken, that it was just FUD. It was not FUD. That claim has been refuted.
I wasn't addressing the paging system issue, but that was definitely FUD too. FUD does not have to be disinformation per se. Its main property is the spread of a generally negative viewpoint that is intended to persuade the recipient to side with the negative actor.
Even if the paging system is broken, that's no reason to simply stop using VMs on it, or to say it's impossible to have a secure VM on a system with broken paging. It's perfectly possible to have a VM on a broken-paging machine that's more secure than a working-paging machine's OS, with or without a VM.
De Raadt was not trying to make a rational argument about the validity of VMs on faulty hardware. He was literally saying you are stupid if you put a VM on x86 and expect it to be secure. Which is a stupid thing to say without knowing anything about the OSes, or what the alternative might be, either platform or OS-wise, to say nothing of hardening.
De Raadt has a bone to pick with Intel and specifically x86-based machines, and is simply interested in convincing people not to use it by insinuating you're innately not capable of doing secure computing on it. Which is basically untrue. That's why it's FUD.
One thing does not follow from the other. Core 2 has had paging bugs, ergo x86 has a barely working paging system => Pentium had the FDIV bug, ergo x86 can't be trusted with arithmetic.
For the claim to be properly refuted, the claimer would have to show systemic problems in x86 paging. I believe such a claim can be made, but it simply wasn't yet.
You're litigating a different claim than I am. The claim I'm refuting is:
"barely has correct page protection' is just a way of saying 'has correct page protection, but I want to be really snotty about it
I don't have to demonstrate systemic flaws in x86 paging to refute that.
I don't think paging system security is a good basis on which to choose processor architectures. I do sort of agree with Theo's point about virtualization, which really is a petri dish for terrible vulnerabilities. But either way: my point is just that Theo isn't just making things up here.
Inherently, adding more systems creates more risk vectors. When an application is installed on an operating system, both the OS and application now have to be protected. An example would be Flash ontop of an OS. You have to defend, patch, and architect based on whether your systems have Flash or not.
With virtualization you have the hypervisor that has applications running along with it (ie: ssh, a cli, syslog, bash etc) and then you install a guest in a VM on top of the hypervisor. The OS on the VM is another vector which has applications on it (DB, web, ftp, etc).
If I have a bare metal server with just an OS installed on it and its applications on top of that, I only have to worry about that set of OS and applications and their associated risk vectors.
If I have a bare metal server with a hypervisor and then the above OS and set of applications, I have increased the number of risk vectors by however many applications are running along with the hypervisor.
“but do people actually believe that it makes it less secure?”
Just bringing a hypervisor into an environment does not of itself immediately make it less secure. I agree with you, I don’t think it makes it less secure. It does increase the risk of the environment and appropriate architecture and action must be taken to prevent your statement from being true. A large number of environments do not architect and manage properly.
Another very realistic, and happening today, example:
Bare metal server with Windows OS installed.
Bare metal server with a hypervisor which just happens to have bash on it (or is susceptible to this memory issue). The same Windows OS is installed as a VM.
In the second instance with the hypervisor I would have, indirectly and out of my immediate control, made my environment less secure.
An increase in complexity or increase in components will increase the risk of an environment.
"No-one is claiming that virtualization makes a system magically completely secure, but do people actually believe that it makes it less secure? (Compared to, running the same software on the same hardware using a single OS). I don't think so."
However, common virtualized platforms such as EC2 encourage you to run your whole server setup in an environment where a (possibly malicious) neighbour could be running arbitrary x86 code in an instance on the same physical machine. This is not an attack vector that is remotely possible in the traditional, non-virtualized setup.
They aren't encouraging you, it is being demanded (by you, by everybody). This is how cheap, reliable, redundant computing is offered, and it will always be cheaper than paying for and maintaining entire physical machines.
There is a general assumption amongst virtualised environment administrators that guests are securely separated. And yes, more code to run means more vulnerabilities.
From the perspective of a public cloud host etc., it's not more code to run; any fault of the guest kernel is not their problem, so they likely have less code to run compared to jail-based solutions that run a full Unix kernel in ring 0.
'barely has correct page protection' is just a way of saying 'has correct page protection, but I want to be really snotty about it'. So, highlighting a non-problem.
No-one is claiming that virtualization makes a system magically completely secure, but do people actually believe that it makes it less secure? (Compared to, running the same software on the same hardware using a single OS). I don't think so.