New motherboard – Arch Linux tweaks and tips

So, I changed out my motherboard to an Asus B500-I ( https://rog.asus.com/motherboards/rog-strix/rog-strix-b550-i-gaming-model/ ), so this page will serve to document some of the tweaks I have done to get it working on Arch Linux.

Audio

The motherboard comes with an ALC1220 chip. It was necessary to add options snd-hda-intel model=dual-codecs to /etc/modprobe.d/alsa.conf to get the soundcard working.

I have also noticed that hotplugging a headset still does not work, the headset does not get detected as an audio sink. So I either have to log out of gnome, and re-login to reload the modules, or do the following for the headset to get detected if it is not permanently plugged in:

rmmod -f snd_hda_intel
rmmod -f snd_intel_dspcfg
modprobe snd_hda_intel

Sensors

The motherboard comes with a Nuvoton nct6798 chip. The chip was picked up by sensors-detect, but I had to add acpi_enforce_resources=lax to my kernel boot options for the sensors output to work.

More to come…

As I get more features working with this motherboard, I will revise this post.

Linux life: using the built in encryption of solid state disks

Introduction

This post has been sitting around in my drafts for about a year and a half. I have since abandoned this solution, preferring to encrypt my home partition only. But if someone finds it useful, I’ve published it here.

Background

Most solid state disks nowadays proudly claim that data is encrypted in the controller before being written to disk. But if no ATA password is set on the disk, then that encryption is not really of much use. All it does is prevent someone from disassembling your SSD and reading the data off the flash modules without the controller, and ensuring that a secure erase can be performed quickly. This is not much use for me, as I was trying to guard my data on my laptop against theft, while not compromising on performance.

One vital part of a proper security system is protecting “data at rest”, i.e. preventing data on your laptop from being accessed if it is lost or stolen while turned off. For this, Full Disk Encryption (FDE) is generally the best solution, but if your CPU does not support AES-NI, then implementing FDE on the operating system level can cause throughput to be painfully slow (around 40 MB/s through the encryption pipeline on my AMD E2-1800), and CPU intensive. Not ideal for a laptop, and having spent all that money on an SSD, very annoying to have to compromise between speed and security. Step forth the SSD controller, a small chip on your SSD that manages the interface between SATA and flash modules. Samsung’s newest SSDs use a triple-core ARM controller, so wouldn’t it be cool to offload responsibility for FDE to this controller, since it is already doing it?

Leaving aside issues of whether to trust your SSD vendor’s claims about a proper keychain of trust, I at least wanted to use the provided encryption of my solid state disk. The big problem I faced though was that my BIOS did not support setting an ATA password, nor did it support unlocking an already set ATA password (ATA passwords can be set and unlocked using hdparm on linux. But make sure you can boot a live USB disk to unlock it again if your BIOS turns out not to be able to unlock it, otherwise your system may be unbootable).

Solution

After a bit of thinking, my solution turned out to be:

-Ensuring my computer could boot a USB disk if the SSD was locked (check boot order in BIOS)

-Prepare a USB disk which would boot, run hdparm, ask for the password, unlock the SSD, and hand over to the linux installation on the SSD. Henceforth called the drive-unlock-stick (DUS).

-Set the ATA password on my SSD.

-Verify that the setup worked (it does)

-Test for additional problems caused (one big one: Suspend to RAM does not currently work properly, described below)

Preparing the “drive-unlock-stick” (DUS)

Firstly, consider that you will need this disk every time you boot your laptop. Either, you could use this opportunity to implement a form of two-factor authentication (to boot you need both the DUS and your password), or find a USB disk small enough that you don’t mind leaving it in your computer. I chose the latter, and for the added performance benefits of USB 3.0, bought a compact USB disk off amazon.

The DUS must be bootable, so set up syslinux. This involves making sure that the partition on the DUS has the bootable flag set (check with fdisk for example), copying the syslinux MBR onto the DUS, installing the syslinux bootloader, and writing the configuration file.

Next thing you need is a linux kernel and an initial ramdisk environment in which to run hdparm. I’m using Arch linux, so I scripted a hook that would load the drivers to interface with the disk (ahci in my case, but check using lsmod), load the drivers to eventually read the filesystems of my boot and root partitions on the SSD, ask for the password from the user, unlock the drive, do a bit of magic by unloading the driver again and reloading it, freeze the drive security, to prevent setting another password in the operating system, mount the boot and root partitions of the SSD, and hand over control to the original linux kernel on the SSD through a kexec call, from which point normal booting continues. This requires some work to get right, and my current solution still spews a lot of errors when the ahci module gets confused, and I think it has a 5 second timeout somewhere that slows it down quite a bit, but it works.

Since writing this post back in 2013, I seem to have lost the configuration files. But the above descriptions seem to sum the method up nicely.

Linux life: Syncing iPhone with iTunes on a virtual machine

This post is a bit different from my previous posts, but I thought it was interesting enough to post, and it might help someone in the future.

The issue at hand is to get music onto my iPhone 4 running iOS 6, using only a Linux machine. Unfortunately, the iTunesDB on the phone is encrypted on iPhone 4 and up, and the excellent libgpod  team have not been able to reverse-engineer it yet, so USB syncing of music is not possible natively on Linux. From this there are two obvious workarounds: jailbreak your phone, and use some of the programs available on Cydia to enable adding music to the iTunesDB, or somehow get your iPhone talking with a real iTunes installation.

I chose the second option, but iTunes does not work very well on wine currently, so I chose to install windows on a virtual machine. I had a Windows 7 OEM license bundled with the laptop, so I set up Virtual Machine Manager and Qemu, and installed iTunes on top of this. This works very well with the RedHat virtIO drivers for networking and virtual storage, highly recommended.

To allow the iTunes on my virtual machine to see my music stored on my linux box, I set up a Samba share, restricted to the virtual network. iTunes 11 no longer has the option to add an entire folder to your library from the menu, but you can still drag and drop folders from Windows Explorer into iTunes, which took a while, but worked.

I was able to get USB passtrough to the virtual machine working  for a short while, long enough to get the iPhone recognised in iTunes, but this was painfully slow. I ticked the box for enabling wifi sync in iTunes, and left it for the next day.

The wifi sync feature requires a Bonjour connection between iTunes and the iPhone, but unfortunately Bonjour cannot bridge from the virtual machine over virtIO, and the other virtual network devices I tried did not work well. Finally, i found mdns-repeater a small program that does exactly what I want: it runs on my Linux machine, and forwards Bonjour packets from the virtual network between the host and virtual machine, and the wireless network on which my iPhone and Linux host are both connected. Using this, iTunes and the iPhone can see each other, and I am syncing with around 10 Mbit/s, much faster and more reliably than with the USB passtrough solution.

If anyone finds this useful, feel free to ask questions if you need a step or two fleshed out. I’ll be happy to help. 🙂