PinePhone Misconceptions | Hacker News Reader

PinePhone Misconceptions

pine64.org

200 pointsUkiahSmith88 comments

What most critics miss about its hardware is that the few closed subsystems have no access to system memory and storage. It is very different from say a ME module into a CPU, or a closed card stuck into the same bus with the disk controller, which is the case of just every "open" laptop out there. USB, i2c and SPI are effective measures against malicious hardware taking control of the system bus and sucking data from peripherals. Even in the unlikely (but technically possible) scenario in which some chips loaded with malicious firmware attempt to sniff the i2c bus, they will be fed data that has been already encrypted on a system memory, bus and storage they have no access to.

If the user encrypts the data before sending it, whether the 4G modem/WiFi/BT are closed or not, they will see just noise.

The PinePhone looks compelling indeed.

One question: does anyone know where encryption occurs for 4G and Bluetooth voice for example? Is audio going to a BT headset encrypted inside the BT chip? Is audio going to the 4G network encrypted inside the modem?

Edit: Thanks for your replies.

I would assume each would happen inside the BT chip and inside the modem, respectively.

There's not really any meaningful encryption in LTE in the real world, that there is is vulnerable to all sorts of nasty downgrade attacks. You're better forgetting there is any and assuming that it's all in cleartext. Any there is will be deciphered on the radio hardware and then send in the clear to the main processor. This is how it always works.

The point of the pinephone post here is that you're basically treating the entire modem as untrusted and part of the internet rather than part of your device, which is the correct approach.

This is possible, although if the user has control over the "trusted" part of the system, nothing prevents the data to be encrypted before leaving it. That is, suppose we know the radio chip contains the encryption code, but also some suspicious closed firmware we cannot examine; since we can't trust that chipset, we could add one more encryption layer on the data before it reaches the untrusted chipset, so that any potentially malicious firmware would see essentially random noise. Of course the other end must employ the same decryption scheme, which is not immediate for sure, but still doable and would make extremely difficult for anyone to snoop our data.

The point is: we can't have a 100% fully open and auditable system, both in HW and SW, so they built a fence to separate the trusted hardware in which we work with our data and the untrusted but necessary part where our data can't enter before being encrypted.

It's a huge effort, which brings us one more time on the importance of having full open hardware/firmware/software. I wonder if current technology would allow crowfunding the creation of fully open chipsets. Nothing immediate, just one damn chip at a time: networking today, storage controllers in two years, graphics in 5, etc.

I pretty much agree.

However, there is the risk that compromised cellular or WiFi modules could defeat isolation, and fsck with the AP etc.

But if that's a concern, you can turn them off, and use tethered cellular or WiFi. And if you really 100% don't trust the USB bus, you can tether through Ethernet.

Even then, it'd actually be Ethernet via USB-C. But perhaps the additional transport layer would increase isolation.

I'd love to see arguments why that makes sense, or doesn't.

This is one good reason why the GNU crowd is doing more harm than good by labelling both the firmware as well as device drivers as "blobs" without taking any time to elaborate that one is much worse than the other.

This is why the terminology used by the BSD community is much more realistic and pragmatic.

http://www.gnu.org/distros/common-distros.html#BSD — «In BSD parlance, the term “blob” means something else: a nonfree driver.»

http://www.openbsd.org/lyrics.html#39 — «Blobs are vendor-compiled binary drivers without any source code.»

http://web.archive.org/web/20060603230017/http://kerneltrap.... — «Of course, also note that we don't want to become Hermes (the architecture of the Lucent/Prism/Symbol chip) assembly language programmers... we have more than enough to do. Just a specific example. Please, people, don't load us up with more tasks ;)» (NB: Theo's talking about the wi(4) firmware, see http://mdoc.su/-/wi.4 .)

> the firmware as well as device drivers as "blobs"

I'm pretty sure that both of them could completely compromise you

Did you just miss the original comment?

> USB, i2c and SPI are effective measures against malicious hardware taking control of the system bus and sucking data from peripherals.

