34 ms·

What is your point, exactly? That we shouldn't care about hardware-backed virtualization because we have zones? That AWS should go home and re-write EC2 to just

What is your point, exactly? That we shouldn't care about hardware-backed virtualization because we have zones? That AWS should go home and re-write EC2 to just be zones instead of VMs?

Annatar 9y ago
What is your point, exactly? That we shouldn't care about hardware-backed virtualization because we have zones? Yes! That AWS should go home and re-write EC2 to just be zones instead of VMs? There is no reason for AWS to exist.
- openasocket 9y ago
  Zones aren't a replacement for VMs. With VMs you can have different OSes, for example, which is not generally possible with a zone (you can do some stuff with syscall routing to do this in certain ways, but requires support from the root container). In a zone you can't do a variety of things that require higher level kernel access, like installing custom kernel modules. Zones also have a higher attack surface, which matters quite a lot when you are dealing with a multi-tenancy situation. But I'm pretty sure you knew that already.
  - Annatar 9y ago
    If you need another OS besides SmartOS for serving data, you have far bigger problems. Kernel modules are only meant to be installed in the global zone, on the hardware. This is by design. If you need access to that particular device, it can be delegated to that zone with the add subcommand to zonecfg(1M). Zones do not increase attack surface, I don't know what would make you think that. They reduce the attack surface because one can set up read-only zones, good luck changing anything in there. In a zone, attacker lands in a jail, assuming they actually manage to break in! What strange times we live in when there is so much misconception. So much knowledge lost! No wonder AWS and Linux rule the day! Zones are a revolutionary technology in terms of network security. What makes you think zones increase attack surface?
    - openasocket 9y ago
      Zones increase attack surface compared to a hypervisor because you have a shared kernel, and every syscall is a potential attack surface. Compare that to a hypervisor, which a much simpler API exposed with far less functionality. Hypervisor vulnerabilities are far less common than kernel vulnerabilities for that reason. This is fairly well known in the security space. In fact, if you look into Joyent, you'll see they don't use regular zones for multi-tenancy, but rather a KVM-inspired hypervisor implementation of zones.
      - Annatar 9y ago
        This is cookamamie. A hypervisor also has syscalls and in this particular case the global zone is the hypervisor. They even call it "type 1 hypervisor". Apropos "KVM-inspired hypervisor": the zones still function in exactly the same way as they did when I first used them in 2006; in fact when running lx and KVM Joyent is exploiting an obscure capability called a brand (branded zones), but that capability has always been there, since day one back in 2006. Finally, there has only been one known case of managing to break out of a zone and this was through a kernel driver exposed to it, exactly the kind of scenario you'd have on VMware. In the decade since, there have been no known cases, so not only is your argumentation cookamamie, it's in the realm of pure hypothesis.
      - solarengineer 9y ago
        SmartOS provides Zones, and if you need it a KVM instance within a Zone. Hypervisors have their own security issues. They're just programs. That's why there've been all the patching over the years for Xen and for KVM. Last year, an independent researcher did find an issue related to Dtrace that Joyent patched. However, the security and engineering that backs Zones is way more than with other kernels. https://www.joyent.com/blog/dtrace-conf-16-wrap-up https://www.joyent.com/blog/dtrace-conf-16-wrap-up DTrace exploitation: http://slides.com/benmurphy/deck#/ http://slides.com/benmurphy/deck#/ http://benmmurphy.github.io/blog/2017/01/06/arbitrary-kernel-memory-reads-on-illumos/ http://benmmurphy.github.io/blog/2017/01/06/arbitrary-kernel... https://vimeo.com/173300650 https://vimeo.com/173300650

What is your point, exactly? That we shouldn't care about hardware-backed virtualization because we have zones? That AWS should go home and re-write EC2 to just be zones instead of VMs?

Annatar 9y ago

What is your point, exactly? That we shouldn't care about hardware-backed virtualization because we have zones? Yes! That AWS should go home and re-write EC2 to just be zones instead of VMs? There is no reason for AWS to exist.

openasocket 9y ago
Zones aren't a replacement for VMs. With VMs you can have different OSes, for example, which is not generally possible with a zone (you can do some stuff with syscall routing to do this in certain ways, but requires support from the root container). In a zone you can't do a variety of things that require higher level kernel access, like installing custom kernel modules. Zones also have a higher attack surface, which matters quite a lot when you are dealing with a multi-tenancy situation. But I'm pretty sure you knew that already.
- Annatar 9y ago
  If you need another OS besides SmartOS for serving data, you have far bigger problems. Kernel modules are only meant to be installed in the global zone, on the hardware. This is by design. If you need access to that particular device, it can be delegated to that zone with the add subcommand to zonecfg(1M). Zones do not increase attack surface, I don't know what would make you think that. They reduce the attack surface because one can set up read-only zones, good luck changing anything in there. In a zone, attacker lands in a jail, assuming they actually manage to break in! What strange times we live in when there is so much misconception. So much knowledge lost! No wonder AWS and Linux rule the day! Zones are a revolutionary technology in terms of network security. What makes you think zones increase attack surface?
  - openasocket 9y ago
    Zones increase attack surface compared to a hypervisor because you have a shared kernel, and every syscall is a potential attack surface. Compare that to a hypervisor, which a much simpler API exposed with far less functionality. Hypervisor vulnerabilities are far less common than kernel vulnerabilities for that reason. This is fairly well known in the security space. In fact, if you look into Joyent, you'll see they don't use regular zones for multi-tenancy, but rather a KVM-inspired hypervisor implementation of zones.
    - Annatar 9y ago
      This is cookamamie. A hypervisor also has syscalls and in this particular case the global zone is the hypervisor. They even call it "type 1 hypervisor". Apropos "KVM-inspired hypervisor": the zones still function in exactly the same way as they did when I first used them in 2006; in fact when running lx and KVM Joyent is exploiting an obscure capability called a brand (branded zones), but that capability has always been there, since day one back in 2006. Finally, there has only been one known case of managing to break out of a zone and this was through a kernel driver exposed to it, exactly the kind of scenario you'd have on VMware. In the decade since, there have been no known cases, so not only is your argumentation cookamamie, it's in the realm of pure hypothesis.
    - solarengineer 9y ago
      SmartOS provides Zones, and if you need it a KVM instance within a Zone. Hypervisors have their own security issues. They're just programs. That's why there've been all the patching over the years for Xen and for KVM. Last year, an independent researcher did find an issue related to Dtrace that Joyent patched. However, the security and engineering that backs Zones is way more than with other kernels. https://www.joyent.com/blog/dtrace-conf-16-wrap-up https://www.joyent.com/blog/dtrace-conf-16-wrap-up DTrace exploitation: http://slides.com/benmurphy/deck#/ http://slides.com/benmurphy/deck#/ http://benmmurphy.github.io/blog/2017/01/06/arbitrary-kernel-memory-reads-on-illumos/ http://benmmurphy.github.io/blog/2017/01/06/arbitrary-kernel... https://vimeo.com/173300650 https://vimeo.com/173300650