Thursday, March 24, 2011

Virtualization solution #3: Windows Virtual PC

Note that my Windows platform is Windows 7, which basically includes a free Windows XP virtual machine for Windows Virtual PC. But I was wanting to add physical hard drives. And... err... no. It won't do it.

My basic take: Windows Virtual PC works well if you're wanting some Windows "sandboxes" to play in. The drop-and-drag integration in particular is fairly impressive. But for what I want -- to create a virtual machine that's given ownership of a bunch of disks in order to software RAID-6 them and divvy slices of the resulting arrays out via iSCSI, CIFS, and AFP, i.e., to create a virtual storage appliance -- it simply lacks the basic functionality I need. Thus far my 64-bit Scientific Linux 6 is working quite well as a JBOD-manager with VMware Player... and there's not many virtualization solutions that can do that, and nothing other than VMware Player on the desktop.


Sound, Flash, and VMware Player

This is some notes on how to get sound and flash working on a Scientific Linux 64-bit guest ( rebranded Red Hat Enterprise Linux 6 ) running inside VMware Player on Windows 7 64-bit:

Flash: Note that Chrome for 64-bit Linux does *not* include the integrated Flash player that all other platforms have. You'll need to download 64-bit Flash beta from Adobe. At the time of this writing, that's at Adobe Labs. Once you extract the tgz file, you'll be left with a file "", simply copy it to /usr/lib64/mozilla/plugins , restart Chrome or Firefox, and you're set.

Sound: VMware's sound system crashes with the default Ubuntu / Red Hat sound configuration. This is apparently because VMware doesn't bother emulating all pieces of the hardware they say they're emulating, and when ALSA touches the missing bits, VMware disables the sound device. That's easy enough to fix though. From the Gnome menu, go to System->Preferences->Sound. In the Sound preferences, click on Hardware. Change the profile at the bottom from "Analog Stereo Duplex" to "Analog Stereo Output". Then on the little icon of the speaker on the bottom margin of the VMware Player, right-click it and select "Connect". After about a minute it'll turn green and you'll be able to play sound again.

Why this happens: Though the Ensoniq device emulated is capable of stereo duplex operation (i.e., both recording and outputting at the same time), I know because I actually had one of the physical cards back in the day and used it for that purpose along with a multitrack recorder program, VMware's emulation of the device is not capable of such and thus you must disable that capability. Unless you were intending to record audio within the Linux virtual machine (*not* recommended, VMware's timing is not sufficiently good to get good results there), this has no actual effect -- you can still play Flash videos from Chrome (and Firefox presumably) and hear the sound.

So if you're running Windows 7 on your physical hardware because you need the graphics performance for games and aren't willing to do the dual-card IOMMU hack with Xen that I demonstrated previously (or your hardware simply doesn't have IOMMU support, or you're not willing to use the latest bleeding-edge OpenSUSE as your platform), you can still have the far more secure web browsing environment of Linux available, and with VMware Player you can give Linux any additional drives beyond your boot drive for Linux to manage. Linux works far better as a server than Windows 7 does -- it can provide CIFS, AFP, iSCSI, and do it all on a much better software RAID stack than Microsoft's, as well as using LVM to manage that space, for which Windows 7 has no equivalent. And VMware's Unity system actually works pretty well with SL6/RHEL6 on Windows, although not as well as it works in VMware Fusion on MacOS (the issue being that the little Unity menu icon gets put into the screen menu bar on MacOS and has a native look and feel, while shows up as a clunky little usually-invisible icon above the Start menu on Windows). Which means that you can mix Linux Chrome windows, Windows IE windows (ick! But there's a couple of applications I need for customer support that requires IE plugins that don't exist for any other browser), Linux shell windows, and hoary old Outlook all on the same screen and manage them using the normal Aero Peek icons at the bottom or, if you have a Logitech mouse with the Logitech drivers installed, by assigning one of the side buttons to Window Switcher (their clone of Apple's Expose'). And unlike earlier versions of Windows, Windows 7 is stable -- in fact, I've never managed to make it crash. It's just very annoying... but that's why Apple is still in business, after all. Because Apple makes computers that are not annoying. For a price. A big price, alas...


Tuesday, March 8, 2011

Virtualization solution #2: VirtualBox

So the next piece of virtualization software that I was going to try out is VirtualBox. Remember, my Linux is installed on an entirely separate hard drive pair, that I mapped into VMware Player as two drives then installed Scientific Linux 6 onto one of the RAID arrays previously configured on that drive pair for that purpose (a 20GB RAID1 pair). 'grub' handles that situation just fine, it skips the RAID header and loads the Linux kernel and does its thing. At that point, I can see the remaining 1.8 terabytes of RAID'ed LVM volumes.

