Musings from kb8ojh.net

Wed, 05 Feb 2014

Creating a chroot jail with sound and X11

by on :

As time goes on, I have become increasingly mistrustful of closed-source software. I have always been mistrustful of crypto that the authors won't talk about. Therefore I decided that, while I do require[1] it for employment reasons from time to time, I am not interested in installing Microsoft's Skype client on my new Sputnik 3 laptop — at least, not directly.

My first inclination was to put the whole ball of wax in a virtual machine; after all, when I provisioned the disk I left a substantial amount of room just for development VMs — why not one for untrusted software, too? Unfortunately, some digging for information and hacking at the issue indicated that it wasn't going to be that easy, at least not with a KVM partition. To make a long story short, emulated sound hardware isn't really a working thing in Ubuntu 12.04 (the distribution presently on my laptop for various reasons, some of which are detailed here). That left me with two possibilities: 1) chase a network audio solution, or 2) find a different way to sandbox Skype. I've done my share of playing with network audio solutions over the years, and let's just say that I wasn't looking forward to doing it again; therefore, new sandbox it was.

A chroot jail seemed like the next best choice, after a dedicated VM fell down. The isolation between a chrooted application and the host operating system is not nearly as good, particularly after riddling the chroot with holes for sound and graphics, but I felt like I could mitigate the worst of the exposed surface area. So I set about doing so, and in the process built a set of scripts and a chroot configuration for a (relatively) efficient audio-enabled sandbox for untrusted or semi-trusted applications. At the moment, mine runs Skype. This document describes how I set it up. There is nothing here that isn't documented somewhere else, but I couldn't find it all scraped up in a pile, so here it is.

Setting up a minimal chroot

Building chroots in Debian-based distributions is refreshingly easy. Several tools are provided for both managing a chroot environment and creating an installation with the required dependencies for a particular package set. For this task, I used schroot and debootstrap. The former manages the chroot environment itself, while the latter handles packaging for a minimal (or not so minimal, in this case!) internally-consistent environment.

The first thing to take care of is installing a complete enough set of packages that the chroot jail can manage itself from there on out. To do this, pick where you want to put your chroot (I used /mnt/unsafe/, and that's the path I'll be using throughout the rest of this document; adjust accordingly for your own purposes) and initialize it with debootstrap. In this case, I chose an i386 Ubuntu 12.04 (“precise”) jail, and initialized it as follows: 

sudo debootstrap --arch=i386 precise /mnt/unsafe/ http://archive.ubuntu.com/ubuntu

Documentation for how to use debootstrap effectively is readily available, so I won't cover it further in this document.

The next step is to turn this set of extracted packages into an actual chroot jail; as previously mentioned, I used schroot to accomplish that. It handles setup that requires superuser privileges, including mounting special filesystems such as /proc, and jail lifetimes. In order to jail Skype as tightly as possible while still allowing it access to my session PulseAudio server for sound, I needed a jail that was slightly more permissive than its minimal configuration, but far less permissive than its default configuration — which mounts user home directories inside the jail, even! I chose to create a configuration called unsafe that mounts the necessary files, but not a complete /home, and does not copy over unnecessary user or password database information.

