> After that, I’ll work on disabling the Intel ME

I don't know anything about PureOS and I've never seen coreboot in action, but this genuinely sounds like a selling point.

Intel HW without the dreaded ME would be super-nice.

PureOS is just a Debian derivative (which attempts to get FSF approval like some other distros).

Purism has been talking up their work on a free firmware and disabled ME for two years now. They haven't gotten anything working until now.

I like what they're trying to do, and (roughly) how. I bought a Librem 13 and received it a year ago. But my overall impression is that they just didn't have the familiarity and expertise they needed on the software and firmware (and not enough money to buy enough expertise). Thus the slow and long-stalled progress on the coreboot port, the very slow and still somewhat disappointing development of the touchpad driver (which was the only driver they had to do real work on), and the confused/misinformed promises about the ME for the first year or so of the project.

But there isn't an alternative that's better in all dimensions, at the moment.

Isn't the 2015 Pixel laptop a good fit except for the limited storage ? I'm guessing that it supports coreboot out of the box, probably has all drivers upstreamed, and has a great display. If there were a way to upgrade the storage, that would be the ideal laptop. Also, Google might release a new Pixel laptop this year too.

You're right about everything except all drivers upstreamed. I don't know what is taking so long to get drivers upstreamed, but us samus users have our own patched kernel: https://github.com/Raphael/linux-samus.

That's pretty bad. I thought Google was good with this sort of stuff. Is the delay caused because they were closed drivers, and had to be reverse engineered ?

I ended up RMAing 3 different 2015 pixels. The g+ group was filled with hardware issues (possibly an echo chamber; how many happy users were posting in hardware problems threads?). I really wanted the pixel to be a medium screen size with an i7 and 16gb of RAM, but it didn't stand up to being a daily driver for me.

I can confirm that pixel does use coreboot and has a backup seabios (also open source) if you want to use that (ended up being slightly easier to run arch via seabios).

It's not on this list: https://www.coreboot.org/Laptop

Does it even have a supported chipset?

I'm pretty sure that both Pixel laptops run coreboot. This page says so: https://www.chromium.org/chromium-os/developer-information-f... .I think Google is one of the major contributors to coreboot. I hope they release a full fledged laptop with expandable storage.

Can confirm, 2015 pixel is a great relatively linux friendly linux laptop running coreboot. Until recently the sound driver wasn't in the upstream kernel, but it is in 4.9 (but still isn't perfect).

But everything else is great.

Awesome. 'Tis pricey tho'.

see https://johnlewis.ie/custom-chromebook-firmware/rom-download... for various coreboot for x86-chromebook builds

I didn't know the Chromebook Pixels ran coreboot, that is indeed a very interesting option!

Does PureOS use grsecurity? It seems to suggest it in the FAQ on Purism's website, but does not say on the PureOS pages.

It kills me that every device I own has a secret RPC-capable OS running on it. Intel ME on my laptop, radio OS on my cell phone.

Why have hardware companies always wanted to bundle crappy software?

By "radio OS" I assume you mean the baseband controller firmware?

It would be nice if it was open source, but it's a bit more understandable than the Intel ME. The baseband firmware often has regulatory requirements the rest of the phones doesn't have. It comes from a different vendor, and is compartmentalized. I too would like it to be open source, but it seems like a different situation.

I'll grant there's an argument for requiring signed code for GSM-capable hardware on consumer devices; we don't want people accidentally turning their device into a jammer.

But:

1. closed-source driver code always has security holes. Having insecure devices is as bad for public policy as jamming.

2. if I really want to jam cell signals I can take the door off my microwave. (kids listening at home -- don't do this). Anyone who's ever flashed an android device will agree that it's easier to hotwire the microwave than build bootable code for the handset.

3. the radio controller runs a sophisticated RTOS that (I assume) can read the phone's RAM and execute wacky RPC. And most cellular networks have experimented in the past with some form of rootkit or spyware. Dear Verizon: I paid for the device. Let me own it.

One answer that compromises between consumer needs & FCC needs is to say signed code has to be open source and verified-build.

I'm guessing there's a lock-in argument for the radio chipset creator. Being the only vendor of software for your hardware means vertical integration, i.e. there are fewer companies expert in any part of your stack.

2. Microwaves are 2.4 GHz, and phones (except their wifi) is nowhere near. This should not work.

The regulatory requirements are bullshit. I can build out of spec transmitters in my garage. If I use one, I get in trouble with the FCC.

The requirements as they stand are nothing more than an excuse for shitty networks to spend less on reliability and security while providing a convenient backdoor for state-level actors.

It's much more likely that a ton of people start installing dodgy firmware they got off the internet than they start building jammers in their garage.

Imagine if such a firmware had a slider that boosts the transmitting power. People would love it but the network as a whole would suffer.

How difficult do you think it is to build jamming equipment? If you are technical enough to install new firmware, you can follow directions to block cell phone calls in your immediate vicinity. It just takes a Google search and a soldering iron.

Yes, but sometimes regulators mandate that firmware can't be changed by the user for example. So, while perhaps not better, I can see that it's a different situation that the Intel ME.

A question about me_cleaner: can malware simply re-enable it? Or does using me_cleaner "brick" the ME system permanently?

It removes enough parts of the ME firmware that it's stuck in whatever mode initialized by the ME's boot ROM (which is in-chip).

In principle it might be possible to upload code through an undocumented interface and get it to boot up later. Nobody (outside Intel) knows.