5 ms·

Op seems to misunderstand the following: 1. Your hypervisor is the security boundary. 2. Unikernel design lets you maximize the security benefits of AppSec an

by zmanian 11y ago

Op seems to misunderstand the following: 1. Your hypervisor is the security boundary. 2. Unikernel design lets you maximize the security benefits of AppSec and LangSec by removing the large OS surface area.

DasIch 11y ago
He addresses the hypervisor as security boundary and explains not only how it sometimes fails it it's intended job and why it's insufficient by design. Further unikernels don't remove the large OS surface area they replace it with something that may or may not be larger and safer.
- im_down_w_otp 11y ago
  They're definitely smaller. Whether or not they're safer depends on how you create the unikernel. Many hypervisor security flaws which allow peeking between the VM isolation boundaries rely on sloppy protections around the virtualized virtual memory subsystem. Most unikernel platforms don't even expose a virtual memory semantic, and thus don't consume these sometimes leaky hypervisor HAL implementation flaws. They don't use or expose the flimsiest floorboards in the hypervisor. A full OS (including SmartOS) on the other hand... definitely does.
geofft 11y ago
Given that the author's impression of kernel security is Solaris', not Linux's, I think it's entirely reasonable to not believe that there are problems with kernel API security that hypervisors will meaningfully improve on. Of course, nobody would listen to "you're all idiots for continuing to run Linux when I gave you this perfectly good Linux emulation on Solaris without a CVE every week" either. (Myself included, to be fair.)
chubot 11y ago
No, all these were addressed in the article. On 1) " Hypervisor vulnerabilities emphatically exist; one cannot play up Linux kernel vulnerabilities as a silent menace while simultaneously dismissing hypervisor vulnerabilities as imaginary" This is obvious, but it's true that people somehow think hypervisor vulnerabilities don't exist. Amazon and Linode just rebooted a bunch of machines because of a Xen vulnerability. Could something like Xen be more secure than the Linux kernel? Maybe. That's a good question, and one I haven't seen the answer to. I actually doubt it because emulating hardware is probably full of more "C tricks" than kernel code, but I'm not an expert here. Another complication is that when you use a hypervisor, you always have Linux in addition. You generally use its drivers for the real hardware. It would seem that Linux + hypervisor is less secure than Linux alone. But there are probably some mitigating factors. 2) "And to the degree that unikernels don’t contain much code, it seems more by infancy (and, for the moment, irrelevancy) than by design." I agree that unikernels are smaller at the moment mostly because they don't have a lot of features. (Writing in a memory safe language helps, but it also hurts! Because I need to run linear algebra in production, etc.) When you run them on a hypervisor, they actually rely on Linux for real drivers and such. So you're not actually getting rid of the code -- you're moving it around.
- emilecantin 11y ago
  > Could something like Xen be more secure than the Linux kernel? Maybe. That's a good question, and one I haven't seen the answer to. The answer might possibly be 'yes': https://www.qubes-os.org/doc/user-faq/#why-does-qubes-use-xen-instead-of-kvm-or-some-other-hypervisor https://www.qubes-os.org/doc/user-faq/#why-does-qubes-use-xe... The reasoning is that Xen is fairly small, so relatively easy to audit by hand, OpenBSD-style.
- lmm 11y ago
  >Could something like Xen be more secure than the Linux kernel? Maybe. That's a good question, and one I haven't seen the answer to. It ought to be, because the attack surface is zillions of times smaller (x86 spec vs all the system calls offered by linux). >you always have Linux in addition. You generally use its drivers for the real hardware. It would seem that Linux + hypervisor is less secure than Linux alone Doesn't have to be Linux - but even if it is, users have no way to exploit most Linux vulnerabilities because the hypervisor (hopefully) doesn't make most possible system calls.
  - cyphar 11y ago
    > >Could something like Xen be more secure than the Linux kernel? Maybe. That's a good question, and one I haven't seen the answer to. > It ought to be, because the attack surface is zillions of times smaller (x86 spec vs all the system calls offered by linux). Bullshit. Either your Hypervisor is a user mode program (it uses syscalls) and therefore requires a full kernel underneath all of the other abstractions you've got (which makes it slower). Or it's like KVM, where it's kernel mode and thus doesn't need syscalls to break the host (does the phrase "floppy driver local root" mean anything to you?).
    - lmm 11y ago
      I'm talking about the complexity of what the kernel-level thing is implementing. It's pretty easy to make a secure Hello World program, even if it's running in kernel mode. It's arguably impossible to make a secure implementation of the linux API, which is not even formally documented. The x86 spec is not simple but at least there is a spec. Floppy driver local root is a good example - the linux kernel suffers from that, but a hypervisor might well not even implement a floppy driver.

