My notes on the Spectre / Meltdown vulnerabilities


I will spare you the gory details and leave you to read that stuff from the experts. Here I will simply document my thoughts and reactions to the news as it comes out.




Impact on Librebooted machines


Before this all hit the news wire, I was mostly running Librebooted ThinkPads in my fleet. My daily driver was an X200, and I had been using a T400 as a “home server” of sorts, mostly because it was less portable than the X200. These had all been converted to run Libreboot, as per the documentation. This is all well and good, I am a huge proponent of modifying corporate products into personalized projects, and Libreboot fits that bill nicely. However, one of the stated goals of the Libreboot project is to remove microcode updates from the BIOS. Generally, this might be a good thing, if you’re the type of person that doesn’t fully trust the proprietary binary BIOS. To be clear, the Intel Management Engine is something worth disabling, if you can, simply because it is a highly flawed and inauditable system beyond your control. Even if it wasn’t intentionally malicious, you are prevented from fixing or finding any flaws in the system without jumping through flaming hoops and voiding warranties left and right. There has got to be a better way…


Fast forward to January of this year, and the SpectMelt vulnerability rocks the cyber-security world. This is a set of hardware flaws unlike anything we’ve dealt with before. Patching on the software level is akin to putting an “adhesive strip bandage” (avoiding brand-name identification when possible) on a compound fracture. The hardware design is fundamentally flawed. All the software patches in the world will not fix this, and at best we are hoping for is mitigation of the flaws, temporary workarounds that themselves will probably have holes and bugs. This problem is not going away anytime soon.


My reaction was to just get rid of all of the Librebooted machines and replace them with less-flawed devices of some sort. Perhaps this is a bit of an overreaction. What do I have to hide? What am I worried about? Am I a target of any sort? Not really, at least I don’t think so. For me, personally, it’s the principle of the matter. If Intel (and AMD/ARM) are going to hoist flawed chips onto us in the hopes that we’ll swallow the pill, then I for one would rather just excuse myself from the drama. If I am not running chips with that flaw, then I don’t have to spend time thinking about the patches or the performance hit that the patches tend to provide.


I’m not paranoid (at least not in this instance). I am simply not interested in being a guinea pig for the cyber-security ePocalypse (TM) that is unfolding around us. Personally, I’d rather just run a slower and simpler CPU than run a power-hungry and backdoored CPU that has been shackled and hobbled to run slower than intended anyway. Besides, in the eternal words of Joseph Heller, “Just because you’re paranoid doesn’t mean they aren’t after you.”




The search for a “more secure” CPU


A quick search around the web revealed that not all CPUs have this inherent flaw of design. This page has been a reliable resource, mostly because of the citation links to vendor pages. Of notable interest to me are the following processors:


  • ARM Cortex-A53 MPCore


  • Early Intel Atoms including S/D/N Series: {Diamondville, Pineview, Cedar View}


  • RISC-V {Rocket}


There are others on the list, as you can see at the link above, however these ones jumped out at me as processors that I might be able to easily get my hands on and start using in a practical way. Okay, maybe not RISC-V just yet, but it’s on my radar, for sure.


Is your phone vulnerable? At the time, I had a Samsung Galaxy Note 2 that I was running Replicant on. Well, the Note 2 has a Quad-core 1.6 GHz Cortex-A9. According to ARM, this CPU is vulnerable. Time to downgrade the phone, too!




New hardware acquisitions


  • ASUS EEE PC 1025C (to replace X200)


  • FriendlyARM Neo Core2 (to replace T400)


  • Nokia 3310 3G (to replace Note 2)


  • Pinebook64 (possible future purchase)


  • EOMA69 Numero Uno (already funded, patiently awaiting)




ASUS EEE PC 1025C


Having fond memories of my long-dead ASUS EEE PC 900HA, I went looking around for a netbook with an Atom processor from the S/D/N series. A quick look at Wikipedia helped me narrow my search down to the Cedar View series, having a few more features than either Pineview or Diamondville.


My first EEE went on many adventures with me (including to the depths of the Peruvian jungles and back), and was also the very first machine I was able to run a fully free OS on, because of the default Atheros Wi-Fi card inside. At the time, it was ConnochaetOS, which I’ve mentioned previously.