The configuration for such a jail consists of four files in a directory under /etc/schroot (in this case, /etc/schroot/unsafe), two of which (copyfiles and nssdatabases are empty. You can download a tarball containing the setup I used, though it will require some editing, but I will include descriptions of the other two files here.

The first is config, and it is simply a shell script fragment describing the location of the other files. Mine looks like this: 

# Filesystems to mount inside the chroot.
FSTAB="/etc/schroot/unsafe/fstab"

# Files to copy from the host system into the chroot.
COPYFILES="/etc/schroot/unsafe/copyfiles"

# System NSS databases to copy into the chroot.
NSSDATABASES="/etc/schroot/unsafe/nssdatabases"

The second is a description of the filesystems to be mounted onto the chroot, in fstab(5) syntax. In this case, the entries are all bind mounts, and there are two extra mounts that won't appear in most chroots: /home/elb/.pulse and /var/lib/dbus. These directories are required to get PulseAudio connectivity into the chroot, and they are helpfully documented in the PulseAudio FAQ. The complete fstab for my setup is: 

/proc		/proc		none	rw,bind		0	0
/sys		/sys		none	rw,bind		0	0
/tmp		/tmp		none	rw,bind		0	0
/run/shm	/run/shm	none	rw,bind		0	0
/home/elb/.pulse	/home/elb/.pulse	none	rw,bind	0	0
/var/lib/dbus	/var/lib/dbus	none	rw,bind		0	0

Having established the configuration to be used for the chroot, we now have to bind it to the chroot directory and determine who can use it. This is done in the file /etc/schroot/schroot.conf, which uses a syntax reminiscent of Windows .ini files. To configure this particular chroot, I used this stanza: 

[unsafe-i386]
type=directory
directory=/mnt/unsafe
description=Precise chroot for i386 untrusted binaries
script-config=unsafe/config
personality=linux32
users=elb

This instructs schroot to create a jail called unsafe-i386 using the unsafe scripts we created earlier on a jail located at /mnt/unsafe containing an i386 distribution, and to allow the user elb to create and enter the jail without superuser privileges.

The last step is to create a home directory on the chroot, and add a user account to its /etc/passwd and /etc/group databases. You can probably accomplish this by the following (basically what I did), but you will want to double-check the results; in particular, assuming that the current user's primary GID is the same as the UID is not so portable (but will work on most standalone Ubuntu installs): 

sudo mkdir -p /mnt/unsafe/home/$USER
sudo chown $USER:$USER /mnt/unsafe/home/$USER
sudo echo "$USER:x:$UID:$UID:,,,:/home/$USER:/bin/bash" >> /mnt/unsafe/etc/passwd
sudo echo "$USER:x:$UID:" >> /mnt/unsafe/etc/group

Buffering X11 access

An application with direct access to your X11 server can do all kinds of mean, nasty, ugly things to you, particularly if it belongs on the Group W bench like Skype. These things range from sniffing your keystrokes to bypassing your screen lock to who knows what else. Unfortunately, we have to provide the jail with access to several things we would rather not (like /tmp, the PulseAudio socket, and — possibly most unfortunately — dbus), but that doesn't mean we have to give it direct access to X11.

Enter Xpra. Xpra is what the maintainers describe as “screen for X,“ providing detachable sessions and window forwarding over the network via an efficient, rootless protocol. In this case, however, we're not as concerned about that as the fact that Xpra uses its own headless X server and proxies actual windowing information between the client and your server. The actual extent to which this will protect you from client badness isn't clear to me, but it's a start. I need to do more research on this point — as well as into the possibility of using a newer release of Xpra to handle this whole shebang from a VM using PulseAudio.

To get the Ubuntu packages for Xpra, we have to add Universe to the chroot package system. In order to do that, edit (as root) /mnt/unsafe/etc/apt/sources.list and add the word universe to the end of the Precise sources line. It should look like this: 

deb http://archive.ubuntu.com/ubuntu precise main universe

Having done that, enter the chroot jail as root and install the package and its prerequisites: 

    sudo schroot -c unsafe-i386
    apt-get update
    apt-get install xpra

Note that the two commands from within the jail don't need a sudo prefix, as you're already root. Be sure to exit the jail when you're done.

The final step in walling the jail away from your local X11 server is to revoke its access to the server socket in /tmp. By default, most modern Linux distributions use a magic xhost property that allows all local processes owned by the same user as the X11 server to access the server without other authentication credentials. Since the chroot jail has direct access to the server socket, we want to prevent that. You can see the permission for this by running xhost. If something like this shows up, local user access is enabled: 

access control enabled, only authorized clients can connect
SI:localuser:elb

The second line is the important one — you should always see the first! That access will need to be revoked to prevent jailed applications from accessing your X11 server directly whether you want them to or not. The command to do so is xhost -SI:localuser:$USER, but if you use the scripts linked later on this page they will handle it for you.

Configuring the jail for Skype

Having created the jail, we now want to set it up for Skype. Since I elected to handle most of the getting in and out of the jail tasks external to the jail (more on that later), that basically means two steps: fetching and installing Skype's prerequisites, and installing Skype itself.

I downloaded the Skype package for my distribution, placed it in the /tmp directory for the chroot, then entered the chroot as root to install the dependencies and then the package itself: 

sudo schroot -c unsafe-i386
apt-get install libqtgui4 libasound2-plugins libxss1 libxv1 libqtwebkit4
dpkg -i /tmp/skype-ubuntu-precise_4.2.0.13-1_i386.deb

The above prerequisite list was complete for me, but if things change it may become stale. Fortunately, the package management system handles this (relatively) gracefully. If the dpkg command fails, simply run apt-get install -f to have it patch up the necessary dependencies, then re-run dpkg.

Gluing it all together

Once all of this is in place, the key is gluing it all together to minimize the pain of working across the jail interface. I have created a set of scripts to manage the jail. They handle starting the jail, starting the Xpra server on the jail side and the Xpra client on the local side, plumbing apps through Xpra, and shutting the jail down when you're done. I am not going to document how they work, and if they break you can keep both pieces — but they're working for me, and I'd be happy to answer specific questions.

The poor man's guide to setting them up is this: Copy start-unsafe, stop-unsafe, and unsafe-exec to somewhere in your path on the host machine. Put withxpra in the chroot jail in ~/bin (specifically — not just in the path!). Then, run a jailed GUI command as unsafe-exec <command>. For skype, that's unsafe-exec skype.

Final words

This isn't an ideal solution. I don't like the (lack of) isolation it provides. It allows audio, but not video. It's unclear exactly how much trouble Skype can get into through the xpra connection. (Something like ssh -X would be more clear.) I strongly believe that a determined attacker could bust out of this chroot more or less immediately. Don't trust your familyl jewels to this solution! However, I also believe that it will protect the host machine from casual abuses of by the jailed software, and that it provides some measure of isolation in the event that the jailed software has dangerous bugs.

Running a parallel OS in VMware or some other audio-capable virtualization solution would be better. Avoiding ugly proprietary software like Skype would be even better yet.

Finally, note that sound propagation with this solution only works with clients that use PulseAudio. That will cover a lot of clients, but not everything.

[1] This is, of course, an exaggeration. I do not require it for employment, and were my convictions a bit stronger, I could almost certainly get away from it entirely. The effort of doing so, however, is somewhat higher than the effort of building a chroot jail plus my mistrust. Or so it turns out.

tags: chroot, pulseaudio, skype, ubuntu, xpra
path: / | permalink | Comments

Sun, 02 Feb 2014

Setting the Sputnik 3 up with Encrypted /home

by on :

This is basically a guide for setting up a LUKS-encrypted home directory on LVM in Ubuntu 12.04, with the added wrinkle of working around the Dell installer setup bugs detailed in a previous post. Most of these instructions should work on other Ubuntu systems — you just probably don't have to do it this way, because you can set up LVM and LUKS at install time in the Ubuntu installer. Or so I suppose, I haven't actually done it.

This procedure makes a number of implicit assumptions. I'm going to make them more explicit here, so that you can decide if it's appropriate for your use:

  • My primary concern is protecting my data from loss/theft and prying eyes, not complete secrecy. In particular, this has implications on the configuration of LUKS and trim, and prepping the partition for storage. If you have greater privacy needs, there are other tutorials with information on how to mitigate some of the shortcomings here.
  • I am assuming that all important information that is privacy-sensitive is stored under /home. In particular, I am not (as yet) encrypting /tmp or any of the system directories. This assumption is true to a first approximation for the system on which I am installing it. Your needs may differ.
  • Hibernate is a desired feature for me. Since the keys for encrypted partitions are stored in memory, and thus flushed to disk at hibernation time, this necessitates encrypted swap. Encrypted swap is a good idea anyway, since some of my precious data might be in RAM, but failing to use encrypted swap with hibernate essentially provides a direct path to decrypting your entire disk.
  • I am willing to wipe the entire machine to set this up. I just got this laptop a couple of days ago, and I have good backups already. If your situation is different, you might want to take a more staged approach, resize partitions, etc. That task may be easier or harder, depending on your existing configuration and how you go about it.

Note: A mistake in the following, either in my instructions or in their execution, will almost certainly result in lost data. When followed correctly, these instructions will wipe your machine clean. Make sure you understand what you're getting into before beginning.

Repartitioning the disk and installing the system

I used the Dell recovery image, written to a USB flash drive, to repartition the disk. Hop through the prompts and tell it that you want to install only the Linux OS, that you want to do a fresh install, and that you want to set up the disks manually. I don't recall the exact prompt wordings, but if you're prepared to follow this guide you really shouldn't need them. If you get too confused at this point, abort — it doesn't get clearer from here on out.

Create three primary partitions. The first should be as large as you expect the system to be (I used 40 GB, which should provide about 20 GB of overhead). It's not going to be easy to expand this later, so be suitably generous. You can always store non-sensitive data there if you need to. The size of the second depends on the size of the third, which will be swap; it should be the remaining disk space minus about twice as much space as you have RAM. My XPS13 has 8 GB of RAM, so I used 16 GB of swap. Note that the recovery installer stupidly uses 1,000,000 byte megabytes, so you may want to do a little bit of math if you're compulsive like I am. Set this second partition to unused, we're going to format it later. The third partition is swap. Use the disk space you set aside in creating the previous partition, and mark it as swap. It won't be encrypted for now, but that's OK.

Let the installer do its thing. When it gets all done and wants to restart, though, don't restart just yet. As I discuss in my previous post, the Dell installer is buggy and doesn't flag the boot partition as bootable. Therefore, just before the reboot, hit Ctrl-Alt-F1 and run sudo fdisk /dev/sda. If you partitioned the same as I described above, your boot partition is /dev/sda1, so hit a to toggle the bootable flag, and select 1 to select the first partition. If you partitioned differently, you know what you're doing, so do it here. Press w to write the partition table to disk (it may tell you it couldn't be loaded by the running kernel and will require a reboot, that's fine). Press Ctrl-Alt-F7 to go back to the installer, and hit Reboot.

Installing necessary packages and obtaining a setup environment

At this point, we're going to need some packages not present in the base install, for LUKS and LVM. We're also going to want a setup environment that doesn't use /home. We'll achieve both of these in one step. Don't log in to X11; instead, hit Ctrl-Alt-F1 to get to a virtual console and log in there. Then issue these commands: 

    cd /
    exec sudo -H -s
    apt-get install cryptsetup lvm2

This will get you a root shell that isn't using any files under /home and provide the functionality necessary for the rest of the setup. use this terminal (and its root shell) for the remainder of this procedure.

Configuring encrypted swap

The next step is encrypted swap, because we need encrypted hibernate before we set up an encrypted /home. There are instructions for encrypted swap on the Ubuntu community wiki, although I don't quite like how they handle some things. For one, you don't need to enable ecryptfs and muck with the Ubuntu encryption solutions to get started, so don't do that — it just makes headaches. The cryptsetup package installed in the previous section provides everything necessary. The only major difference is that you'll have to create your own /etc/crypttab. You're going to be doing that for /home anyway, so not a big deal.

Note that you can follow these encrypted swap instructions to set up encrypted swap with hibernation without doing basically anything else in this document. Be forewarned that a misstep in the partition setup process will result in lost data, however.

Skip everything in those instructions up through How to Set up Hibernation, and do this instead:

  1. Run swapon -s and make note of the disk used by your swap device. If you partitioned as above, it will be /dev/sda3. The following will assume that device.

  2. Run:

    swapoff -a
cryptsetup --verify-passphrase luksFormat --hash=sha256 \
    --cipher=aes-cbc-essiv:sha256 --key-size=256 /dev/sda3

    You may or may not want to tweak the cipher options; the recommendation above is what I used, but it does not represent any sort of guarantee on my part that it's suitable for your purposes. You'll be prompted for a passphrase to encrypt the swap partition; this is very important. This passphrase will be used to generate the key used to encrypt your swap partition, so make sure it is good and make sure you can remember it. I recommend using something much longer than your typical login password. If you forget this passphrase, you'll have to set up your swap partition again following these instructions; you also won't be able to resume from hibernation if you hibernate and then can't remember the password. You have been warned.

  3. Next, we need to mount that partition and set it up for swapping. Do that as follows:

    cryptsetup luksOpen /dev/sda3 cswap0
mkswap -f /dev/mapper/cswap0

    It is important that you leave that partition mounted, and that we set it up for swapping during this session, so that the initramfs image created later knows what modules to include to mount it on boot. The name cswap0 is somewhat arbitrary, but it is important that it is consistent from here on out.

  4. The system then has to be told about the new swap partition, and its encryption configuration. To do that, you're going to edit /etc/crypttab and /etc/fstab as follows. First, open /etc/crypttab and insert the following line, which tells the system that there is an encrypted swap partition on /dev/sda3, that it uses LUKS for configuration, and that the user should be prompted for the passphrase:

    cswap0 /dev/sda3 none luks

    Next, remove or comment out the old swap configuration line in /etc/fstab and replace it with this:

    /dev/mapper/cswap0 none swap sw 0 0

  5. Run swapon -a and make sure your swap initializes correctly. If it doesn't figure out why not now, or you'll be sorry later.

Now that you've set up encrypted swap, follow the remainder of the instructions linked above to fix up the hibernation stuff. Skip generating the initial RAM disk, if you're going to go on to setting up an encrypted home partition, because you're just going to have to do it again later, anyway.

Configuring LVM and LUKS for encrypted /home

This part of the setup can likewise be followed without doing the reinstall or setting up encrypted swap, but as mentioned above it doesn't make a whole lot of sense to set up encrypted partitions and not encrypted swap if you plan to hibernate. If you don't plan to hibernate, you should be OK — but I make no guarantees.

Setting up an LVM disk, volume group, and logical volume is pretty straightforward and well-documented elsewhere, so I will include the commands here but not the rationale or detailed description. Red Hat offers a really fantastic LVM administration guide that should answer almost any questions that come up before the point that we start talking about encryption. So with that said, do this (again, this assumes the partitioning scheme set up earlier in this guide, adjust as necessary or lose data!): 

pvcreate /dev/sda2
vgcreate vg0 /dev/sda2
lvcreate -Z n -L 100G -n home-crypt vg0

This should create a 100 GB logical volume called /dev/vg0/home-crypt. Feel free to adjust names and sizes as you wish, but names have to be consistent from here on out. Note that there are mechanisms for resizing LUKS volumes and filesystem sizes, so you can always fix things up later; I used 100 GB to leave room for additional volumes for virtual machines.

Setting up encryption for this volume is substantially similar to setting up encryption for the swap partition, but we don't have to jump through the hibernation hoops.

  1. Run:

    cryptsetup --verify-passphrase luksFormat --hash=sha256 \
    --cipher=aes-cbc-essiv:sha256 --key-size=256 /dev/vg0/home-crypt

    The same caveats regarding encryption setup for the encrypted swap partition apply here. Please review them if you are not fully aware of the consequences.

  2. Attach the encrypted volume and create the filesystem with:

    cryptsetup luksOpen /dev/vg0/home-crypt home
mkfs.ext4 /dev/mapper/home

    You're going to want to leave this attached from here on out, too, so that update-initramfs can do its thing.

  3. Update /etc/crypttab and /etc/fstab as follows, correcting for any differences in naming you may have chosen:

    /etc/crypttab:
home /dev/vg0/home-crypt none luks,discard

/etc/fstab:
/dev/mapper/home /home ext4 relatime 0 1

    Note the discard option in the LUKS configuration above; this enables TRIM support and has security and privacy implications. In particular, it reveals which portions of the disk your filesystem is using. It may make certain forms of cryptanalysis easier, and will almost certainly leak information about how much data you are storing on the encrypted partition. I believe the tradeoffs are appropriate for my particular usage scenario, but you should understand the considerations before enabling it. Note that if you do not enable it, you may also need or want to take other steps not included in this document. There are various resources on the Internet discussing these tradeoffs, and I suggest you consult them if you have questions.

That completes setup for the partition that will hold your home directories. If you have data in /home already, you may want to mount /dev/mapper/home someplace and move it over now. You will almost certainly want to mount it and create a home directory for your user (remember to chown it appropriately!).

Creating an updated initial RAM disk and booting

The final critical step is creating an updated initial RAM disk that contains the modules and crypto configuration to boot your machine with the encrypted swap and filesystems in place. At this point you should double check your /etc/crypttab, /etc/fstab, and hibernation configurations, and make sure the swap partition and encrypted home partition are mapped (they don't necessarily have to be mounted). When you are sure that everything is in place, run this command: 

update-initramfs -u -k all

It should complete without errors. When it does, your system is set up, and you can reboot. I recommend doing so now. Upon bootup, you will be prompted for the passphrase first for your swap partition, and then for your encrypted /home partition. The first prompt is pretty and nice and everything works normally. For the second prompt, for some reason there will be some on-screen glitches (at least, there are on my machine), but everything works normally anyway. Note that you will be prompted three times for each passphrase if you make a mistake on entry, and after the third time bootup will continue without the partition in question. Not having /home in particular is not going to lead to a nice day, so type carefully and remember those passphrases!

tags: hibernate, luks, lvm, recovery, sputnik, swap
path: /xps13 | permalink | Comments

Installing linux on an XPS13 isn't as easy as running it!

by on :

There are likely to be a lot of these XPS13 posts, so I've created a category for them. This is the first post in that category.

Wherein a reinstall is harder than it should be

So I decided to wipe and reinstall my XPS13 for a variety of reasons, most of which boil down to encrypted /home. I found that that process was somewhat more difficult than it could otherwise have been, mostly because a) the Sputnik 3 install image does not have networking support, b) the recovery process doesn't partition correctly, and c) nothing else has networking support, either.