BTW, it's not I2C, but I2S that PinePhone has as one of these interfaces, but that makes little difference — it's still hardly something over which you can DMA. (I'd be more concerned about USB, however.)

---

The problem with GNU and Stallman's logic is how arbitrary the line is drawn — if the hardware has proprietary logic like a microwave, that's fine; but if it allows to be upgraded by the user, it's suddenly not fine. The difference between one of these devices having some ROM, or letting the host upload the firmware, is minuscule. In fact, if you're concerned about hardware compromise, it would actually be better if the hardware is ROM-less, and you're the one who is uploading that binary blob into a device, because then they can't just intercept your laptop on being shipped from the vendor by simply installing a compromised memory chip with compromised firmware. (Of course, this is rather trivial example, because if they do intercept hardware, then they might as well just swap the whole device even if it's ROM-less, but then they gotta fit more stuff into a smaller space. And, of course, the whole thing being OSS is the best option, but this is just a threat-model analysis here — it's slightly more secure to upload the firmware yourself than have it ship with the hardware.)

> In fact, if you're concerned about hardware compromise

Right, but hardware compromised has never been the focus of GNU and Stallman. Saying the distinction is arbitrary from that POV is rather missing the point.

The distinction is still arbitrary even if you omit the hardware compromise aspect.

I mean, let's go back to that quote about assembler from Theo:

DDG for "Stallman microwave" returns this page and this quote:

http://stallman.org/stallman-computing.html — «As for microwave ovens and other appliances, if updating software is not a normal part of use of the device, then it is not a computer.»

Now, what does that firmware for wi(4) actually even does? How's it different from the hardware itself? What sort of language is it written in? I'm mean, I'm a kernel developer here, I've hacked drivers and subsystems because they weren't working properly, but are you seriously going to argue here that actually updating this firmware is any more common than updating the software of the microwave?

I mean, let's take a look and find out. NetBSD appears to have it all in a single dir over at http://bxr.su/n/sys/dev/microcode/wi/ — clicking on any individual file, then the CVSweb link, reveals that it's been committed 15 to 17 years ago and not once updated (apart from the whitespace in the .h header file). Searching for these files in OpenBSD reveals the same situation — http://bxr.su/o/sys/dev/microcode/symbol/ .

So, basically, the manufacturer decided to save a few cents by omitting a ROM component on their cards; requiring you to bootstrap the device by giving it its firmware on each boot. How's that any different from the situation where the ROM chip is fixed from the factory? As a user and kernel developer, I don't really see a difference. Would it be nice if the firmware is OSS? I mean, sure, but it's written in a proprietary language anyways, for proprietary hardware, and it's really much more part of the hardware than it is of the software or the OS, and there's better battles to fight here than getting this sort of useless thing FLOSS'ed.

In fact, those 12-hour clocks on most microwaves are really annoying, and there's never an option to fix it. It should be possible to get the source code for all those microwaves to fix them to use 24-h time; I'd much rather campaign for that than for making wi(4)'s firmware OSS.

If it is compromised then they can install ROM and use that instead of the uploaded firmware (possibly using a checksum to make it more difficult to detect).

> It’s worth mentioning that LPDDR3 initialization is done by u-boot SPL, which is also open source. There are no blobs in there either.

That's actually pretty impressive, isn't it? I was under the impression that RAM setup was a mess.

It's been open on these chips for a while (which is probably one of the reasons why Pine is so into them).

And the way it works with these chips it's a pain to support more than one board layout with more than one model of chips, but that's more a supply chain and SKU explosion issue.

This just sounds like a classic case of perfect being the enemy of good. A bunch of "purists" unironically lamenting the fact the device isn't 100.00% FOSS while typing on much more closed platforms. Or maybe just planted misinformation by competitors or three-letter agencies, either of which don't seem too far-fetched these days.

Can someone explain why the modem running closed source blob is not considered a huge problem?

Well, the issue there is that no modern modems at all have open firmware, no matter what your choice is.

*4G modems. I think you can get at least 2G with open firmware... maybe GSM.

Often the case and one excuse they provide is so that they can comply with radio regulations - which as many are semi software with DSP's in effect, would make the slightest software bug/change cause issues with the local radio regulators and indeed, the telco's. Not saying that you would need a radio licence from the local area just to compile modem code, but maybe not that far removed in part. Certainly testing, would dictate a sheilded enviroment to avoid legal issues and then at the end of all that, it would have to be certified by whatever local regulator of the country(s) it is used.

So does make open source modems rare, liability exposure of legal fallouts make for some muddy waters.

For the cellphone service. In ham land you can do anything that follows the emissions rules.

In ham land, the transmitter possesses the license to utilize the radio spectrum. With mobile phones, the carriers do. Cell phone owners don’t need a license - the model assumes their equipment manufacturers do, and will do what’s needed to assure continued compliance.

> In ham land you can do anything that follows the emissions rules.

In the US, hams are prohibited from employing encryption with the single exception for control coms with amateur space-based radios. With the proliferation of digital modes, the encryption rule is increasingly being challenged and it will be interesting to see where this goes in the future.

It would still be possible to be open source, even if it cannot be altered, such as by storing it in ROM (or storing a checksum so that only the exact version will run; this works better if the program is written in assembly language, since then you do not have to worry about the compiler messing up stuff). It could also be designed allow the code to be uploaded but to disallow transmission in that case, making it so that if the code is altered then it can only receive, and cannot transmit. Another alternative might be that the radio and the DSP are separate components in a single package, and then if you want to use them separately you will have to break the package to reveal the parts, and then it cannot be resealed; you will have to make your own and lose the warranty. (This last alternative is what I think is good, but if that won't work (I don't know much about its working, so maybe it won't work) then the others ways might do.)

It depends on how you define the "problem". Is it ideal, nope. But there is really nothing else out there even trying to do this other than librem which has its own problems. Not to mention this is very cheap. You have to start some where.

As long as the modem is connected via SDIO/USB to your open system (which it is), how is this a problem? It's treated as compromised/hostile.

Encryption of IP traffic happens on the open system, so no problem there.

If you'd like to complain about encryption of voice calls happening on the closed modem, I have some bad news. It wouldn't matter if it was open or closed, since the network it negotiates keys with is also compromised.

The only problem remaining, on this particular device, is direct connection of physical sensors (microphone, GPS, etc) directly to the modem. This is solved by physical switches (or hardware switches controlled from the open system) between the sensor and the modem.

The only exception I see now is the GPS, which is embedded into the modem. If they solve that, I'm buying the phone.

You gave a great answer to my question. Thank you.

Right. There are two distinguishable risks from cellular or WiFi modems. One is geolocation by towers or access points. And the other is isolation of the open system from cellular or WiFi modems.

You can't use cellular or WiFi without being geolocated. But as long as the modems are securely isolated from the open system, geolocation information can't pollute your communications. There's obviously the same geolocation issue with broadband.

Also, that isolation prevents compromised modems from compromising the open system, and the accessing data, compromising end-to-end encryption, and so on.

Both are aspects of modems being "treated as compromised/hostile".

> The only problem remaining, on this particular device, is direct connection of physical sensors (microphone, GPS, etc) directly to the modem

is that even the case of the microphone? My understanding was that - independently of the possibility to turn the microphone and modem off with kill switches - all audio data to the modem comes via I2S from the SoC anyways, i.e. that the microphone is NOT directly connected to the modem but to the SoC (possibly via a separate audio codec Chip) and that the SoC serves the modem via I2S whatever audio data the user pleases (whether that be from the microphone or whatever else).

Yes, the modem can't talk to anything, it's only connected to the SoC with the i2s audio bus and the usb bus, the SoC controls what gets sent to the modem. for a voice call the SoC proxies audio between the mic/speaker and the modem.

I don't know but I find the structure of the post pretty hilarious.

Basically the post says that the PinePhone mobile phone is, with the exception of the "mobile phone" part, a completely open source mobile phone.

It's just a funny way to write the post. If you remove the mobile phone part it's not a mobile phone. It's like saying a cake is, with the exception of the cake part, completely vegan.

If you remove the CPU its not a mobile phone either.

If it were a feature phone, this would be an accurate summary. For a smartphone, calling is a minority usage (an actual issue with the modem, sure) and network access is assumed over a hostile link anyway; does it matter if it's hostile at hop 1 or hop 2, if the modem is not a privileged part of the system?

An FBI tracker under your car is not a privileged part of your car

I do not follow the car analogy, please explain.

Not GP: but I assume the answer is "because GPS is in the modem, the closed source untrusted part could still be actively disclosing your location".

Aha! That is a valid concern indeed. Lesser than the usual "baseband has full access to whole system", but still significant.

.. But the modem itself is broadcasting it's identity to multiple radio receivers. Is there enough of a difference wrt GPS positioning for the distinction to matter?

Sure, I agree it’s subtle. But it is: a) much higher resolution b) potentially to a specific third party who may not have access to cell network data. Like, say, an angry ex-spouse.