So I fire up VirtualBox and go to create a virtual machine via its GUI and... err... it doesn't allow me to assign physical drives to my VM. Which is one of those "WTF?!" moments, because the underlying QEMU that VirtualBox is based upon certainly has the *capability* to add physical drives into a virtual machine, but a bit of Googling around finds that you must do some cryptic command line hacking to make VirtualBox do it. The GUI won't do it.

At that point, realizing that VMware was point and click and ridiculously easy to set up and did what I wanted it to do without said hacking, I said "F*** that" and uninstalled VirtualBox. It may be that VirtualBox could perform better than VMware Player. But my time is more valuable than any tiny increment of performance that VirtualBox could potentially give me compared to VMware Player.

Next up: I check out Windows Virtual PC and see what I can do with it. For one thing, it'll be cool to try Windows XP Mode, even if it turns out not to be useful for virtualizing Linux...

-- ELG

Sunday, March 6, 2011

Bizarre Windows behavior

Some bizarre things I've seen with Windows 7 Ultimate thus far:
  1. No loopback device. I had an ISO of Office 2010 on my network share, I copied it over to Windows 7 and... err... now what? I ended up exporting it to the Linux virtual machine as a virtual CD, mounting it in the Linux VM, then re-exporting it via Samba to Windows as a share.
  2. Windows 7 won't browse my workgroup. No way, no how. I can go directly to the Run prompt and type in "\\linserver\office" and get my Office share, but it won't automagically populate its network neighborhood thingy in the left margin of Windows Explorer with my workgroup shares. It's not that Samba is misconfigured. My MacBook properly populates *its* left margin with the Samba server and expands to show the shares when I click on it, as well as showing the share I exported from Windows 7.f
  3. Windows 7 won't do a thing when I click "Map Network Drive". Nothing. Nada. I remember that in the Xen installation of Windows 7 it certainly worked fine, it popped up a dialogue and all that, but now that it's native nothing -- zero -- happens when I click on that item.
  4. Probably related to Homegroups. This is the only Windows 7 system on my network, so Homegroups is utterly useless. I attempt to change it and... nada. Nothing. Won't let me leave the homegroup.
Computers are supposed to be deterministic. Windows 7 isn't -- its behavior appears to be semi-random, operating upon a logic that Boole and Von Neumann would not have recognized. So have you had weird things happen with Windows 7? Curious penguins want to know!


Saturday, March 5, 2011

Windows virtualization software

Previously I mentioned three bare metal hypervisor solutions -- Xen, KVM, and VMware ESXi -- and what was required to push through a video card to a WIndows VM living on those hypervisors. I have since managed to get that working with VMware ESXi, and I suspect if I install the very latest Fedora 14 host it'll work with KVM too.

That works fine with a desktop machine or rack server where I can mount multiple video cards into the box. The performance of Windows 7 virtualized is indistinguishable from Windows 7 raw. Here are my scores for Windows 7 raw on that box, with a Seagate Momentus XT 7200 RPM boot drive (due to the front-loading slot on my case that allows easy swapping of OS drives):

  • Processor: 7.5
  • Memory: 7.6
  • Graphics: 7.3
  • Gaming graphics: 7.3
  • Primary hard disk: 5.9
Compare with the virtualized numbers.

The problem, however, is when you want to go mobile. You simply can't add a second video card to a laptop. So if I want to play games on one of those new Dell Sandy Bridge desktop-replacement laptops, I need to run WIndows native, and come up with a way to have Linux also running and handling my years of accumulated data, all of which is in a Unix filesystem tree and cannot simply be copied into Windows. I preferably want this Linux to be running on a raw partition -- not on a file within a Windows partition -- and it has to be able to access raw Linux-formated USB and SATA drives. So, let's look at the first candidate... VMware Player

VMware Player is VMware's entry level desktop virtualization program. At one point in time VMware player would only start up virtual machines that had been created by VMware Workstation, but now it's an almost full version of VMware Workstation with various functionality like snapshots stripped out and with a limitation of only four cores allowed. VMware Player is "free" -- it's free for personal use, if you want to deploy it in a corporate environment you can license it for a fairly trivial per-seat fee (quite trivial, it'll be lost in the noise of your IT budget).

The test machine is my Xen server with Windows 7 installed as described above. I installed VMware Server on it without any problem. I created my Scientific Linux 6.0 virtual machine with no problem, giving it 2 gigabytes of memory and a 16gb root filesystem. VMware Tools installed easily into SL6 and allowed me to treat the Linux "X" desktop as if it were just any other Windows window, I could click into it, my mouse pointer could be moved outside of the window while I was typing into Linux program, and so forth. Adding the two 2TB SATA physical hard drives to the virtual machine was as simple as point and click, though the VM had to be off to do so because VMware Player's hot-plug functionality apparently does not work with physical drives. Once I booted SL6 up, it saw the two 2TB drives and assembled the Linux software RAID arrays on it automagically, though I had to do vgchange -a -y to get SL6 to recognize the LVM volumes on the RAID arrays.

