ChromeOS script to re-write the current kernel configuration to enable VT-x extensions and lsm.module locking for virtualbox/virtualization. Based on steps provided by @zwxfzzzjr on the crouton github site here - https://github.com/dnschneid/crouton/issues/675#issuecomment-40567742

enable-vmx.sh

#!/bin/sh -e 
C_ROOT=''
C_KERNEL=''
##
## Exits the script with exit code $1, spitting out message $@ to stderr
error() {
    local ecode="$1"
    shift
    echo "$*" 1>&2
    exit "$ecode"
}

##
## Ensure this script is run from a Cros shell (as chronos or superuser)
if [ "x$USER" != 'xchronos' -a "x$SUDO_USER" != 'xchronos' ]; then
  error 1 "This script has to be run from a Cros shell (as chronos or superuser) - exiting!"
fi

#Following routine borrowed from @drinkcat ;)
ROOTDEVICE="`rootdev -d -s`"
if [ -z "$ROOTDEVICE" ]; then
    error 1 "Cannot find root device."
fi
if [ ! -b "$ROOTDEVICE" ]; then
    error 1 "$ROOTDEVICE is not a block device."
fi
# If $ROOTDEVICE ends with a number (e.g. mmcblk0), partitions are named
# ${ROOTDEVICE}pX (e.g. mmcblk0p1). If not (e.g. sda), they are named
# ${ROOTDEVICE}X (e.g. sda1).
ROOTDEVICEPREFIX="$ROOTDEVICE"
if [ "${ROOTDEVICE%[0-9]}" != "$ROOTDEVICE" ]; then
    ROOTDEVICEPREFIX="${ROOTDEVICE}p"
fi

##
## 0.Disable verified boot : (You could do this later, but you have to do this before step 5. IT WON'T BOOT OTHERWISE!)
echo "## 0.Disable verified boot"
echo -n "Changing system to allow booting unsigned images: "
sudo crossystem dev_boot_signed_only=0 || ( echo; error 2 "*** Couldn't disable 'verified boot'" )
echo 'crossystem dev_boot_signed_only=0'
sleep 3 && echo

##
## 1.Get current root & assign current kernel
echo "## 1.Get current root & assign current kernel"
echo -n "Determining current kernel = "
C_ROOT=`rootdev -s`
if [ $C_ROOT = ${ROOTDEVICEPREFIX}3 ]; then C_KERNEL=2; else C_KERNEL=4; fi
echo "$C_KERNEL"
sleep 3 && echo

##
## 2.Copy the existing kernel configuration into a file
echo "## 2.Copy the existing kernel configuration into a file"
echo "Copying current kernel into file = kernel$C_KERNEL"
sudo /usr/share/vboot/bin/make_dev_ssd.sh --save_config /tmp/x --partitions $C_KERNEL || ( echo; error 2 "*** Couldn't create kernel config file" )
sleep 3 && echo

##
## 3.Edit the config file and add 'disablevmx=off' + 'lsm.module_locking=0' to the config line
echo "## 3.Edit the config file and add 'disablevmx=off' + 'lsm.module_locking=0' to the config line"
if grep --color 'disablevmx=off lsm.module_locking=0' /tmp/x.$C_KERNEL ; then
  echo; error 255 "*** Kernel configuraiton already modified - exiting"
fi 
echo -n "Editing /tmp/x.$C_KERNEL to append = "
sudo sed -i -e 's/$/ disablevmx=off lsm.module_locking=0/' /tmp/x.$C_KERNEL || ( echo; error 2 "*** Couldn't edit kernel config file" )
echo "disablevmx=off lsm.module_locking=0"
sleep 3 && echo

##
## 4.Save the current kernel configuration and reload the new one
echo "## 4.Save the current kernel configuration and reload the new one"
echo -n "[ press ENTER to continue - Ctrl-C to abort ] "; read DOIT
echo "Reloading the kernel configuration from /tmp/x.$C_KERNEL"
sudo /usr/share/vboot/bin/make_dev_ssd.sh --set_config /tmp/x --partitions $C_KERNEL || ( echo; error 2 "*** Couldn't reload kernel configuration" )
sleep 3 && echo

##
## 5.reboot, and enjoy VT-x extensions
echo "## 5.reboot, and enjoy VT-x extensions"
echo "All done - rebooting..."
echo -n "[ press ENTER to continue - Ctrl-C to abort ] "; read DOIT
sudo reboot
exit 

Dennis

If a another script were created to reverse what enable-vmx.sh changed (maybe called unenable-vmx.sh) would a Chromebook boot into Verified boot again?. Seems if the saved kernel bits were restored (bit-for-bit) so that the hash/digital sign matched Googles, it might boot verified mode (unless something else permanently flags the kernel modifications)? From what I have read, "Verified Boot" while in Developer mode gives a little more security. Assuming any of the above would work, we could execute the enable-vmx only when we need to run a 64Bit VirtualBox VM then execute unenable-vmx.sh to reestablish verified boot.

BTW, Thanks for making your enable-vmx.sh script available!!
Regards, Ron

Script changed to accommodate root devices ending in a number like 'mmcblk0', etc. - thanx @drinkcat

How do I run this script?!

I had it working once, but after a clean reinstall of chrome os, crouton, etc. it fails again.
My kernel is adjusted. Running the enable-vmx.sh script says its ok already. disablevmx=off.
But when I start my virtual box I get the message that VT-x is not supported by the BIOS.
Do I need to redo something in the installation of Vbox itself?
Thanks in advance, Patrick

I'm seeing the same issue. Prior to the latest ChromeOS update that happened yesterday I could start 64bit VM using VT-X in Virtuallbox in Crouton. However now, after the ChromeOS update, I'm getting the error message "VT-x is disabled in the BIOS (VERR_VMX_MSR_VMXON_DISABLED)". However I just repacked using the manual steps and verified and it still doesn't work. Something broke with the ChromeOS update?

@DennisLfromGA Maybe you should update your script. changing the boot command line can be done much easier. See https://github.com/dnschneid/crouton/wiki/Repack-kernel-to-Enable-VT_x-for-Virtualbox I updated the wiki with the better method.

Re-written to use simplified routine suggested by @divx118 - thanx ;)
... and tweaked USER logic to actually work - again ;) ...

After the latest beta update for ChromeOS, I'm also getting the "VT-x is disabled in the BIOS (VERR_VMX_MSR_VMXON_DISABLED)" in VirtualBox in trusty. I know it was working before the update. Anyone else had the same issue and have a resolution?

Same problem here, since yesterday's update I get the VT-x error -- which I've never seen before.

CrOS just updated, and suddenly I'm getting the VT-x error also, leaving my 64-bit guest in the mud. The previous CrOS updates up to this one seemed fine after I ran the scripts, but not this time. Any ideas? Thanks.

Update: Shutting down and restarting fixed it where reboots did no good at all.

Does doing this give access to /dev/kvm in crouton?

UPDATE: the answer is no... it does not :-/