Enable SMEP CPU Feature

From: Fenghua Yu <[email protected]>

Add support for newly documented SMEP (Supervisor Mode Execution Protection) CPU feature flags.

Signed-off-by Fenghua Yu <[email protected]>

---
 arch/x86/include/asm/cpufeature.h |    1 +
 arch/x86/kernel/cpu/scattered.c   |    1 +
 2 files changed, 2 insertions(+), 0 deletions(-)

arch/x86/include/asm/cpufeature.h +1 -0

index 50c0d30..e773f13 100644
@@ -174,6 +174,7 @@
 #define X86_FEATURE_PLN		(7*32+ 5) /* Intel Power Limit Notification */
 #define X86_FEATURE_PTS		(7*32+ 6) /* Intel Package Thermal Status */
 #define X86_FEATURE_DTS		(7*32+ 7) /* Digital Thermal Sensor */
+#define X86_FEATURE_SMEP	(7*32+ 8) /* Supervisor Mode Execution Protection*/
 
 /* Virtualization flags: Linux defined, word 8 */
 #define X86_FEATURE_TPR_SHADOW  (8*32+ 0) /* Intel TPR Shadow */

arch/x86/kernel/cpu/scattered.c +0 -0

index c7f64e6..2de3aea 100644

From: Fenghua Yu <[email protected]>

Enable newly documented SMEP (Supervisor Mode Execution Protection) CPU feature in kernel.

SMEP prevents the CPU in kernel-mode to jump to an executable page that does not have the kernel/system flag set in the pte. This prevents the kernel from executing user-space code accidentally or maliciously, so it for example prevents kernel exploits from jumping to specially prepared user-mode shell code. The violation will cause page fault #PF and will have error code identical to XD violation.

-----Original Message-----
From: Matthew Garrett [mailto:[email protected]]
Sent: Monday, May 16, 2011 7:10 PM
To: Yu, Fenghua
Cc: Ingo Molnar; Thomas Gleixner; H Peter Anvin; Mallick, Asit K; Linus Torvalds; Avi Kivity; Arjan van de Ven; Andrew Morton; Andi Kleen; linux-kernel
Subject: Re: [PATCH v2 3/4] x86, head_32/64.S: Enable SMEP

Quoted 3 lines · Fenghua Yu

From: Fenghua Yu <[email protected]>

Enable newly documented SMEP (Supervisor Mode Execution Protection)

CPU

Quoted 3 lines

feature in kernel.

SMEP prevents the CPU in kernel-mode to jump to an executable page

that does

Quoted 1 line

not have the kernel/system flag set in the pte. This prevents the

kernel

Quoted 1 line

from executing user-space code accidentally or maliciously, so it for

example

Quoted 1 line

prevents kernel exploits from jumping to specially prepared user-mode

shell

Quoted 1 line

code. The violation will cause page fault #PF and will have error

code

Quoted 1 line

identical to XD violation.

Are EFI runtime service pages currently set up appropriately?

Quoted 2 lines

Are EFI runtime service pages currently set up appropriately?

They are not set up yet. efi init is called after this.

But at this time there is no user space code yet. So there is no SMEP violation chance until later when any user space page table is setup.

-----Original Message-----
From: H. Peter Anvin [mailto:[email protected]]
Sent: Tuesday, May 17, 2011 4:13 PM
To: Yu, Fenghua
Cc: Matthew Garrett; Ingo Molnar; Thomas Gleixner; Mallick, Asit K; Linus Torvalds; Avi Kivity; Arjan van de Ven; Andrew Morton; Andi Kleen; linux-kernel
Subject: Re: [PATCH v2 3/4] x86, head_32/64.S: Enable SMEP

Quoted 5 lines · Fenghua

Quoted 2 lines

Are EFI runtime service pages currently set up appropriately?

They are not set up yet. efi init is called after this.

Quoted 1 line

But at this time there is no user space code yet. So there is no SMEP

violation chance until later when any user space page table is setup.

Quoted 1 line

Are EFI runtime pages set up with U=0? I would argue it is a bug if they aren't, but we want to make sure that there isn't such a bug.

-hpa

Note: This patch set doesn't enable the SMEP feature in KVM. If it's needed, another patch will be pushed for enabling the feature in KVM.

Quoted 4 lines · Fenghua Yu

Note: This patch set doesn't enable the SMEP feature in KVM. If it's needed, another patch will be pushed for enabling the feature in KVM.