The setup

Let's start with networking support. Apparently, the wifi adapter in the Sputnik 3 is about five and a half minutes old. You have to have a very new kernel, and very new firmware, to get it to work. I have read variously that Linux 3.10 and 3.12 are the requisite kernel versions, and several different comments on firmware blobs. I don't know for sure, I haven't gotten that far. The bottom line is that neither Debian 7 (wheezy) nor Debian testing (jessie) netinst images would work, even with extra non-free firmware packages. That's not entirely unsurprising, but what is surprising is that Dell's own recovery image doesn't appear to have the appropriate driver and/or firmware. This means that you can't install software to the recovery image system.

... Which is unfortunate for me, because the whole point of this exercise was to set up the drive using LVM and LUKS encrypted partitions. Ubuntu 12.04 supports both of these things just fine, just not on the Dell recovery image. Ugh.

Reinstall #1

I decided to do things the “hard” way, leave everything but /home unencrypted, and just set up the encrypted /home partition once the recovery image had done its thing. For this to work, I deleted the partitions I didn't want, created a / partition, a large unused space for LVM, and a swap partition, then installed. The recovery image appeared to be happy, and did its thing for a while. So far so good. Except ...

When the laptop rebooted, it said Operation system not found. Yeah, “Operation system“. The Chinese-to-English translator was sleeping on the job that day, apparently. I had left a small FAT partition on the drive that appeared at a glance to be for UEFI, so I thought maybe it required some updates to get things working. I was a bit confused, though, as the system was configured for legacy boot and I wasn't sure why it would want that partition, anyway. So, figuring I could just do a complete restore (restoring the UEFI and recovery partitions, as well as the Linux install) if things went too wrong, I took the nuclear option.

