Concerns about Parallels over at the Apple forum

I'm curious to see what Parallels developers and fellow potential users might think of the concerns voiced by "PeterWor" over on the Apple forum:

http://discussions.apple.com/thread.jspa?threadID=434122&tstart=0

In short, he claims that Parallels installs the equivalent of a rootkit, and therefore compromises the security of the system. I honestly don't know enough about the kernel and the Parallels mods to know how much merit his concerns have.

These concerns are repeated over in MacSlash:

http://macslash.org/comments.pl?sid=6081&cid=108843

Look, I'm really not trying to stir up trouble here---I fully intend to plop down my $40 for this software once I get my MBP this week (and 30" display too! yahoo!). Nevertheless I am interested to know what Parallels folks might have to say about this.

 

Some of those people on the discussion boards gets really testy. I'm well aware that Parallels (and any other virtualization product) needs to write code at the kernel level to get virtualization to work as we as users want it to. Its fine with me, just as long as the code doesn't provide hooks for others to piggy back on.

In my humble opinion some people are just too uptight ever since the Sony rootkit problem.

 

Good point. It ought to be simple to apprecaite the difference between a rootkit installed without the knowledge or permission of the user (as Sony did), and legitimate a piece of software like this which happens to have kernel-level access.

Anyone else?

 

My position is that it's no more dangerous than a driver for any piece of hardware that has kernel access. I think that the person who posted it on the Apple forums is overreacting, and while he appears to have a good grasp of many technical details, he's dead wrong about the VT-x extension being used by Parallels. You can not get a good view of what's happening internally in Parallels in this short a time, particularly if you're examining it from compiled code and runtime tracing/debugging without the benefit of source.

Bottom line, I'm unconcerned.

 

.
The two links in the post above are from the same person.

Also, I believe that his main concern / point is that it might not be "real" virtualization software. I know nothing of kernel programming, and only take his word for what he says. But it doesn't really matter what he or any other person says. How operable is it for you? That is the only question that matters in the slightest. If it is going to cause kernel panics, then it may not be too operable for you. If it does not cause panics as in Linux and Windows versions, and I fully expect in the release version for OSX, and it provides a very effective means to an end, then it certainly will be operable for you.

I don't care if it's a hook, or an extension, or what way it stirs the glue. I only care that it is reliable and effective. I only care that it is operable for me.
.

 

My only real concern is getting confirmation that if I decide to uninstall at some point, for whatever reason, that I can remove all files created for/by Parallels Workstation and that OS X will then be in its original state - ie, no alterations to the kernel.

Can someone from Parallels confirm that? Thanks.

 

Scott,

This is where "PeterWor" seems to provide Parallels with the perfect reply to one of his concerns. He said it wasn't "real", but he also thought it might cause full system crashes if buggy. If, as he suggests, Parallels is a kernel extension, then removing the extension leaves the kernel in its previous state. Indeed, in his little removal script, all it does is stop Parallels and remove files. According to him, that should be all you need to clean it up completely.

So backing out of Parallels seems to be painless, and getting answers to the questions PeterWor poses seems painless as well. Just provide him with enough rope.
.

 

That wasn't his script either. That script was posted here first. It's the same one posted in one of the threads on this forum. He did say he's looking to see if there's anything else that remains.

I always like to know what apps are doing to my system so if I do uninstall something I know it's gone completely.

I'm not saying I plan to uninstall the product, as I don't, but I still like to know what software is doing and what it takes to remove it if I ever decided to.

Anyway... any clarification from Parallels would be appreciated. Thanks again and keep up the great work guys.

 

Parallels comments

Dear Friends,

Thank you very much for your questioins, comments and even concerns. We have a good effective discussion here on the forum corcerning different aspects of our Mac version and it's usage. I believe this discussion is beneficial for both sides. It allows us to feel and hear thoughts of the masses and make the product more suitable for you. On the other hand it allows you do know more about the it, its possibilities and implementations. Some usefull tricks and workarounds are described here by some of our most active participants. So, thank you very much for each single feedback you bring to us.

Below you can find statements from those messages followed by our answers. In general everything being said there can be concluded in two simple statements:

1. Parallels runs some of its code in primary OS kernel space.

