OSDev.org

Hi,

Intel has gone and released details for new "virtualization" instructions, which are intended to make it faster to have a computer running a VMM with several OSs running under the VMM. See:

http://www.intel.com/technology/computing/vptech/

As far as I can tell, if an operating system is running on a computer that supports VMX but VMX isn't in use, then a virus that manages to get into CPL=0 could become the VM Monitor. This virus would have complete access to all hardware and software, could make itself the first thing booted and could allow the real OS to run as a guest in such a way that it'd be impossible for the real OS (or the users) to detect the virus.

Considering that most OS's run device drivers at CPL=0, delivering the virus wouldn't be too difficult. All you'd need is something that looked like a video driver update - you could submit it to one or more device driver sites and thousands of Windows users would try it out (thinking it was originally from NVidia or something).

The only thing an OS can do (that I can think of) is try to become the VMM itself so that a virus would be blocked, or prevent any software from getting to CPL=0 (including device drivers). People using existing OS's like Windows XP would be screwed.

Any thoughts?


Cheers,

Brendan

I think it will not change anything for virus writers, since they mostly target weak computers... They don't need such a feature to get control of your computer, they are so many vulnerabilities.
Traditionnal anti-virus software should be enough, if up to date.

I think this will be a great feature, It could even be used to jail some critical applications And from that point of view, it will improve (server) security.

Hi,

ineo wrote:I think it will not change anything for virus writers, since they mostly target weak computers... They don't need such a feature to get control of your computer, they are so many vulnerabilities.

While they may not need VMX to get control of the computer, if they did use VMX it would be impossible for any anti-virus software to detect or remove it afterwards - even a complete fdisk might not get rid of it unless it was done from clean removeable media started by the BIOS directly.

The essential difference is that the OS would be running under the virus, rather than the virus running under the OS.

Of course there's also the possibility of someone using a VMM on a boot CD to snoop confidential data from a pre-existing secure OS (ie. disgruntled employee with an undetectable keylogger).

ineo wrote:I think this will be a great feature, It could even be used to jail some critical applications And from that point of view, it will improve (server) security.

I have conflicting opinions about it...


Cheers,

Brendan

I understand the point.

What I mean is that you could have said that from a lot of improvements. Even the way some OS works are unsafe, since drivers usually runs at CPL 0. A virus using this way of propagation should be able to cloak itself from the OS, with or without that feature.

You could have said the same about flashable BIOS ROM chips, since it's the very first thing loaded.

New potential security threat means new way to overcome the problem. It should not be a brake for improvements.

Hi,

Any virus running under any OS must use something that can be found by anti-virus software - some memory, some CPU time, some disk space, some API hooks. If it doesn't use any of these then it can't exist under the OS. A VMX virus (on top of the OS) can tell the OS anything it likes to hide everything.

Flash BIOSs are encrypted and trigger an SMI that the original BIOS can use to do security checks, etc before unlocking NVRAM (or unencrypting the new BIOS image). If a flash BIOS virus got past this somehow it'd only work on a specific chipset/motherboard and would have trouble spreading.


Cheers,

Brendan

Brendan wrote:[...]Flash BIOSs are encrypted and trigger an SMI that the original BIOS can use to do security checks, etc before unlocking NVRAM (or unencrypting the new BIOS image).[...]

You see there is always a new security system one could imagine to overcome this problem.

I understand what you mean, but it's not really a problem.
There's no problem, just solutions

Excuse me... but have I missed something: if a virus gets to CPL0, it's game over for the virus scanner anyway. The virus can replace any OS feature is wants to (with some sophistication ofcourse), and prevent virus scanners for detecting itself.

What this new feature does is basicly what protected mode (and vm86) does to real-mode. It allows a virus to hide itself from operating systems/programs not aware of the feature, with far less work than what would have been required otherwise. It's not like you couldn't put VMWare-alike into your virus today if you wanted. So at most it becomes a bit easier.

Now, once this flag is in shipping processors, I would assume any half-decent virus scanner will be aware of it, in order to prevent this kind of stuff.

Ok, maybe they'll add to their virus scanners only after the first such virus is found, but at that point any mainstream operating systems will support it anyway...

Hi,

mystran wrote:Excuse me... but have I missed something: if a virus gets to CPL0, it's game over for the virus scanner anyway. The virus can replace any OS feature is wants to (with some sophistication ofcourse), and prevent virus scanners for detecting itself.

Any code running under any OS must be in memory somewhere, and must get CPU time somehow (e.g. hooking an API or running as a thread). This can't be done without providing some method of detection (regardless of CPL). If the OS can't prevent a normal virus from disabling anti-virus software, then the OS is doomed in any case.

