
Qualcomm’s Chain of Trust - krtkush
https://lineageos.org/engineering/Qualcomm-Firmware/
======
JoshuaAshton
I mean, why can't they just have a regular bootloader like a PC? It's a lot of
effort for what is essentially 0 gain if you just have full device encryption.

The phone should at least always be unlockable by a single switch in the
developer settings - none of this "oh go to our website and generate an unlock
code/pay us money for an unlock code/phone us" which is a HUGE pain in the
butt.

I swap between roms a lot, and the whole idea of a system partition and data
partition etc is just stupid. They always are the wrong size for what they
need to be and then I try to install gapps and its like "oh your system
partition is too small my dude," so why separate these and just have
everything like a regular linux OS.

Maybe I'm missing something stupid? But I kinda just want a phone that just
starts a linux based operating system like a PC, and lets me do everything I
can on my linux PC in a touch-centric way.

~~~
exDM69
These secure boot systems exist because of DRM protection to media that is
mandated by the content companies. Their point is to verify that the whole OS
from kernel to userspace can't be modified by 3rd parties (such as you, the
owner of the device).

It boils down to "no secure boot, no DRM, no Netflix 4k for you".

At least this was the case when I was still working with consumer electronics
a few years ago.

~~~
minipci1321
> These secure boot systems exist because of DRM protection to media that is
> mandated by the content companies.

That statement sounds too simplified. How about non-approved images pumping
power upstream above regulatory limit on RF? Or overclocking the CPU? Or
reporting all keystrokes to a place of your choice? Would you, as a
manufacturer of the device, like to make that easily possible?

> Their point is to verify that the whole OS from kernel to userspace can't be
> modified by 3rd parties (such as you, the owner of the device).

What makes it impossible is not the secure boot but the fact that the
_unauthorized_ 3rd parties don't have the keys for signing stages of the
images. Some owners of some secure-boot devices, do have keys and sign their
images. One example: a telecom operator, owner of its park of the set-top box
decoders, does that. Secure boot can be made to allow several/many authorized
keys.

~~~
dcow
If I don't own the device then why am I paying for it?

~~~
minipci1321
Unclear what you had in mind. I'll assume you were speaking about your own
secure-booting mobile phone that you paid full price and now would like to be
able to reflash?

I am not sure what to tell you. The situation pre-dates the secure boot. If I
recall correctly, Iiyama monitors were known to be unrepairable because the
manufacturer always refused to release schematics. It did not prevent their
extreme popularity.

As an end-consumer, I support very much the freedom to change any products I
own, the way I want. I once replaced ball bearings in the drum of my washing
machine -- you get the idea.

As a person authorizing a product that can potentially emit unhealthy or
unsafe levels of RF, or a parent of teenagers using social media, or a
developer of medical applications intended for mobile phone... I am none of
that, but I guess I would have a very different opinion.

~~~
TeMPOraL
> _As a person authorizing a product that can potentially emit unhealthy or
> unsafe levels of RF,_

This used to be, can be, and should continue to be limited on a hardware
level. You can't flash a phone to emit "unhealthy or unsafe levels of RF" if
the circuit itself won't let such amounts of power to flow to the radio. Of
course, someone could still mess with the hardware itself, but that doesn't
scale and (in case of breaking RF limits) is illegal.

> _or a parent of teenagers using social media,_

This is interesting because, in a way, it's telling me that you the maker of
the device are _my_ parent. The argument sounds like, "to prevent your child
from flashing your device, we'll prevent _you_ from flashing your device". How
about giving me the tools to limit my child's access, if I desire to do so,
while not limiting _my_ access?

> _or a developer of medical applications intended for mobile phone..._

This is a large topic, but to a first approximation, I don't believe a
software that _cannot_ be modified by the end-user for health reasons should
be allowed on the phone. I also don't believe most medical apps in the
smartphone spaces are of this category. The way I see it currently: either
accept that some users (like myself) want to have full read & write access to
_their_ data on _their_ phones, or make your solution a separate, tamper-
proof, black-box device (and get a regulator to rule that for me to open it is
illegal).

