actually no. they do have a very transparent roadmap laid out pretty clearly. no one actually thinks it’s a 100% buletproof machine. not even the newbies.
and even when they actually reach the point of a perfect machine - it would still be insecure because nothing is unbreackable.
the librem machines are the only modern machines that come with a dedicated gnu/linux OS for the hardware preinstalled thus they have that premium.
Sorry for assuming you actually read the article before linking it here.
You did not care to explain how the vulnerability gives you unexpectedly more power than the coreboot-update utility Purism provides.
So, basically you referenced a CVE for dramatic effect.
Nothing really can.
But when PureBoot leaves beta (by shipping devices in separate packages), it can at least give you the same level of trust that a locked-down firmware (with source and reproducible builds available) gives you, while retaining freedom.
But the main point you’re trying to make is that Purism should
The first will not happen, but the second might be worth consideration.
Sorry to crash your party but it’s not. System76 does it, ThinkPenguin does it.
Flashing a malicious ME payload, such as one that will allow remote access is one of the scenarios.
Watch what you can do, as:
And stop talking about Pureboot as some kind of a silver bullet, Purism had nothing to do with Heads,
and if you so much like Tramell’s work, read his (correct) tips for further hardware hardening:
Soldering jumpers on WP# pins, setting BP bits, epoxy blobs.
Yes, exactly, not leaving an additional software attack surface as a “freedom feature”.
Even if Purism shipped the machine with a WP flash chip, who’s to prevent a skilled attacker from simply removing any hardware protection mechanisms, flashing their own firmware and putting the temper protection back? With enough dedication, even a epoxy blobbed chip can be desoldered and a new one put on complete with a new epoxy blob.
It would be better than shipping without WP as it protects the end user from software flashing attacks. The mobo could have a hardware button or jumper to disable WP for the short time the user wants to do a firmware update. Still, if the software is compromised at that time, the flash image could be altered as it’s being written to the chip. One could boot from a live USB drive with only the flashing tools on it to protect from that, and ideally the flashing disk would be created on a different machine. But for a start, enabling WP on shipped machines and having a button to disable WP before flashing would be an advantage.
I’m not sure if there’s a way for Purism to load their own signing keys into the processor itself, I thnk only Intel and OEMs have a way to do that. But then only binary firmwares supplied by Purism could be used, and that has its own issues of one single point of compromise at Purism.
That’s why they won’t do it.
Read how PureBoot works. For this, you would need to have physical access to both, the laptop and the key.
That’s why they intend to ship them separately.
Well researched, as always.
Yes, besides ‘git clone’ and a nice blog post about how they made it possible. Apparently they are good at that.
I forgot about the Key. That’s much better. Still, they could both get intercepted by e.g. customs at the destination country. You’d need to ship the Key with a different shipping provider, preferably disguised as normal mail from someone else, in a normal envelope so customs wouldn’t intercept it.
You’re on to something big I think.
Leak it to the press how you discovered that a git clone disproves collaboration and financial compensation.
Hudson will be furious when he discovers how his good name was used without him ever knowing.
How long has this fraud been going on before you opened our eyes? Two years?
Wow. 
I’m still undecided whether you’re just trolling or you’re an actual customer who has no problem to damage the reputation of a company for being too lazy to do actual research.
But the way you avoid giving details and tagging a knowledgeable staffer somehow hints you’re more interested in heated discussion than factual answers.
Precisely. Well said @Caliga.
Furthermore, a small aside partially relevant to this thread based on a previous comment, Purism is not trying to be the ONLY company doing anything. They hope to spur a host of competition that helps to champion their goals.
they do but not like Purism does it. also librem 5. also PureOs. also PhoSh. also hardware switches. also anything that helps to further the gnu/linux ecosystem and bring software freedom security and privacy into the general public attention.
as Caliga says - what are you really trying to say ? would it be better if we didn’t buy Purism goods at all ? or if Purism didn’t exist at all …
I didn’t know a vulnerability report will end up a fanboy party off topic. Enjoy.
A “vulnerability report” 
It’s really hard to take somebody serious who
You off-topic yourself by not following up on attempts to actually answer the question you posed.
In case you forgot, your question was:
Why do Librem laptops ship with Manufacturing Mode enabled?
tried to bring you back on topic:
And this is where it becomes clear you’re not looking to have an actual conversation on any topic.
It doesn’t take much effort to look at the commits / pull requests for coreboot, Heads, etc and see that while Purism maintains our own repos for many projects out of convenience, we also push as much of our work back upstream as possible, and work with closely with those projects to advance common goals (the UI Interface for Heads was done by Purism, eg). Claiming as you do that we simply clone and blog is dishonest at best.
Why, because I am not talking like some unpaid fanatic shills around here?
This is my right to have this opinion and this by no means changes anyhow the idea of this topic.
You know exactly what I mean by saying that, it’s enough to take a look at most Pure[name] rebrands
to know that just changing a few minor things and changing the project name is also dishonest at best.
Sometimes it can make people think that Purism is entirely behind the development - look how many
people around here say “Wow, they have their own OS, they have their own Browser, they have their
own name it” kind of thing, which makes me smile.
Care to address the elephant in the room?
you have the right to your own opinion, you don’t have the right to your own facts. Your facts are wrong about Heads, which is specifically what I was addressing, given the topic of this conversion
To the best of my knowledge, a disabled/neutered ME is not exploitable in the ways described in PT’s blog post linked in the OP, because there is no way to interact with it from userland, even with escalation. There’s no PCI interface, no HECI interface, and no way for FPT or any of the other tools mentioned to query or change any settings of the ME (I verified this on one my my Librems earlier today). One would need to flash custom (AP) firmware which does not enable the HAP bit, enables the ME/HECI interface, and which contains non-neutered ME firmware for any of this to be an issue. And if an attacker has managed to flash custom firmware on your device, then the ME Manufacturing Mode not being closed isn’t really your problem.
Fusing the OEM pubkey hash isn’t a feature available on shipped Librem laptops, notice the article is referring to specific newer platforms on which this feature was added. We also don’t do signed firmware updates, because that would prevent the user from running their own firmware on the device (vs Purism’s official release).
Next time, try with less arrogance.
It will pay out in the long run. Trust me.
Again, as I explained, an open Manufacturing Mode has nothing to do with disabled ME. Yes, the CVE
and technique are regarding ME, but we will touch it later.
The idea behind the attack is to flash a new BIOS image, just like one would do from:
Now, instead of flashing your version of clean_me (with -S) flag, I take the full skl/kbl image +pre-2018 ME and flash it along. By that we both enable ME and downgrade it to the vulnerable version, including old Microcode.
So we have now a malicious BIOS+enabled exploitable ME+exploitable pre Spectre/Meltdown microcode.
If you want to leave ME out of this question, fine, just a custom malicious BIOS+exploitable microcode.
Less persistence but at least without the ME confusion.
The attack surface here is not ME itself, we just may use ME later for persistence and other malicious things.
A vector like this means leaving the BIOS flashable from any privileged software in the OS, when the attacker
can flash a malicious BIOS and then fuse the chip with the malicious code - similar to ifdtool --lock.
After that the user is left without an option to install a clean Coreboot.
Remember that when you provide the user with a simple way of flashing a clean ME and blob free BIOS,
which is good and not many vendors offer it, fair enough, you also leave a way for the attacker to
flash anything bad and with unfused chip (MM) it’s a race of who will persist first.
Here is when freedom is a sword with two sides, and it shouldn’t be that way.
It’s a weird way of saying “sorry for needlessly complicating the matter with an unrelated vulnerability report”, but I’ll take it.
You’re now basically saying what I said in post #4:
@Caliga
You definitely showed that you have no capability of understanding how to chain attacks and make PoCs.
Calling an attack scenario unrelated because it’s part of the chain shows some level of incompetence.
We understand it, and your opinion here is largely irrelevant, it’s for the real devs and not forum celebrities.
Keep it coming, I begin to enjoy
When I asked for that chain in #2, it didn’t really look like you already had one in mind.
Now you paraphrased the one I had in #4, which actually contains your CVE trick.
Look. If somebody gains root access, you’re ******* DOOMED.
And if the machine grants you the right to overwrite the BIOS, you OWN the boot process and the CPU firmware already.
It’s really cute to have a trick to do some restricted stuff from OS level, but when you’re already in god mode, it’s really just sugar coating.
As you have to reboot anyway after flashing the ME enabled firmware, you can execute whatever you want during boot time, before EOP.
After you executed this already almighty power, you can then go ahead and use the CVE to …
an attacker who sends these two HECI commands opens the ME region and can write arbitrary data there, without having to reset the platform as a whole.
Cool. After gaining god mode and rebooting, I can then do god mode stuff without rebooting…
Sorry for stating the obvious. You real devs of course knew that all the way long. 