Reinstall #2, and resolution

I rebooted to the recovery image, wiped the UEFI partition as well, and reinstalled with only the Linux install and empty partition. Same as before, everything appeared to go fine, then reboot, and whoops, no dice.

So I said to myself, “surely it's not as simple as they installed grub to the OS partition and didn't mark it bootable!,” and I rebooted to that !*$@& recovery image AGAIN. I fired up fdisk, marked /dev/sda1 bootable, wrote, and rebooted — without even looking at their GUI. Presto, the annoying setup video played and I was off to the races.

Summary

I'm done jacking with this thing for tonight. We'll see how the rest of the saga goes tomorrow (and maybe I'll write it up). This situation doesn't really significantly damage my opinion of the hardware, as it's obviously still great, but it does give me some pause regarding Dell's commitment to the product. Ubuntu 12.04 is pretty old, there doesn't appear to be a way to install anything newer (at least, without doing some installer futzing) at the moment, and even the Dell installer doesn't really seem to be brought up to speed for the new hardware. It's almost like they shipped with the Sputnik 2 installer and some extra install-time packages.

The charitable part of me hopes that this is because this product is only a month old, and they're already prepping 14.04 for April. Any word on that, Dell?

tags: bugs, recovery, sputnik
path: /xps13 | permalink | Comments

Sat, 01 Feb 2014

First Impressions of the Dell XPS 13 Developer Edition (AKA“Sputnik 3”)

by on :

The following are my initial impressions of the third-generation Dell XPS 13 Developer Edition “ultrabook”, often called Sputnik 3 in reference to the Dell skunkworks project that produced the original machine and to distinguish it from its predecessors. It is a 13.3" slim Intel Core i7 laptop with a 1920x1080 touchscreen display, full-size keyboard, solid state disk, and large touchpad. It comes installed with Ubuntu 12.04, which is a little dated at this point, but generally functions.

This review comes after just a few hours of use. I'll try to do a follow-up later, with more experience, for perspective. I received the laptop on Thursday, January 30 2014, but really didn't have time to do more than make sure the parts were in the box until late on Friday, January 31, and I am writing this review on Saturday, February 1.

To put this review in perspective, I keep my laptops for their useful lifetime, which has thus far meant about 5 years. My first laptop was an Apple iBook 12" (the white kind, not the toilet seat) in 2001, on which I ran first Linux, then OS X, then Linux again. When it died in 2005 (the BGA graphics chip problem that killed most of them), I replaced it with a Dell Latitude d610. The d610 was much larger, heavier, and generally less elegant than the iBook, but it a) worked, b) was free, and c) ran Linux like a champ. By the fall of 2009 it was getting pretty long in the tooth, had a battery life of only about two hours, and was noticeably slower than other machines I had access to. I will note that it's the only laptop in this story that still works, however — I have it sitting on a desk where I occasionally need to pop up reference documentation and it can remain plugged into AC power. I replaced it with a MacBook Pro mid-2009 that just died in January of 2014. The MBP was down to about 2 1/2 hours of battery life and I had been thinking I either needed to get a new battery or replace it, and it took the issue out of my hands when its SATA controller apparently went South for the winter. Over the years I have also had a fair amount of experience with my wife's older MacBook and 2012-vintage MacBook Air, as well as other Dell and Lenovo laptops.

Given the above experience, and that my immediate previous laptop that I had been using for 5 years was a MacBook Pro, you're going to find a lot of Apple comparisons in this article. I think that's OK, because it seems to me that this machine's most direct competitor is the Apple MacBook Air 13".

Presentation and Initial Physical Impressions

The very first thing I noticed is that this machine comes in the nicest packaging I've ever seen, for a consumer laptop. It's nicer even than MacBook packaging, although similar in broad comparison. It's almost a presentation case. It has sharp, square corners and a mid-hinge design that provides an overall slick impression. I'm not really too concerned about such things, but it did make an impact when I opened the shipping box.

The next thing I noticed is that it's tiny. Footprint-wise, it's about 1" shorter than the MacBook Air, maybe 3/8" narrower, and a similar body thickness. It's overall a bit thicker because its “feet” are somewhat more substantial, but the body itself is similar. More on those feet later. The display is wider and shorter than the MBA, but total viewable space is very similar and the bezel is markedly smaller. The body width leaves enough room for a full-size (or close enough that I can comfortably touch-type, anyway, I haven't measured) keyboard, though the height dictates that the touchpad is somewhat smaller in the Y dimension than my MacBook Air.

