Re: What belongs in the Debian cloud kernel?
On Thu, Apr 02, 2020 at 10:55:16AM -0700, Ross Vandegrift wrote:
> I don't think just saying "yes" automatically is the best approach. But
> I'm not sure we can come up with a clear set of rules. Evaluating the
> use cases will involve judgment calls about size vs functionality. I
> guess I think that's okay.
You certainly may be right. I wasn't able to convince myself either
way, which is why I posted for additional opinions.
> The first two bugs are about nested virtualization. I like the idea of
> deciding to support that or not. I don't know much about nested virt,
> so I don't have a strong opinion. It seems pretty widely supported on
> our platforms. I don't know if it raises performance or security
> concerns. So these seem okay to me, as long as we decide to support
> nested virt, and there aren't major cons that I'm unaware of.
IMO nested virtualization is not something I'd want to see in a
"production" environment. Hardware-assisted isolation between VMs is
critical for hosting mixed-trust workloads (e.g. VMs owned and
controlled by unrelated parties without a mutual trust relationship).
Current hardware virtualization extensions, e.g. Intel VTx, only have a
concept of a single level of virtualization. Nested virtualization is
implemented by trapping and emulating the CPU extensions, and by doing a
bunch of mapping of nested guest state to allow it to effectively run as
a peer VM of the parent guest in hardware. Some details at [1]. So not
only is it painfully complex, but it's also quite slow.
This is not to say that there aren't any legitimate use cases for nested
virtualization. Only that I'm not sure it's something we want to be
optimizing for.
> Can you share more about the KSM use case? I'm worried about raising
> security concerns for this one. KSM has had a history of enabling
> attacks that are sorta serious, but also sorta theoretical. This might
> cause upset from infosec folks that freak out about any vulnerability -
> even when they don't really understand the magnitude of the risk.
I don't have any direct experience with KSM. I can certainly see how it
could help with certain classes of workload, though, if it's known that
multiple processes with mostly identical state are running.
I'm not sure I'd focus too much on the security implications of KSM,
though, since it's widely enabled in Debian's generic kernel and kernels
distributed by other distros. I don't want to cargo-cult it, but
neither do I want to ignore prior art. I don't think there's any reason
to drop support for applications making use of KSM in our cloud kernels,
though. I can't think of any reason why the feature would be less
useful in a cloud environment, and it could certainly save money by
allowing the use of smaller instances.
noah
1. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/virt/kvm/nested-vmx.rst
Reply to: