Breaking BIOS: enabling VT-x virtualization support on Acer Aspire One netbook
In this article, we will tell you step by step about how to file your netbook or laptop, in which bit 2 in MSR 0x3A is turned off and locked in this state for some misunderstanding - simply put, you have virtualization support in the processor, but it blocked by biosomes.
WARNING: Everything described in this article is designed to let you know what you are doing. All at your own peril and risk! If you are not sure - do not try to repeat this at home.
The problem that we will solve for the end user of the computer looks like this: When using a second type of hypervisor (for example, VirtualBox)
You can see this message when you try to start a
virtual machine with a number of processors greater than 1: You also get a similar error message if you intend to start a 64-bit virtual machine (for example, Debian amd64) from a 32-bit OS host, for example WinXP.
This question can be answered by checking some bits in some processor status words. The easiest way to make sure that in your case the problem is treated is to look at what SecurAble shows . In my case, it looked like this:
So, if your program shows the same picture as shown above, then you can cure this problem. However, the nuance is that it is possible to set the desired bit in the processor register only in the BIOS, since the harmful BIOS of your laptop sets it to zero, then it turns on the blocking bit and changing this bit is no longer possible (until the computer reboots, where the BIOS during POST again it will be thrown and locked).
BIOS on the Acer Aspire netbook manufactured by Insyde, its settings are very scarce and on F2 we naturally cannot go into the BIOS settings editing program and enable virtualization there. That would be too easy.
Therefore, we will disassemble the BIOS and change its code so that our bit is set to 1. If you are ready, then read on.
So, some technical information - to understand what we are doing and why.
Modern processors, at least many of them, have virtualization support. Bit No. 5 in the ECX word is responsible for it when the CPUID command is called with parameter EAX = 01H. This verification method is the only true one, since, as practice shows, the Intel website is lying, for example, for my Intel Atom N570 processor . This link says:
However, we know that this is not true. For those who are on the “you” with assembly language programming, it’s easy to find out by writing something like
I was too lazy to do this, so I downloaded the open source CPUID Explorer program , launched it and looked at the result. By the way, CPU-Z is unsuitable here - it gives the result too "user friendly" - we also needed to find out the exact value of the bit. Here's how it looked in my case:
The VMX bit of interest to us is circled. It is set to 1, it is, despite what the Intel website tells us.
The processor command documentation on page 215 tells us about the CPUID command, which
But that is not all. For hypervisors of the second type to be able to use virtualization support commands (VMX), it is necessary to explicitly enable these instructions in MSR (special processor register) number 0x3A. Here is what the documentation for this register tells us on page 237:
register 3Ah: IA32_FEATURE_CONTROL
Bit 0: lock bit - if it is set, then further modifications to this register are not allowed until the next reboot.
Bit 1: VMX in SMX - safer mode extensions. Virtualization functions in SMX are allowed only when the processor supports SMX - this is indicated in the neighboring 6th bit on ECX when the CPUID.01H command is called - in the picture above this bit is zero, our Atm N570 processor does not support SMX - therefore and in MSR 0x3A, bit No. 1 must be zero.
Bit 2: VMX is not in SMX - this, in fact, is the bit responsible for supporting virtualization. It corresponds to a circled bit in the CPUID and it should be set to 1.
To make sure that we understood everything about our computer correctly, you need to look at what is actually stored in MSR 0x3A. For this, I used the msr-tools package in Debian (real, not virtual. In virtual, the result is incorrect). This is how you can check the value of this bit:
- we are in Debian, then:
Nine!!! Nine is 00001001. As you can see, our BIOS uses the undocumented bit number 3 in a special register word 0x3A - according to the documentation, this bit is Reserved. But that is not the point. The bottom line is that we have lock bit turned on and our VMX bit No. 2 is turned off - so that's right, the SecurAble program is not lying and we really have virtualization support disabled at the BIOS level, although it is supported by the processor.
We will rule it.
The fact is that with virtualization support (VMX) disabled in the processor word 0x3A, your virtual machines in VirtualBox work in paravirtualization mode. They, unable to transfer the hypervisor to VMX Root and the virtual machine to VMX Non-root operation, are forced to translate processor instructions ON SUMMER. The problem is represented by 17 processor instructions that are not “VM-safe”, i.e. they use the only registers or data blocks (tables) in the processor for the entire computer. These commands are: SGDT, SIDT, SLDT, SMSW, PUSHF / POPF, LAR, LSL, VERR / VERW, CALL, JMP, INT n, INTO, RET, STR, and even the trivial MOV! All these instructions change on the fly, so that the virtual machine executes them in a safe form for the system. More details about this problem are described here.(eng.). Because of this, the performance of the virtual machine suffers.
For this task, we need the following things:
To begin with, it is very important to know that if something goes wrong, then how to restore the computer. For my InsydeH20 BIOS notebook there is an undocumented BIOS recovery procedure:
And voila, the motherboard itself (as a riddle) will pump out a new BIOS from the USB HDD and flash it in 1 minute, then the laptop will reboot.
I checked this method, filling the standard BIOS in this way from the manufacturer’s website (of a different version than I had before) - it really works, the BIOS version was updated.
In the same way, I decided to eventually upload the downloaded bios to the system.
So, we begin:
Unpack the BIOS from the SFX archive downloaded from the manufacturer’s website. Ios itself will have a file name something like
Next, we need to unpack the BIOS, since it is compressed. To do this, use the PhoenixTool.exe program. In the first field in its window, we indicate this compressed bios, and the program itself decompiles it into, in my case, as many as 609 source files that have names in the format GUID.ext. Some of these files are configuration files, and some are binary files, but all with the ROM extension. Some binaries contain programs with a standard Windows PE header.
Our task is to find the file containing the instruction we need among these 609 files
it turned out that looking for the MOV EAX, 3AH command in front of the WRMSR command is pointless - in my BIOS, WRMSR is framed as a separate function and takes parameters through the stack. Therefore, I did it this way (it seemed easier to me, cham in the IDA): I installed the nasm package on Linux, which includes ndisasm. Then disassembled all * .ROM files with the command
And then, by a simple search, I found a command
Such code was found in only one file with the name 62D171CB-78CD-4480-8678-C6A2A797A8DE.MOD, and it looked like this (after some of my work on renaming functions to more understandable ones, and adding a couple of comments):
By definition, a code that locks a register does this once. Therefore, this is the best place to make our hack: change the number 1 to the number 5 in the instructions:
This will lead to the fact that at the same time setting the lock bit, we set the VMX bit (bit # 2). Note here that we do not have the right to set bit # 1, since the set of SMX instructions is not supported in our processor (this says CPUID.1H: ECX bit 6.
We will not change it entirely in the * .ROM file, but in the * .MOD braid , which contains this file, for this you need to use the PhoenixTool.exe program, which is already open and the BIOS has already been loaded into it, click on the Structure button, and find the branch with our file name:
We press the Extract button, we get the * .MOD file (which consists of the header + body of the * .ROM file), and we correct our bit in this MOD file. We look in the IDA what binary code corresponds to the neighborhood of the instruction that we are changing, and in the HEX editor we open the file, look for this place in the code, and change only 1 byte from 01 to 05. We save the modified * .MOD file. Then in PhoenixTool, click Replace, select the modified MOD, and click Exit. All. The program itself rebuilt the bios and packed it for us, while calling it the same name as it was (the old file was saved with the .old extension).
All. Now fill in the only file with the new BIOS on the USB HDD (you can also on the USB flash drive), and perform the BIOS emergency recovery procedure described above. She will flash the computer with this new BIOS and everything will be ready.
Here is what the output of the SecurAble program now looks like:
VirtualBox now runs virtual machines with 4 cores (and not with one, as it was before). Now, from under my main 32-bit operating system, I can run 64-bit OSes in virtual machines.
And, most importantly, now virtual machines are actually virtualized (the hypervisor uses VMX instructions), rather than paravirtualized ones.
PS In the bios of other manufacturers (not Insyde), it is possible to correct not the BIOS itself, but only its settings, extracted by the SYMCMOS.EXE program. The process there is the same, except that in the disassembled BIOS there is a setting number that is used to prohibit or enable VMX, and then this setting is edited directly in the CMOS of the BIOS. In my BIOS, there are no such settings, or the symcmos program does not find them, so this file-cutting path is not suitable in my case. The direct BIOS hack path looks more reliable: in this way we simply ignore any BIOS settings, just set the VMX bit and lock the 0x3A register after that.
Happiness is :) Thank you for reading to the end.
WARNING: Everything described in this article is designed to let you know what you are doing. All at your own peril and risk! If you are not sure - do not try to repeat this at home.
So what is the problem?
The problem that we will solve for the end user of the computer looks like this: When using a second type of hypervisor (for example, VirtualBox)
- you cannot run virtual machines with more than one processor
- you cannot run 64-bit guest operating systems inside a 32-bit host OS.
You can see this message when you try to start a
virtual machine with a number of processors greater than 1: You also get a similar error message if you intend to start a 64-bit virtual machine (for example, Debian amd64) from a 32-bit OS host, for example WinXP.
Can this be cured?
This question can be answered by checking some bits in some processor status words. The easiest way to make sure that in your case the problem is treated is to look at what SecurAble shows . In my case, it looked like this:
So, if your program shows the same picture as shown above, then you can cure this problem. However, the nuance is that it is possible to set the desired bit in the processor register only in the BIOS, since the harmful BIOS of your laptop sets it to zero, then it turns on the blocking bit and changing this bit is no longer possible (until the computer reboots, where the BIOS during POST again it will be thrown and locked).
BIOS on the Acer Aspire netbook manufactured by Insyde, its settings are very scarce and on F2 we naturally cannot go into the BIOS settings editing program and enable virtualization there. That would be too easy.
Therefore, we will disassemble the BIOS and change its code so that our bit is set to 1. If you are ready, then read on.
What you need to know before you get started
So, some technical information - to understand what we are doing and why.
Modern processors, at least many of them, have virtualization support. Bit No. 5 in the ECX word is responsible for it when the CPUID command is called with parameter EAX = 01H. This verification method is the only true one, since, as practice shows, the Intel website is lying, for example, for my Intel Atom N570 processor . This link says:
Intel® Virtualization Technology (VT-x) No
However, we know that this is not true. For those who are on the “you” with assembly language programming, it’s easy to find out by writing something like
MOV EAX, 1
CPUID
I was too lazy to do this, so I downloaded the open source CPUID Explorer program , launched it and looked at the result. By the way, CPU-Z is unsuitable here - it gives the result too "user friendly" - we also needed to find out the exact value of the bit. Here's how it looked in my case:
The VMX bit of interest to us is circled. It is set to 1, it is, despite what the Intel website tells us.
The processor command documentation on page 215 tells us about the CPUID command, which
Bit #5 VMX Virtual Machine Extensions. A value of 1 indicates that the processor supports this technology
But that is not all. For hypervisors of the second type to be able to use virtualization support commands (VMX), it is necessary to explicitly enable these instructions in MSR (special processor register) number 0x3A. Here is what the documentation for this register tells us on page 237:
register 3Ah: IA32_FEATURE_CONTROL
Bit 0: lock bit - if it is set, then further modifications to this register are not allowed until the next reboot.
Bit 1: VMX in SMX - safer mode extensions. Virtualization functions in SMX are allowed only when the processor supports SMX - this is indicated in the neighboring 6th bit on ECX when the CPUID.01H command is called - in the picture above this bit is zero, our Atm N570 processor does not support SMX - therefore and in MSR 0x3A, bit No. 1 must be zero.
Bit 2: VMX is not in SMX - this, in fact, is the bit responsible for supporting virtualization. It corresponds to a circled bit in the CPUID and it should be set to 1.
How to check the contents of MSR 0x3A
To make sure that we understood everything about our computer correctly, you need to look at what is actually stored in MSR 0x3A. For this, I used the msr-tools package in Debian (real, not virtual. In virtual, the result is incorrect). This is how you can check the value of this bit:
- we are in Debian, then:
# apt-get install msr-tools
# modprobe msr
# rdmsr 0x3A
9
Nine!!! Nine is 00001001. As you can see, our BIOS uses the undocumented bit number 3 in a special register word 0x3A - according to the documentation, this bit is Reserved. But that is not the point. The bottom line is that we have lock bit turned on and our VMX bit No. 2 is turned off - so that's right, the SecurAble program is not lying and we really have virtualization support disabled at the BIOS level, although it is supported by the processor.
We will rule it.
Why this problem needs to be addressed
The fact is that with virtualization support (VMX) disabled in the processor word 0x3A, your virtual machines in VirtualBox work in paravirtualization mode. They, unable to transfer the hypervisor to VMX Root and the virtual machine to VMX Non-root operation, are forced to translate processor instructions ON SUMMER. The problem is represented by 17 processor instructions that are not “VM-safe”, i.e. they use the only registers or data blocks (tables) in the processor for the entire computer. These commands are: SGDT, SIDT, SLDT, SMSW, PUSHF / POPF, LAR, LSL, VERR / VERW, CALL, JMP, INT n, INTO, RET, STR, and even the trivial MOV! All these instructions change on the fly, so that the virtual machine executes them in a safe form for the system. More details about this problem are described here.(eng.). Because of this, the performance of the virtual machine suffers.
What do we need
For this task, we need the following things:
- original BIOS for our netbook from the manufacturer’s website.
- IDA
- phoenixtool210.zip (google knows where to download)
- HHD Hex Editor Neo or any other HEX Editor
- FAR Manager :)
- nasm - for disassembling
- Knowledge of how to fill BIOS with emergency method
To begin with, it is very important to know that if something goes wrong, then how to restore the computer. For my InsydeH20 BIOS notebook there is an undocumented BIOS recovery procedure:
- format USB HDD in FAT16 with a partition of 100 megabytes (FAT32 does not understand)
- upload one file with compressed bios there (ZE6.fd in my case)
- turn off the laptop, then remove all USB devices and the battery
- unplug the power cord
- connect USB HDD
- press and hold Esc + Fn
- plug in the power and after 5 seconds press the power button
- release the keyboard buttons
And voila, the motherboard itself (as a riddle) will pump out a new BIOS from the USB HDD and flash it in 1 minute, then the laptop will reboot.
I checked this method, filling the standard BIOS in this way from the manufacturer’s website (of a different version than I had before) - it really works, the BIOS version was updated.
In the same way, I decided to eventually upload the downloaded bios to the system.
So, we begin:
Unpack the BIOS from the SFX archive downloaded from the manufacturer’s website. Ios itself will have a file name something like
ZE6.fdand have a size of 2 megabytes exactly.Next, we need to unpack the BIOS, since it is compressed. To do this, use the PhoenixTool.exe program. In the first field in its window, we indicate this compressed bios, and the program itself decompiles it into, in my case, as many as 609 source files that have names in the format GUID.ext. Some of these files are configuration files, and some are binary files, but all with the ROM extension. Some binaries contain programs with a standard Windows PE header.
Our task is to find the file containing the instruction we need among these 609 files
WRMSR
it turned out that looking for the MOV EAX, 3AH command in front of the WRMSR command is pointless - in my BIOS, WRMSR is framed as a separate function and takes parameters through the stack. Therefore, I did it this way (it seemed easier to me, cham in the IDA): I installed the nasm package on Linux, which includes ndisasm. Then disassembled all * .ROM files with the command
ndisasm -b 32 file.rom > file.asm
And then, by a simple search, I found a command
wrmsrin them - there were 29 such files. Then each of them had to be loaded into the IDA and looked for the necessary code there that locks the 3AH register. Such code was found in only one file with the name 62D171CB-78CD-4480-8678-C6A2A797A8DE.MOD, and it looked like this (after some of my work on renaming functions to more understandable ones, and adding a couple of comments):
LOCK_VMX proc near
push esi
push 3Ah
call ReadMSR
pop ecx
mov ecx, eax
xor esi, esi
and ecx, 1
or ecx, esi
pop esi
jnz short exitprc ; if(ReadMSR() & 1) goto exitprc;
push edx
or eax, 1 ; Set lock bit (bit #0)
push eax
push 3Ah
call WriteMSR
add esp, 0Ch
exitprc:
retn
LOCK_VMX endp
By definition, a code that locks a register does this once. Therefore, this is the best place to make our hack: change the number 1 to the number 5 in the instructions:
or eax, 1
This will lead to the fact that at the same time setting the lock bit, we set the VMX bit (bit # 2). Note here that we do not have the right to set bit # 1, since the set of SMX instructions is not supported in our processor (this says CPUID.1H: ECX bit 6.
We will not change it entirely in the * .ROM file, but in the * .MOD braid , which contains this file, for this you need to use the PhoenixTool.exe program, which is already open and the BIOS has already been loaded into it, click on the Structure button, and find the branch with our file name:
We press the Extract button, we get the * .MOD file (which consists of the header + body of the * .ROM file), and we correct our bit in this MOD file. We look in the IDA what binary code corresponds to the neighborhood of the instruction that we are changing, and in the HEX editor we open the file, look for this place in the code, and change only 1 byte from 01 to 05. We save the modified * .MOD file. Then in PhoenixTool, click Replace, select the modified MOD, and click Exit. All. The program itself rebuilt the bios and packed it for us, while calling it the same name as it was (the old file was saved with the .old extension).
All. Now fill in the only file with the new BIOS on the USB HDD (you can also on the USB flash drive), and perform the BIOS emergency recovery procedure described above. She will flash the computer with this new BIOS and everything will be ready.
Here is what the output of the SecurAble program now looks like:
VirtualBox now runs virtual machines with 4 cores (and not with one, as it was before). Now, from under my main 32-bit operating system, I can run 64-bit OSes in virtual machines.
And, most importantly, now virtual machines are actually virtualized (the hypervisor uses VMX instructions), rather than paravirtualized ones.
PS In the bios of other manufacturers (not Insyde), it is possible to correct not the BIOS itself, but only its settings, extracted by the SYMCMOS.EXE program. The process there is the same, except that in the disassembled BIOS there is a setting number that is used to prohibit or enable VMX, and then this setting is edited directly in the CMOS of the BIOS. In my BIOS, there are no such settings, or the symcmos program does not find them, so this file-cutting path is not suitable in my case. The direct BIOS hack path looks more reliable: in this way we simply ignore any BIOS settings, just set the VMX bit and lock the 0x3A register after that.
Happiness is :) Thank you for reading to the end.