I'm very much a function-over-form guy, and I'm more concerned about practicality than looks for the sake of looks. That said, the overall package is reasonably attractive. Dell makes a big deal out of the "magnesium and carbon fiber" construction, but frankly it might as well be "aluminum and plastic", because that's what it looks and feels like to me. Many of the plastic surfaces (including keyboard keys) feel somewhat rubberized, which is a bit disconcerting at first but rapidly fades from notice. They do seem to fingerprint very easily. The feet on the body are very much rubberized, and stay put nicely. Time will tell whether they present a problem for sliding in and out of a backpack without interfering with other papers and such. There's a reasonably classy but too-obvious for my taste Dell logo on the back of the display; at least it doesn't glow like my MBP did! There is also a weird metal plate on the bottom with an embossed XPS and laser-etched Ubuntu and Intel logos on it. It has a little finger groove under one side like it might be a cover or otherwise removable, but moderate tugging at it didn't move it, so I don't know what it is or what it's for. Decoration, I guess. Update: More concerted prying reveals that it does indeed open, and there's a service tag and some typical FCC/UL information underneath. So yeah, decoration.

Function-wise, an immediate positive design aspect jumped out the moment I saw the power adapter. It's similar in size to recent MBA power adapters (somewhat longer and thinner), but much better designed. The DC power cable is larger in diameter and wraps around the body of the adapter itself, rather than those stupid tiny stress-inducing ears that Apple has been using for a few years now. I don't anticipate spectacular, spark-throwing failures of this supply like I experienced with my MBP. Dell did pull a successful page out of Apple's book and supplies both a wall-wart style plug and a short AC cord for the brick. Again here, the design is somewhat better, with the folding AC prongs being mounted to a square-faced block that can be configured to protrude either out the broad side of the adapter for horizontal mounting or out the end of the adapter to stand in a power strip. Both configurations are better leverage-wise than the Apple plug block, which has a tendency for the AC adapter weight to try to fold the plug back into the body, dragging it out of outlets. (I have experienced this with two different Apple AC adapters of different sizes, so it's not a rare failure mode.) An additional nice design touch is that the DC cable exits the AC adapter through a hard molded channel that should provide very effective strain relief, instead of perpendicular from the body as is so common.

