I recently acquired the Samson C01U USB condenser microphone for better quality voice-overs on the sleep-inducing screencasts I sometimes make. It took some fiddling to get it setup correctly on Ubuntu 12.04 with the default ALSA drivers and PulseAudio sound system, so I’ve documented the steps here on the chance that it might help some other Ubuntu / Linux user.
The microphone looks like this:
It comes with a USB cable, pouch and usable tripod stand. One can accessorize with the Samson PS01 pop-filter (have it), and even with a spider shockmount (don’t have it yet, I like people to hear me typing when I make screencasts). Importantly, the quality of the recorded audio is miles better than any headset, if you can get the levels setup correctly.
It turns out that the microphone has a stereo amplifier chip. Both channels are exposed to the computer it’s connected to, as left and right. However, the two amplifiers have been cascaded for more gain. The right channel is the intermediate audio, i.e. after the first amplifier, and should not be used. The left channel is the final output that should be used. Furthermore, both the gains can be separately adjusted, and this is the reason my recordings were initially far too soft.
To adjust the gains of the built-in amplifiers, you have to use the alsamixer application, which you can start up from a terminal window. Right after startup, it will probably look something like this:
It will probably show the channels available on your default sound card. Press F6, then select your Samson, then press F4 to select the capture channels. You should now see this:
Here you can adjust the gains of the right (pre-amplifier) and left (main amplifier) separately. This is completely separate from the gain that you can set in the Ubuntu / Gnome sound settings:
I’ve found that by setting the gain of both of the built-in microphone amplifiers to about 19 dB with alsamixer, I can keep the (probably software) gain in Ubuntu / Gnome sound settings at “Unamplified”. Note also that I’ve selected the “Analog Mono Input” mode. I’ve tried with different gain settings for left and right, as some permutations should in theory have less noise than others for the same total gain, but have not yet found anything that resulted in a difference I could hear.
So that’s it kids. Let me know in the comments if you have any questions, if this howto might have helped you or you have other ideas about the perfect left/right gain settings!
Update on 2013-05-17
Recently, Google Hangout users started reporting that the volume of my voice was too low. This was strange, because the recordings I made with Sound Recorder were perfect. After some frustrating minutes, I discovered that the Pulse per-application volume for Google Chrome (which I use for Hangouts) had been adjusted. This means that there’s a third configuration that you should check when adjusting the levels of your C01U (or any other microphone), and that’s on the “recording” tab of the Pulse Audio Volume Control (pavucontrol). See this screencast (and check my description) for more details:
I recently needed a new mobile development workstation. My main requirements were that it should have at least a Full HD (1920×1080) IPS (in-plane switching) screen and a good keyboard, and that it should be able to run Linux, preferably Ubuntu, as its primary operating system.
After experimenting with a screenshot of my 1920×1080 desktop workstation running IntelliJ Idea 12 (my IDE of choice) on an Asus UX31A with 13″ Full HD IPS screen, I realised that I would have to go with a larger screen. The Asus UX52VS with 15.6″ IPS also looked like a good bet, but there were no reviews available yet, it was not clear whether the 4GB RAM and hybrid HDD (large spindle drive, 24GB SSD cache) would be easily upgradable to full SSD, and the €1200 price tag was reason for more consideration.
I finally stumbled upon this review of the Acer V3 571G with Full HD IPS, which was mostly quite surprised that such a laptop with such a screen could be sold for entry-level prices. I subsequently purchased model number V3-571G-73638G75Maii, with Full HD IPS (this is the LP156WF4-SPB1 LED IPS matte panel by LG Philips ), Intel i7 36732QM (a real mobile quad-core; many mobile i7s are dual core), NVIDIA GeForce 710m with 2GB VRAM (Optimus graphics switching), 8GB RAM, 750G HDD, all for €799. I also purchased an Intel 520 240G SSD, a really fast SSD with built-in hardware encryption that would replace the main HDD, for €200.
Upgrading HDD and RAM
My first impression of the laptop was that in reality it does not look quite as cheap as the photos might make one believe. I was pleasantly surprised when I set out to replace the HDD with the Intel SSD. After removing two screws on the underside, a panel can be removed behind which the hard drive and RAM can be easily upgraded:
Configuring Linux: Ubuntu 12.04.2
After the SSD upgrade, installing Ubuntu 12.04.2 went mostly without a hitch. 12.04.2 comes with the LTSEnablementStack, backports of the Quantal kernel (3.5) and the new X stack to support more hardware. This caused some dependency problems when I installed bumblebee (Linux support for NVIDIA Optimus graphics switching), but this problem was almost immediately fixed by the ubuntu-x-swat team when I reported it on #freenode, so you should be fine. Just in case you need a reminder, bumblebee is installed and configured as follows:
If you want to run something on the NVIDIA, just do “primusrun command” or “optirun command”, where the former is preferred due to performance.
Other than that, make sure you have GRUB_CMDLINE_LINUX_DEFAULT=”apci_backlight=vendor acpi_osi=” in your /etc/default/grub (run update-grub and reboot after you change this) to get the screen brightness hotkeys working. Unfortunately, the brightness notifier itself does not work, but this is not a problem.
Weakpoint: BIOS ATA security support
After a few mails to-and-fro with Acer tech support (they do respond, mostly) and two nights of experiments, I can now confirm that the HDD password implementation on the laptop is worth less than nothing. In the spirit of full disclosure, this is the Insyde H2O BIOS implementation of HDD passwords. This BIOS is used on many modern laptops besides Acer.
For many of the current self-encrypting drives, BIOS support of the ATA security feature mode set is important. It should be possible to set both master and user passwords, and, more importantly, the BIOS should ask for this password at bootup, at which point it should pass the user-entered password, unchanged, to the hard drive as ATA commands. Setting the HDD password on the Acer does none of the above. Instead, it sets a fixed password that has nothing to do with the user password. At bootup, it asks for a HDD password. However, if you enter this incorrectly 3 times, you get a hash code. This hash code can be used with a simple Python script to generate a master unlock password with which the HDD can be trivially unlocked. I confirmed experimentally that this works.
I also experimented with setting the ATA security user password to a known value using hdparm from a Linux boot USB. The Insyde H2O BIOS unfortunately does not fall back to sane behaviour.
To summarise: The Acer BIOS can’t be used to manage ATA security. Because it is important that my SSD is fully encrypted, I now boot the laptop with a USB stick, unlock with the real ATA user password using hdparm, and then warm-boot back into the SSD. I perceive this as a relatively small price to pay for reasonable and super fast data security (my Intel does 500MB+ read and write, all with AES-128 encryption). Remember that software encryption has a severe performance and durability impact on all SSDs, especially those using compressing controllers such as the Sandforce, but also SSDs that employ no compression at all. AES-NI is really not the issue here, it has to do with the performance and durability optimizations modern SSD controllers do.
The matte Full HD IPS screen on this laptop is a pleasure to use. I find the chiclet keyboard above average for programming. It’s not as rigid as the keyboard on my Samsung NP300V3a, but it’s entirely acceptable. The combination of an Ivy Bridge i7 3632QM quad core, an Intel 520 SSD and 8GB of 1600MHz DDR3 RAM makes for a laptop that feels super responsive. Taken together with the solid Ubuntu support and the €799 + €200 price tag, and in spite of lack of ATA security support in the BIOS, I can only highly recommend this machine to any developer looking for a powerful Linux laptop on a budget.
(tl;dr / post summary: Many current SSDs do super fast hardware AES encryption, but only a very few expose this correctly to the user, meaning you often still need a third-party software solution. Information on this is incredibly hard to find.)
Imagine that your laptop or your PC gets stolen. That would be terrible. However, it would be even worse if your laptop contained confidential data, either your own or that of your employer or client. It’s clear that encrypting one’s hard drive has become a necessity. There are good open source software solutions for this, for example TrueCrypt (Windows, Linux and OSX) and the LUKS/dm-crypt system. However, such software encryption systems require a small chunk of your CPU capacity, and also affect SSD performance and durability to a lesser or greater extent, depending on the controller.
A number of SSD drives now implement real-time AES encryption in hardware. Usually the reason for this is to enable fast secure erase: When the AES keys are destroyed by the firmware, a very cheap operation that requires almost no writing to the flash, no data on the whole SSD can be read, and can thus the data can be considered securely erased. The encryption and decryption take place in the controller hardware, so there is no performance hit. The Sandforce SF2281 controller is one of the more well-known SSD controllers that does this. In some cases, the manufacterer uses the HDD password or ATA password (configurable via many laptop BIOSes, very few desktop BIOSes, or the ATASX BIOS extension) to encrypt the AES keys. This means that even if the manufacturer got hold of your drive, and you had set a strong ATA password, they would probably never be able to decrypt your data. I call this usable built-in-hardware-based full disk encryption. In these cases, you do NOT need to install third-party software full disk encryption, and can enjoy the full performance of your SSD. In many other cases, the encryption keys are stored in the drive firmware, but are NOT explicitly encrypted with a user-supplied password. This is non-usable encryption, because in theory the manufacturer or a sufficiently skilled hardware hacker can extract the encryption keys from the drive firmware and decrypt all of your data. In these cases, you ABSOLUTELY have to use a third-party software disk encryption software tool. The purpose of this post is to keep a list of current SSDs with usable and non-usable built-in hardware-based full disk encryption. Whilst recently shopping for a suitable SSD, this information was unreasonably hard to come by, hence this list. If you have additions or corrections, please let me know in the comments.
SSDs with USABLE built-in encryption:
This post and this post by an Intel representative confirm that the AES keys on the Intel 320 SSD are encrypted with the user’s ATA password. The second gives more detail on the implementation details, for example that the ATA password itself is also stored in non-reversible hashed form in the drive firmware. The white paper linked to under the Intel 520 heading below confirms the working of the 320 encryption setup.
This is the first Intel SSD making use of the Sandforce SF-2281 controller. Due to a bug in the controller, the drive does AES-128 encryption (instead of the advertised AES-256). AES-128 is still considered to be sufficient for most purposes. After two unsuccessful attempts getting a clear answer on the details of the Intel 520 encryption directly from Intel support, I finally stumbled on this white paper by Intel: Managing Intel Solid-State Drives Using Intel vPro Technology (mirror here). On page 3, in the grey box at the bottom of the page, we see the following text (bold words by me):
How Self-encrypting drives (SEDs) Work: SEDs, such as the Intel® SSD 320 Series and Intel® SSD 520 Series, have a drive controller that automatically encrypts all data to the drive and decrypts all the data from the drive. The disk encryption key is never present in the computer’s processor or memory, where it could be accessed by hackers. The key used to encrypt and decrypt is securely stored only on the drive. Because the disk encryption key is encrypted with the ATA (Advanced Technology Attachment) passwords, the key is made accessible to the drive only after successful user authentication; without the key the data remains encrypted on the media. Authentication of the user is done within the SED by supplying the ATA user password, which is isolated from the OS. Therefore, attacks on OS vulnerabilities cannot affect an SED’s pre-boot process.
That’s a pretty conclusive statement by Intel that both the 320 and the 520 encrypt their AES encryption key with the user-supplied ATA password. After a few weeks and some mails with Intel tech support, I also received the following confirmation concerning the Intel 520 SSD:
Yes, ATA password is used to encrypt the encryption keys stores on the SSD. In other words: The Encryption Keys depends on the ATA password to decrypt them. The ATA password is not used in combination with the Encryption Keys to encrypt the data.
Intel support furthermore confirmed that the Intel 520 is compliant with FIPS-197.
SSDs with PERHAPS USABLE built-in encryption
In these cases there are indications that the mentioned drives are encrypting the encryption keys with the ATA user password, but I have not been able to find more conclusive confirmation. If you find anything, please let me know it the comments, because eventually I’d like to move them out to the list of USABLE or NON-USABLE encryption.
Plextor M5 Pro
On the product page the graphic shows quite clearly that ata passwords are related to encryption keys, but it does not specify in which way these are linked. A reasonable approach would of course be that the key is encrypted with the ATA password, but until that’s confirmed, this drive remains on the “perhaps”-list.
Samsung 840 Pro
Again it’s far too hard to find conclusive information on the encryption implementation. On this product page, we find the following text:
Keep your data safe with Self-Encrypting Drive (SED) Technology Simply enable an HDD password via your computer’s BIOS, and Samsung’s SSD 840 applies data encryption automatically.
This is not as conclusive as I’d like, but there is an implication that there’s a link between the HDD password and the encryption on the Samsung.
This drive is not to be confused with the consumer-oriented Samsung 830. The PM830 is a special professional OEM version, found for example in Dell Latitude laptops. There are indications, such as this great 2012 overview paper, titled Hardware-based Full Disk Encryption (In)Security Survey, by Tilo Muller, Tobias Latzo, and Felix C. Freiling (accompanying website with demonstration videos), which mention the PM830 as an example of hardware-based full disk encryption. I’m still searching for the cited spec document that might confirm whether the PM830 encrypts its AES-256 keys with the ATA password, and also the possible password-length limitations.
SSDs with NON-USABLE built-in encryption
OCZ Agility / Vertex 2 / 3 / 4
In this posting on the OCZ Technology Forum, we see that in at least some of the OCZ SSDs, “The encryption key is not directly linked to the ATA Security password (or the BIOS password).” I have not been able to find more specific information about other OCZ offerings. However, my expectations are not very high based on this previous work by OCZ.
Manufacturers of SSDs with built-in encryption are doing an absolutely TERRIBLE job of informing their customers of their specific encryption implementations. For something as critical as full disk encryption, I would expect full disclosure. If the encryption approach is good, disclosing its details won’t affect its security.
The only SSDs that I’d recommend in terms of usable built-in disk encryption are the Intel 320 and 520 drives. It would be great if this list could be expanded. If you have a direct connection to the relevant persons at the various manufacturers, please make use of this and let me know of the results so I can update this blog post.
Your BIOS has to support the full 32 character ATA password specification. The Samsung laptop I’m typing this on only supports 8 character ATA passwords, so I’d think carefully about installing a hardware-based encrypted SSD in here. My desktop with the Intel 520 SSD has the ATASX bios extension and supports up to the full 32 characters. When you buy a new laptop or motherboard, make sure it has a good ATA security extensions implementation, supporting the full 32 characters.
Although ideally the built-in hardware encryption would be usable and secure, the disappointing state of affairs leads me to the conclusion that a good option at this point is still to select an SSD that is impacted as little as possible by the software encryption (avoid the Sandforce controllers, or any other controllers that make use of hardware compression), and then use a solution such as TrueCrypt or luks/dm-crypt (even for a non-Sandforce controller such as on the OCZ Vertex 4, the negative impact is significant, unfortunately). For my next SSD purchase, I will again compare the super-fast hardware encryption of the Intel 520 vs. SSDs that are able to cope to some extent with software encryption, although I am currently leaning towards the Intel 520.
I’ve written another post documenting my successful experience with r0m30’s open source TCG Opal configuration utility and PBA image.
Vincent Tenniglo sent in this article by AnandTech where Anand himself experiments with the TCP Opal 2.0 compliant Crucial M500 and the Windows 8 eDrive support. In theory, with eDrive-compatible drives (meaning Opal 2.0), Windows BitLocker makes use of the drive’s hardware encryption. Ed: Because this is Windows closed-source, we are unfortunately even less sure of what’s happening behind the scenes. It’s an interesting development nonetheless.
I’ve just purchased an Intel 520 SSD drive, which does hardware-based AES encryption of the whole disk, and is clever enough to encrypt the AES passphrase with the ATA / HDD password. This encryption implementation was my primary reason for getting this specific SSD. Many modern SSDs also employ hardware-based AES encryption for randomisation and for fast secure erase (they just reset the AES key!), but do NOT use the ATA password to encrypt the keys, so the encryption is far less effective at protecting your precious data. As far as my current information goes, the Intel 320, 520 and 710 drives do it correctly, as does the Samsung SSD 840 Pro and the Kingston SSDNow 200V+.
However, the AMI-BIOS in the Asus P5KC motherboard in my workstation does not support the ATA Security Mode Feature Set, and hence does not allow me to set the ATA password, or to enter the set ATA password at bootup so that the SSD can be unlocked. Enter the ATA Security eXtension BIOS, or ATASX, a piece of ROM BIOS code that you can add to your system or network ROM in various ways, that then gives you the required ATA Security Mode Feature Set components.
This post documents the exact steps I took to patch the AMI-BIOS of my Asus P5KC motherboard. If you follow these instructions, you do so entirely at your own risk.
I made use of method 2 for the AMI-BIOS, that is to integrate the ATASX as a PCI extension ROM, targeted at the boot room on the built-in network card, into a BIOS ROM image, which I could then flash on the motherboard using the built-in EZ-Flash tool.
The ATASX.ROM needs to be configured with the network and vendor id of your network card. Under Linux, I used “lspci -nn”, which returned “02:00.0 Ethernet controller : Atheros Communications Inc. Attansic L1 Gigabit Ethernet [1969:1048] (rev b0)” for the ethernet card. At the very end, you can see that the vendor id is 1969 and the device id is 1048.
Using bromcfg.exe (part of the ATASX download) in a dosbox (it’s a dos utility, and I only have Windows 7 64bit on my laptop, which can’t run dos EXEs) I loaded ATASX.ROM and entered the correct vendor and device IDs. I left the default passwords blank, and the default Ctrl-S delay at 1 second.
Downloaded the latest Asus P5KC .ROM file from the Asus support site.
Downloaded mmtool.exe, loaded the Asus P5KC.ROM file, selected the PCI Option ROM with the vendor and device ID extracted in step 1 in the RunLoc column, and then used the replace tab to replace it with the BROMCFG configured ATASX.ROM, see below for screenshot. Saved the new .ROM file.
Burn the mmtool-saved ROM with ASUS EZ Flash (Alt-F2 at boot). It should look like this:
After rebooting, make sure you have Enabled the “LAN Option ROM” in the BIOS, under Advanced | Onboard Devices Configuration, else ATASX.ROM will never get a chance to start!
At your next boot, you should see the ATASX CTRL+S message:
If you press Control-S on time, you should be greeted with the ATASX drive selection screen (the Intel 520 SSD is not installed yet, you’re seeing my Barracuda only):
From which you can select a drive and then configure various ATA Security related variables, such as the master and user HDD passwords, which is exactly what we were after:
Update on 2012-12-23
I’ve discovered one more caveat: ATASX unfortunately does not support drives in AHCI mode. AHCI mode can be faster than IDE mode, especially for multi-threaded disk access.
Update on 2012-12-01
I now have this working with an Intel 520 SSD. There is one caveat though: If your machine suspends to RAM (S3), the drive goes into its locked state. At resume, there is no secure way to supply the drive password, and so it remains locked. In many cases this means that S3 suspend-to-ram is not usable for password protected drives. This seems to be a common problem with desktops and also some laptops, as can be seen here on askubuntu, here on the intel communities, here on the ATASX forums, and here in the German C’T magazine.
The Motorola Atrix 4G, flagship phone about a year ago, is now a great budget option if you need an unlocked and high performance Android phone. An NVIDIA Tegra 2 dual-core 1 GHz processor, 1GB of RAM, 16GB of built-in storage, micro SD slot, front and back cameras, a 1950 mAh battery (!) and more can be had for an affordable € 260 here in the Netherlands.
However, Motorola has cancelled the plans to upgrade this phone to Android 4.0 (ICS), so it’s stuck with its stock Android 2.3.4. It’s a fine ROM with great battery life, but Motorola probably won’t even ship incremental updates or bug fixes. There are know problems with Google Search updates FCing on app drawer, and newer versions of Google Maps getting confused with the relative priority of the GPS or network positioning.
It would be nice to have some options. This post briefly summarises the steps I took to root and unlock the phone, and my first impressions of CyanogenMod 7.2. The specific version of the phone that this post deals with is 45.31.0.MB860.AsiaRetail.en.03.
Warning: You follow these instructions AT YOUR OWN RISK. If by doing this you manage to break or brick your telephone, or you invoke any other calamity, the responsibility is entirely yours.
To root the phone, take the following steps
Make sure your Windows installation has the Motorola USB and phone drivers installed. If you simply connect your phone with its stock ROM to the PC that you’re going to use, everything should be automatically installed.
Download fastboot from this XDA post, and unpack it in an easy to find directory, for example c:\moto\.
Download the preinstall image from this XDA post, and put the unpacked .img file in the same directory.
Switch phone off, then on again with the volume down button held down. After a short while the phone says fastboot at the top: Now press volume up, it should say “starting fastboot protocol support”.
In a Windows command window, in c:\moto\, type: moto-fastboot.exe flash preinstall preinstall.img
After it’s done flashing, type: moto-fastboot.exe reboot
The phone will reboot now.
Download the android SDK from here and unpack the archive. Somewhere in there you should find adb.exe.
On the phone, go to Settings | Applications | Development and activate USB Debugging.
Disconnect and reconnect the phone to your computer. Drag down the phone notification area, tap “usb connection” then select “USB mass storage”.
Now you’re going to root the phone, by typing the following at the Windows command prompt:
The previous command should drop you into a $-style unix shell to your phone. At the $-prompt, type the following:
After all that, reboot the phone. It has now been rooted.
Unlocking and CyanogenMod 7.2
That was the difficult part. To unlock, simply follow the instructions under “Unlocking the Bootloader with RSD Lite (Windows)” in this CyanogenMod install guide, making sure to use the “International Variants Only: Unlockable Bootloader”. Once you’re done, move on to the part “Installing the ClockworkMod Recovery” and then “Flashing CyanogenMod”, the “Method via Recovery”. It’s all pretty straight-forward if you stick to the instructions.
CyanogenMod 7.2 feels fantastically fast on this telephone, almost buttery. The fingerprint unlocker works much better than on the stock ROM, with the one caveat that you can’t have a pin-code-unlock backup. In other words, one unlock method can be active at a time. The battery unfortunately seems to drain quite a bit faster than with stock ROM. However, things seem to have become much better after one or two full charge-recharge cycles. Here’s my battery usage graph at about 29 hours after being taken from its charger:
It was disappointing to discover that although the camera and camcorder work, the camcorder in portrait mode does not correctly orient the stored movie. I have not yet been able to find a work-around for this.
The phone feels really fast. Together with the flexibility that CyanogenMod 7.2 and being rooted give me (zillions of configuration options! if the XDA hackers manage to get the leaked ICS ROM into more solid shape, that upgrade is a tap away!), the trade-offs are, for the moment, acceptable.