Chameth.com - posts like g15-ram-upgrade, offline-gnupg-master-yubikey-subkeys but not debugging-beyond-the-debugger, why-you-should-be-using-https

Upgrading the RAM in a Dell G15 laptop

2023-07-29T00:00:00Z

The Dell G15

I currently use a Dell G15 laptop for work. It has served me well for a little over a year, but recently it has been struggling a little with my day-to-day workload. It came with 32GB of RAM — the highest possible specification at the time¹ — but that is apparently no longer enough for me.

For a recent project, I was working on a Rust library used in an Android app. That meant running the usual glut of Android tools (Android Studio, an emulator and at least one Gradle daemon) alongside a normal IDE (IntelliJ IDEA). Throw in a web browser and a couple of electron apps, and I often managed to use all 32GB.

When you start swapping memory out to an encrypted disk — even an SSD — it doesn’t make for great performance. At first, I tried to work around this by enabling the Linux out-of-memory (OOM) killer, but it turns out that it’s not too good with Electron apps: it will kill the large browser process, but then the small Electron wrapper will just respawn it.

Can it be upgraded or not?

The obvious solution to not having enough RAM is to add more RAM. A quick look in the manual showed this might not be possible, though. The manual includes the following “Memory specifications” table:

Description	Values
Memory slots	Two SODIMM slots
Memory type	DDR5
Memory speed	4800
Maximum memory configuration	32GB
Minimum memory configuration	8GB
Memory size per slot	8GB or 16GB
Memory configurations supported	8 GB, 1 x 8 GB, DDR5, 4800 MHz 16 GB, 1 x 16 GB, DDR5, 4800 MHz 16 GB, 2 x 8 GB, DDR5, 4800 MHz, dual-channel 32 GB, 2 x 16 GB, DDR5, 4800 MHz, dual-channel

That unambiguously says that an upgrade from 32GB is not possible. I gave up.

Later though, I was complaining about memory issues to a friend, and he pointed out a Dell forum thread where a couple of people claim to have successfully installed dual-channel 32GB modules. Since the alternative was getting an entire new PC after only a year, I decided to give it a go.

The upgrade attempt

I ordered a pair of Crucial 32GB DDR5-4800 SODIMMs, and after they turned up dismantled the laptop. The G15 comes apart pretty normally: there are uncovered screws on the bottom holding the lower part of the case on. With those removed and some gentle prying, it pops off, and you get access to the battery, GPU and motherboard.

The first thing I saw was this:

The G15 motherboard adamantly proclaiming that it doesn’t want 32GB SODIMMs

Not one but two labels that indicate it will only accept 8GB or 16GB modules. Oh well, what’s the worst that can happen?

Oops?

I dutifully installed the new modules, reconnected the battery and put the case back together. I pressed the power button, and… nothing. None of the usual garish lights that immediately come on, no screen output, just a dead laptop. After reading some more of the user manual, I found that there is a tiny status LED on the side next to the ethernet port. Forcing the laptop to power off and back on again, the status LED blinked a distress code at me: 2 amber blinks, 4 white blinks. The manual says that is — unsurprisingly — a memory fault.

I figured at this point that the manual and labels on the motherboard were probably right. I took the laptop apart again, reinstalled the original 2x16GB modules, reassembled it, and pressed the power button. It didn’t boot. I don’t spend a lot of time fiddling inside computers, but I’ve done it enough that I’m reasonably confident I can’t entirely break a computer while swapping some RAM modules. I took to Googling², and found an interesting article that said Dell laptops don’t like to boot after RAM changes unless you clear the CMOS by popping out the battery for 15 minutes.

I opened the laptop up, and looked around for the CMOS battery. There wasn’t one. Turns out they don’t exist any more. I left the main battery disconnected for a while to see if it would help, and it didn’t.

Unexpected success

I started to get worried: if I couldn’t fix this, I wouldn’t be able to work until I got a new PC, and that wasn’t really in my budget at the minute. I sat reading old forum threads and help guides³, none of which were actually useful. Out of nowhere, though, the laptop booted up.

Naturally, I immediately shut the laptop down again, opened it up, and switched back to the new RAM modules. Then I turned it on again and sat waiting. After about 15 minutes of it looking totally dead, it turned on and showed a BIOS warning about the hardware configuration being changed. It then booted perfectly normally, and all 64GB of RAM was visible and usable.

My theory is that the forum threads were right: Dell laptops are funny about RAM upgrades. But somehow in removing the physical CMOS battery, they’ve kept the same “you have to wait 15 minutes” behaviour just without any indication that’s what’s happening. Regardless, I now have enough RAM even for the greediest of IDEs and Electron apps.

Bizarrely, the maximum spec has decreased to 16GB since then. ↩︎
In the generic sense. I use Kagi these days. ↩︎
On my phone because, y’know, the laptop was busted. ↩︎

Creating an offline GnuPG master key with Yubikey-stored subkeys

2016-08-11T00:00:00Z

A pair of Yubikeys

I recently noticed that I’d accidentally lost my previous GPG private key — whoops. It was on a drive that I’d since formatted and used for a fair amount of time, so there’s no hope of getting it back (but, on the plus side, there’s also no risk of anyone else getting their hands on it). I could have created a new one in a few seconds and been done with it, but I decided to treat it as an exercise in doing things properly.