My primary complaint about the power adapter configuration is that it has glowing lights on the end of the DC cable. Apple does this, Alienware (now owned by Dell) does this, and probably other manufacturers. All I can figure is that the designers of this feature do not have small children. What does a small child do when they see a glowing light? PULL ON IT. Another minor annoyance is that the LED in the top of the DC power cable lights whether or not the cable is plugged into the laptop. I suppose this is so people will recognize that it's still energized even when the laptop isn't plugged in and unplug the adapter, but ... kind of annoying.

On the subject of power, the battery is non-removable. We'll treat battery life later, but it seems to be good. There is a recessed button and row of five tiny LEDs on the right-hand edge of the lower shell that shows remaining battery charge — a very nice feature. My MacBook Pro had this, and all of my laptops with removable batteries have had this, but for some reason the new MacBook Airs do not. Stupid.

There's a gauche Intel Inside™ CORE i7 sticker on the lower right palm rest that doesn't appear to readily peel off. A large Dell XPS horn-tooting sticker on the left palm rest has a fake folded corner indicating that it does peel off, and it removed easily without leaving behind any noticeable residue.

Initial Boot and Setup

On first boot (which is of course very fast, off the SSD!), the installed OS immediately goes into a song-and-dance routine like OS X. Also annoyingly like OS X, you actually have to watch the whole thing. It's probably only 30 seconds long or so, but it seems longer since it's stupid and useless. Once it finishes, a well-executed initial setup dialog walks you through creating your user and a few other settings, then drops you to the Unity desktop. The only glitch I experienced here was that I couldn't find a way to tell it about my hidden wireless network; I had to skip networking and configure that once I was at the desktop.

