6 ms·

Well looks like Mr De Raadt was right again: 'x86 virtualization is about basically placing another nearly full kernel, full of new bugs, on top of a nasty x86

• joosters 12y ago
  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.
  • zorpner 12y ago
    (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.
    • amluto 12y ago
      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.)
      • zorpner 12y ago
        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.
        • amluto 12y ago
          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.
          • boyaka 12y ago
            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?
            • amluto 12y ago
              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.)
    • comex 12y ago
      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.
      • amluto 12y ago
        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.
        • ris 12y ago
          "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".
          • amluto 12y ago
            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).
          • comex 12y ago
            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).
    • rodgerd 12y ago
      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.
  • cesarb 12y ago
    To be fair, that email is from 2007. Did x86 processors have nested page tables back then? If not, he might have been complaining about that.
    • sudowhodoido 12y ago
      No they didn't have SLAT/EPT then. That came in with the i-series processors. The processors were knee deep in errata and buggy as hell. As they are now: http://www.intel.co.uk/content/dam/www/public/us/en/documents/specification-updates/xeon-e5-family-spec-update.pdf http://www.intel.co.uk/content/dam/www/public/us/en/document... Intel don't do a good job of design or engineering really. That's going to sting, I know. I'd love to see 64 bit SPARC make a comeback TBH. Proper hardware contexts/threads, more registers, a decent MMU etc.
      • justincormack 12y ago
        Its called arm64... the first new modern RISC design for a long time.
        • sudowhodoido 12y ago
          Good point! I'd completely forgotten about arm64.
  • ultramancool 12y ago
    > No-one is claiming that virtualization makes a system magically completely secure, but do people actually believe that it makes it less secure? I believe he was comparing it with jails and other similar technologies, which work at the OS level rather than loading another kernel.
  • sudowhodoido 12y ago
    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.
    • trekkin 12y ago
      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).
      • Someone1234 12y ago
        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.
  • tptacek 12y ago
    Didn't deRaadt have to commit OpenBSD workarounds to TLB errata just a couple years back? I don't think he's making things up.
    • sudowhodoido 12y ago
      Yes. See: http://marc.info/?l=openbsd-misc&m=118296441702631 http://marc.info/?l=openbsd-misc&m=118296441702631
      • cesarb 12y ago
        This reminds me of the Intel SYSRET bug: https://blog.xenproject.org/2012/06/13/the-intel-sysret-privilege-escalation/ https://blog.xenproject.org/2012/06/13/the-intel-sysret-priv... 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).
      • peterwwillis 12y ago
        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.
        • tptacek 12y ago
          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.
          • 12y ago
  • hobbes300 12y ago
    There is a general assumption amongst virtualised environment administrators that guests are securely separated. And yes, more code to run means more vulnerabilities.
    • comex 12y ago
      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.
  • blibble 12y ago
    there have been a few xen hvm issues that allow user processes to bypass the VM kernel's normal memory protections, e.g. http://xenbits.xen.org/xsa/advisory-105.html http://xenbits.xen.org/xsa/advisory-105.html so the answer to your question is yes: there have been cases where simply adding the hypervisor introduced a vulnerability .
  • ris 12y ago
    "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.
    • boyaka 12y ago
      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.
  • ewams 12y ago
    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.
• lmm 12y ago
  Why? Virtualization has a much smaller surface area for vulnerabilities than jail-like APIs do.
• cperciva 12y ago
  > I have hope for things like cgroups/jails and MAC/SELinux over virtualization. The attack surface of a virtualization layer is much smaller than the attack surface of an operating system kernel.
• h43k3r 12y ago
  Can somebody point me to beginner articles on what is wrong with x86 ? PS- I have only done a undergraduate level course on computer architecture