
Deconstructing Xen (2017) - godelmachine
https://blog.acolyer.org/2017/03/16/deconstructing-xen/
======
cthalupa
>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?

------
KMag
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.

------
inetsee
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...](http://nathandautenhahn.com/downloads/publications/shi-
deconstructing-2017.pdf)