Hi Avi,

Could you comment on if this needs to be a gating factor?

Quoted 9 lines · H. Peter Anvin

Quoted 4 lines · Fenghua Yu

Note: This patch set doesn't enable the SMEP feature in KVM. If it's needed, another patch will be pushed for enabling the feature in KVM.

Hi Avi,

Could you comment on if this needs to be a gating factor?

I think KVM would benefit from the native kernel playing guinea pig whether SMEP is really, truly 100% trouble-free to enable by default (for Linux) ;-)

Some programmable configurability seems necessary on the KVM side, as KVM has no control over how sane the guest kernel is.

Quoted 2 lines

Some programmable configurability seems necessary on the KVM side, as KVM has no control over how sane the guest kernel is.

We should simply expose the cpuid bit and cr4.smep. If the guest kernel feels it is up to it, it can enable smep itself.

Quoted 5 lines · Avi Kivity

Quoted 2 lines

Some programmable configurability seems necessary on the KVM side, as KVM has no control over how sane the guest kernel is.

We should simply expose the cpuid bit and cr4.smep. If the guest kernel feels it is up to it, it can enable smep itself.

Well, given that there's lots of legacy installations around it would be a neat KVM feature if it was possible to enable SMEP even if the guest kernel does not enable it. As an additional (optional) layer of security.

For example legacy Linux guests will work just fine, even if they do not enable SMEP themselves.

Quoted 12 lines · Ingo Molnar

Quoted 5 lines · Avi Kivity

Quoted 2 lines

Some programmable configurability seems necessary on the KVM side, as KVM has no control over how sane the guest kernel is.

We should simply expose the cpuid bit and cr4.smep. If the guest kernel feels it is up to it, it can enable smep itself.

Well, given that there's lots of legacy installations around it would be a neat KVM feature if it was possible to enable SMEP even if the guest kernel does not enable it. As an additional (optional) layer of security.

Quoted 2 lines

For example legacy Linux guests will work just fine, even if they do not enable SMEP themselves.

It's certainly possible (set CR4.SMEP transparently and hide it from the guest). But there's no way to tell if it doesn't break something wierd. The host might not even know if the guest is Linux or something else.

We could support it as a non-default feature, but that reduces its utility.

Quoted 2 lines

We could support it as a non-default feature, but that reduces its utility.

It would be a nice touch for tools/kvm/: we would use KVM_GET_SREGS and KVM_GET_SREGS to twiddle CR4.SMEP, even without the guest explicitly doing it.

A quick glance suggests that it could be done straight away in tools/kvm/kvm-cpu.c::kvm_cpu__setup_sregs() during vcpu setup, and hopefully that cr4 value survives boot and ends up in the guest kernel's mmu_cr4_features mask shadow register.

Quoted 10 lines · Ingo Molnar

Quoted 2 lines

We could support it as a non-default feature, but that reduces its utility.

It would be a nice touch for tools/kvm/: we would use KVM_GET_SREGS and KVM_GET_SREGS to twiddle CR4.SMEP, even without the guest explicitly doing it.

A quick glance suggests that it could be done straight away in tools/kvm/kvm-cpu.c::kvm_cpu__setup_sregs() during vcpu setup, and hopefully that cr4 value survives boot and ends up in the guest kernel's mmu_cr4_features mask shadow register.

Depends if the guest uses a read-modify-write pattern or not. We could do it transparently in kvm.ko, since the real cr4 need not corresponds to the guest notion (for example, we often set cr0.wp or cr0.ts even though the guest wants them clear).

Quoted 5 lines

Depends if the guest uses a read-modify-write pattern or not. We could do it transparently in kvm.ko, since the real cr4 need not corresponds to the guest notion (for example, we often set cr0.wp or cr0.ts even though the guest wants them clear).