Could it be made less bad if you could turn the tracker off (switch to airplane mode by physically removing power from the modem) any time you want?

It'd be nice if the PinePhone supported this.

Both the PinePhone and Librem 5 have physical kill switches for the modems.

Right. We're just moving the DMZ, and that's for a lot of cases totally fine. Rather than how people would assume it works like this.

    CPU -> LTE Modem || DMZ || Cellphone Provider

We have this for the Pinephone.

    CPU || DMZ || LTE Modem -> Cellphone Provider

This is fine.

Remember that in the first model, and in most typical phones, the LTE Modem have above root access to the CPU through DMA. The exception is some more modern devices like the iPhone, which give the modem a specific sandbox device to DMA into that's not the actual processor.

On the iPhone, the modem has always been on a separate chip.

separate chip doesn't tell you anything about the security model.

It was USB/HSIC and then switched over to PCIe with IOMMU.

Right, regardless of chip configuration, modern phones use IOMMU for isolation. Arguably the main advantage of the PinePhone and Librem 5 is the kill switches.

There are two reasons for wanting an open source phone: safety and hackability. Yes, the actual modem part isn't hackable, but they did do a good job (as do iPhones!) of segregating the closed source part so at least you don't have to worry about it remotely popping the actual phone OS. (nitpicking about "the modem is the real phone" not withstanding)