by zmanian 11y ago

DasIch 11y ago

He addresses the hypervisor as security boundary and explains not only how it sometimes fails it it's intended job and why it's insufficient by design. Further unikernels don't remove the large OS surface area they replace it with something that may or may not be larger and safer.

im_down_w_otp 11y ago
They're definitely smaller. Whether or not they're safer depends on how you create the unikernel. Many hypervisor security flaws which allow peeking between the VM isolation boundaries rely on sloppy protections around the virtualized virtual memory subsystem. Most unikernel platforms don't even expose a virtual memory semantic, and thus don't consume these sometimes leaky hypervisor HAL implementation flaws. They don't use or expose the flimsiest floorboards in the hypervisor. A full OS (including SmartOS) on the other hand... definitely does.

geofft 11y ago

Given that the author's impression of kernel security is Solaris', not Linux's, I think it's entirely reasonable to not believe that there are problems with kernel API security that hypervisors will meaningfully improve on. Of course, nobody would listen to "you're all idiots for continuing to run Linux when I gave you this perfectly good Linux emulation on Solaris without a CVE every week" either. (Myself included, to be fair.)

chubot 11y ago

No, all these were addressed in the article. On 1) " Hypervisor vulnerabilities emphatically exist; one cannot play up Linux kernel vulnerabilities as a silent menace while simultaneously dismissing hypervisor vulnerabilities as imaginary" This is obvious, but it's true that people somehow think hypervisor vulnerabilities don't exist. Amazon and Linode just rebooted a bunch of machines because of a Xen vulnerability. Could something like Xen be more secure than the Linux kernel? Maybe. That's a good question, and one I haven't seen the answer to. I actually doubt it because emulating hardware is probably full of more "C tricks" than kernel code, but I'm not an expert here. Another complication is that when you use a hypervisor, you always have Linux in addition. You generally use its drivers for the real hardware. It would seem that Linux + hypervisor is less secure than Linux alone. But there are probably some mitigating factors. 2) "And to the degree that unikernels don’t contain much code, it seems more by infancy (and, for the moment, irrelevancy) than by design." I agree that unikernels are smaller at the moment mostly because they don't have a lot of features. (Writing in a memory safe language helps, but it also hurts! Because I need to run linear algebra in production, etc.) When you run them on a hypervisor, they actually rely on Linux for real drivers and such. So you're not actually getting rid of the code -- you're moving it around.

emilecantin 11y ago
> Could something like Xen be more secure than the Linux kernel? Maybe. That's a good question, and one I haven't seen the answer to. The answer might possibly be 'yes': https://www.qubes-os.org/doc/user-faq/#why-does-qubes-use-xen-instead-of-kvm-or-some-other-hypervisor https://www.qubes-os.org/doc/user-faq/#why-does-qubes-use-xe... The reasoning is that Xen is fairly small, so relatively easy to audit by hand, OpenBSD-style.
lmm 11y ago
>Could something like Xen be more secure than the Linux kernel? Maybe. That's a good question, and one I haven't seen the answer to. It ought to be, because the attack surface is zillions of times smaller (x86 spec vs all the system calls offered by linux). >you always have Linux in addition. You generally use its drivers for the real hardware. It would seem that Linux + hypervisor is less secure than Linux alone Doesn't have to be Linux - but even if it is, users have no way to exploit most Linux vulnerabilities because the hypervisor (hopefully) doesn't make most possible system calls.
- cyphar 11y ago
  > >Could something like Xen be more secure than the Linux kernel? Maybe. That's a good question, and one I haven't seen the answer to. > It ought to be, because the attack surface is zillions of times smaller (x86 spec vs all the system calls offered by linux). Bullshit. Either your Hypervisor is a user mode program (it uses syscalls) and therefore requires a full kernel underneath all of the other abstractions you've got (which makes it slower). Or it's like KVM, where it's kernel mode and thus doesn't need syscalls to break the host (does the phrase "floppy driver local root" mean anything to you?).
  - lmm 11y ago
    I'm talking about the complexity of what the kernel-level thing is implementing. It's pretty easy to make a secure Hello World program, even if it's running in kernel mode. It's arguably impossible to make a secure implementation of the linux API, which is not even formally documented. The x86 spec is not simple but at least there is a spec. Floppy driver local root is a good example - the linux kernel suffers from that, but a hypervisor might well not even implement a floppy driver.