...does what it says on the tin. Read.
This evening I am having A Headache. It's an annoying headache; it's definitely a distracting headache; but it's "just" A Headache. No other symptoms that I'm noticing.
... except that it's Exactly The Right Time For A Migraine, and yesterday I had a bunch of migraine prodrome symptoms. (Being Too Warm. Wanting to close my eyes a lot. Nausea. Overwhelming despair.)
I find myself Wondering whether my regular menstrual migraines actually started on 1st January 2021, or if that's just the point at which symptoms tipped over into very obviously photosensitive migraine. At that point I was on continuous acute pain relief, and it is slowly dawning on me that An Annoying Headache with no other symptoms distinguishable from background noise (anxiety, depression, thesis-related stress, ...) is the kind of thing I'd have just merrily ignored, and for that matter that I'd still be ignoring if I weren't now Keeping A Headache Diary...
This is possibly my favourite photo yet of me playing ice hockey:
A lot of hardware runs non-free software. Sometimes that non-free software is in ROM. Sometimes it’s in flash. Sometimes it’s not stored on the device at all, it’s pushed into it at runtime by another piece of hardware or by the operating system. We typically refer to this software as “firmware” to differentiate it from the software run on the CPU after the OS has started1, but a lot of it (and, these days, probably most of it) is software written in C or some other systems programming language and targeting Arm or RISC-V or maybe MIPS and even sometimes x862. There’s no real distinction between it and any other bit of software you run, except it’s generally not run within the context of the OS3. Anyway. It’s code. I’m going to simplify things here and stop using the words “software” or “firmware” and just say “code” instead, because that way we don’t need to worry about semantics.
A fundamental problem for free software enthusiasts is that almost all of the code we’re talking about here is non-free. In some cases, it’s cryptographically signed in a way that makes it difficult or impossible to replace it with free code. In some cases it’s even encrypted, such that even examining the code is impossible. But because it’s code, sometimes the vendor responsible for it will provide updates, and now you get to choose whether or not to apply those updates.
I’m now going to present some things to consider. These are not in any particular order and are not intended to form any sort of argument in themselves, but are representative of the opinions you will get from various people and I would like you to read these, think about them, and come to your own set of opinions before I tell you what my opinion is.
THINGS TO CONSIDER
Does this blob do what it claims to do? Does it suddenly introduce functionality you don’t want? Does it introduce security flaws? Does it introduce deliberate backdoors? Does it make your life better or worse?
You’re almost certainly being provided with a blob of compiled code, with no source code available. You can’t just diff the source files, satisfy yourself that they’re fine, and then install them. To be fair, even though you (as someone reading this) are probably more capable of doing that than the average human, you’re likely not doing that even if you are capable because you’re also likely installing kernel upgrades that contain vast quantities of code beyond your ability to understand4. We don’t rely on our personal ability, we rely on the ability of those around us to do that validation, and we rely on an existing (possibly transitive) trust relationship with those involved. You don’t know the people who created this blob, you likely don’t know people who do know the people who created this blob, these people probably don’t have an online presence that gives you more insight. Why should you trust them?
If it’s in ROM and it turns out to be hostile then nobody can fix it ever
The people creating these blobs largely work for the same company that built the hardware in the first place. When they built that hardware they could have backdoored it in any number of ways. And if the hardware has a built-in copy of the code it runs, why do you trust that that copy isn’t backdoored? Maybe it isn’t and updates would introduce a backdoor, but in that case if you buy new hardware that runs new code aren’t you putting yourself at the same risk?
Designing hardware where you’re able to provide updated code and nobody else can is just a dick move5. We shouldn’t encourage vendors who do that.
Humans are bad at writing code, and code running on ancilliary hardware is no exception. It contains bugs. These bugs are sometimes very bad. This paper describes a set of vulnerabilities identified in code running on SSDs that made it possible to bypass encryption secrets. The SSD vendors released updates that fixed these issues. If the code couldn’t be replaced then anyone relying on those security features would need to replace the hardware.
Even if blobs are signed and can’t easily be replaced, the ones that aren’t encrypted can still be examined. The SSD vulnerabilities above were identifiable because researchers were able to reverse engineer the updates. It can be more annoying to audit binary code than source code, but it’s still possible.
Vulnerabilities in code running on other hardware can still compromise the OS. If someone can compromise the code running on your wifi card then if you don’t have a strong IOMMU setup they’re going to be able to overwrite your running OS.
Replacing one non-free blob with another non-free blob increases the total number of non-free blobs involved in the whole system, but doesn’t increase the number that are actually executing at any point in time.
Ok we’re done with the things to consider. Please spend a few seconds thinking about what the tradeoffs are here and what your feelings are. Proceed when ready.
I trust my CPU vendor. I don’t trust my CPU vendor because I want to, I trust my CPU vendor because I have no choice. I don’t think it’s likely that my CPU vendor has designed a CPU that identifies when I’m generating cryptographic keys and biases the RNG output so my keys are significantly weaker than they look, but it’s not literally impossible. I generate keys on it anyway, because what choice do I have? At some point I will buy a new laptop because Electron will no longer fit in 32GB of RAM and I will have to make the same affirmation of trust, because the alternative is that I just don’t have a computer. And in any case, I will be communicating with other people who generated their keys on CPUs I have no control over, and I will also be relying on them to be trustworthy. If I refuse to trust my CPU then I don’t get to computer, and if I don’t get to computer then I will be sad. I suspect I’m not alone here.
Why would I install a code update on my CPU when my CPU’s job is to run my code in the first place? Because it turns out that CPUs are complicated and messy and they have their own bugs, and those bugs may be functional (for example, some performance counter functionality was broken on Sandybridge at release, and was then fixed with a microcode blob update) and if you update it your hardware works better. Or it might be that you’re running a CPU with speculative execution bugs and there’s a microcode update that provides a mitigation for that even if your CPU is slower when you enable it, but at least now you can run virtual machines without code in those virtual machines being able to reach outside the hypervisor boundary and extract secrets from other contexts. When it’s put that way, why would I not install the update?
And the straightforward answer is that theoretically it could include new code that doesn’t act in my interests, either deliberately or not. And, yes, this is theoretically possible. Of course, if you don’t trust your CPU vendor, why are you buying CPUs from them, but well maybe they’ve been corrupted (in which case don’t buy any new CPUs from them either) or maybe they’ve just introduced a new vulnerability by accident, and also you’re in a position to determine whether the alleged security improvements matter to you at all. Do you care about speculative execution attacks if all software running on your system is trustworthy? Probably not! Do you need to update a blob that fixes something you don’t care about and which might introduce some sort of vulnerability? Seems like no!
But there’s a difference between a recommendation for a fully informed device owner who has a full understanding of threats, and a recommendation for an average user who just wants their computer to work and to not be ransomwared. A code update on a wifi card may introduce a backdoor, or it may fix the ability for someone to compromise your machine with a hostile access point. Most people are just not going to be in a position to figure out which is more likely, and there’s no single answer that’s correct for everyone. What we do know is that where vulnerabilities in this sort of code have been discovered, updates have tended to fix them - but nobody has flagged such an update as a real-world vector for system compromise.
My personal opinion? You should make your own mind up, but also you shouldn’t impose that choice on others, because your threat model is not necessarily their threat model. Code updates are a reasonable default, but they shouldn’t be unilaterally imposed, and nor should they be blocked outright. And the best way to shift the balance of power away from vendors who insist on distributing non-free blobs is to demonstrate the benefits gained from them being free - a vendor who ships free code on their system enables their customers to improve their code and enable new functionality and make their hardware more attractive.
It’s impossible to say with absolute certainty that your security will be improved by installing code blobs. It’s also impossible to say with absolute certainty that it won’t. So far evidence tends to support the idea that most updates that claim to fix security issues do, and there’s not a lot of evidence to support the idea that updates add new backdoors. Overall I’d say that providing the updates is likely the right default for most users - and that that should never be strongly enforced, because people should be allowed to define their own security model, and whatever set of threats I’m worried about, someone else may have a good reason to focus on different ones.
Code that runs on the CPU before the OS is still usually described as firmware - UEFI is firmware even though it’s executing on the CPU, which should give a strong indication that the difference between “firmware” and “software” is largely arbitrary ↩︎
Because UEFI makes everything more complicated, UEFI makes this more complicated. Triggering a UEFI runtime service involves your OS jumping into firmware code at runtime, in the same context as the OS kernel. Sometimes this will trigger a jump into System Management Mode, but other times it won’t, and it’s just your kernel executing code that got dumped into RAM when your system booted. ↩︎
I don’t understand most of the diff between one kernel version and the next, and I don’t have time to read all of it either. ↩︎
There’s a bunch of reasons to do this, the most reasonable of which is probably not wanting customers to replace the code and break their hardware and deal with the support overhead of that, but not being able to replace code running on hardware I own is always going to be an affront to me. ↩︎
succulent delicacy; I surmised that may be an easy utterance in ventriloquism too.
I had a little run of "brief meetings with old hockey friends" in the last two weekends. A few words, a hug, sometimes just a wave in passing while we both briefly occupied the same ice rink. All of them put a smile on my face.
Saturday before last was the Varsity matchup between Oxford Vikings A and Cambridge Narwhals at Cambridge rink, before my Kodiaks 2 team played visiting team Invicta Dynamics. Three of my tournament buddies from Biarritz were on the Vikings team. The next day Kodiaks were away at Bristol. I had an expected brief chat with my friend C from Hull camp but also complete surprise appearances from M who coaches Hull camp and goalie J, both of whom are tournament buddies. M was there with the away team for the previous game, J now lives in Bristol, which I theoretically knew but had forgotten.
Saturday just gone I had an evening game in Peterborough with Warbirds. I arrived a bit early and saw the previous game in progress: Phantoms Dev women were playing Streatham Storm Dev (my first ever hockey team). I recognised the jerseys first, and then a bunch of the faces. I dumped my kit in the changing room and went to lurk next to their bench and cheer them on for their last ten minutes. The timing worked out for me to see the end of their game (they won!) and walk with them back to their changing room before I needed to join Warbirds in ours.
... is a placeholder; apparently getting the bus to a hospital appointment today ate my entire brain, and I need to be up early tomorrow morning for a different medical appointment for a different body part in a different place. (Why am I being sent to get an ultrasound four stops down the Piccadilly line instead of five minutes up the road? A MYSTERY.)
Reading. Progress on my pile of tabs, mostly in the form of short stories! ( Read more... )
And finally Library Books In Progress:
Writing. I continue to eke out words. :|
Watching. One (1) episode of Farscape (S2E08), while bleaching A. It sure was a Farscape episode.
Listening. More Hidden Almanac! And also (see Reading) A Physical Education, Casey Johnston.
Playing. ... we are tentatively trying an Inkulati run with Exploders at max difficulty. It's... working? I'm suspicious about how well it's working (so far) (and I am also annoyed that I couldn't make my beloved foxes work this well).
Eating. Enjoyed discovering Kiernan's Coffee at Wimpole; particularly appreciated the cinnamon bun but the multi-inch stack of whipped cream on top of my hot chocolate was also extremely welcome (albeit messy). That was not my only ridiculous pile of whipped cream of the day; I also got Birthday Cake later on in the afternoon...
Exploring. Had a good poke around Wimpole on Saturday. Enjoyed the Walled Garden feat. nonsense petticoat daffodils out in force, and also bimbling round Home Farm, where there were sleepy Shires and tiny (squeaky) piglets.
Books on pre-order:
The release of the third Heated Rivalry book - which was only announced in January after the TV adaptation got wildly popular - is pushed back by eight months. I'm assuming this is to allow Rachel Reid more time to finish it and/or engage with the adaptation of the second book, The Long Game.
Books acquired in February: none (wow)
Borrowed books read in February:
It's been a really intense month, mostly with ice hockey commitments, so what reading I have managed has been entirely the ongoing Riordan read-through. Trials of Apollo successfully grows Apollo from intensely irritating in the first few chapters of the first book to someone I cried over in the last book. Plus I have now watched both seasons of the Disney+ adaptation of Percy Jackson and the Olympians and oh boy do I have Opinions, especially on the second season. They get a lot of details right, the casting is excellent, and yet they get the heart of the story so so wrong. (Will I still watch season 3 when it comes out? Probably! Maybe they won't mess it up as badly?)
Anyway. Onward into March.
[3] Physical book
mathematical engineering, it captures what I enjoy most about it. It's rewarding to devise and express good solutions. I love to create systems that do well at behaving in desired ways.
hey, you still have this bit unfinished, shall I do it?and I'm like,
no, let me!
Orientalis a rather Western-centric term for a region then
Middle Eastis no less so.
Both finals ended up being USA-Canada. Both finals I expected USA were more likely to win, actually wanted Canada to win, felt it was possible Canada might actually win for a majority of the game, only to have USA win in 3v3 OT. I didn't manage to watch either game entirely conventionally.
The women's final was on at the same time as Women's Blues "strength and conditioning" at the university sports centre. (The team gets an hour a week in term time in the Team Training Room, supervised by a personal trainer who's developed a programme for us to follow that's tailored to the needs of ice hockey. I love it, it's such a great perk of playing for the university.) My friend C and I arrived early and asked Will the PT to get the game up on the big screen, so we could follow it while we trained, and it was very exciting. A hardcore of about six of us then watched the last five minutes or so of the second period on a laptop at the end of the room, and then scattered at speed to bike to our respective destinations before the third period started.
The men's final took place while I was driving a large vehicle full of Kodiaks to Bristol (nine people: eight players with kits, one coach). My phone was paired to the car sound system, and I had the iPlayer coverage playing through it from our last pickup point (because obviously I didn't want to be messing with my phone while on the motorway). We had about half an hour of curling commentary that we only half-listened to, and then I turned up the volume for the game itself. With excellent timing, the game-winning goal was scored when we were a few minutes away from arriving at Bristol ice rink. I would still like to watch back at least the highlights of the game and actually see the bits of skating that had the commentators get especially excited.
| Sun | Mon | Tue | Wed | Thu | Fri | Sat |
|---|---|---|---|---|---|---|
|
1
|
2
|
3
|
4
|
5 |
6
|
7
|
|
8
|
9
|
10
|
11
|
12
|
13
|
14
|
|
15
|
16
|
17
|
18
|
19
|
20
|
21
|
|
22
|
23
|
24
|
25
|
26
|
27
|
28
|