To me, the modem running a closed source blob is okay so long as that entire system is acting as a slave to the host, and isn't integrated with that host. The PinePhone appears to be explicitly designed around a total lack of trust for that modem. In a way, you could think of the modem at that point like any other Wireless Access Point you might connect to. Think about going into a coffee shop; sure you can hop on CafeBucks WiFi, but do you know what firmware the access point is running? How do you know it's secure? Heck, could you even guess the model number? Of course you can't; instead, your security model treats that entire communication line as potentially insecure, and implements SSL/TLS on top of it.

The PinePhone appears to use a similar approach here. The modem's only job is to provide a data connection, and ideally everything sent through that connection is encrypted in such a way that even if the modem wanted to snoop, it would be unable to do so. All it sees is encrypted noise, with the OS and application doing everything they can to keep it that way. The additional hardware isolation helps to ensure that even if the modem is compromised in some way by an attacker (difficult, but theoretically not impossible) it has very limited access to the rest of the phone, and would hopefully not be able to do very much damage. This is in stark contrast to most of the rest of the mobile industry today, which happily integrates the modem into the rest of the memory space, and would be at far greater risk should a modem exploit be discovered.

None of this is perfect, of course. In a perfect and ideal world, a FOSS modem would exist at scale, and the PinePhone would use that and all of the firmware would be open source. But the practical reality is that, at scale, a closed blob for the modem is required; no alternative exists that's cost effective enough to bring to market. So, the phone is designed to give that blob just as little trust as possible while still making the connection work. I think that's a perfectly fair trade.

> This is in stark contrast to most of the rest of the mobile industry today, which happily integrates the modem into the rest of the memory space, and would be at far greater risk should a modem exploit be discovered.

Is that still the case? I though that most phones now isolate modems via some flavor of USB with IOMMU.

And indeed, that phones now isolate modems better than Intel and AMD machines isolate USB devices. There's IOMMU, but only some software actually uses it, such as Qubes.

Modems in modern phones are all integrated in the SoC, it's technically seperated by iommu, but the issue with that is that you can't verify that the iommu works. There isn't really anything preventing the modem having some hard lines into the RAM.

With the PinePhone (and also the Librem 5) the modem and SoC are physically seperate so the communication between those two components can be inspected and controlled.

Thanks. So OK, it comes down to trusting IOMMU.

But iOS devices don't have the cellular modem in the SoC.

And neither does the latest from Qualcomm with 5G, which I gather will go in at least high-end phones.

While a completely open device is the ideal, to many there's nothing inherently wrong with making a few pragmatic compromises as long as they are well thought through. In the case of the radios, they appear to be well isolated from the CPU/system memory on the PinePhone. So if you want to be paranoid and ensure that every byte sent through them is encrypted before they see it, even if some malicious / snooping code is in those blobs, you can do that and they won't be able to accomplish very much. If that's not good enough, you can cut power to the radios entirely if you can live without them. So that's Pine64's approach.

We have two devices coming to market that take ideologically different approaches to choose from: the PinePhone (pragmatic compromise) and the Librem 5 (no compromise). So just pick where on the libre spectrum you want to live and enjoy 2020... it should be a fun year!

Replicant has an evaluation page incorporating this info with a handy table.

https://redmine.replicant.us/projects/replicant/wiki/Pinepho...

Looks like camera is open. I wonder if it possible to tweak software to get unholy quality out of sensors like Pixel phones do, or does one need to have high power/integrated GPU or TPU hardware for it.

