7 ms·

One of his dumber takes. Virtualization replaces an ultra-functional general-purpose kernel evolved over decades to support every conceivable application with a

by tptacek 4mo ago

One of his dumber takes. Virtualization replaces an ultra-functional general-purpose kernel evolved over decades to support every conceivable application with a drastically smaller "kernel" (KVM and the userland hypervisor). It's a drastic attack surface reduction, and the empirical data bears that out: kernel LPEs aren't even newsworthy (there's whole repos full of unnamed, unremarked-upon LPEs), and KVM escapes are very rare.

ummonk 4mo ago
How big is the OpenBSD kernel and userland actually compared to a virtualization layer?
boricj 4mo ago
Doesn't that message date back to a time that either predates or is almost concurrent with the introduction of x86 hardware-assisted virtualization? I wasn't around playing with VMs back then, but I'm not sure that the track record of x86 virtualization 20 years ago was that great.
- tptacek 4mo ago
  It does, but that's an argument about implementations, and his comment is an argument about design. Just read it again and see if you think it's reasonable. Pay attention to the tone and (especially) the conclusory certainty he deploys.
  - SoftTalker 4mo ago
    And since then, OpenBSD has developed its own VM subsystem vmm(4), vmd(8), vmctl(8).
    - tptacek 4mo ago
      Sure, I mean, he was wrong, and I assume he knows he's wrong, and wouldn't say the same thing today. He's not dumb. Just this take is.
      - otterley 4mo ago
        I’ll take someone who’s dumb over someone who is smart but rudely and confidently incorrect any day. Modesty, thoughtfulness, and kindness are too-undervalued virtues in our business.
        tptacek 4mo ago
        I agree with everybody else who's wondered why this got posted today.
        otterley 4mo ago
        I too wonder why as it’s not news. That said, I don’t know whether Theo has since “eaten crow” or has otherwise personally evolved.
        deleted 4mo ago
        [deleted]
        newsomix9xl 4mo ago
        I would still prefer the opinions of smart rude people over not, but agreed about modesty, thoughtfulness, and kindness. And even smart people can be wrong. Sometimes a lot.
- justsomehnguy 4mo ago
  The letter is dated 2007-10. AMD released (ie commercially available) Pacifica on May 23, 2006 while Intel did released their Vanderpool a half of year earlier November 14, 2005. [0] Windows Server 2008 was RTM'ed on February 2008 which provided Hyper-V as a first class component. [1] Virtual Server 2005 R2 SP1 added support for both Intel VT (IVT) and AMD Virtualization (AMD-V) and was released 11 June 2007. [2] https://en.wikipedia.org/wiki/X86_virtualization#AMD_virtualization_(AMD-V) https://en.wikipedia.org/wiki/X86_virtualization#AMD_virtual... https://en.wikipedia.org/wiki/Windows_Server_2008 https://en.wikipedia.org/wiki/Windows_Server_2008 https://en.wikipedia.org/wiki/Microsoft_Virtual_Server#Version_history https://en.wikipedia.org/wiki/Microsoft_Virtual_Server#Versi...
- dredmorbius 4mo ago
  The email in question actually addresses one of the first, if not the first, x86 hypervisor product, Xen, relying on both my memory of the time (I did some work with Xen in the mid aughts) and Wikipedia: <https://en.wikipedia.org/wiki/Timeline_of_virtualization_technologies https://en.wikipedia.org/wiki/Timeline_of_virtualization_tec...>. The Xen hypervisor itself was pretty minimal, as I understand mostly serving to time-slice CPU cycles among guest domains and partition memory access. As a contrast to VMWare, device access and drivers were handled by the guests themselves. As such, the attack surface of the Xen hypervisor itself is fairly minimal. Most security issues seem to be denial of service vulnerabilities, though there are some privilege escalation, access, information leak, and overflow issues listed: <https://xenbits.xen.org/xsa/ https://xenbits.xen.org/xsa/> I generally respect de Raadt's expertise and instincts, though he may have been over his skis here.
TZubiri 4mo ago
I'm anti virtualization, but mostly due to the internal complexities of the guest applications being swept under the rug, it's undeniable that the host is protected and thus neighbouring guests (of course it is with almost 20 years of hindsight I can say this.) That the hypervisor is effectively an operating system/kernel I have always held, and that it is a smaller and thus less vulnerable kernel is an appropriate explication I think. It's very hard to secure an all purpose kernel like Linux without actually building it yourself (and even then..)
naturalmovement 4mo ago
If someone purposely dug up emails you wrote 19 years ago, I'm sure they'd find some of your "dumber takes" as well. I'm not sure what the purpose of revisiting this is beyond provoking a flamewar on a slow Sunday.
- tptacek 4mo ago
  I mean, I agree there. We all have dumb takes! I hear roughly once a month about my old "I don't think Dual EC is a backdoor, it's too dumb and obvious for anyone to actually use it" take.
- bawolff 4mo ago
  Probably people are responding less to the dumbness of the take and more the arrogance of the tone combined with the dumbness of the take. Everyone has dumb takes, not everyone is an asshole while giving their dumb takes. Regardless i do agree with you though, not sure what the point of digging up ancient skeletons is.
- throw0101a 4mo ago
  > If someone purposely dug up emails you wrote 19 years ago, I'm sure they'd find some of your "dumber takes" as well. "Give me six lines written by the hand of the most honest man, I will find something in them which will hang him." * https://en.wikipedia.org/wiki/Give_me_the_man_and_I_will_give_you_the_case_against_him https://en.wikipedia.org/wiki/Give_me_the_man_and_I_will_giv...
xattt 4mo ago
> replaces an ultra-functional general-purpose kernel evolved over decades to support every conceivable application with a drastically smaller "kernel" Is a Proxmox kernel that much smaller than a typical Linux kernel?
- tptacek 4mo ago
  I don't know. I don't use Proxmox.
- dehrmann 4mo ago
  Isn't Proxmox a management layover over Debian and KVM? I doubt the kernel is even smaller.
  - xattt 4mo ago
    Yes, so this narrative about hypervisors needing to be this skinny layer is a bit bunk.
Veserv 4mo ago
Virtualization is responsible for effectively none of those security benefits. It is the reduction to a smaller “kernel” that is responsible. If you applied the same design and operational model to running regular old processes instead of virtual machines you would also get a system with less security holes than the grossly insecure rat’s nest that is Linux, Windows, or whatever other commercial IT OS you have in mind. Virtualization is almost entirely orthogonal, if not harmful, to security of the platform and operations. It is not magic pixie dust that makes your operational model more robust. You need a robust operational model, then you can have a robust operational model with virtual machines. There is a reason why the most secure systems in the world are separation kernel architectures instead of hypervisors even though most of those systems do support virtualization as a feature, just not as the basis of their security propertys.
- tptacek 4mo ago
  You can falsify these claims simply by looking at the records of platform vulnerabilities. I don't think this is a live argument.
  - Veserv 4mo ago
    Great, then falsify it. Point at a system with the same operational model as KVM-based multi-tenant systems with large numbers of platform vulnerabilitys. Let us review a standard operational model: Virtual machines are usually pre-allocated their total RAM. Virtual machines are usually pre-allocated a number of cores and pinned to them. Virtual machines are usually only allocated a small number of devices such as a virtual block storage device and virtual network device upon which they implement a in-VM filesystem and network stack. Virtual machines usually have no access to shared services provided by the hypervisor. So we have a operational model where you have to pre-allocate RAM to a process. You have to pre-allocate a whole core and pin the process to it. The process has no access to a global filesystem, network stack, or devices. The process has access to exactly one file, which is logically similar to a virtual block storage device, and a single raw network socket, which is logically similar to a virtual network device. The process has no ability to form a socket to another process, form a new file, or even have any way of interacting with other processes at all. The process has no access to shared services of any kind. The chasm between that operational model and any commercial IT operating system is immense, being basically the polar opposite in every dimension in the direction of security. Default-deny instead of default-allow. Shared-nothing instead of shared-everything. What you have there is a system even more static and simple than what runs on most microkernels. That is the comparable class of platforms with a similar operational model. To demonstrate that virtualization is the key factor, you need to demonstrate that actually comparable systems with similar operational models like microkernels have more platform vulnerabilitys than comparable KVM-based, or even just hypervisor-based, systems. Which, again, flies against the face of evidence as the systems that are actually used in high security applications designed to protect against state actors are separation kernels instead of hypervisors.

by tptacek 4mo ago

ummonk 4mo ago

How big is the OpenBSD kernel and userland actually compared to a virtualization layer?

boricj 4mo ago

Doesn't that message date back to a time that either predates or is almost concurrent with the introduction of x86 hardware-assisted virtualization? I wasn't around playing with VMs back then, but I'm not sure that the track record of x86 virtualization 20 years ago was that great.

tptacek 4mo ago
It does, but that's an argument about implementations, and his comment is an argument about design. Just read it again and see if you think it's reasonable. Pay attention to the tone and (especially) the conclusory certainty he deploys.
- SoftTalker 4mo ago
  And since then, OpenBSD has developed its own VM subsystem vmm(4), vmd(8), vmctl(8).
  - tptacek 4mo ago
    Sure, I mean, he was wrong, and I assume he knows he's wrong, and wouldn't say the same thing today. He's not dumb. Just this take is.
    - otterley 4mo ago
      I’ll take someone who’s dumb over someone who is smart but rudely and confidently incorrect any day. Modesty, thoughtfulness, and kindness are too-undervalued virtues in our business.
      - tptacek 4mo ago
        I agree with everybody else who's wondered why this got posted today.
        otterley 4mo ago
        I too wonder why as it’s not news. That said, I don’t know whether Theo has since “eaten crow” or has otherwise personally evolved.
        deleted 4mo ago
        [deleted]
      - newsomix9xl 4mo ago
        I would still prefer the opinions of smart rude people over not, but agreed about modesty, thoughtfulness, and kindness. And even smart people can be wrong. Sometimes a lot.
justsomehnguy 4mo ago
The letter is dated 2007-10. AMD released (ie commercially available) Pacifica on May 23, 2006 while Intel did released their Vanderpool a half of year earlier November 14, 2005. [0] Windows Server 2008 was RTM'ed on February 2008 which provided Hyper-V as a first class component. [1] Virtual Server 2005 R2 SP1 added support for both Intel VT (IVT) and AMD Virtualization (AMD-V) and was released 11 June 2007. [2] https://en.wikipedia.org/wiki/X86_virtualization#AMD_virtualization_(AMD-V) https://en.wikipedia.org/wiki/X86_virtualization#AMD_virtual... https://en.wikipedia.org/wiki/Windows_Server_2008 https://en.wikipedia.org/wiki/Windows_Server_2008 https://en.wikipedia.org/wiki/Microsoft_Virtual_Server#Version_history https://en.wikipedia.org/wiki/Microsoft_Virtual_Server#Versi...
dredmorbius 4mo ago
The email in question actually addresses one of the first, if not the first, x86 hypervisor product, Xen, relying on both my memory of the time (I did some work with Xen in the mid aughts) and Wikipedia: <https://en.wikipedia.org/wiki/Timeline_of_virtualization_technologies https://en.wikipedia.org/wiki/Timeline_of_virtualization_tec...>. The Xen hypervisor itself was pretty minimal, as I understand mostly serving to time-slice CPU cycles among guest domains and partition memory access. As a contrast to VMWare, device access and drivers were handled by the guests themselves. As such, the attack surface of the Xen hypervisor itself is fairly minimal. Most security issues seem to be denial of service vulnerabilities, though there are some privilege escalation, access, information leak, and overflow issues listed: <https://xenbits.xen.org/xsa/ https://xenbits.xen.org/xsa/> I generally respect de Raadt's expertise and instincts, though he may have been over his skis here.

TZubiri 4mo ago

I'm anti virtualization, but mostly due to the internal complexities of the guest applications being swept under the rug, it's undeniable that the host is protected and thus neighbouring guests (of course it is with almost 20 years of hindsight I can say this.) That the hypervisor is effectively an operating system/kernel I have always held, and that it is a smaller and thus less vulnerable kernel is an appropriate explication I think. It's very hard to secure an all purpose kernel like Linux without actually building it yourself (and even then..)

naturalmovement 4mo ago

If someone purposely dug up emails you wrote 19 years ago, I'm sure they'd find some of your "dumber takes" as well. I'm not sure what the purpose of revisiting this is beyond provoking a flamewar on a slow Sunday.

tptacek 4mo ago
I mean, I agree there. We all have dumb takes! I hear roughly once a month about my old "I don't think Dual EC is a backdoor, it's too dumb and obvious for anyone to actually use it" take.
bawolff 4mo ago
Probably people are responding less to the dumbness of the take and more the arrogance of the tone combined with the dumbness of the take. Everyone has dumb takes, not everyone is an asshole while giving their dumb takes. Regardless i do agree with you though, not sure what the point of digging up ancient skeletons is.
throw0101a 4mo ago
> If someone purposely dug up emails you wrote 19 years ago, I'm sure they'd find some of your "dumber takes" as well. "Give me six lines written by the hand of the most honest man, I will find something in them which will hang him." * https://en.wikipedia.org/wiki/Give_me_the_man_and_I_will_give_you_the_case_against_him https://en.wikipedia.org/wiki/Give_me_the_man_and_I_will_giv...

xattt 4mo ago

> replaces an ultra-functional general-purpose kernel evolved over decades to support every conceivable application with a drastically smaller "kernel" Is a Proxmox kernel that much smaller than a typical Linux kernel?

tptacek 4mo ago
I don't know. I don't use Proxmox.
dehrmann 4mo ago
Isn't Proxmox a management layover over Debian and KVM? I doubt the kernel is even smaller.
- xattt 4mo ago
  Yes, so this narrative about hypervisors needing to be this skinny layer is a bit bunk.

Veserv 4mo ago

Virtualization is responsible for effectively none of those security benefits. It is the reduction to a smaller “kernel” that is responsible. If you applied the same design and operational model to running regular old processes instead of virtual machines you would also get a system with less security holes than the grossly insecure rat’s nest that is Linux, Windows, or whatever other commercial IT OS you have in mind. Virtualization is almost entirely orthogonal, if not harmful, to security of the platform and operations. It is not magic pixie dust that makes your operational model more robust. You need a robust operational model, then you can have a robust operational model with virtual machines. There is a reason why the most secure systems in the world are separation kernel architectures instead of hypervisors even though most of those systems do support virtualization as a feature, just not as the basis of their security propertys.

tptacek 4mo ago
You can falsify these claims simply by looking at the records of platform vulnerabilities. I don't think this is a live argument.
- Veserv 4mo ago
  Great, then falsify it. Point at a system with the same operational model as KVM-based multi-tenant systems with large numbers of platform vulnerabilitys. Let us review a standard operational model: Virtual machines are usually pre-allocated their total RAM. Virtual machines are usually pre-allocated a number of cores and pinned to them. Virtual machines are usually only allocated a small number of devices such as a virtual block storage device and virtual network device upon which they implement a in-VM filesystem and network stack. Virtual machines usually have no access to shared services provided by the hypervisor. So we have a operational model where you have to pre-allocate RAM to a process. You have to pre-allocate a whole core and pin the process to it. The process has no access to a global filesystem, network stack, or devices. The process has access to exactly one file, which is logically similar to a virtual block storage device, and a single raw network socket, which is logically similar to a virtual network device. The process has no ability to form a socket to another process, form a new file, or even have any way of interacting with other processes at all. The process has no access to shared services of any kind. The chasm between that operational model and any commercial IT operating system is immense, being basically the polar opposite in every dimension in the direction of security. Default-deny instead of default-allow. Shared-nothing instead of shared-everything. What you have there is a system even more static and simple than what runs on most microkernels. That is the comparable class of platforms with a similar operational model. To demonstrate that virtualization is the key factor, you need to demonstrate that actually comparable systems with similar operational models like microkernels have more platform vulnerabilitys than comparable KVM-based, or even just hypervisor-based, systems. Which, again, flies against the face of evidence as the systems that are actually used in high security applications designed to protect against state actors are separation kernels instead of hypervisors.