Kata used “Linux kernel Direct Access filesystem (DAX)” to directly share access of the host filesystem to the guest kernel. I thought this was pretty interesting, but it sounds like a possible spot to start a jailbreak. I’m guessing these kinds of optimizations along with using super simple virtualized devices is what gives Kata its almost-cgroups-like performance.
> Mapping files using DAX provides a number of benefits over more traditional VM file and device mapping mechanisms:
> Mapping as a direct access device allows the guest to directly access the host memory pages (such as via Execute In Place (XIP)), bypassing the guest kernel's page cache. This zero copy provides both time and space optimizations.
> Mapping as a direct access device inside the VM allows pages from the host to be demand loaded using page faults, rather than having to make requests via a virtualized device (causing expensive VM exits/hypercalls), thus providing a speed optimization.
> Utilizing mmap(2)'s MAP_SHARED shared memory option on the host allows the host to efficiently share pages.
Yeah, it's worth understanding the attack surface of DAX - if someone has information I'd be very interested. That said, you could mitigate it in other ways depending on your use case.
Having gone through an evaluation of Firecracker's security my main conclusion was that sandboxing the processes in the guest is the highest 'bang for your buck' way to reduce escapes.
Do you mean inside the guest? I'm sure they do stuff like that; they operate the normal sort of cgroups + fs mappings inside the guest VM to create inner containers. Eg all the containers in a Kubernetes pod run inside the same VM, but different containers within the VM.
> Mapping files using DAX provides a number of benefits over more traditional VM file and device mapping mechanisms:
> Mapping as a direct access device allows the guest to directly access the host memory pages (such as via Execute In Place (XIP)), bypassing the guest kernel's page cache. This zero copy provides both time and space optimizations.
> Mapping as a direct access device inside the VM allows pages from the host to be demand loaded using page faults, rather than having to make requests via a virtualized device (causing expensive VM exits/hypercalls), thus providing a speed optimization.
> Utilizing mmap(2)'s MAP_SHARED shared memory option on the host allows the host to efficiently share pages.
From https://github.com/kata-containers/kata-containers/tree/main...