User:Mis012/Buyer's Guide

From postmarketOS

Aspiring device owner’s buyers guide

In today’s world, when one is to buy a new electronic device, the amount of choice can be overwhelming. Yes, there are reviews, which may catch some issues that the manufacturer failed to disclose, but most reviewers don’t really care about the same things that we do. So, I propose a way to massively reduce the amount of devices that deserve consideration when shopping for your next phone (or a TV, or anything electronic really).

Mainline Linux is the name of the game

If your SoC is not just a simple MCU, it can probably run Linux. Chances are it already does - example being android phones and a lot of smart TVs. Before you verify that you would really own the device (see next paragraph), you should make sure that running the latest and greatest Linux kernel, free of vendor hacks, won’t be a massive pain. Because you do want to run the latest and greatest version, trust me.
The first thing to check is SoC support. That is, does support for your device candidate’s SoC of choice exist in mainline linux?
The way to check that is straightforward - find out what SoC you have (did I say straightforward? With android phones at least…), and grep for it’s codename in mainline Linux tree. You can also check out upstreaming efforts such as linux-sunxi (allwinner), if they provide information on level of support for a particular SoC. It’s important to note that not all features of an SoC will necessairly be supported - just make sure those are only minor ones, not something important like the display subsystem…
Some SoCs with good levels of support are:

  • Qualcomm
    • msm8916
    • msm8974 (with some out of tree patches that are slowly getting usptreamed)
    • msm8998 (at least on Windows ARM edition laptops)
    • sdm845, sdm855 (which are still WIP to some degree, but sdm845 seems to be in a good shape already);

there are undoubtedly many more SoCs with just as good support, so if you know of any, feel free to add them (links to feature matrices are even better ;)
If your SoC is supported, you should check that you have a way to gather information about the connected hardware, needed to write a dts and sometimes even a new driver. One option is downstream kernel source - Linux is GPLv2, so you can have it, and it should by design contain all the information needed to get the hw to work. Another possibility are schematics + datasheets, but those are not always available.

One last remark - steer clear of PowerVR graphics, they are probably the only completely unsupported mobile GPUs in mainline linux.

What is ownership, anyway? (Do I really own it?)

The first question you need to ask yourself is simple - can I do whatever I want with the device, considering it will supposedly become my property when I buy it? The main show stopper in this regard is signature verification of code to be executed. It may be hard to find out what the deal is before you buy said device, but it’s possible.
First, you need to determine what level of control you are willing to settle for. In the land of android phones, for example, there is a notion of “locked” and “unlocked” bootloaders, depending on whether there is signature verification in place which prevents booting custom Linux kernels. However, this is not the full picture, and if you think it is, it may bite you in the future.
On modern SoCs, by the time control is handed to user controlled code (usually the Linux kernel), the SoC has already dropped into a lower privilege mode. That means that you have no control over, for example, the code running in trustzone or on a cool auxillary core that you would like to play with.
Obviously, the manufacturer won’t tell you in the product information whether or not you can boot your own Linux kernel, let alone whether or not you can run your own code with full privileges. So how does one obtain that information before deciding to buy a device? Well, I can’t speak for other SoC vendors, but with qualcomm for example, it’s not only possible, but also quite trivial. The idea is that you obtain a firmware update that contains trustzone, sbl, aboot, etc (or xbl, … with newer SoCs) and check if they contain a cryptographic key. You can see the certificate even with strings.
If they don’t, then clearly the device can’t be checking for it. And it also means that you should be able to use your own keys for signature verification, actually utilizing the “security” potential. Be aware that this can be “fixed” by a firmware update.
If there is a key, you still have a chance - provided it’s the qualcomm test key, private keys of which are available thanks to non-existent key confidentiality management (it’s a test key after all).
If there is a different key, you are probably screwed - it’s still possible that the device doesn’t check it, but it’s quite unlikely and you definitely should not count on it.

Be sure to check how this process differs with your SoC vendor!