ksmd should be opt-in rather than opt-out

[Seth Arnold]

This was originally raised in https://bugs.launchpad.net/cloud-images/+bug/2032933/comments/13 :

> > +ksmd
>$
> I'm concerned about this change. Historically, the page-merging
> code has allowed cross-VM snooping, including even recovery of
> GnuPG private keys: https://eprint.iacr.org/2013/448.pdf
>$
> Unless something has changed to mitigate the cross-domain privacy
> leaks in ksmd, it ought to be opt-in for administrators to select
> if all their VMs are in the same security domain.

There's a collection of references on Wikipedia https://en.wikipedia.org/wiki/Kernel_same-page_merging#Security_risks showing the work; there's a paper from 2021 demonstrating the issue remotely: https://graz.elsevierpure.com/en/publications/remote-memory-deduplication-attacks

I realize KSM is the difference between some workloads working and not working, so I'm not proposing that it be removed entirely. It has its place. But I also think it should be opt-in rather than opt-out.

Thanks

[Mitchell Dzurick (mitchdz)]

Hi Seth, thanks for making the bug report!

Did you see Thomas' recent comment in the original bug? https://bugs.launchpad.net/cloud-images/+bug/2032933/comments/21

Does having it enabled only when installing ksmtuned good enough?

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Thomas Bechtold (toabctl)]

As Christian pointed out (see https://bugs.launchpad.net/cloud-images/+bug/2032933/comments/22), it also gets activated when installing qemu-system-...

[Seth Arnold (seth-arnold)]

What are our options for making KSM opt-in rather than opt-out for qemu-system-... packages?

(ksmtuned doing what it does seems fine to me: (a) it's in universe, thus not a default installed tool anywhere (b) the name clearly says what it's going to do. An admin that installs it knows what they want.)

A debconf setting is the first thing that comes to mind, but it's not very discoverable. A systemd service file feels easy, sort-of, but I'm not sure it's that much more discoverable than debconf.

Should we change it only for future releases or also including historical releases? (I'm inclined to say only future releases. Even though I feel strongly that we should disable it by default for safety, I also don't want users with pitchforks at my door for a surprise change that makes their workloads fail.)

Thanks

[Sergio Durigan Junior (sergiodj)]

Hi Seth,

Just dumping some thoughts here; bear in mind that I haven't looked deep into this yet so take my opinions with more than a grain of salt.

In Ubuntu I'm always wary about using debconf for anything; I guess it's because of how many times I've heard that we should really limit the number of prompts the user will have during the system upgrade. Anyway, I like the idea of a systemd service because it's easier to control (it doesn't require running dpkg-reconfigure if you change your opinion). I agree with the discoverability issue, and I think we can resort to a NEWS entry for that. Not sure how many people will actually see it, but it's better than just throwing the service file out there.

As for including in historical releases: I'm very inclined to say no. Let's go with future releases only. As you said it yourself, "An admin that installs it knows what they want." I think this goes both ways: if the package is already installed and working as expected, the less we touch it the better, IMHO.

Anyway, as I said above, I still plan on looking into this issue more carefully. We'll see what the future holds.

Thanks.