If you are not using Samsung 5 550 (lumpy) or a Samsung 3 Chromebox (stumpy), back away slowly now.  These instructions WILL NOT WORK for any other device.

This document is intended for people who don't mind getting their hands dirty, voiding warranties, or possibly bricking their devices.  If any of those thing scare you, just walk away.

Background

The BIOS that shipped on earlier devices (such as stumpy and lumpy) had minor misfeatures in them where they would disable VMX support in the read-only firmware stage.  That means there is no way to use those virtualization extensions once you booted.  Putting into dev mode won't help, nor will installing an alternative OS.

This document attempts to guide you through the process of binary patching your BIOS.  This way VMX support won't be disabled while it is loaded.  Instead, the kernel itself will take care of enabling/disabling it.  This way you can leverage that hardware functionality to use KVM or other such technologies.  The Virtual Machine explains more.

If you're still here, and you have a lumpy or stumpy device, and you want to hack your BIOS (coreboot) to keep VMX (hardware virtualization insns) support from being disabled at boot, then let's get into it.

Prepare The Device

Make sure your device is in dev mode already and you can get a root shell.  See the Samsung Series 5 550 Chromebook and Series 3 Chromebox page for details on how to do this.

You should also see what version of firmware you're running.  All the example output below is taken from a Chromebox.  This will be invaluable if you ask for assistance.

Note that while most of these commands can be run on the device, some will require tools that are available in the Chromium OS SDK (like cbfstool and a compiler/assembler).  So you should extract the bios on the device, and then do all the other commands on your development system.  You can transfer the file via scp.

Extracting The BIOS

Now that you're in dev mode, extract the BIOS from the read-only SPI flash using flashrom.

The BIOS can be read with fmap_decode.

Here we see all the wonderful sub-sections of the BIOS.  The one we really care about is the last part -- the BOOT_STUB.

Extracting Coreboot

Using the details from the last line from the fmap_decode output, we can use dd to extract coreboot.

You can verify this actually worked by running the cbfstool (part of coreboot, and in the Chromium OS sdk chroot).

Extracting Coreboot RAM Stage

We want the coreboot_ram stage there.  Let's extract it using cbfstool.

Decompressing Coreboot RAM Stage

You might have noticed we called the output file here coreboot_ram.lz instead of just coreboot_ram.  That's because the stage is compressed by LZMA.  That means we need to decompress it first.

We skip 0x1c bytes there because that's the CBFS stage header information.  This should be constant across all images.

Now, finally, we have the raw x86 code that gets executed during initial boot.

Hacking Coreboot

You can do a sanity check to make sure we've got the right file by using objdump and disassembling the code.

Your output might not look *exactly* like that (some of the number constants might be different).  The first few instruction names should be the same though (a cli, then a lgdtl, then a ljmp, then a bunch of mov's).  If your output doesn't resemble this, then you should abort and seek help.

Locate wrmsr

Buried in that output somewhere is the magic insn sequence that turns off VMX on us.  This is done by writing to the 0x3a machine specific register using the wrmsr instruction.  Let's scan the output for it.

The key sequence to look for is a mov insn that stores 0x3a in the eax register, followed by a call insn to a small func that does a rdmsr+wrmsr, followed by some more movs/calls and then a cpuid insn.

Above you can see the "bad" call to the wrmsr function happens at offset 0x26d55.

Nopping The wrmsr

We now have the right offset, so let's patch that particular insn to be a nop instead! :)

This will write five 0x90 bytes (the hex for the nop insn) to the offset of the call insn.  Let's see our handy work by consulting objdump.

You can see that we have successfully executed our gambit!

Repacking The BIOS Image

We've broken everything down and made our small change.  Let's rebundle everything so we can deploy the fix on our device.

Repacking Coreboot

We have to get creative now.  It's easier if we just let the cbfstool repack the code since it includes compressed data and checksums in the headers and other fun stuff rather than trying to do it manually using dd.

Rebuilding Coreboot RAM Stage

First rebuild the input ELF using the modified binary code.

Updating Coreboot

Now delete the existing stage from coreboot, and then add the new one.

If you look at the cbfstool print output, you might notice that the order of the components has changed (the ram stage now comes later and there is an empty hole where the ram stage used to be).  That's not a problem -- coreboot is smart enough to dynamically scan the CBFS structure for the ram stage.

Updating The BIOS Image

This part is easiest to do with dd again.

Flashing The New BIOS

This is the only part where things can go wrong and possibly brick your device.  Make sure your device is fully plugged in before attempting this process (like the lumpy -- don't run it on battery).

The details of each step below can be found in the Samsung Series 5 550 Chromebook and Series 3 Chromebox page.  Consult that as you go.

Hardware Preparation

1. Open the case
1. You'll now have to disassemble your device (which most likely voids your warranty).  
2. Disable write protect
1. You'll have to locate the Write Protect jumper and enable it.
2. This will make the BIOS read-write so you can update it.
3. Once things have been updated, you can undo this so your BIOS is read-only again.
3. Reassemble the device
1. Now that you've done toggled the jumper, you need to reassemble the device and power it up.
4. Check the write protect
1. Run crossystem and look at the wpsw_cur field; it should be 0.
5. Plug your system in to be safe!
1. For the Chromebook laptop, make sure the battery is charged, and the power supply is connected.
2. For the Chromebox, try and plug it into a battery backup (UPS), and don't try this during a storm :).

Write The BIOS

With the new bios.bin.new file in hand, let's use flashrom to update things.  Obviously you'll need to scp this file back to the device and run flashrom there.

Then read it back out to verify things worked

If the md5 hashes match, then you're ready to cross your fingers and reboot!

If you saw any weird errors, then do not power off the device.  Try and reprogram the original BIOS instead.

Check VMX Support

Now follow the normal Virtual Machine document.  You should be able to use kvm and other fun things on your device now.

Note that if the initial reboot worked, you actually have to power off the device (not just reboot) in order for the relevant software registers to fully reset themselves.

Enable Write Protect

Now that you've made sure everything works, you should re-enable the write protection on your BIOS.  Follow the Hardware Preparation steps above to remove the physical jumper.

You'll also have to run some software steps once you reboot.  This tells the flash to re-enable write protection on itself.  We only want to do this for the 2nd half of the flash though and not the entire thing.

First get the current status.  It should look something like:

Now get the flash size:

Take that value and divide it by two and use that to re-enable write protection:

Finally double check the result: