diff mbox series

[v3,10/11] KVM: x86/MMU: Require reboot permission to disable NX hugepages

Message ID 20220330174621.1567317-11-bgardon@google.com (mailing list archive)
State New, archived
Headers show
Series KVM: x86: Add a cap to disable NX hugepages on a VM | expand

Commit Message

Ben Gardon March 30, 2022, 5:46 p.m. UTC
Ensure that the userspace actor attempting to disable NX hugepages has
permission to reboot the system. Since disabling NX hugepages would
allow a guest to crash the system, it is similar to reboot permissions.

This approach is the simplest permission gating, but passing a file
descriptor opened for write for the module parameter would also work
well and be more precise.
The latter approach was suggested by Sean Christopherson.

Suggested-by: Jim Mattson <jmattson@google.com>
Signed-off-by: Ben Gardon <bgardon@google.com>
---
 Documentation/virt/kvm/api.rst | 2 ++
 arch/x86/kvm/x86.c             | 9 +++++++++
 2 files changed, 11 insertions(+)

Comments

Sean Christopherson March 30, 2022, 6:02 p.m. UTC | #1
On Wed, Mar 30, 2022, Ben Gardon wrote:
> Ensure that the userspace actor attempting to disable NX hugepages has
> permission to reboot the system. Since disabling NX hugepages would
> allow a guest to crash the system, it is similar to reboot permissions.

This patch needs to be squashed with the patch that introduces the capability,
otherwise you're introdcuing a bug and then fixing it in the same series.
Ben Gardon March 30, 2022, 11:42 p.m. UTC | #2
On Wed, Mar 30, 2022 at 11:02 AM Sean Christopherson <seanjc@google.com> wrote:
>
> On Wed, Mar 30, 2022, Ben Gardon wrote:
> > Ensure that the userspace actor attempting to disable NX hugepages has
> > permission to reboot the system. Since disabling NX hugepages would
> > allow a guest to crash the system, it is similar to reboot permissions.
>
> This patch needs to be squashed with the patch that introduces the capability,
> otherwise you're introdcuing a bug and then fixing it in the same series.

I'm happy to do that. I figured that leaving it as a separate patch
would provide an easy way to separate the discussion on how to
implement the new cap versus how to restrict it.
I don't know if I'd consider not having this patch a bug, especially
since it can make testing kind of a pain, but I see your point.
diff mbox series

Patch

diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
index b40c3113b14b..ca5674e04474 100644
--- a/Documentation/virt/kvm/api.rst
+++ b/Documentation/virt/kvm/api.rst
@@ -7850,6 +7850,8 @@  should adjust CPUID leaf 0xA to reflect that the PMU is disabled.
 :Capability KVM_CAP_PMU_CAPABILITY
 :Architectures: x86
 :Type: vm
+:Returns 0 on success, -EPERM if the userspace process does not
+	 have CAP_SYS_BOOT
 
 This capability disables the NX huge pages mitigation for iTLB MULTIHIT.
 
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index e00dcf19f826..81e7d825639e 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -6063,6 +6063,15 @@  int kvm_vm_ioctl_enable_cap(struct kvm *kvm,
 		mutex_unlock(&kvm->lock);
 		break;
 	case KVM_CAP_VM_DISABLE_NX_HUGE_PAGES:
+		/*
+		 * Since the risk of disabling NX hugepages is a guest crashing
+		 * the system, ensure the userspace process has permission to
+		 * reboot the system.
+		 */
+		if (!capable(CAP_SYS_BOOT)) {
+			r = -EPERM;
+			break;
+		}
 		kvm->arch.disable_nx_huge_pages = true;
 		kvm_update_nx_huge_pages(kvm);
 		r = 0;