I was able to score a used ASUS EEE PC 1025C on eBay for around $60. I resigned myself to the fact that I would be running at 32-bits on 2GB of RAM. Low resource computing is something I’ve grown fond of, for several reasons. It appeals to my eco-ethics, which will emerge through this blog eventually. This particular model featured an Intel Atom N2600, only to be outdone by the N2800 in terms of clock speeds (CPU, GPU, RAM), which also comes at a cost of higher Thermal Design Power (6.5W vs. 3.5W for the N2600). Not too shabby for $60 with free shipping. I figured it was worth the investment.


Staring at the CPU spec sheets though, I couldn’t help but notice that these chips supposedly support Intel64. “So, why am I running a 32-bit operating system?”, I asked myself. After poking around on the ‘net a bit, I found this thread:


https://www.bios-mods.com/forum/Thread-REQUEST-Asus-eeepc-1025C?page=2.


It turns out that, with a modded BIOS (admittedly not libre in any way, just a warranty-voiding hacker-mod), I can flip on the 64-bit switch on the CPU and also install some new microcode. I’m guessing, in this case, the microcode is more about flaw-fixing than backdoor-introducing, because these Atom processors do not have any sort of Management Engine to enable in the first place. If I’m going to load microcode, doing so on a dumbed-down CPU (relatively speaking) feels safer than trying to patch holes in a CPU that was designed to have backdoors in the first place.


As a result, I’m back to running FreeSlack64 (or Freenix, or FXP, or whatever) on this thing, my desired OS. Reading the thread above, I noticed that a similar mod can enable 4GB of RAM on the N2800. Darnit. That’s a good reason to keep my eye out for an N2800 then. 4GB of RAM on one of these would be oh so sweet, although with a switch in Desktop Environments (from my usual Xfce to Openbox), the 2GB RAM overhead hasn’t been an issue unless I’m trying to build a package from source with multiple threads while also browsing the ‘net and answering emails. At that point, 2GB of RAM starts to become a bit limited for my needs. So, I just wait to build software when I’m not also browsing the web. Problem solved, for now.




FriendlyARM Neo Core2


Featuring an ARM Quad-Core Cortex-A53, this kit seemed like just the thing I needed to play the role of a torrent-box, music-server (with a 3.5mm jack), Monero-node (using a 128GB M.2 SSD in the SATA slot), and eventually an I2Pd router (or Kovri, if I can get it to build easily) once I get the configuration worked out. So far so good, expect updates once I get the 2A power supply that I am waiting for.


It is worth noting that the swtich from the provided OpenMediaVault image (based on Debain) to Devuan went really well for the basic instructions. On the other hand, the minimal instructions left me unable to SSH back into the Neo, so I figured the standard migration process was enough. Not only am I running this thing without systemd, but vrms -e tells me that rms would be proud. Nice.




Nokia 3310 3G

I was getting burned out on my “smartphone”. I just find the touchscreen interface combined with the “mobile” browser-based experience to be very frustrating. Plus, my phone would randomly reboot when browsing the web or taking photos. I’m sure the hardware people would blame it on the software (Replicant not being officially supported by any hardware vendors), while the mailing lists I’ve read suggest that it might be faulty hardware.


Wow, all of this just to make phone calls and texts? I mean, is this a phone, or a computer, or a camera, or what?!?! What ARE these shiny polished robot turds that we are all so obsessed with? Think about it. If we were living 100 years ago, and someone pulled something expensive and shiny out of their pocket to stare at several times a day, what would it be? A WATCH! A pocket watch. That’s what a shiny polished robot turd essentially is! I’ll bet most of you use your “phone” much more often to tell what time it is than to make voice calls. It’s not a phone with a clock on it, it’s a watch that makes phone calls! These things are modern day pocket watches. They just happen to be network connected and multimedia-enhanced. However, I argue that they play the same social role that pocket watches played for a very long time. One example: price (or lack of ownership) is a marker of social class. The newer “smartwatches” only back up my claim even further. Anyway, I digress, yet again…