Oh, being transparent is a nice touch when it comes to security measures (catching attackers who think there's no SMEP and such) - but that would need KVM support and a new ioctl to configure it, right?

Quoted 6 lines · Ingo Molnar

Quoted 2 lines

Depends if the guest uses a read-modify-write pattern or not. We

could do it

Quoted 1 line

transparently in kvm.ko, since the real cr4 need not corresponds

to the guest

Quoted 1 line

notion (for example, we often set cr0.wp or cr0.ts even though the

Quoted 6 lines

guest

Quoted 1 line

wants them clear).

Oh, being transparent is a nice touch when it comes to security measures (catching attackers who think there's no SMEP and such) - but that would need KVM support and a new ioctl to configure it, right?

Yes.

Quoted 17 lines · Avi Kivity

Quoted 14 lines · Ingo Molnar

Quoted 9 lines

 Depends if the guest uses a read-modify-write pattern or not.  We could do it
 transparently in kvm.ko, since the real cr4 need not corresponds to the guest
 notion (for example, we often set cr0.wp or cr0.ts even though the guest
 wants them clear).

Oh, being transparent is a nice touch when it comes to security measures (catching attackers who think there's no SMEP and such) - but that would need
KVM support and a new ioctl to configure it, right?

Quoted 2 lines

Yes.

btw, KVM support is required anyway, you can't set random bits in cr4 (from either the guest or host userspace) - kvm needs to understand them.

Quoted 15 lines · Avi Kivity

Quoted 13 lines · Ingo Molnar

Quoted 2 lines

Depends if the guest uses a read-modify-write pattern or not.

We could do it

Quoted 1 line

transparently in kvm.ko, since the real cr4 need not

corresponds to the guest

Quoted 1 line

notion (for example, we often set cr0.wp or cr0.ts even

though the guest

Quoted 1 line

wants them clear).

Oh, being transparent is a nice touch when it comes to security measures (catching attackers who think there's no SMEP and such) - but that would need
KVM support and a new ioctl to configure it, right?

Quoted 2 lines

Yes.

btw, KVM support is required anyway, you can't set random bits in cr4 (from either the guest or host userspace) - kvm needs to understand them.

From: Avi Kivity
Sent: Tuesday, May 17, 2011 7:34 PM

Quoted 5 lines · Ingo Molnar

Quoted 2 lines

We could support it as a non-default feature, but that reduces its utility.

It would be a nice touch for tools/kvm/: we would use KVM_GET_SREGS and KVM_GET_SREGS to twiddle CR4.SMEP, even without the guest explicitly

doing it.

Quoted 5 lines

A quick glance suggests that it could be done straight away in tools/kvm/kvm-cpu.c::kvm_cpu__setup_sregs() during vcpu setup, and hopefully that cr4 value survives boot and ends up in the guest kernel's mmu_cr4_features mask shadow register.

Depends if the guest uses a read-modify-write pattern or not. We could do it transparently in kvm.ko, since the real cr4 need not corresponds to the guest notion (for example, we often set cr0.wp or cr0.ts even though the guest wants them clear).

From: Avi Kivity
Sent: Tuesday, May 17, 2011 7:34 PM

Quoted 6 lines · Ingo Molnar

Quoted 2 lines

We could support it as a non-default feature, but that reduces its utility.

It would be a nice touch for tools/kvm/: we would use KVM_GET_SREGS and KVM_GET_SREGS to twiddle CR4.SMEP, even without the guest explicitly

doing it.

Quoted 5 lines

A quick glance suggests that it could be done straight away in tools/kvm/kvm-cpu.c::kvm_cpu__setup_sregs() during vcpu setup, and hopefully that cr4 value survives boot and ends up in the guest kernel's mmu_cr4_features mask shadow register.

Depends if the guest uses a read-modify-write pattern or not. We could do it transparently in kvm.ko, since the real cr4 need not corresponds to the guest notion (for example, we often set cr0.wp or cr0.ts even though the guest wants them clear).

After this basic enabling work, we could work out a patch to address Ingo's idea, which will mandatorily turn on SMEP for guests.

From: Fenghua Yu <[email protected]>

Intel new CPU supports SMEP (Supervisor Mode Execution Protection). SMEP prevents kernel from executing code in application. Updated Intel SDM describes this CPU feature. The document will be published soon.

Note: This patch set doesn't enable the SMEP feature in KVM. If it's needed, another patch will be pushed for enabling the feature in KVM.

Quoted 6 lines · Fenghua Yu

From: Fenghua Yu<[email protected]>

Intel new CPU supports SMEP (Supervisor Mode Execution Protection). SMEP prevents kernel from executing code in application. Updated Intel SDM describes this CPU feature. The document will be published soon.

Quoted 2 lines

Note: This patch set doesn't enable the SMEP feature in KVM. If it's needed, another patch will be pushed for enabling the feature in KVM.

We can do it separately from native kernel support, but i'm sure Avi would agree that SMEP support in KVM would be nice!

(as long as it's configurable as
well, there might be guest OSs that break if SMEP is enabled, right?)