[Note: This thread is intended to be a place for discussing the topics in this blog post. Please keep the discussion on topic. In particular, customer support requests about Librem 14 orders, or discussions that could be summed up with “when do I get my Librem 14?” would be considered off topic.]
The Librem 14 was designed based on a long wishlist we made to build our dream laptop. When we first announced the Librem 14 we stuck to the features we knew for sure would be part of the first revision. Over the next few months as we worked through prototypes we were able to announce new features such as dual RAM slots and a number of exciting security features. While these features are mentioned on the Librem 14 product page, I thought it would be useful to collect all of the security features of the Librem 14 into a single place.
So how different is the current IME version compared to the previous neutralized version before, in terms of firmware image size?
What efforts are currently being made to disable/remove the remaining IME from previous Librem products, such as the Librem 13v4 and 15v4, as well as the current products, such as the Librem Mini? Where is this progress tracked?
I think it is widely believed that the main CPU simply won’t boot if you completely remove all the code from the firmware for the ME CPU (the homunculus CPU).
If you have a problem with that - and I think just about everyone in this forum does - then you would have to take that up with Intel (and of course get nowhere).
Is the belief in the first paragraph correct? Who knows? It’s not as if Intel is open about these matters.
oh, come on – get off that high horse; there are innumerable Debian based distributions – Ubuntu included – which are marketed in a similar fashion; and it’s not like Purism does not contribute back to some fundamental bricks of the GNU/Linux world.
“Another security feature that’s completely new to the Librem 14 is a set of switches on the motherboard that will allow you to write protect the BIOS and EC firmware. Currently the physical switches are implemented, but we still need to complete some software and configuration work so that they actually trigger write protection.”
Can you elaborate a bit on this information?
This sounds to me like there is some additional “input device” (switch on mainboard) that triggers some software to not allow writing of firmware memory.
Where is this software implemented so that it cannot be overridden? Which level of system access is necessary to change this piece of software?
I agree that it should be elaborated on but my best guess is the switches are to prevent writing when the OS is booted. Likely the EC firmware will read the state of the switches and either allow or deny the OS rights to overwrite the various flash chips. So it probably relies on the EC firmware being implemented correctly and doesn’t stop anyone with physical access and a flash programmer.
To my understanding, we still need to identify and define the addresses that will end up being write protected when those switches are flipped and that’s something that ends up being defined within the firmware itself so it will come with a future firmware update.
The risk mitigated with this feature is similar to PureBoot–someone compromising your computer over the network and reflashing your firmware remotely so their attack persists. Having the write-protect switch enabled would mean that an attacker would need to have physical access to the computer (and you can add some tamper detection methods like glitter nail polish on screws to help frustrate that, or at least detect it, as well) and enough time to remove screws, flip the switch and/or attach a hardware flasher.
This is a warning to keep this thread on topic (security features of the Librem 14). If you want to start a new thread with whatever gripe you may have about our efforts with PureOS and upstream, you are free to do so.
I don’t have specific details on the differences between software size on different ME versions. I can answer your other question though, we have been using the work from Positive Technologies and the me_cleaner tool to disable and neutralize the ME for past products.
The hope is that the me_cleaner tool can be updated for newer versions of the ME.
Let me think about that. It would potentially fit in Fund Your App if that campaign weren’t phone-centric. It may be worth expanding FYA outside of phone work and into a larger way to fund advancements in free software overall.
Based on the current product offerings, it would only make sense to do so, unless Purism intends to change their stance to different, more (hardware) libre platforms such as ARM or POWER, and replace the Librem 14, Mini, and Server with such. If you did, however, you would need to still liberate the IME anyways, as that is still a part of the roadmap, and your customers/investors expect you to follow the standards set by it.
Whichever way Purism wants to achieve Purism Purist standard is up to you and the rest of the team, x86 or not. However, Purism remains the only company willing to liberate the remaining IME.
If x86 (Intel) is liberated, that makes it incredibly accessible to the average consumer. Even then, Purism would still offer unique offerings such as hardware kill switches, PureBoot, and so on. There is still great incentive for prospective costumers to consider Purism, irrespective of which Purism Purist option taken.