It is true. All virtualization solutions install a number of kernel drivers to have direct access to actual hardware. It is not possible to do virtualization (even with VT support) without running some piece of code at kernel level. It is not that dangerous as PeterWor said - installing kernel drivers for running some code at kernel level is a common and often used technique. Many system applications do it antiviruses, firewalls, virtualization software and so on. Simple hardware drivers written by 3-rd party vendors also run at kernel level.

2. Parallels doesnt leverage Intel VT-x technology.

It is just not true. Parallels Workstation 2.0 was the first production virtualization solution fully and efficiently leverage Intel VT-x technology on VT enabled processors. Parallels has a collaboration agreement with Intel and implemented VT support according to Intel recommendations. In our press release for version 2.0 you can find the official quote from Intel about Parallels use of VT:

"We're pleased to see Parallels use Intel's new hardware Virtualization Technology," said Melissa Laird, general manager of Intels Developer Relations Division. "With this offering, Parallels provides an affordable solution for client virtualization."

Additionally in press release to 2.1 version one more confirmation can be found in Intel quote:

"Intel is delivering relevant innovations for virtualization solution providers including Intel Virtualization Technology for CPU (VTx) and Directed IO (VTd), Dual Core microprocessors and Intel(R) Core(R) Microarchitecture," said David Tuhy, General Manager of Intel's Desktop Products Division. "Parallels has taken full advantage of VTx in Parallels Workstation 2.1, and we look forward to continued collaboration with Parallels on enabling new platform capabilities such as VTd which will help improve the reliability, performance and flexibility of I/O devices on virtual machines."

For non-VT systems Parallels uses its own patent pending software virtualization technology.

Scott, especially for your assurance. We don't do any changes to the kernel, we just install additional kernel drivers. Once the product is removed from the system and all those binaries deleted you have the system in exactly the same state as it was before installing Parallels.


My Best Regards,
Nick

 

Sounds great. I figured as much after I looked at the kexts being loaded. Anyway, thanks for the response and keep up the great work on the product.

 

Thanks! I much appreciate the response.

 