I am not thrilled with the choice of Unity as an interface. Obviously this is because Ubuntu is their operating system of choice (I would pick Debian, but I can't substantially fault them for this), but I'm really not a fan. I used it for a few minutes before the window placement became annoying and I switched to XFCE4. That was even more annoying, so I installed fvwm2 and slurped my config from another machine and got down to business.

Part of the initial setup process was an option to create restore media. Because I understand that installing Linux on this machine (as opposed to running it) is somewhat tricky due to requiring newer kernels than most distributions provide (or backported drivers), I elected to create a restore disk. This overwrote a 4 GB USB stick (they say you need at least 2 GB, and the actual ISO image is about 2.4 GB). I haven't tried to use it. That process also leaves the restore ISO image in ~/Downloads. Writing the ISO image took a few minutes; I'm not sure how long, because I was doing other things, but it was at least 5 or 10. Some of that is undoubtedly because my USB flash drive is a free drive from some conference.

The factory SSD setup leaves you with about 200 GB of free disk space. There is a small UEFI partition and a 3+ GB factory restore partition on the disk other than the primary installation, as well as a 16 GB swap partition and about 7.5 GB of preinstalled software. The disk is advertised as 256 GB, so I figure 200 GB of usable free space is pretty reasonable.

Throughout much of the initial setup process, there was an annoying squealing sound coming from the motherboard. This is very common with modern electronics, and usually indicates a coil or capacitor that is producing audio-frequency physical vibrations induced by whatever signal is passing through it. I noticed that it went away at some point, and assumed it was just startup weirdness and gone, but some poking online suggested that it was actually related to the keyboard backlight (see, for example, this forum thread), which I had turned off. Indeed, turning the keyboard backlight on causes it to come back with a vengeance. Some Dell forum posts suggest that they're working on this, and it's covered by warranty; I don't intend to use the keyboard backlight so I don't care too much for the time being, but it's something to keep in mind.

Basic Functionality

All advertised features seem to work, and work well. For Linux on a laptop, that's definitely not always the case!

The keyboard hotkeys for display and keyboard backlight work under all desktop environments, although the volume controls seem to require Unity. (They didn't work under XFCE4, and they don't work in Fvwm.) That's to be sort of expected, but they also don't seem to send normal Xf86 media key keycodes. They will require further analysis. Fn-key combos like page up, page down, etc. also work as expected — and as a bonus, are located on the same arrow keys in the same configuration as my MacBook Pro.

The touchpad is great. Apple has had the corner on amazing touchpads since the release of the glass clickable touchpad on the MacBook Pro half a decade ago. Nothing else has even come close. I'm pleased to say that the touchpad on this laptop is definitely getting there. It's a little bit more jittery than the Apple touchpad, but multitouch taps work as expected, left and right click by corner work as expected, and the sensitivity and accuracy are in general much superior to any PC touchpad I've used in a very long time. (NB: there are probably other machines with this pad on the market now, but I simply haven't seen one.) As mentioned earlier in this review, the touch pad is a little bit shorter than on my MacBook Pro, leaving it closer to the aspect ratio of the XPS screen — which is probably appropriate. If it's wider, it's not a lot wider; over all, I suspect the touchable area is slightly smaller. The only thing I'm missing so far is multitouch swipe gestures in my web browser, which Linux browsers (I've tried Firefox and Chrome) don't seem to support. I'm not sure if this is a driver problem, an X input model problem, or simply a limitation of the browsers. I haven't looked into it yet.

When I moved to Fvwm, I did lose three-finger-tap as a middle click. This is easily re-enabled with the Synaptics configuration utility by running synclient TapButton3=2. I put that in my Fvwm startup scripts and all is well.

The touchscreen seems to work OK. I am neither a big fan of touching displays nor particularly convinced that a touch laptop display is ergonomically a great idea. Time will tell if I find it useful. Touches seem to be accurate and mostly DWIM. I haven't really poked at it enough to say more.

