>Of the 144 Xen hypervisor vulnerabilities in the report, Nexen can defend against 96 of them on the Intel x86 platform, and if an equivalent implementation was created for ARM and AMD processors, the architecture would also defend against a further 17 vulnerabilities specific to those processor types. In total, Nexen prevents 107 out of the 144 vulnerabilities.
I've never quite understood papers that quantify things in this manner. Presumably, the Xen hypervisor can now defend against 144 of the 144 vulnerabilities listed. I understand that the point of Nexen is to eliminate classes of vulnerabilities, but this paragraph does a very poor job of conveying it.
Why is it not "Nexen is defended against X, Y, and Z classes of vulnerabilities as a product of it's design, of which 107 of the 144 Xen vulnerabilities are, blah blah blah"?
If it's not a product of the design, then it's pretty meaningless - cool, a reimplementation of Xen that came after all of these vulnerabilities is defended against a lot of them. So what?
A hypervisor is a microkernel with a hardware-like system interface (trapping and emulating attempts to directly interact with the MMU, network cards, etc.) plus a higher efficiency software-like interface (upcalls).
I hope modern hypervisors are merely a transitional evolutionary form to a more sensible minimal interface. DEC was really on the right track with providing essentially a hypervisor (PALcode) as the firmware and from day 1 not allowing the OS kernels to manipulate page tables, etc. VMS (on Alpha), Tru64 UNIX, and Linux (on Alpha) all always essentially ran as dom0 in hyperisor terminology. As far as I know, DEC never shipped PALcode that supported multiple simultaneous guest kernels, but that's only a small stretch of their original architecture and wouldn't have required any hardware changes or changes to the VMS or Tru64 UNIX (or Linux for Alpha) kernels.
I'm surprised we don't use a modern realtime high-performance microkernel (seL4, OKL4, mabye something QNX-like) and put the hardware emulation functionality out in one or more userspace programs that would translate trapped operations into normal micokernel syscalls (upcalls). OS kernels can be modified (paravirtualized) to use calls to the microkernel instead of performing the operations that would get trapped.
In the short term, this would result in lower performance for unmodified OSes, but increases security and increases incentives for the OS vendors to paravirtualize their kernels. In the longer term, though, it would result in a smaller cache footprint and thus lower overhead and lower latency for microkernel/hypervisor operations.
>Of the 144 Xen hypervisor vulnerabilities in the report, Nexen can defend against 96 of them on the Intel x86 platform, and if an equivalent implementation was created for ARM and AMD processors, the architecture would also defend against a further 17 vulnerabilities specific to those processor types. In total, Nexen prevents 107 out of the 144 vulnerabilities.
I've never quite understood papers that quantify things in this manner. Presumably, the Xen hypervisor can now defend against 144 of the 144 vulnerabilities listed. I understand that the point of Nexen is to eliminate classes of vulnerabilities, but this paragraph does a very poor job of conveying it.
Why is it not "Nexen is defended against X, Y, and Z classes of vulnerabilities as a product of it's design, of which 107 of the 144 Xen vulnerabilities are, blah blah blah"?
If it's not a product of the design, then it's pretty meaningless - cool, a reimplementation of Xen that came after all of these vulnerabilities is defended against a lot of them. So what?
A hypervisor is a microkernel with a hardware-like system interface (trapping and emulating attempts to directly interact with the MMU, network cards, etc.) plus a higher efficiency software-like interface (upcalls).
I hope modern hypervisors are merely a transitional evolutionary form to a more sensible minimal interface. DEC was really on the right track with providing essentially a hypervisor (PALcode) as the firmware and from day 1 not allowing the OS kernels to manipulate page tables, etc. VMS (on Alpha), Tru64 UNIX, and Linux (on Alpha) all always essentially ran as dom0 in hyperisor terminology. As far as I know, DEC never shipped PALcode that supported multiple simultaneous guest kernels, but that's only a small stretch of their original architecture and wouldn't have required any hardware changes or changes to the VMS or Tru64 UNIX (or Linux for Alpha) kernels.
I'm surprised we don't use a modern realtime high-performance microkernel (seL4, OKL4, mabye something QNX-like) and put the hardware emulation functionality out in one or more userspace programs that would translate trapped operations into normal micokernel syscalls (upcalls). OS kernels can be modified (paravirtualized) to use calls to the microkernel instead of performing the operations that would get trapped.
In the short term, this would result in lower performance for unmodified OSes, but increases security and increases incentives for the OS vendors to paravirtualize their kernels. In the longer term, though, it would result in a smaller cache footprint and thus lower overhead and lower latency for microkernel/hypervisor operations.
The link at the top of the paper seems to be broken. A pdf of the paper being reviewed can be found here: http://nathandautenhahn.com/downloads/publications/shi-decon...