> Narrowing the interface of a platform will not necessarily improve security, unless it reduces the footprint of host code likely to contain vulnerabilities, so we have focused on understanding the kernel footprint underneath each virtualization system.
These things are hard to quantify, but this is a very reasonable attempt. However, as we say in one of our Firecracker papers (https://www.usenix.org/conference/nsdi20/presentation/agache):
> Li et al [32] demonstrate the effectiveness of a ’popular paths’ metric, showing that only 3% of kernel bugs are found in frequently-used code paths (which, in our experience, overlap highly with the code paths used by the VMM)
There, the reference is to Lock-In-Pop by Li et al (https://www.usenix.org/conference/atc17/technical-sessions/p...). This is important, because bug density isn't constant across the kernel surface area (just as it isn't constant across any code base). FWIW I don't think Lock-In-Pop is the right mechanism for isolation, but it's a very good way to weight the metrics if we're comparing kernel surface area.
Back to the paper at hand:
> Both gVisor and Firecracker restrict the set of system calls
available to improve security and isolation.
I'm not sure what they mean here. Firecracker doesn't restrict the set of system calls guests can use. In my mind, that's one of the biggest advantages of Firecracker's approach - there's no hard tradeoff to be made between isolation strength and guest software compatibility.
These things are hard to quantify, but this is a very reasonable attempt. However, as we say in one of our Firecracker papers (https://www.usenix.org/conference/nsdi20/presentation/agache):
> Li et al [32] demonstrate the effectiveness of a ’popular paths’ metric, showing that only 3% of kernel bugs are found in frequently-used code paths (which, in our experience, overlap highly with the code paths used by the VMM)
There, the reference is to Lock-In-Pop by Li et al (https://www.usenix.org/conference/atc17/technical-sessions/p...). This is important, because bug density isn't constant across the kernel surface area (just as it isn't constant across any code base). FWIW I don't think Lock-In-Pop is the right mechanism for isolation, but it's a very good way to weight the metrics if we're comparing kernel surface area.
Back to the paper at hand:
> Both gVisor and Firecracker restrict the set of system calls available to improve security and isolation.
I'm not sure what they mean here. Firecracker doesn't restrict the set of system calls guests can use. In my mind, that's one of the biggest advantages of Firecracker's approach - there's no hard tradeoff to be made between isolation strength and guest software compatibility.