~~~
jacobush
Maybe not unsafe per se from an emissions perspective, but there are spectrum
considerations and other things, and with more and more done in software and
less with discrete components, the trend is clear.

Safety is complex - what if the phone starts emitting on bands allocated to
emergency services.

------
ohazi
Without some pretty drastic changes, I don't think I'm ever going to feel
confident that a computer with a Qualcomm or Broadcom SoC can be made secure.
These two companies are basically _the worst_ at making their documentation /
datasheets / code available for inspection.

The article suggests that the boot process has been simplified, but as an
outsider it still looks astoundingly complex, and the "random oem additions
that are likely to be insecure" part is absolutely terrifying.

Am I wrong?

------
voltagex_
>Motorola’s use of a single QFUSE that must be blown to unlock the device,
permanently voiding the warranty.

If this isn't illegal (the warranty part), it should be.

~~~
drdaeman
Not that simple. Depends on what warranty is on.

Hardware warranty shouldn't be generally affected, unless it's about parts
that can fail because of software malfunction - e.g. when failsafes are
defined in user-overridable software. It is fair that a hardware vendor
shouldn't be responsible for user e.g. overclocking something.

Software warranty should be voided. Although I can't remember when it was the
last time I saw a warranty for software, explicit or implied. Rather, I
believe there's an explicit dismissal of any warranties in every single
licensing agreement out there.

~~~
taneq
My phone's screen sometimes wouldn't come back on after a phone call. The
sound quality transmitted was sometimes terrible. Both of those things present
as hardware problems (prox sensor, microphone) but turned out to be software
related. How would you prove that a hardware problem's not actually software?

As an aside, LineageOS seems to have been getting gradually more buggy on my
Nexus 5X. 15.1 has the two issues above, plus Bluetooth music streaming is
broken and crashes the music player. I reverted to an old 14.1 ROM and
everything works perfectly.

~~~
craftyguy
> As an aside, LineageOS seems to have been getting gradually more buggy on my
> Nexus 5X. 15.1 has the two issues above, plus Bluetooth music streaming is
> broken and crashes the music player.

I have none of those problems with 15.1 on my nexus 5x, but I also make it a
point to install the latest weekly updates and the latest vendor partition
blob.

~~~
taneq
Maybe I set it up wrong, then? My basic install flow:

\- Get latest nightly build from lineageos.org

\- Get matching factory image from Google and extract vendor and radio images
from it

\- Install TWRP

\- Do a full wipe of the phone

\- Install LineageOS, vendor image and radio image

Then when an OTA update came out, I'd install it and update the vendor image
manually if it complained.

What'd I miss?

~~~
craftyguy
That seems about right, and similar to what I do. Maybe it's a hardware issue?
I also don't use the default music app for streaming music over bluetooth, so
it could be an issue with that..

~~~
taneq
Yeah, I assumed it was hardware (there's a known issue with some 5Xes with
poor mic quality) but I've gone back to 14.1 and all is fixed, so meh. The
only thing I really miss is the new power saving features and I can live with
charging every two days instead of every three days.

~~~
craftyguy
> I can live with charging every two days instead of every three days.

Yea it's incredible how long the battery lasts on this device, compared to
previous nexus devices (though I never owned a nexus 5..) I've only ever run
lineageos on this thing and regularly get multiple days on a charge with
light/moderate usage. I once took it on a 8 day backpacking trip where it was
powered on but in airplane mode (to serve as camera and backup map), got out
of the wilderness with something like 40% battery left. IMHO that really shows
how much negative impact on performance google's shit has on a mobile device
when it can last that long without it.

------
walrus01
For those who haven't heard of it, LineageOS is essentially a fork of
CyanogenMod. Cyanogen (the corporation) is now dead.

OnePlus' oxygenOS which they ship on the 3, 3T, 5, and 6 is very close to
cyanogenmod in functionality and no-bullshit-added android experience.

