The Linux kernel has far too large of an attack surface to be trusted as a hard security boundary. It is good enough to prevent mostly trusted software from accidentally interfering with each other but I would not trust it to protect me from an untrusted workload.

For example GCP and AWS both have container running services. They both use hardware VMs to isolate different tenants. You will never share a kernel with another customer (I don't even think you will share one with yourself by default).

I agree with the other comments. On the cloud, the VM is still the golden standard for strong (hardware-level isolation): if you deploy a container in the cloud, you can almost be sure there's a VM underneath. Given this, what we tried to do in that paper, in the LF Unikraft project (www.unikraft), and on kraft.cloud, is ensure that each VM only has the thinnest possible layer between the application and the hypervisor underneath -- strong isolation and hopefully max efficiency. We do use Dockerfiles to have users specify the app/filesystem, but then we transparently convert them to unikernels (specialized VMs) at deploy time.

The kernel can be attacked and exploited.

Container escape exploits are more common than VM escape exploits.

Everything you said is correct, in theory. In practice, however...