The unholy quality on pixel phones is achieved through taking many pictures and combining them in smart ways (Google's computational photography wizard Marc Levoy has given a great series of lectures about the theory behind it: https://www.youtube.com/playlist?list=PL7ddpXYvFXspUN0N-gObF...) through a Qualcomm Hexagon processor, which has a special VLIW (Very Long Instruction Words) architecture. This co-processor is in every high-end Snapdragon (800 series) phone made in the last few years and you can relatively easily get the software to run on them through modded Google Camera versions commonly known as "Gcam ports".

My actual point is: You don't need special camera firmware to do this.

What you do need special (or open enough) firmware for is stuff like long exposures - the inability of which highly frustrated me on the phones, especially from Sony, I have owned so far. Doing weird stuff with the camera will probably be quite fun, but then again I don't believe the actual camera device will be that good.

All network connected systems have a boundary where they become untrusted. With the exception of the GPS, this all seems like a securable, hackable, and supportable system architecture.

RE cellular modems, there are some things worth noting. First, they are a huge privacy hole. It doesn't matter if they run open or closed firmware, the real adversary is the cell provider's hardware. Second, interoperability is a real problem. There would be large consequences if enough improperly configured cellular modems ended up in the wild.

Edit: Another point here. Open firmware does guarantee security. It is unlikely that whatever distro you end up running on your pine phone will be nearly as secure as iOS or Android. Of course privacy is a different story.

Can someone clear up if the modem and the GPS can talk directly? Not being able to shutdown the GPS indepandently put me off librem.

Looks like it's on the SOC (SOC has it and not seeing external GPS chip on board pictures), so most likely.

Ask them on twitter @thepine64 Though how the SOC is wired up inside may beyond their scope or the dreaded NDA from the SOC supplier.

https://wiki.pine64.org/index.php/PinePhone

Looks like GNSS is directly on the modem chip.

The GPS is on the modem SOC, as I understand. Perhaps they should leave the antenna unconnected. Then use an additional GPS module?

Perhaps it would be better to say "Not being able to run the GPS with the modem shut down"?

If the modem is on, the carrier can figure out your location relatively precisely from your transmissions, even if GPS were disabled.

So the real loss is that you can't use the device for navigation/mapping without turning on the modem.

Right?

At least this can be resolved by using an external receiver.

I believe modern cell standards use either NAVSTAR or base station broadcasts to synchronize time slots, adjust beam forming parameters, arrange call tower handovers and such to provide Tokyo or New York or Delhi relevant density capability, and thus GPS functionality is a requirement, apart from convenience of whether it’s available to userland runs in application processor.

Virtual UART drivers for every phone since 3G HSDPA creates GPS NMEA ports on your PC and it spits it garbage when it feels like doing.

The GPS is done on the EG25-G modem and can't be switched independently.

A removable battery AND a headphone jack? I mean, this is my definition of luxury.

Has anyone actually gotten one of these yet? Any critical impressions? Could I actually rely on it as a phone?

People are reporting receiving them (the bravehert edition with near final hardware) now in #pinephone on the pine64 discord.

> The LTE modem on the PinePhone is a ‘black box’, and runs its own Linux system internally.

First mention of Linux I’ve seen wrt modem firmware. Interesting!

The EG25 has two cores like most Android devices. One is running Qualcomm AMSS and the other a Linux kernel. The Linux side apparently converts AT into QMI messages, and provides endpoints for NMEA and other protocols.

It also uses an android bootloader and partition layout, and can support adb connections.

https://osmocom.org/projects/quectel-modems/wiki/EC25

This phone is looking fantastic. I‘m getting one for sure.

Perhaps the GPS issue can be solved by disconnecting the GPS antenna using a kill switch.

How long before PinePhone goes the way of Phantom Secure? https://www.sandiegouniontribune.com/news/courts/sd-me-ramos...

> To prevent law enforcement from getting their hands on the special phones, Phantom Secure required existing customers — referred to as “executives” — to vouch for new customers, then conducted background checks. The company’s safeguard didn’t always work.

> The judge called Fairfield’s participation in the scheme “aggravated” because of the significant amount of money laundered, the use of his expertise and the four-year stretch of illegal activity.

In contrast, anyone (including law enforcement officials) can buy a PinePhone, and I doubt Pine64 is laundering money. It is unlikely for Pine64 to be prosecuted the way Phantom Secure was.

It’s just as closed as the typical laptop (better in many ways, some newer laptops have some nasty stuff in the bios) I think there might be 2 WiFi cards that even have open source firmware and the firmware isn’t complete enough to be usable for most people.

I’m not sure who would be surprised by this, I feel like anyone that cares this much would be paying enough attention to know what’s going on.

The librem phone seems a lot more open, and the zerophone is also very interesting.

I'd say both are about the same. The Librem 5 physically puts the Modem and Wifi/BT modules on a physical card, where the PinePhone make it all into a single board. I believe both have the same physical/logical seperation (i.e. Modem and Wifi/BT are on a Bus versus integrated directly into the CPU), and both support a hardware disable due to the physical seperation.

Both Phones have to load firmware into the Modem and WiFi/BT.

For all practical purposes, it looks to me that there's no difference between soldered and slotted when they both have a physical switch to disable them.

In theory you can change the modem/wifi in the Librem, that may be more "open" but you pay for it in size.

the librem isn't more open than the PinePhone at all. The only difference is that they put the modem on a separate card… but that doesn't make it any more open at all. What matters, given the fact that there just isn't any open modem out there, is the fact that the modem is kept isolated from the SoC in a way that doesn't allow the modem to access anything the SoC doesn't explicitly give it.

It is, however, a lot more open than most ARM Single board computers and ARM phones. Most ARM Phones/SBCs cannot run mainline Linux, and due to closed drivers, will likely never be able to. You in addition have Phones with locked bootloaders, so you can't even load your own firmware in it!

This gets us into the situation we see today: even if you have a Phone that you can run your own firmware on it, it has a lifetime because the vendor has little financial intentive to do so.

Even the most open Android Phones (Pixels) have about a 3 year lifetime:

https://support.google.com/nexus/answer/4457705

On an iPhone, you are completely at the mercy of Apple for updates (for which they have a much better track record than Android).

Meanwhile, my Thinkpad x200 was released in 2008 and continues to be a supported just fine, with no end in sight. I hate to say, in contrast to even my Novena, is much better, as my Novena sits in my desk because it does not run mainline Linux, and I can't even get it to run properly on an updated Linux 4.4 Kernel that I tried to compile (due to no support).

So the Pinephone (and Librem 5) shooting to ensure that they can run unmodified Mainline Linux is a huge win for openness and longetivity in a Phone.

There's been some great work on mainline support for the Pixel 3XL / Snapdragon 845: https://gitlab.com/postmarketOS/pmaports/issues/153#note_207...

That's good to see! If I remember right, the last Google Phone with mainline support was a Nexus 5.

The Nexus 5 did not have mainline support while current; it ran a patched kernel like just about every other AOSP/Android build. Mainline support is now being provided by the postmarketOS folks for the Nexus 5, and could be achievable for other devices.

Ahh, thanks for the correction.

> On an iPhone, you are completely at the mercy of Apple for updates

Hm, isn't it theoretically possible to use the checkm8 exploit to boot your own code? Is the problem just that writing your own OS for the iPhone is difficult, or is there anything actually blocking you once you have code execution in the boot ROM?

Boot, and then what? Are there open drivers to the iPhone peripherals? Last I checked, there weren't: only having access to the CPU is not entirely satisfactory.

That's the point of the article: being capable of running code on main CPU is but the first step, drivers and firmware for all the other parts are far more problematic.

Modern desktop CPUs require blobs to boot (Intel FSP / AMD AGESA), Intel laptops (except Chromebooks) are especially bad because Boot Guard. Anything with Allwinner/Rockchip/NXP/Marvell SoCs is not nearly as closed.

How are chrome books more free? Don’t they require everything to be signed (with support for disabling user space checks at the cost of a loud threat from the firmware during start up?)

It's not a "loud threat", and it's only if you keep the stock coreboot. With a debug cable, you can flash anything you want, I have a fully custom coreboot+edk2 build with cleaned ME and no signature checks anywhere.

Uh, no? This is much more free-er than typical laptop, be it recent or old.

The vast majority of laptops have closed-source BIOS. The vast majority of laptops have components with closed-source firmware with access to RAM (Intel ME comes to mind), which includes BIOS (because it keeps running after boot).

Also, only modern laptops have IO-MMUs to prevent PCI-Express devices from accessing the RAM directly. (PinePhone simply doesn't use PCI-E)

And I don't think there is /any/ x86 laptop on which we know how to do DRAM initialization without closed-source blobs.

> I don't think there is /any/ x86 laptop on which we know how to do DRAM initialization without closed-source blobs

Pre-SandyBridge 2009 era stuff?

ESP8266 is not free, not secure, but open and fully usable(if used in its originally intended purpose)

Is it fully open? I thought the lower-level WLAN firmware was only available as binary blobs there too.

Reply on news.ycombinator.com