A fast, Cross-VM attack on AES [pdf] (opens in new tab)

That ship has already sailed, so much so that real companies are willing to execute hostile code inside Docker instances; Docker isn't even virtualized.

Given that virtualization is the de facto standard deployment technology for the majority of all new applications, it's worth knowing the specific limitations.

Virtualization does offer additional security if it's used to isolate things that otherwise would have been running on the same host. For example, at my old job we used OpenVZ to isolate wordpress, twiki, and roundcube, whereas historically we would have had them all installed on the same webserver.

I think this is the original source of the confusion, which has since disseminated to those who don't understand the nuances and think that virtualization adds security in every case.

The PCI DSS requires that each server just has one purpose. I was surprised when in a later version they explicitly allowed virtualization as a way to comply with that requirement.

While I agree with Theo in principle, it sounds like he's precluding the possibility that one can create a virtualization layer with formally-proven correctness guarantees (be it a hypervisor, an OS, or an application VM). For example, seL4 is proven to be free of many common types of bugs (NULL pointer dereferences, use-after-free errors, buffer overflows, etc.) that lead to security holes. AFAIK, there is no such proof for OpenBSD.

I'm not trying to suggest that a virtualization layer with formal proofs of correctness is a security panacea (it's not--correctness is necessary but not sufficient for security). What I am suggesting is that there is a way forward to developing secure virtualization layers.

If anything, this paper suggests to me that it would be best if the lowest layer in the stack (be it the OS or the hypervisor) implemented some of the crypto primitives on behalf of the applications. I can't see any other way to run them while also guaranteeing that (1) their execution is correct with the specification, (2) they run in full isolation from one another, and (3) they avoid timing attacks and whatever side-channels we can think of.

I'm curious about NaCl, would it be possible to replace OpenSSL with something based on this library? If not, why not?

The feature list certainly looks impressive!