Background: GPG? Yubikey?

GPG or GnuPG is short for Gnu Privacy Guard, which is a suite of applications that provide cryptographic privacy and authentication functionality. At a basic level, it works in a similar way to HTTPS certificates: each user has a public key which is shared widely, and a private key that is unique to them. You can use someone else’s public key to encrypt messages so only they can see them, and use your own private key to sign content so that others can verify it came from you.

A Yubikey is a small hardware device that offers two-factor authentication. Most Yubikey models also act as smartcards and allow you to store OpenPGP credentials on them.

Introducing subkeys

GnuPG supports subkeys, which provide fairly significant security advantages. Instead of just having a single public and private key, you have a master pair and then any number of subkey pairs. The subkeys are automatically associated with the master key, but they can be revoked independently.

Having a master key fall into the wrong hands is a problem — you have to revoke the whole thing (assuming you have access to a revocation certificate) and start again, convincing everyone else that your new key is the “real” you. With subkeys, you can issue a revocation signed with your master key and then sign some new subkeys. There’s no loss of trust, and as long as people refresh your key from a keyserver, everything carries on as normal.

The other advantage to using subkeys is that you can keep the master key elsewhere. It doesn’t need to be routinely accessible, and using it doesn’t require access to the Internet. The master key is kept offline, significantly reducing the risk of anything bad happening to it.

Setting up a secure environment

My main desktop runs Windows, and most of my other devices are work ones which come with automatic backups and network mounts that I don’t fully grok. Neither of those is a particularly good option if I want to do something security sensitive.

Tails is the defacto choice for a secure, live linux system, so I went through their installation process and eventually ended up with a USB drive that can boot into Tails. The installation process from Windows is slightly convoluted, as it involves creating a bootable Tails image, then booting to that and using the Tails installer to create the real image on a different drive. If you’re starting on a Linux box, you can just use the Tails installer directly instead of doing the two-drive shuffle.

Just to be completely paranoid, I disconnected my PC from the network before booting Tails. This is known as air-gapping, and is done to eliminate the possibility of a remote attacker doing something to your system. Ideally the machine never would have been connected to the network, but I didn’t happen to have an unused machine laying around.

The final thing I needed was a secure place to store my master key. I opted for an IronKey — a hardware-encrypted USB drive that self-destructs if there are too many unsuccessful attempts to access it. It works out-of-the-box on both Windows and Linux, presenting a small unencrypted drive with software to run to interact with the secure partition.

Creating the keys

Now I had a nice over-the-top setup it was time to actually the keys. There is an excellent guide by Simon Josefsson that walks through the entire process of creating the master key, creating three subkeys, and then transferring them to a Yubikey.

The only point where I had to deviate from Simon’s guide was setting the machine up to work with the Yubikeys. I was setting up two keys (a nano and a neo), and one just worked out of the box with the version of libykpers-1-1 that was in Tails’ apt repository. The other needed a slightly newer version but that was also available in apt and can be selected by specifying the version manually as pointed out in this GitHub issue. The version numbers have since changed, but apt-policy makes it easy to figure out what’s needed. As I was using an air-gapped system this process was a bit more complicated than it sounds, involving several USB drive transfers.

After finishing the guide, I had my master key and a pre-generated revocation certificate stored securely on my IronKey, and the three subkeys stored on each Yubikey. Time to go back to Windows.

GPG, Windows and SSH

Now with the IronKey disconnected and the master key out of harms way, it’s time to go back to Windows. I downloaded the GnuPG Modern distribution and followed the instructions at the end of Simon’s guide to import my public key and make GPG aware of the subkeys on the Yubikey. After that Enigmail was able to sign and encrypt e-mail in Thunderbird.

XKCD #979: Wisdom of the ancients

Next up, I enabled PuTTy support and started the GPG agent, as documented over on Yubico’s site. This allows you to use the authentication GPG key to authenticate SSH sessions from PuTTy. To find the SSH key you need to add to .authorized_keys, simply run gpg --export-ssh-key. At first I could SSH into a host but not use agent forwarding. After lots of unsuccessful Googling, I realised that GPG couldn’t access the key anymore locally. Another quick search and I found a forum thread where someone had the same issue and found it was a problem with exclusive access to the card. They even passed on their wisdom and updated the thread with a solution, which got everything working for me.

VMWare

I have a Ubuntu image running inside VMWare on my desktop that I use for most development activities. I’m unlikely to want to sign e-mail, but I probably want to sign commits (especially now that GitHub exposes verified signatures).

To do that I need to pass the Yubikey through to the virtual machine. In its default configuration, VMWare recognises the Yubikey device but doesn’t pass it through correctly. You need to configure it to allow HIDs, after which gpg --card-status starts working from the VM.

Unfortunately passing through the device makes it exclusively available to the VM so the host OS can no longer use it. As I have two Yubikeys, I just configured VMWare to ignore the nano key that’s always plugged in, and pass through the neo when I plug that in. While swapping the configuration around, I found out that GPG remembers the ID of the smartcard that store credentials - if you swap the two keys with identical subkeys it demands the other one is reinserted. You can get rid of the references to the previous card using gpg --delete-secret-keys.

In conclusion…

… I have a new PGP key you can use to verify things I sign or encrypt messages to me.