4 ms·

"You've been smoking something really mind altering, and I think you should share it. x86 virtualization is about basically placing another nearly full kernel,

"You've been smoking something really mind altering, and I think you should share it. x86 virtualization is about basically placing another nearly full kernel, full of new bugs, on top of a nasty x86 architecture which barely has correct page protection. Then running your operating system on the other side of this brand new pile of shit." The rest of the rant is here: http://www.electricmonk.nl/log/2007/10/25/virtualization-security/ http://www.electricmonk.nl/log/2007/10/25/virtualization-sec...

agentultra 11y ago
From the same article: > Theo de Raadt's problem is that he views security the way cryptography experts view cyphers: as an absolute. But security isn't like math. It's not absolute. There are right and wrong ways of doing security. Not an absolute but there is a right and wrong way to "do security?" To be fair Boender is attacking the naive maxim that "virtualization is secure." It's just another layer if you isolate processes inside of virtualized run-time environments. Makes sense... it's not snake oil. However there is no need for "right" and "wrong" in these discussions. The security of any given system exists in a continuum and it will only be a matter of time before the next vulnerability is discovered. I get the sense that all we can do is limit the damage that can be done by any particular system. It seems that virtualization is just one path towards providing those limits just as chroot and other attempts have been. I'm most interested in seeing how jitsu and unikernels can turn the tables... not only can a process be wrapped in a virtualization layer but it is short lived and only runs when it is requested. It puts the onus on us to set up the summoner properly and provide safe-guards... but it's just another layer of complexity for attackers to manage.
- avsm 11y ago
  > I'm most interested in seeing how jitsu and unikernels can turn the tables The useful aspect about the MirageOS unikernels is that they use the pure Xen PV interface, which has almost no dependency on qemu. No floppy or block/net emulation, timers through the direct Xen shared_info page, and generally as "native" to x86 as Xen permits.
  - cthalupa 11y ago
    >timers through the direct Xen shared_info page HVM has support PV timers (and interrupt controllers, and spinlocks) for quite some time now >generally as "native" to x86 as Xen permits. I really don't know if I agree with this. With hardware extensions basic CPU performance is going to be significantly better on HVM instances (No longer having to bounce to the hypervisor every time you make a system call since you once again have three CPU protection rings with ring -1), and that's before getting into SR-IOV, etc. Unikernels are sweet and all, but without PVH, PV will outperform modern "PVHVM" implementations, and with PVH you're still running in a partial HVM shell.
    - cthalupa 11y ago
      Can't edit this anymore apparently, but correction: PV will not outperform modern "PVHVM"
krakensden 11y ago
Isn't that the appeal of KVM, though? It's just the Linux kernel, instead of a new thing like Xen?
csirac2 11y ago
It's with those thoughts in mind that usually deploy Xen dom0s without QEMU installed at all (so only PV guests). You just have to read through past Xen CVEs to see that HVM presents a lot of attack surface, admittedly I'm unsure if PV is smaller but shallower (certainly you leak more info about dom0 to guests but for guest escapes it seems there are just a lot of opportunities with QEMU in the mix).

agentultra 11y ago

From the same article: > Theo de Raadt's problem is that he views security the way cryptography experts view cyphers: as an absolute. But security isn't like math. It's not absolute. There are right and wrong ways of doing security. Not an absolute but there is a right and wrong way to "do security?" To be fair Boender is attacking the naive maxim that "virtualization is secure." It's just another layer if you isolate processes inside of virtualized run-time environments. Makes sense... it's not snake oil. However there is no need for "right" and "wrong" in these discussions. The security of any given system exists in a continuum and it will only be a matter of time before the next vulnerability is discovered. I get the sense that all we can do is limit the damage that can be done by any particular system. It seems that virtualization is just one path towards providing those limits just as chroot and other attempts have been. I'm most interested in seeing how jitsu and unikernels can turn the tables... not only can a process be wrapped in a virtualization layer but it is short lived and only runs when it is requested. It puts the onus on us to set up the summoner properly and provide safe-guards... but it's just another layer of complexity for attackers to manage.

avsm 11y ago
> I'm most interested in seeing how jitsu and unikernels can turn the tables The useful aspect about the MirageOS unikernels is that they use the pure Xen PV interface, which has almost no dependency on qemu. No floppy or block/net emulation, timers through the direct Xen shared_info page, and generally as "native" to x86 as Xen permits.
- cthalupa 11y ago
  >timers through the direct Xen shared_info page HVM has support PV timers (and interrupt controllers, and spinlocks) for quite some time now >generally as "native" to x86 as Xen permits. I really don't know if I agree with this. With hardware extensions basic CPU performance is going to be significantly better on HVM instances (No longer having to bounce to the hypervisor every time you make a system call since you once again have three CPU protection rings with ring -1), and that's before getting into SR-IOV, etc. Unikernels are sweet and all, but without PVH, PV will outperform modern "PVHVM" implementations, and with PVH you're still running in a partial HVM shell.
  - cthalupa 11y ago
    Can't edit this anymore apparently, but correction: PV will not outperform modern "PVHVM"

krakensden 11y ago

Isn't that the appeal of KVM, though? It's just the Linux kernel, instead of a new thing like Xen?

csirac2 11y ago

It's with those thoughts in mind that usually deploy Xen dom0s without QEMU installed at all (so only PV guests). You just have to read through past Xen CVEs to see that HVM presents a lot of attack surface, admittedly I'm unsure if PV is smaller but shallower (certainly you leak more info about dom0 to guests but for guest escapes it seems there are just a lot of opportunities with QEMU in the mix).