I figured I didn’t need my S.P.R.T. to track my every movement and provide a full-blown web experience. Why is that a standard? How about a dedicated device for making calls and texts? I’ll do the rest on a laptop at least, thank you very much. I’m a sucker for keyboards, I guess that makes me a relic.


Anyway, since my fingers like buttons, I tried to find a good “candybar” phone. I almost went for a classic Nokia 3310, before I realized it didn’t work with my current T-Mobile plan (wrong frequency). Then I realized they released a 3G model last year in the spirit of the original 2G model. I found one for around $37 with free shipping, so it seemed like a good way to downgrade to an actual phone that wouldn’t frustrate me so much. It has buttons, actual buttons, and I never need to touch the screen for any reason. What a concept!


The specs list a MediaTek MT6260, which includes an ARM7EJ (ARMv5), which is a “safe” ARM chip. Yay.


The phone is a tiny bit buggy, especially if you text a lot. Whatever, who cares, it’s just a phone, anyway. At least it doesn’t have GPS or a forward camera or any of that other built-in spyware crapola. I treat it like a phone, and I barely use the built-in Opera browser at all, because it serves up ads on a tiny little screen. This way, I barely touch my data usage, and I also have a really long battery life. So, it’s maybe a bit more than a dumbphone, a sub-smartphone. A SubGeniusphone, if you will. (insert SubGenius Salute here)




PineBook64


This looks like a slim netbook based around the Pine64 SBC, which itself runs a ARM Cortex-A53, which is on the “invulnerable list”. There are two models, both around $100. The price is right. If I get an itch for something to accompany my EEE 1025C, this might be something worth looking into.




EOMA68 Numero Uno


Featuring an Allwinner A20 (which includes an ARM Dual-Core Cortex-A7, on the safe list), and running Devuan, this will be a nice little desktop to hook up to a keyboard and VGA monitor. Can’t wait.


Eventually, if the standard becomes a success, we can expect second generation cards with RISC-V -based “Shakti” processors. That will be an entirely new ballgame. Keep your eyes peeled for the Shakti processors.




Final Thoughts


Have I eliminated all of the flaws from my computers? Am I now running perfect systems that cannot be compromised? Is this the final solution? Of course not. It would be silly to think so. Bugs linger, vulnerabilities lurk, and the road to perfection is never-ending. However, just the mere fact that I’ve switched to simpler processors that had less instruction sets to begin with is a good indicator I think. A less complex processor is going to have less flaws than a more complex processor. The more instruction sets a CPU has, the more of those that can lead to potential flaws. This is where Reduced Instruction Set Computing (RISC) comes in. this is going to be the road forward. Just check the 12th CVE on this list to see the writing on the wall.


Overall, I actually made a tiny profit from the “Great CPU Switchout of 2018”. By selling of the highly coveted Libreboot-able ThinkPads and the Note 2, I was able to buy everything on my list, including all the peripherals, plus pay for shipping both ways, with a tiny bit of change left over. So, this excersice hasn’t cost me anything in the long run. In fact, I have a bit of pocket money to spare.


I did a quick comparison of several machines I have access to currently, using the Spectre-Meltdown checker script found here:


https://github.com/speed47/spectre-meltdown-checker


Here are the results, in screenshot form. All of the important info is listed with each image.


Image

AMD E-350 running Ubuntu 16.04 with latest updates.


Image

Librebooted T400 running FreeSlack and no microcode updates at all.


Image

Atom N2600 running FreeSlack and latest microcode updates.


Image

This is using the Feb-20-2018 PureOS image with intel_microcode upates on the same Librebooted T400 as above. Even more vulnerable!


Image

AMD Phenom II running Slackware proper. All clear! Seems like the mitigations are working correctly here.


Image

Arm Cortex-A53 running Devuan. Looks good, despite not much kernel support for the script, it seems.




To post comments to this page, email me directly via this link, and I will post relevant comments to this page upon the next site update.


If you like what you have read, please consider donating through one of the links in my footer (ShapeShift for cryptocurrencies and Liberapay for fiat), or by leaving your browser on my XMR mining page for a short while. Thank you!