# VirtualMachine security without PAX

## garythompson

Hi all,

I posted recently about an unstable kernel I managed to build.  This all resulted after I discovered (after building a hardened system) that I can not run VirtualBox on the system (http://www.virtualbox.org/ticket/941).  I'm using an atom so no VT-x.

My plan now is to recompile as a non hardened (I'm using nomultilib as well) system but at the very least still implement GRSEC.

BTW: the symptom is that my PC will hang when virtualbox launches (no logs, nothing, even keyboard LEDS feeze).  

My Intention:

- The HOST is a nomultilib amd64 build which acts as the VirtualBox Host as well as a network storage (CIFS / NFS)

- I'll be running several guests on a hardened Gentoo providing various services (directory services, mail, web, VPN)

Questions:

- If I had hardened including PAX, PIE/SSP and GRSEC on all guests and these were the only machines capable of communicating outside of my network, what is the risk of the host being broken into?  Has anyone been keeping an eye out on VM's been broken out of?

- I want to run guest machines as non-privileged and use GRSEC to significantly reduce resource access, will this still provide reasonable security without PAX?

- Since VT-X etc. allows execution of code on host CPU, does this circumvent kernel anyway? In which case, does PAX actually provide protection against VT-X run code?

Appreciate people's time.

----------

## Sadako

Just one note: AFAIK that bug only affects amd64/x86_64 systems, a 32-bit install on 64-bit hardware should be unaffected...

----------

## garythompson

Thanks for that, what about thoughts then:

- A secure system but using 32-bit on a 64 bit CPU (which is already a crippled CPU compared to the desktop offerings)

- A less secure system but with a 64-bit host 

I'm assuming that there is a performance difference between running 32-bit on a 64 bit Atom (I'm using AES on encrypted drives and my main performance concern is using the 32 bit aes driver instead of the 64 bit). 

I would need to do some testing to confirm all of this, of course.

Any thoughts out there on the above dilemma?

I went atom because it was low power and cheap.  In retrospect I should have gone i5, but the significant jump in price wasn't acceptable.  Despite my intel focus, I do prefer AMD but a lot of research just didn't bring up a suitable product based on my criteria.

----------

## Sadako

There probably isn't nearly as much of a performance difference between  32- and 64- bit as you might think, especially on an atom, most atoms (at least the early ones) aren't even capable of running 64-bit code, and you usually see a much more noticeable difference between 32- and 64-bit on amd hardware than you do on intel.

That, together with the fact that your atom system probably can't even be fitted with 4GB of ram or more, and there's very little reason to go with a 64 bit install (also, wrt hardened, the recent 64-bit uderef support can have quite a high overhead, especially when the host is running non-accelerated virtual machines, so there's another reason to choose 32-bit in your case...).

As to AES encryption, if your willing to put the time in to test things out it wouldn't be difficult to determine the total throughput and cpu overhead, all you need to do is set up a kernel ramdisk (as large as you can manage, without swap), set up cryptsetup on it with a random key, and time how long it takes to simply cat the device in /dev/mapper to /dev/null, and if you re-setup the crypt mapping for each test ps will give you the total cpu time used by the kcryptd kernel thread.

(You should time a cat of the raw ramdisk for comparision too).

Doing this under both a 32- and 64-bit kernel should tell you what you need (you could use the same 32-bit userland for both if you like, shouldn't have any influence), odds are you'll see very little difference, and as this is an idealised test whatever differences there may be will be vastly diminished when using a hard disk, especially a relatively slow laptop drive.

Unless you're using an SSD, but then the lack of TRIM support via dmcrypt will be a bigger issue...

Anyways, with 128-bit AES there is generally very little overhead (even on something like an atom), so I wouldn't be so concerned about it.

HTH.

----------

