Paravirtualized Control Register pinning
Subsystems (5)
cover Paravirtualized Control Register pinning
Paravirtualized Control Register pinning is a strengthened version of existing protections on the Write Protect, Supervisor Mode Execution / Access Protection, and User-Mode Instruction Prevention bits. The existing protections prevent native_write_cr*() functions from writing values which disable those bits. This patchset prevents any guest writes to control registers from disabling pinned bits, not just writes from native_write_cr*(). This stops attackers within the guest from using ROP to disable protection bits.
The protection is implemented by adding MSRs to KVM which contain the bits that are allowed to be pinned, and the bits which are pinned. The guest or userspace can enable bit pinning by reading MSRs to check which bits are allowed to be pinned, and then writing MSRs to set which bits they want pinned.
Other hypervisors such as HyperV have implemented similar protections for Control Registers and MSRs; which security researchers have found effective.
https://www.abatchy.com/2018/01/kernel-exploitation-4
We add a CR pin feature bit to the KVM cpuid, read only MSRs which guests use to identify which bits they may request be pinned, and CR pinned MSRs which contain the pinned bits. Guests can request that KVM pin bits within control register 0 or 4 via the CR pinned MSRs. Writes to the MSRs fail if they include bits that aren't allowed to be pinned. Host userspace may clear or modify pinned bits at any time. Once pinned bits are set, the guest may pin more allowed bits, but may never clear pinned bits.
In the event that the guest vcpu attempts to disable any of the pinned bits, the vcpu that issued the write is sent a general protection fault, and the register is left unchanged.
Pinning is not active when running in SMM. Entering SMM disables pinned bits, writes to control registers within SMM would therefore trigger
general protection faults if pinning was enforced.
The guest may never read pinned bits. If an attacker were to read the CR pinned MSRs, they might decide to preform another attack which would not cause a general protection fault.
Should userspace expose the CR pining CPUID feature bit, it must zero CR pinned MSRs on reboot. If it does not, it runs the risk of having the guest enable pinning and subsequently cause general protection faults on next boot due to early boot code setting control registers to values which do not contain the pinned bits.
When running with KVM guest support and paravirtualized CR pinning enabled, paravirtualized and existing pinning are setup at the same point on the boot CPU. Non-boot CPUs setup pinning upon identification.
Guests using the kexec system call currently do not support paravirtualized control register pinning. This is due to early boot code writing known good values to control registers, these values do not contain the protected bits. This is due to CPU feature identification being done at a later time, when the kernel properly checks if it can enable protections.
Most distributions enable kexec. However, kexec could be made boot time disableable. In this case if a user has disabled kexec at boot time the guest will request that paravirtualized control register pinning be enabled. This would expand the userbase to users of major distributions.
Paravirtualized CR pinning will likely be incompatible with kexec for the foreseeable future. Early boot code could possibly be changed to not clear protected bits. However, a kernel that requests CR bits be pinned can't know if the kernel it's kexecing has been updated to not clear protected bits. This would result in the kernel being kexec'd almost immediately receiving a general protection fault.
Security conscious kernel configurations disable kexec already, per KSPP guidelines. Projects such as Kata Containers, AWS Lambda, ChromeOS Termina, and others using KVM to virtualize Linux will benefit from this protection.
The usage of SMM in SeaBIOS was explored as a way to communicate to KVM that a reboot has occurred and it should zero the pinned bits. When using QEMU and SeaBIOS, SMM initialization occurs on reboot. However, prior to SMM initialization, BIOS writes zero values to CR0, causing a
general protection fault to be sent to the guest before SMM can signal
that the machine has booted.
Pinning of sensitive CR bits has already been implemented to protect against exploits directly calling native_write_cr*(). The current protection cannot stop ROP attacks which jump directly to a MOV CR instruction. Guests running with paravirtualized CR pinning are now protected against the use of ROP to disable CR bits. The same bits that are being pinned natively may be pinned via the CR pinned MSRs. These bits are WP in CR0, and SMEP, SMAP, and UMIP in CR4.
Future patches could implement similar MSR and hypercall combinations to protect bits in MSRs. The NXE bit of the EFER MSR is a prime candidate.
John Andersen (2):
KVM: X86: Add CR pin MSRs
X86: Use KVM CR pin MSRs
Documentation/virt/kvm/msr.txt | 38 +++++++++++++++++++++++ arch/x86/Kconfig | 9 ++++++ arch/x86/include/asm/kvm_host.h | 2 ++ arch/x86/include/asm/kvm_para.h | 10 +++++++ arch/x86/include/uapi/asm/kvm_para.h | 5 ++++ arch/x86/kernel/cpu/common.c | 5 ++++ arch/x86/kernel/kvm.c | 17 +++++++++++ arch/x86/kvm/cpuid.c | 3 +- arch/x86/kvm/x86.c | 45 ++++++++++++++++++++++++++++ 9 files changed, 133 insertions(+), 1 deletion(-)
Signature · 1 line
2.21.0
RFC 1/2 KVM: X86: Add CR pin MSRs
Add a CR pin feature bit to the KVM cpuid. Add read only MSRs to KVM which guests use to identify which bits they may request be pinned. Add CR pinned MSRs to KVM. Allow guests to request that KVM pin certain bits within control register 0 or 4 via the CR pinned MSRs. Writes to the MSRs fail if they include bits which aren't allowed. Host userspace may clear or modify pinned bits at any time. Once pinned bits are set, the guest may pin additional allowed bits, but not clear any. The guest may never read pinned bits. If an attacker were to read the CR pinned MSRs, they might decide to preform another attack which would not cause a general protection fault.
In the event that the guest vcpu attempts to disable any of the pinned bits, send that vcpu a general protection fault, and leave the register unchanged. Entering SMM unconditionally clears various CR0/4 bits, some of which may be pinned by the OS. To avoid trigerring shutdown on SMIs, pinning isn't enforced when the vCPU is running in SMM.
Should userspace expose the CR pinning CPUID feature bit, it must zero CR pinned MSRs on reboot. If it does not, it runs the risk of having the guest enable pinning and subsequently cause general protection faults on next boot due to early boot code setting control registers to values which do not contain the pinned bits. Userspace is responsible for migrating the contents of the CR* pinned MSRs. If userspace fails to migrate the MSRs the protection will no longer be active.
Pinning of sensitive CR bits has already been implemented to protect against exploits directly calling native_write_cr*(). The current protection cannot stop ROP attacks which jump directly to a MOV CR instruction.
Guests running with paravirtualized CR pinning are now protected against the use of ROP to disable CR bits. The same bits that are being pinned natively may be pinned via the CR pinned MSRs. These bits are WP in CR0, and SMEP, SMAP, and UMIP in CR4.
Other hypervisors such as HyperV have implemented similar protections for Control Registers and MSRs; which security researchers have found effective.
https://www.abatchy.com/2018/01/kernel-exploitation-4
Future patches could implement similar MSR and hypercall combinations to protect bits in MSRs. The NXE bit of the EFER MSR is a prime candidate.
Patches for QEMU are required to expose the CR pin cpuid feature bit. As well as clear the MSRs on reboot and enable migration.
https://github.com/qemu/qemu/commit/e7a0ff8a8dcde1ef2b83a9d93129614f512752ae
https://github.com/qemu/qemu/commit/7e8c770c91616ae8d2d6b15bcc2865be594c8852
--- Documentation/virt/kvm/msr.txt | 38 +++++++++++++++++++++++ arch/x86/include/asm/kvm_host.h | 2 ++ arch/x86/include/uapi/asm/kvm_para.h | 5 ++++ arch/x86/kvm/cpuid.c | 3 +- arch/x86/kvm/x86.c | 45 ++++++++++++++++++++++++++++ 5 files changed, 92 insertions(+), 1 deletion(-)
Documentation/virt/kvm/msr.txt +38 -0
@@ -282,3 +282,41 @@ MSR_KVM_POLL_CONTROL: 0x4b564d05 KVM guests can request the host not to poll on HLT, for example if they are performing polling themselves. +MSR_KVM_CR0_PIN_ALLOWED: 0x4b564d06 +MSR_KVM_CR4_PIN_ALLOWED: 0x4b564d07 + Read only registers informing the guest which bits may be pinned for + each control register respectively via the CR pinned MSRs. + + data: Bits which may be pinned. + + Attempting to pin bits other than these will result in a failure when + writing to the respective CR pinned MSR. + + Bits which are allowed to be pinned are WP for CR0 and SMEP, SMAP, and + UMIP for CR4. + +MSR_KVM_CR0_PINNED: 0x4b564d08 +MSR_KVM_CR4_PINNED: 0x4b564d09 + Used to configure pinned bits in control registers + + data: Bits to be pinned. + + Fails if data contains bits which are not allowed to be pinned. Bits + which are allowed to be pinned can be found by reading the CR pin + allowed MSRs. + + The MSRs are read/write for host userspace, and write-only for the + guest. + + Once set to a non-zero value, the guest cannot clear any of the bits + that have been pinned to 1. The guest can set more bits to 1, so long + as those bits appear in the allowed MSR. + + Host userspace may clear or change pinned bits at any point. Host + userspace must clear pinned bits on reboot. + + The MSR enables bit pinning for control registers. Pinning is active + when the guest is not in SMM. If the guest attempts to write values to + cr* where bits differ from pinned bits, the write will fail and the + guest will be sent a general protection fault. +
arch/x86/include/asm/kvm_host.h +2 -0
@@ -562,10 +562,12 @@ struct kvm_vcpu_arch {unsigned long cr0;unsigned long cr0_guest_owned_bits; +unsigned long cr0_pinned;unsigned long cr2;unsigned long cr3;unsigned long cr4;unsigned long cr4_guest_owned_bits; +unsigned long cr4_pinned;unsigned long cr8;u32 pkru;u32 hflags;
arch/x86/include/uapi/asm/kvm_para.h +5 -0
@@ -31,6 +31,7 @@#define KVM_FEATURE_PV_SEND_IPI 11#define KVM_FEATURE_POLL_CONTROL 12#define KVM_FEATURE_PV_SCHED_YIELD 13 +#define KVM_FEATURE_CR_PIN 14#define KVM_HINTS_REALTIME 0
@@ -50,6 +51,10 @@#define MSR_KVM_STEAL_TIME 0x4b564d03#define MSR_KVM_PV_EOI_EN 0x4b564d04#define MSR_KVM_POLL_CONTROL 0x4b564d05 +#define MSR_KVM_CR0_PIN_ALLOWED 0x4b564d06 +#define MSR_KVM_CR4_PIN_ALLOWED 0x4b564d07 +#define MSR_KVM_CR0_PINNED 0x4b564d08 +#define MSR_KVM_CR4_PINNED 0x4b564d09struct kvm_steal_time {__u64 steal;
arch/x86/kvm/cpuid.c +2 -1
@@ -712,7 +712,8 @@ static inline int __do_cpuid_func(struct kvm_cpuid_entry2 *entry, u32 function, (1 <<KVM_FEATURE_ASYNC_PF_VMEXIT ) | (1 <<KVM_FEATURE_PV_SEND_IPI ) | (1 <<KVM_FEATURE_POLL_CONTROL ) | - (1 <<KVM_FEATURE_PV_SCHED_YIELD ); + (1 <<KVM_FEATURE_PV_SCHED_YIELD ) | + (1 <<KVM_FEATURE_CR_PIN );if (sched_info_on ()) entry->eax |= (1 <<KVM_FEATURE_STEAL_TIME );
arch/x86/kvm/x86.c +45 -0
81 lines not on this page · raw message
Signature · 1 line
2.21.0
RFC 2/2 X86: Use KVM CR pin MSRs
In reply to John AndersenStrengthen existing control register pinning when running paravirtualized under KVM. Check which bits KVM supports pinning for each control register and only pin supported bits which are already pinned via the existing native protection. Write to KVM CR0 and CR4 pinned MSRs to enable pinning.
Initiate KVM assisted pinning directly following the setup of native pinning on boot CPU. For non-boot CPUs initiate paravirtualized pinning on CPU identification.
Identification of non-boot CPUs takes place after the boot CPU has setup native CR pinning. Therefore, non-boot CPUs access pinned bits setup by the boot CPU and request that those be pinned. All CPUs request paravirtualized pinning of the same bits which are already pinned natively.
Guests using the kexec system call currently do not support paravirtualized control register pinning. This is due to early boot code writing known good values to control registers, these values do not contain the protected bits. This is due to CPU feature identification being done at a later time, when the kernel properly checks if it can enable protections.
--- arch/x86/Kconfig | 9 +++++++++ arch/x86/include/asm/kvm_para.h | 10 ++++++++++ arch/x86/kernel/cpu/common.c | 5 +++++ arch/x86/kernel/kvm.c | 17 +++++++++++++++++ 4 files changed, 41 insertions(+)
arch/x86/Kconfig +9 -0
@@ -839,6 +839,15 @@ config PARAVIRT_TIME_ACCOUNTING config PARAVIRT_CLOCK bool +config PARAVIRT_CR_PIN + bool "Paravirtual bit pinning for CR0 and CR4" + depends on KVM_GUEST && !KEXEC + help + Select this option to have the virtualised guest request that the + hypervisor disallow it from disabling protections set in control + registers. The hypervisor will prevent exploits from disabling + features such as SMEP, SMAP, UMIP, and WP. + config JAILHOUSE_GUEST bool "Jailhouse non-root cell support" depends on X86_64 && PCI
arch/x86/include/asm/kvm_para.h +10 -0
@@ -102,6 +102,16 @@ static inline void kvm_spinlock_init(void) }#endif /* CONFIG_PARAVIRT_SPINLOCKS */ +#ifdef CONFIG_PARAVIRT_CR_PIN +void kvm_setup_paravirt_cr_pinning (unsigned long cr0_pinned_bits, +unsigned long cr4_pinned_bits); +#else +static inline void kvm_setup_paravirt_cr_pinning (unsigned long cr0_pinned_bits, +unsigned long cr4_pinned_bits) +{ +} +#endif /* CONFIG_PARAVIRT_CR_PIN */ +#else /* CONFIG_KVM_GUEST */ #define kvm_async_pf_task_wait (T ,I ) do {} while(0)#define kvm_async_pf_task_wake (T ) do {} while(0)
arch/x86/kernel/cpu/common.c +5 -0
@@ -20,6 +20,7 @@#include <linux/smp.h> #include <linux/io.h> #include <linux/syscore_ops.h> +#include <linux/kvm_para.h> #include <asm/stackprotector.h> #include <asm/perf_event.h>
@@ -435,6 +436,8 @@ static void __init setup_cr_pinning(void) mask = (X86_CR4_SMEP |X86_CR4_SMAP |X86_CR4_UMIP ); cr4_pinned_bits =this_cpu_read (cpu_tlbstate.cr4) & mask;static_key_enable (&cr_pinning.key); + +kvm_setup_paravirt_cr_pinning (X86_CR0_WP , cr4_pinned_bits); }/*
@@ -1597,6 +1600,8 @@ void identify_secondary_cpu(struct cpuinfo_x86 *c)mtrr_ap_init ();validate_apic_and_package_id (c);x86_spec_ctrl_setup_ap (); + +kvm_setup_paravirt_cr_pinning (X86_CR0_WP , cr4_pinned_bits); }static __init int setup_noclflush (char *arg)
arch/x86/kernel/kvm.c +17 -0
@@ -858,6 +858,23 @@ void __init kvm_spinlock_init(void)#endif /* CONFIG_PARAVIRT_SPINLOCKS */ +#ifdef CONFIG_PARAVIRT_CR_PIN +void kvm_setup_paravirt_cr_pinning (unsigned long cr0_pinned_bits, +unsigned long cr4_pinned_bits) +{ +u64 mask; + +if (!kvm_para_has_feature (KVM_FEATURE_CR_PIN )) +return ; + +rdmsrl (MSR_KVM_CR0_PIN_ALLOWED , mask); +wrmsrl (MSR_KVM_CR0_PINNED , cr0_pinned_bits & mask); + +rdmsrl (MSR_KVM_CR4_PIN_ALLOWED , mask); +wrmsrl (MSR_KVM_CR4_PINNED , cr4_pinned_bits & mask); +} +#endif +#ifdef CONFIG_ARCH_CPUIDLE_HALTPOLL static void kvm_disable_host_haltpoll (void *i)
Signature · 1 line
2.21.0