So how fast is access to those two SATA drives? On a subsequent reboot of my Linux VM, a RAID check got fired off. The two drives were being read at 105MB/sec apiece -- 210MB/sec total -- and it used less than 20% of one of my eight cores for VMware to virtualize this. My take on it is that VMware Player's fake SCSI device takes a fair chunk of CPU to virtualize, but modern multi-core CPU's are so bleepin' fast that you won't even notice (which I didn't, until I went to see).

The final thing I wanted to do was to export a NTFS-formatted volume to Windows via iSCSI. Windows 7 has Microsoft's iSCSI initiator built in. I gave both my Windows machine and my Linux VM fixed addresses (using the bridged mode for the Linux VM's virtual network card), and installed the iSCSI target daemon and utils with 'yum install scsi-target-utils'. Then I added the already existing logical volume /dev/datagroup/win7 volume to /etc/volumes/targets.conf (see that file for exact format of what you need to add) and started up the daemon with "service tgtd start". Then I went to the Windows Administrative Tools (you can get to them from the the Start Menu if you've configured them to appear there, or from the Control Panel), selected the iSCSI Initiator, told it to scan the IP address of my Linux VM, and voila, it popped up there and as a drive letter in the Windows Finder. Easy peasy! The only thing to remember is to poke a hole for iSCSI in both the Linux and Windows firewalls, or it doesn't work :). (Yes, been there, done that, heh!).

The final test was to attach a USB hard drive to the system and export it to my MacBook Pro via iSCSI and use it as a Time Machine device. When I attached the hard drive to the system, it popped up in Windows, but clicking Virtual Machine ->Removable Devices showed the new drive, and allowed me to add it to the virtual machine. I then added it to targets.conf and told the tgd daemon about it, then went to my iSCSI initiator on the MacBook (the globalSAN iSCSI initiator) and added it, then used Disk Utility to format it as a Mac volume. Then I went to Time Machine and told Time Machine to use it for backup, and... voila. It started backing up at about 20mb/sec -- or about 50% of theoretical USB2 speed, not too bad considering this is being done via WiFi, not a direct connection, and the iSCSI target is running in a virtual machine, not directly on the hardware. A copy in Windows of a 4GB file to a similar USB drive ran at 26mb/sec, and that should go faster than Time Machine writes because it's a big sequential write, not a lot of smaller files. So now I have the equivalent of one of those expensive Time Capsule thingies, except that a 2TB Western Digital drive in an external USB case costs a *lot* less! Why an external USB? Simple -- so if I ever have to restore my MacBook Pro after a disk crash (which has happened before), I can unplug it from my big server and plug it directly into the MBP for MacOS to restore the system back to pre-crash state.

So... it's clear that VMware Player will do everything I want it to do here. There's two more options to look at before calling this competition done, however: Oracle's VirtualBox, which recently released a brand new version (version 4.0.4), and Microsoft's own Windows Virtual PC, which doesn't officially support Linux but which has been made to do so. More on those later...


Friday, March 4, 2011

Surviving with Windows

Even the most fervent Linux penguin may be required to use Windows for some purpose or another. For example, I have been doing a lot of work with VMware VSphere lately. And VSphere Client runs on... err... *WINDOWS*. Then there's games. Linux gaming is a non-starter due to the fact that the "X" Window System simply doesn't have the performance to do games. Mac gaming is better now that Steam has arrived, but Windows is still "the" PC gaming platform for most games.

So if you have to use Windows, what makes it less stressful for someone who prefers more elegant operating systems than the 16 years of hacks and kludges that is Windows today? I'll make a brief list here...

  1. Microsoft Security Essentials. Don't even think of running Windows without an antivirus. This program is free, works as well as the others, and does *not* spam you or install spyware on your system like many of the other antivirus programs do.
  2. Google Chrome. Internet Explorer on Windows 7 is a lot more secure than in days of yore, but Google Chrome is the most secure web browser for Windows, period.
  3. Microsoft Office 2010, Standard version. It drives me batty with its incoherent user interface but Outlook still is the best here. However, if you do *not* need compatibility with Exchange Server and its calendar, install OpenOffice and Thunderbird instead -- their user interface is much better than Office 2010's.
  4. Apple Quicktime. For playing Quicktime videos. Duh.
  5. Foxit Reader for Windows. For reading PDF files, which is what everybody's documentation is sent out as nowadays. Do *NOT* install Adobe's own PDF reader, it is evil, it has a security breach every other day.
  6. On the other hand, there's no alternative to Adobe's own Flash Player. Though thankfully Chrome doesn't need it, but IE will, so go ahead and install it -- using IE, because the installer will complain that Chrome already has Flash (duh).
  7. GNU Emacs for Windows. Because sometimes you need to edit text files, and Emacs is the best way to do that.
  8. Xmarks. The best way to keep all your bookmarks in sync between Chrome, IE, and any other computers you have.
  9. Evernote, to write things like shopping lists and todo lists and keep your notes in sync with your smartphone, your tablet, and the cloud.
  10. Steam client. Of course :).