I guess none of the protagonists in those threads remembers the days of having to recompile a UNIX kernel just to get support for a particular piece of software or driver (though the Linux crowd goes through those pains sometimes even now -

kernel loadable modules and extensions are an every day fact of life with real UNIX - thats what makes it secure and manageable - the fact that you can see the extensions and have the ability to unload them is a _good_thing_ !!

 

Oh, good grief, I'd nearly forgotten about that. I was "lucky" enough to get one of the very first few SCO Xenix systems in the UK back in the ....errrr.... mid 80's I guess ...

I remember spending many, many, many hours relinking the kernel at what seemed like almost every app install.

I write drivers for a living and everyone here seems to be on the same page. Kernel mode drivers are quiet normal and not much to be worried about.

 

Note: VMware has to install HAL-level hooks in Windows and custom kernel modules in Linux. As a matter of fact, part of the installation procedure in Linux is compiling the kernel module code against the source of the current kernel. If VMware wanted to open huge backdoors, it certainly could.

There has to be some level of trust when you're installing software.

 

Uninstall script?

Apologies for my lack of understanding, but I am having a lot of problems with Beta 4 and need to do a complete uninstall.

I see this script listed (thanks), but honestly do not know how to run a script - can anyone give me a quick hint or two (either in the forum or through direct email)?

Thanks in advance for any help.

 

I think this is an important discussion

An obvious question of every user (informed about technical VT specifica or not) who installs whatever software is:

What is the potential of a certain software to compromise the entire system's security?

It is pointless to discuss about installing kernel extensions or not - every virtualisation solution which does not completely emulate all hardware including the CPU, but makes use of the native CPU needs access to kernel space and therefore needs to install kernel extensions to do so. If you want to avoid this, you have to go back to full emulation and 20% or less of the speed possible with Parallels.

In consequence, this means that you have to trust Parallels that their kernel extension code is stable and does not do bad things to your system by accident. However you have to put the same level of trust into any maker of hardware drivers as well. All of them have the same potential of doing bad things to your system - by accident or even maliciously (the Sony rootkit demonstrated this quite well to a large audience).

Given the open communication, excellent support and generally quick response to issues Parallels shows, I do not have any doubts believing that they do everything not to risk stability of their customer's systems.

So I'm not concerned about Parallels as a software installing a kernel extension at all.

But unlike most hardware drivers, which (more or less) work in kernel space to shuffle around pure data (say, audio streams, network traffic), Parallels is an EXECUTION ENVIRONMENT.

This means, it's purpose is to natively RUN code on the CPU that does not originate from the makers of Parallels. This code is the Guest OS' or from the programs and drivers installed on the Guest OS.

So the interesting question narrows down to the following (and possibly cannot be answered by anyone except those VT experts that actually have designed the critical code):

If at all - what parts of the guest OS and its programs are being executed in kernel space of Mac OS X?

Virtualisation solutions like Parallels are generally perceived as "sandboxes". When bringing an often attacked OS like WinXP into a sandbox on a (currently) mostly safe OS like Mac OS X, my one and only concern is how safe the sandbox actually is.

I do not care too much if a virus crashes the system within the sand box. I just swap in a clean copy of my HD image.

However, I care very much to know if software installed in the sandbox could easily break out in my Mac OS X's kernel space (and I mean - by design of the virtualisation technology, not trough a accidental security hole in Parallels code that can be closed, once detected!)

The original concern of "PeterWor" was that code is passed from Mac OS X user space into Mac OS X kernel space at all.

Mine is only: where can such code possibly originate from (else than, obviously and of no concern for me, from Parallels itself)?

I wish Parallels could make a clear statement on this.

 

You guys worry too much .

 

Being the Peterwor in question I'd like to remind eveyone about the DATE of the post that I did write over in the Apple forums, I believe that it was early beta 1 timeframe and the "discovery" I was talking about was found through some source code from the Linux PW code, as I stated.
I have since purchased the product and use it regularly, so I'm completely satisfied that the code is non malicious. After all we are talking about installing new interupt descriptor tables and some of its own memory management. That has to make you a little nervous at first.

However I still do have a question for Parallels, If you are leveraging TRUE VT-x capability how if that actually done without rebooting the OSX host after an install. If its through a kernal extension as most of the host hooks are, they need to built at startup, or so I thought. I am curious as to how you 'shim" PW in between the OSX layers without rebooting. I believe I said as much in my post.

As I said in my orginal post, this was/is new technology for a lot of us and unfamiliar, the only code I'd seen was from a Linux tar file that was in an early beta and I was curious about the ioctl extensions and the kernal extension, thats all. I was NOT attacking parallels, for what I now know as a pretty solid product. My apologies for ruffling any feathers on anyone, wasn't my intention. And talk about being "testy", the replies responding to the original post are a little testy, Id say.

So I really don't need any rope, thanks anyways, BTW, Constant, as for the issue with my statement about if code is buggy and can cause kernal panics etc, well DUH! and yes I know uninstalling the kexts will leave the OS in its previous state, that wasn't my point. The issue was it could cause crashes when its running. I never said it wasn't uninstalable.

I've been writing OS software for almost 30 years and I'm a curious kind of guy that's all. I have a lot of respect for my fellow OSXers and don't think that being enlightened is that bad a thing, especially when you make your living with computers as a lot of us do.
So, lets all go back to enjoying the product and not worrying about old information. I love what Parallels has done and I ahve tremendous respect for the product, I use it daily.

Cheers all,
Peterwor

 

kexts can be loaded an unloaded at runtime, theoretically. Any kext should be able to load at runtime, however, it's up to the individual kext as to whether it can be cleanly removed at all. There is a kextcache, which is used at startup. This basically is an archive/filesystem in and of its self, which the bootloader loads into memory and hands to the kernel at launch. When you take modularization of drivers to the limit, you clearly have a bootstrapping problem of loading the drivers necessary to load the drivers.
You can check out the kextload, kextunload, and kextstat commands for manipulation of kexts post-boottime. The kextcache man page also has some information about the cache system.

 

Peterwor---thanks for joining the thread, and thanks for the update. I'm glad to see that when all is said and done are ultimately satisfied with how Parallels is working. I think that some of the other folks on that Apple thread went a bit past simple curiosity to rootkit-paranoia. But I do think there's a place for healthy speculation and discussion about just how Parallels is accomplishing things!