~~~
snaky
And the OnePlus kernel and modem firmware are broken so much the maintainer of
3 and 3T LineageOS branches couldn't take it anymore.

[https://forum.xda-
developers.com/showpost.php?p=76423626&pos...](https://forum.xda-
developers.com/showpost.php?p=76423626&postcount=4158)

[https://forum.xda-
developers.com/showpost.php?p=76511525&pos...](https://forum.xda-
developers.com/showpost.php?p=76511525&postcount=4229)

~~~
SmellyGeekBoy
As a LineageOS OP3 user this is fascinating. Although presumably someone else
picked this up as I'm still receiving updates.

~~~
snaky
15.1 is officially supported by LineageOS but it's not as good as 14.1, that's
why 14.1 is still getting security updates thanks to denser@xda
[https://forum.xda-
developers.com/showpost.php?p=77567550&pos...](https://forum.xda-
developers.com/showpost.php?p=77567550&postcount=4551)

------
DoctorOetker
>QFUSE: Microscopic hardware fuse that is integrated into the SoC - Once
physically blown, impossible to reset or replace

I understand that once set, it can't be restored.

My question: could some of the earliest priviliged states decide to burn
unburnt fuses of the public key? or is there an extra special root fuse which
only allows burning the key fuses if it isn't yet burnt, and which is burnt as
soon as the root public key is burnt?

This may seem irrelevant if we don't have access to the privileged states, but
perhaps with hardware vulnerabilities as we have been seeing more and more, it
may conceivably be possible to force it to run code to burn an unburnt fuse of
the key. I.e. perhaps we can set bits in the public key such that the new key
is easier to factor? (in case of say RSA)

EDIT: if this is possible we could sign our own root bootloader

~~~
Ristovski
There is a fuse-antifuse pair most likely. Think of it this way:

You burn the bits "0001" into some fuse bank, which is mirrored in an anti-
fuse bank that now equals "1110".

You can burn the unburned fuses in the normal bank, but can't unburn them in
the antifuse bank.

~~~
DoctorOetker
thanks,

I actually thought of that, but it seems rather inefficient compared to a
single fuse, unblown before writing a key, blown after written key is verified
as correctly written, once blown no fuses for this key can be blown...

But I don't know if they actually use such a system, or perhaps they simply
assume the attackers never get fuseblowing privilege, and perhaps they assume
that a key in a blown set of fuses is no longer rewritable...

------
ggm
so.. can somebody in SoC land explain to me if there is _any_ technology
extant, which can reliably un-blow a blown fuse on die, and not irrevocably
ruin the entire chip?

a lot gets built into these 'cannot be undone' moments. The cryptech people
talked about building large capacitor circuits into their design to be charged
up and blow the secure keystore if the tamper switch went "bing" but I always
wonder if you could eg use a electron microscope to reverse engineer the
keystore state before it was wiped.

~~~
tinganho
I actually did a bit of research on this before.

For easier chips like TPMs(Trusted Platform Module). What I've seen people do
when trying to steal secrets(key) on a chip is to buy multiples of the same
chip. On each chip expose the layer under a microscope(A chip exist of
multiple layers, thats why we need multiple chips). Now, you know everything
to reverse engineer the secrets. There exists tools for drilling and probing
each trace on the chip. Here is an example.
[https://www.youtube.com/watch?v=h-hohCfo4LA](https://www.youtube.com/watch?v=h-hohCfo4LA)

I think what you mean by charging a huge capacitor and blowing up the secrets.
You refer to an HSM(Hardware Security Module). They typically have sensors to
detect any fraudulent behavior. They are much harder hack. But there is always
holes in each HSM. I think hackers use the same technic there as well. Buy
multiple HSM to figure out the design. Reverse engineer the traces and try to
probe without being detected on the target device. To my knowledge there are
currently no sensors that are 100% bullet proof. They can either be fooled or
have weak spots.

~~~
teddyh
> _On each chip expose the layer under a microscope_

Or use X-ray tomography:

[https://news.ycombinator.com/item?id=13952016](https://news.ycombinator.com/item?id=13952016)

