This is related to the previous post regarding the SMEP feature. Personally, I do use a number of solutions for all my kernel debugging work including VirtulBox, VMware, UML (User Mode Linux), and QEMU. There are obviously pros and cons to each of those solutions and I typically would pick one depending on the task at hand. For example, I find the VMware GDB stub to be quite stable and easy to set up.

However, I wanted to highlight the differences in VMWare VM hardware versions. Hardware versions prior to 8 do not support SMEP even if the host CPU provides this feature. For example, I'm running VMware Fusion 5.0.3 (on i7 Ivy Bridge with SMEP support) that by default creates vms with hardware version 9:

bash-3.2$ head Ubuntu\ 64-bit.vmx
.encoding = "UTF-8"
config.version = "8"
virtualHW.version = "9"
vcpu.hotadd = "TRUE"
scsi0.present = "TRUE"
scsi0.virtualDev = "lsilogic"
memsize = "1024"
mem.hotadd = "TRUE"
scsi0:0.present = "TRUE"
scsi0:0.fileName = "Virtual Disk.vmdk"
...

If we'll boot this virtual machine, we'll see that smep is in the list of flags in /proc/cpuinfo. Let's change the virtualHW.version to 8, save the vmx file and boot the virtual machine again:

vnik@ubuntu:~$ grep flags /proc/cpuinfo 
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc up arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc aperfmperf pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 popcnt aes xsave avx hypervisor lahf_lm ida arat epb xsaveopt pln pts dts

I guess this is important for two reasons:

1. If you're trying to get your exploit to work, you would avoid SMEP (VMware hardware versions 9 and later).
2. If your infrastructure only supports virtual machines with hardware version prior to 9 and you would like this extra protection offered by SMEP, you would probably want to upgrade.