Battery, Power, and Thermals

With limited data to work from, battery life seems to be great. As I type this, I've been on battery for about 3 1/2 hours, and the battery is sitting right at 50%. The power monitoring subsystem estimates another 3:20 of battery life, which tracks with those numbers. I have done a very little development work, some package management, a fair amount of web browsing, and a lot of editing (mostly this document!). I would say that the work load approximates my usual development work (I use remote build machines for big builds, which cuts down on absolute CPU usage), so I expect to get 6–7 hours of battery life on a typical charge based on what I've seen so far. That's less than Apple advertises for the MacBook Air, but in line with what I've actually seen it accomplish. More would be better, of course, but it'll get me to Europe.

Update: At approximately 3:30 PM, after about 8 hours on battery, the indicator light at the edge of the laptop (I guess I didn't mention it before, but there's a white indicator at the edge of the laptop) has turned orange and there's a reported 8% and 31 minutes of battery remaining. I was gone for almost exactly one hour with the screen shut off, and that hour appeared to cost me about 20 minutes of in-use battery life. As expected, the screen is a big part of the battery drain. At this point, I'm going to go ahead and plug the thing in. I would call the battery life under active use but with moderate CPU demands about 7 hours, and not worry too much about leaving it running for another hour or so if it's completely idle. Not bad.

Charge times appear to be reasonable, but certainly not particularly rapid. It took a couple of hours to go from a flat battery (under 5% charge remaining) to full charge under light load. The included AC adapter is a 45 W supply, I don't know if the optional larger supply would charge faster or if it's a limitation of the drive controller. Like most modern laptop batteries, it seems to take the bulk of its charge more quickly than the last few percent.

The fan has kicked on a few times, but it mostly stays off and the laptop is silent. Even relatively idle, the bottom of the case does get a bit warm, and I can definitely feel it on my lap. I would say that its heat impact on my legs is broadly similar to the MBP that it's replacing, although it does take longer to cool down when I set it aside — almost certainly because the MBP bottom cover is aluminum, while the XPS is carbon fiber.

Airflow appears to be drawn in a long, narrow recessed vent near the rear of the laptop behind the back “foot“ and pushed out the hinge under the monitor (like a MacBook). This is probably the reason for the larger feet on this unit compared to a Mac laptop; to raise that vent higher above the surface on which it sits so it can capture more air. The rearmost 1/4 or so of the laptop body (from about that vent to the hinge, as one would expect) appear to be where the majority of the heat is concentrated. The palm rests and lower keyboard keys remain quite cool, although the upper keyboard keys get a bit warm when it's working hard.

Display

The display is nice. Very nice. The only nicer displays I have seen are Apple Retina laptop displays. The dot pitch is a little more than half that of a Retina display (I calculate about 166 DPI); high enough to be visibly sharper than a typical laptop display, but not as smooth as a modern Android device or Apple Retina display.

I am disappointed that, in a trend that seems to be gaining momentum, either the GPU, display drivers, Ubuntu configuration, or X.org server ignores the actual panel size and reports a 96x96 DPI display. Historically, X11 has had much better display size and, with the advent of fontconfig and pango, better font rendering at more accurate sizes than any other platform I have used. However, this accuracy requires that the display drivers know how large the panel actually is. The result of lying to it in this fashion is that a logical 9 pt font on this display is more like 5 pt in actual height — much too small to be generally usable. This sort of lying is fixable in X configuration files, but I shouldn't have to do it. Panels know how big they are. Panel communication interfaces tell the GPU. The GPU can tell the driver, and the driver can tell the X server. I've seen it work. It works on my desktop. Get it right, people. When I say I want a screen font to be 9 pt high, I expect it to be 9 actual points high. I'll let you decide whether to use printer's points or 1/72" LaTeX-style points, I'm not that picky, but either way it ought to be close enough that I can't tell.

</RANT>

Summary

I am very impressed. I bought this model of laptop sight-unseen, based on Internet reviews, personal recommendations (Rik van Riel, a coworker of Geoff Lane, etc.), and the stats off Dell's web site. I was a bit nervous about what I would actually receive, but the untimely death of my MacBook Pro coupled with a concern about the direction in which Apple is heading with OS X left me with few plausible options in the laptop market and a pressing need for a new machine. So far, it looks like the leap of faith was justified.

The price sticker is a little bit high. As configured, the total bill was a bit less than $1,700. That is price-competitive with the MacBook Air, as previously mentioned the closest market competitor, but it's more than I really wanted to pay for a laptop. As a laptop makes up a fair portion of my livelihood I can readily justify the expense, but I am not sure I would spend it if I didn't use a laptop for development work for hours a day every day. I think something closer to $1,000–1,200 would be more in line for that purpose. There is a cheaper brother to this model with half as much RAM and half as much SSD that might fit the bill more closely for other customers.

tags: review, sputnik
path: / | permalink | Comments

First Post!

by on :

This is an emptyish post to get Pyblosxom primed. This blog will contain personal musings not really of a ham radio nature (and so not appropriate for the main kb8ojh.net content stream.

tags:
path: / | permalink | Comments

<<  Page 7 of 7
[ | | ]

Tags