To be continued...

Note one of the things I did *not* mention: Cygwin. The reality is that it will constantly annoy you due to the fact that the Unix API doesn't map well onto the Windows API. You're using Windows, not Unix. You're much better off learning how to use the native Windows tools like Powershell. They will annoy you too, but not as much as trying to shove a square peg into a round hole.


Wednesday, March 2, 2011

Disk encryption and LUKS

One of the interesting features of recent Linux distributions such as Ubuntu is LUKS, which allows you to encrypt (most of) your data on the hard drive. So the question I was asked is: How secure is LUKS?

Let's look at the Ubuntu implementation. It uses AES-256 to encrypt the disk volume using an appropriate cipher feedback mode to deal with frequency attacks and other such attacks against statically encrypted data. First, is the cipher secure? The answer there is, yes. AES (Rijndael) has been subjected to extensive cryptanalysis both as part of the AES cipher competition and afterwards, and there are no known compromises against full AES. The reality is that even AES-128 would be sufficient for this purpose, because the weakness of the Ubuntu implementation lies elsewhere: the passphrase. A NSA employee once stated in public that they didn't care anymore about how well encryption algorithms worked, because there was an infinity of methods to obtain the passphrases of anybody they really wanted to spy on.

Remember, a cipher is *not* a cryoptosystem. A cryptosystem consists of both the cipher, and the software required to feed it keys and data. In this case, the biggest weakness is in the keystore (stored in the header of the volume) and the method of securing it. The keystore is secured by a passphrase. Brute force dictionary attacks against the passphrase to decrypt the keystore might work, but usually won't if you chose a sufficiently complex passphrase incorporating non-word "words". The most likely attack here is either a passphrase sniffer injected into the system or a phishing exploit where a prompt is put up for the passphrase, but it is not by the login process, it is by software previously injected into the system via other means (typically a network-based exploit that then uses a privilege elevation exploit to gain permission to insert itself into the system boot sequence at the correct place).

Or, black bag cryptanalysis could be used if done by a determined organization -- a hardware keystroke scanner placed in your system, a pin mike pointed at your keyboard that then can be used to determine what keys were pressed based upon sound (each key has a subtly different sound when pressed, and which keys were pressed can be determined via frequency analysis for your language and assigned to the appropriate sound given sufficient keystroke sounds recorded), a pin camera can be mounted somewhere aimed at your keyboard to record your key presses. If you cannot guarantee that your system and computing environment has been physically secured, no cryptosystem is going to be sufficient. Thus the various exploits against ATM machines, where the machines are physically compromised (via scanner equipment physically added to them) to gain access to ATM card codes and PIN numbers for later use by thieves.

The Ubuntu setup, in other words, is sufficient for dealing with the issue of casual theft of computer equipment by random thieves -- they will not have previously captured passphrases thus will be reduced to brute force dictionary attacks upon the keystore encryption, which should fail as long as you choose a sufficiently complex passphrase -- but is insufficient to deal with a determined attack by someone who is willing to go to the trouble of rootkit'ing or black-bagging you. In particular, it is useless for dealing with network-based exploits, which occur after the passphrase has already been entered and can extract your data via the network accordingly. So it is useful, but adjust your expectations -- it is not going to stop a determined attacker (as vs. a casual theft of your drives or computer).

So, could this setup be made more secure against even passphrase interception attacks? Yes and no. You would need to load the Linux kernel and all pre-boot software from secure read-only media and also have the keystore reside there, then physically secure this media in some location other than with your physical hardware. A dongle in your laptop bag, for example, is not sufficient. You would need to have this media physically secure in your presence at all times to avoid having it compromised by black bag attacks, and have some method of physically destroying it if impending rubber hose cryptography seems likely and the data in question is so sensitive that the repercussions of it being decrypted is dire. But even there, you're still susceptible to ordinary network-based attacks that trick you into installing malware onto your drive or which exploit holes in your network software and which then steal your data via the network.

The reality is that the only computer that is completely and utterly secure is one located in a vault with no network access. Unfortunately, said computer is also not very useful for our day-to-day computing needs. The LUKS setup sufficiently deals with the problem of casual theft of computer equipment but will not stop a determined attacker with the resources of a major criminal syndicate or government behind it. It is a reasonable compromise between security and usability. So adjust your expectations accordingly.