One security vulnerability that worries me is a disgruntled employee deliberately using a VMX keylogger (or something) from a boot CD. In this case the most secure OS that can ever be imagined would still be vulnerable.

mystran wrote:What this new feature does is basicly what protected mode (and vm86) does to real-mode. It allows a virus to hide itself from operating systems/programs not aware of the feature, with far less work than what would have been required otherwise. It's not like you couldn't put VMWare-alike into your virus today if you wanted. So at most it becomes a bit easier.

True - a virus could use VM86 to get control over a real mode OS, and if a virus infected VMWare it'd be able to gain control over the guest OS. There are no secure real mode operating systems so worrying about them is pointless. A virus that infects VMWare can still be defeated by an anti-virus scanner as long as the anti-virus scanner runs on the host OS, not the guest OS.

mystran wrote:Ok, maybe they'll add to their virus scanners only after the first such virus is found, but at that point any mainstream operating systems will support it anyway...

From what I can tell the OS is meant to ignore VMX completely. Intel's plan is for the computer to boot a VMM, and for the VMM to boot any OSs. If the VMM itself can't be trusted by the OS there's no way for the OS to do anything about it, or even detect that a VMM is present.

To be effective the anti-virus scanner must run in the host environment (not in the virtual environment where the OS is). The only possible method I can think of is for the virus scanner to be contained in the BIOS and rely on SMM in order to get CPU time. That would be complicated, especially for updates.

A better method would be for the BIOS to have a setting that enables/disables VMX, so that it can be disabled when it's not intentionally used (in conjunction with a secure BIOS settings password that can't be cleared with DOS debug in less than 5 minutes).

Unfortunately Intel aren't saying anything about VMX security. Instead they released "Le Grande", which is a "trusted computing" thing involving encrypted keyboard, mouse and video, a "Trusted Platform Module" chipset extension, a "TPM" device (which is a secure key thing added to the LPC bus), and a collection of other things. I'm not too familiar with Le Grande yet, but it seems like overkill to me.

I guess I'm starting to feel like Wintel are going for over-kill in all directions lately (ACPI was bad enough). For example, consider the EFI boot specification. It'd make good sense for an EFI boot manager and VMX to be combined into a single product (as VMM boots and then starts the OS/s). In this case you'd have a VMM with it's own (EFI) device drivers that's capable of running it's own (EFI) applications or running operating systems (using VMX). It'd be a "meta-OS". In this case a normal OS would be like an application (and Intel would probably end up adding special CPU support for people who'd like to run multiple VMX based VMMs on the same computer).

I'd rather see the architecture getting simpler - a 64 bit only 80x86 computer with no 32 bit/16 bit, no gate A20, no VMX, no FPU/MMX/SSE, no segmentation, no hardware task switching, no PIT, no PIC, no legacy devices, no ACPI, no APM, no SMM, and BIOS functions that can be used. It'd be cheaper and faster (and less complexity means less code, less bugs and less chance of security holes).

Maybe I'm just getting too old .


Cheers,

Brendan

