How are firmware updates for the phone hardware are done?

General
#1

With the latest critical security issues for the qualcom snapdragons releases 0, I wonder how the update process for hardware firmware is done in SFOS.
In Android, this is done by the OS updates (hopefully) released by the vendor. For example, Sony would release an update for my Xperia X phone which would also update the firmware of the Qualcom Snapdragon 650 to fix / mitigate the vulnerabilities.

How is this process implemented in SFOS? Are hardware firmware updates installed during the regular system upgrade process? Is there a manual way needed to do so? Or are they simply not installed at all, meaning such vulnerabilities are present for all eternity (or at least until you revert to Android, install the updates and then reflash SFOS)?

I’m really hoping for a direct statement from Jolla since this is a serious topic.

9 Likes
#2

I contacted the Jolla Support regarding this issue, here is their reply:

Hi,

those vulnerabilities are not in the code Sailfish OS.

We depend on the device manufacturer to get a) new versions of so-called vendor images b) new versions of android baseband, matching the kernel version used in the Sailfish-driven Xperia devices (Xperia X: Android 4.4.4, kernel 3.1.0).
Both a) and b) are linked to Sailfish as “binary blobs”, as black boxes. We/Jolla do not have the source code of them, so we cannot modify them.

I checked that there are no upgrades of a) or b) for Xperia X since late 2017. There are so many model variants of Xperia in the market that keeping all of them updated for years would be a huge task, even for a big company like Sony.

So, there is nothing you could do, unfortunately. - Other than buying a newer device with newer versions of code. :slight_smile:

While I understand the technical issues of relying on kernels and binary blobs from hardware vendors, I find this attitude deeply troublesome. Leaving critical firmware vulnerabilities unpatched and telling the customers basically to “deal with it” and “buy a new device if you want updates” sounds as worse as the darkest days of Android updates.

4 Likes
#3

I understand their position, as reverse-engineering and patching black boxes is not an option. Some kind of long-term support is basically only available from the manufacturer with the name of a fruit AFAIK.

#4

What would you have wanted them to say? There isn’t much they can do… This almost reads as they could distribute vendor images as parts of updates. I didn’t think the were allowed to do that, and that’s why we had to download them ourselves as part of flashing. I hope someone can clarify that…

#5

As I said, I totally understand the implications of binary blobs and limited resources.
However, if this means that critical security vulnerabilities can’t be fixed, then maybe the decision to go with Sonys Open Device Program was wrong.
We are not talking about minor issues here, these vulnerabilities can be triggered from remote without user interaction, meaning all SFOS Users are subject to these security and privacy concerns. Telling users to “deal with it” is definitely to wrong way to go.

Just because SFOS is relying on Sonys binary blobs does not mean there is no possibility for security updates - Sony is releasing updated blobs regularly. So I would have expected some reply like “we don’t update them automatically, but here is a guide how to do so manually”. Unfortunately, Jolla decided to skip the adaptation of kernel 4.14 for the Xperia X (which may have also allowed to bring the new Android emulation on the Xperia X), getting all users stuck on an old, insecure blob. This decision was made around 1 year after the official release of Sailfish X for the Xperia X.

Anyhow, this issue has hurt my trust in Jolla and SFOS deeply and will probably mean that I won’t replace my Xperia X with a new SFOS phone or can recommend SFOS to anyone.

1 Like
#6

If I understood correctly they’d have to redo the adaptation with every new major kernel release and just don’t have the manpower to handle that. Not an excuse but an explanation for why.

#7

That is correct, adapting new kernels would probably mean a lot of work. Instead, they took the money from the licences and decided to ditch hardware support as early as possible to move to new devices (and grab more license money there). Even though new major releases are quite rare (for the Xperia X, there is one: from the 3.16 kernel line which SFOS uses to the 4.14 kernel).
There would have been the possibility to focus on long-term support for the Xperia X then immediately switching to the XA.

