VT not enabled in Bios - how does enabling work?

[devzero]

Hi !

i`m just curious - if VT is a CPU feature - why isn`t it possible to turn it on from within an operating system - i.e. from within kernel space or via specal driver ?

ok, i know a bios initializes a system to be able to boot and set appropriate registers, but what restricts someone from writing a tool to do this from within an operating system - independent from the bios ?

has this just "yet to be done" or is it absolutely impossible ?

roland

[oreeh]

After enabling VT a complete CPU hard reset (reinitialize) has to occur (power off - power on cycle) a soft reset (reboot) is not sufficient.

This is the reason why you can't enable it from inside the OS or the application.

Message was edited by:

oreeh

I don't know the exact reason for this but I assume that this flag is permanently set inside the CPU (maybe using a static memory).

[mreferre]

There are about 15-20 parameters in the BIOS that you can't change from within an OS. One of them is the VT feature.

Now I have no clue whether this is phiscally impossible to achieve or the amount of work to implement this is proportionally HUGE compared to the advantages you would get in being able to do so.

Quite frankly I don't even see why this feature should be in the BIOS ...... it should be on by default (and even without a chance to disable it). Your hypervisor could then decide to use it or not to use it .......

Is your question based out of curiosity or is it a real requirement ?

Massimo.

[mreferre]

>After enabling VT a complete CPU hard reset (reinitialize) has to occur

>(power off - power on cycle) a soft reset (reboot) is not sufficient.

Are you sure ? Well I don't enable / disable VT twice a day but I don't remember that I had to go through a physical power-off / power-on cycle. I can't even think of a BIOS parameter that would require that.

Massimo.

[oreeh]

In many BIOS update release notes Intel states the following

"Added VT Enable/Disable Callback causing Global Reset when changing VT state."

So it seems that a "Global Reset" is required and most BIOS implementations don't do this after enabling VT.

[devzero]

>Is your question based out of curiosity or is it a real requirement ?

i`m just curious why there is so much fuzz about some processor feature being enabled or not - that you need to ask a vendor if VT works or not before buying a machine - and the vendor not being able to tell you.....

i have seen discussion threads with hundreds of posts and really wonder, why "VT on or off in bios" is such big issue.

actually, i`ve just stumbled across this one:

http://www.theta44.org/software/HVM_Rootkits_ddz_bh-usa-06.pdf

this gives me the slight clue, that some manufacturers decide to disable VT because of security - and maybe it`s security, why there is so much fuzz about the whole thing !?

roland

[oreeh]

A quote from jmattson (VMware developer)

The feature control MSR has a "lock" bit, and the MSR cannot be changed once

this bit is set. The bit persists through warm boots. That's why changwes to the

BIOS setting for enabling VT don't actually take effect if you simply reboot the

machine. To clear this bit, you must remove power from the CPU. Power down

your machine, count slowly to 5, and power it back on again. Then your changes

to the VT setting in the BIOS should actually take effect.

According to the Intel IA32 programmer manuals the lock bit has to be set before the VT bit comes to play.

Setting the VT bit without the lock bit generates an exception when executing the VMXON instruction.

[continuum]

>>> this gives me the slight clue, that some manufacturers decide to disable VT because of security - and maybe it`s security, why there is so much fuzz about the whole thing !?

If you enable VT in a new HP-notebook you indeed get a security warning a la:

Don't enable this feature unless you really use a program that needs this - security warning.

[devzero]

oliver/ulli - that`s interesting!

i really think security issue must be the reason why VT is disabled on so many systems - and maybe some bios manufacturers/vendors just being too short-sighted that having this available as an "switch on/off option" could be a user demand....

[mboz62]

I'm just guessing at this, but this would be my thought...

VT technology adds some important core features to a CPU, at the heart of that is the ability for the OS to manipulate the privilege ring structure, and give guest OS's the appearance of having access to high level privilege rings when in fact they really have access to the lower level ones.

equally, VT maintains a number of registers on behalf of virtualised OS's - because it is always better to have hardware keeping registers than software.

Now I would expect that it would be possible to add the additional VT code to a running system, it would then have access to the privilege ring hooks and additional registers, however what would happen when you removed those from a running system. suddenly dumping a load of data from a system that didn't expect it to be dumped would generally be a bad thing I would expect.

my final argument would be that adding processor virtualisation support is a reasonably important decision to be made, and needing to reboot makes you properly aware of that.

after all if you're installing VMWare on a box, it is probably about to become a VMware server, I doubt many are in the position to say - hey bob, we need to get VMWare running on that Exchange server, make sure you turn on VT and don't reboot it, we've got 20,000 users connected.

[mboz62]

and on by default is an issue too!

when VT first hit the streets I had a machine running a virtual machine (can't remember whether it was xen, ms or vm) that would consistently crash whenever VT was enabled. took me a couple of days to nail it down, but it was definitely VT that killed it.

now that was a reasonably joe-ropey application and I wrote it off as being such, but what if VT suddenly started killing off your firms core business accounting software and there was no need to turn it off, how much would you be complaining that they'd left such an obvious thing as a bios toggle out.

[ksc · Accepted solution]

If the BIOS doesn't touch the VT settings, it's possible to enable them from within the kernel. (Parallels' driver silently does this). VMware has chosen a policy of not silently enabling VT because of the security concerns - see below. For an option to enable VT via VMware config file when BIOS doesn't provide the option ... work is in progress.

On Intel chips, the setting disabled by default, is set once, and cannot be changed until a hard power-off. On AMD chips, the setting can be changed multiple times (or locked to disabled), and is enabled by default. Some BIOS vendors have chosen to not provide a setting for VT (usually citing security concerns, but many leave the setting unlocked ... kinda like deadbolting a door and leaving the window open); other BIOS / EFI vendors have buggy implementations that forget to re-enable VT after system sleep / hibernation. We've even seen buggy implementations that enable VT on one core but not on other cores.

"Blue pill" security concerns:

http://theinvisiblethings.blogspot.com/2006/06/introducing-blue-pill.html

Rebuttals:

http://x86vmm.blogspot.com/2006/08/blue-pill-is-quasi-illiterate.html \[VMware engineer]

http://www.virtualization.info/2006/08/debunking-blue-pill-myth.html \[Xen engineer]

My quick summary: blue pill is theoretical; an actual implementation is well beyond the state-of-the-art.

For technical details of how to enable VT on all processors (audience: anyone able to write a kernel driver) - on Intel, write the value 0x5 to MSR 0x3a (this is described in the IA32 manuals). Getting those 3 assembly instructions to run at the right time (yet not so often to reduce performance) is harder.