Trusted Computing is basically an MS sponsored concept where they build your Windows Certificate Store into a chip on the motherboard (intended to be moved into the CPU eventually) that requires all code be signed by "trusted" parties right from the bootsector and BIOS itself. The concepts also go like encrypted fully seperated memory spaces (All data is transparently encrypted by the chipset so it is impossible for even the OS to snoop program memory), it also comes with other things that help against copyright infringement (Cracks break the code signatures so cannot be used), a general rumour is that Microsoft will use it as an opportunity to launch a subscription based Windows OS (TC enforces DRM like rules on everything from documents to programs, don't pay your subscription and the program won't run, even better, don't pay your MS Office subscription and all your documents won't open [even if they have been sent to other people, when the system updates the cert store it'll be locked out]).

I frankly don't like where this is going, it essentially allows the developers to tell you how to use your computer, you are merely leasing it not owning it. There are also problems like who is going to code-sign Linux so that it'll run on a TC enabled system which defeats Open Source, what's not signed doesn't run. The further problems come with a suggested fix for this remote control is "Owner Override" which is being rejected as it allows you to not uphold the Digital Rights Management if you don't want to which defeats the purpose of creating it to begin with. As far as I can see, any computer with TC is crippled.

On a somewhat lighter note, I too would appreciate a complete dumping of all the x86 legacy features (perhaps replacing 32/16bit pmode with Virtual486 so that the software can still run in an emulated mode).

Also about viruses, virus scanners contain a kernel resident driver now to prevent CPL0 viruses, that measure would be ineffective against a malicious virtualizer.

Something I'm concerned about is what they've done about the hardware, I haven't read it properly but it doesn't seem to mention hardware states, the mode monitor can apparently switch OS' like tasks but that would indicate severe hardware desyncing problems (DMA read the HDD, get switched other OS resets the DMA chips then when you get switched back with incomplete data in memory and no signaling complete transfer either). 16bit DMA could also be a problem.

Do you not think that wintels idea is for virus to be made , then they will bring out protection that only let you run M$ OS's.

AR wrote: Trusted Computing is basically an MS sponsored concept where they build your Windows Certificate Store into a chip on the motherboard (intended to be moved into the CPU eventually) that requires all code be signed by "trusted" parties right from the bootsector and BIOS itself. The concepts also go like encrypted fully seperated memory spaces (All data is transparently encrypted by the chipset so it is impossible for even the OS to snoop program memory), it also comes with other things that help against copyright infringement (Cracks break the code signatures so cannot be used), a general rumour is that Microsoft will use it as an opportunity to launch a subscription based Windows OS (TC enforces DRM like rules on everything from documents to programs, don't pay your subscription and the program won't run, even better, don't pay your MS Office subscription and all your documents won't open [even if they have been sent to other people, when the system updates the cert store it'll be locked out]).

I frankly don't like where this is going, it essentially allows the developers to tell you how to use your computer, you are merely leasing it not owning it. There are also problems like who is going to code-sign Linux so that it'll run on a TC enabled system which defeats Open Source, what's not signed doesn't run. The further problems come with a suggested fix for this remote control is "Owner Override" which is being rejected as it allows you to not uphold the Digital Rights Management if you don't want to which defeats the purpose of creating it to begin with. As far as I can see, any computer with TC is crippled.

On a somewhat lighter note, I too would appreciate a complete dumping of all the x86 legacy features (perhaps replacing 32/16bit pmode with Virtual486 so that the software can still run in an emulated mode).

Also about viruses, virus scanners contain a kernel resident driver now to prevent CPL0 viruses, that measure would be ineffective against a malicious virtualizer.

Something I'm concerned about is what they've done about the hardware, I haven't read it properly but it doesn't seem to mention hardware states, the mode monitor can apparently switch OS' like tasks but that would indicate severe hardware desyncing problems (DMA read the HDD, get switched other OS resets the DMA chips then when you get switched back with incomplete data in memory and no signaling complete transfer either). 16bit DMA could also be a problem.

What's ironic about this "Trusted Computing" junk is that we don't trust them. They don't think of that, do they?

BTW If Rent 'O' Windows comes, then Linux here I come.

srg

I'm personally thinking about how hard it would be to get a generic RISC chip, making a basic board for it, with 100BaseTX (or even 10BaseT) ethernet, at least one USB port (can use hubs anyway), a D/A adapter (for CD-quality sound playback) and a video output. Then writing a nice small OS for the thing.

USB would let you plugin keyb/mouse. And if it had PCI, one could plug a video card and IDE controller into that.

Hi,

mystran wrote: I'm personally thinking about how hard it would be to get a generic RISC chip, making a basic board for it, with 100BaseTX (or even 10BaseT) ethernet, at least one USB port (can use hubs anyway), a D/A adapter (for CD-quality sound playback) and a video output. Then writing a nice small OS for the thing.

USB would let you plugin keyb/mouse. And if it had PCI, one could plug a video card and IDE controller into that.

I've been wondering how hard it'd be to have a computer that's just a main bus with many slots (e.g. 8 along the back of the motherboard and another 8 along the front), where you'd be able to plug a device or a "CPU card" into any slot.

Everything except the bus and power supply would be on plug in cards, so for a 16 slot motherboard you could have 1 video card, 1 IDE card, 1 keyboard/mouse/joystick IO card, 1 sound card and 12 CPUs, or you could have 4 video, 2 IDE, 4 IO, 4 sound and 2 CPUs.

Each "CPU card" would have it's own little BIOS that initializes the card at power on or reset and boots the CPU/s by looking for OS code on the other slots.

Each motherboard slot would be given a specific memory range, where the highest 16 bits of an address indicates the slot number (for e.g. 0x1234FFFFFFFFFFFF would be slot #0x1234), while the remaining 48 bits are an address on the slot. There'd be no IO ports (everything uses memory mapped IO). IRQs would also be "per slot" and there'd be no resource conflicts. It would also allow completely different CPU cards to be used (e.g. 80x86, Itanium and Alpha in the same computer). This would include hard drives, etc, so that reading from address 0x000A000000000200 could read from the first sector of a hard drive in slot #0x0A.

Slot #0xFFFF would always be the motherboard itself, and it'd contain information on each of the other slots (what's in each slot, how many slots there are, power management control for each slot, etc).

Computer cases would come in various sizes, ranging from a "4 slot mini" up to a huge "65536 slot" super computer.


Cheers,

Brendan

That's a really nice idea, though I can imagine some issues with cards wanting the bus at the same time on a 65536 slot machine.