I totally understand their struggle with the financial and personal shortage. But putting all users to severe risks and saying “sucks for you” clearly is the wrong way for a mobile OS in 2020.

2 Likes
#8

With Sony devices, updates to blobs are usually linked to updates in Android and kernel versions. So, 4.14 kernel is for AOSP10 and has updated blobs for it. At the same time, older kernels do get security updates for a while. Don’t know about Xperia X, but 4.9 kernels are still updated. However, Sony does not update blobs for 4.9 anymore.

On Sony devices, all these three components (kernel, Android, blobs) are used for SFOS port. Out of these, Android base and blobs are kept as they were at the end of porting. We currently don’t have any good mechanism to update them. In principle, it is something community can work on.

As for a risk, it is hard to say how much are we exposed to it when using devices via SFOS. It is limited of what we use from Android layer.

5 Likes
#9

This is in no way in Jolla’s reach, not even in Sony’s.
The qualcomm SOC is NOT open hardware, they deliver the black boxes / drivers. They do not update their old hardware driverwise. Also baseband and WiFi drivers will never be opened, as they have to be closed by law. This is, from the point of security catastrophic, but that is the way it sadly is.

#10

They have to be designed to adhere to regulations regarding output power and spectrum usage, not explicitly have closed firmware. That’s just the easy way out that most, if not all, manufacturers have gone for (or rather stayed with). If you have a source for your claim, do post it, but if this misconception keeps spreading it will get an even stronger hold in the industry.

1 Like
#11

I agree with you that it is not the job of Sony or Jolla to provide security updates for Qualcomm SOCs. However, in my opinion it is their responsibility to provide a mechanism to apply such updates when they are released (which often happens for critical vulnerabilities with public awareness). Sony is doing that with binary blobs, Jolla sadly does not seem to care. At least that is the extract I got from their responses.

#12

Thank you for the insight. However, I do not agree with your estimate of the scope for this vulnerabilities. At least previous ones granted access to the whole baseband modem, allowing the attacker to see and manipulate the data stream. This means:

  • recording voice call and SMS
  • capture and suppress messages (e.g. SMS two factor message)
  • capture / manipulate unencrypted data traffic

All this things are used by SFOS as well. And this examples are only the obvious ones, without more elaborate ones like installing code that e.g. continuously collects the phones location and so on.

Living in a city with a lot of diplomatic residences and known IMSI catcher operated by foreign countries, I am very sensitive towards vulnerabilities allowing everyone with access to the SS7 network full control over my baseband.

#13

For clarity - I have not estimated the scope, I stated that I don’t know how much we are exposed.

On AOSP side, updates are done by flashing new AOSP release and blobs. If there is baseband update, situation is not as simple. We are expected to flash stock, boot into it as the update is done after (during?) boot, and then flash AOSP again.

This is all far from simple OTA that we enjoy on SFOS.

Now how to make it all possible on Sailfish, is not clear. I am planning to move the port I am working on (XZ{2,2c,3}) to AOSP10 base at some moment to get better camera support. If it will happen that will be a good opportunity to test options for such updates. So far, I have implemented backup/restore on filesystem level using SD card, would have to think how to update the AOSP base as well. But notice planning above, it is current plan that may change.

1 Like
#14

@ attah
You could be right. But I would not know how to prevent changing regulated settings with open source.
@ jenix
The point is: Every smartphone OS runs just as a slave on the baseband, even sharing the same RAM.The baseband overviews everything you do on a phone. Also your service provider can update your baseband, install code, inserting malware however your government wants them to do.
For example watch the video from CCC media about basebands. Also living near diplomats you almost can be sure being under surveillance. Watch the CCC videos with Erich Moechel seeing how the US does surveillance in Vienna (UNO headquaters).
My point is: if you want privacy, do not use any smartphone.

1 Like
#15

And to break this even more down:
do not use any GSM device… :no_mouth: