QualcommSOCs » History » Revision 5
Revision 4 (Denis 'GNUtoo' Carikli, 07/18/2019 08:35 PM) → Revision 5/9 (Denis 'GNUtoo' Carikli, 07/18/2019 08:55 PM)
h1. Qualcomm SOCs When Replicant was started, the HTC Dream was the only available Android phone, and it had a Qualcomm System On a Chip (SOC). SOC. We then also added support for other very similar devices. The System On a Chip family used by theses When alternatives became available, we switched focus away from devices was the MSM7K. Both the modem and the processor that run Replicant were in that same chip. While working on Replicant, very serious flaws were discovered with that System On a Chip family: such SOC because they had several issues: * The modem the GSM modem/baseband (which runs only non-free software) handled things that were too much privacy sensitive, such as the audio CODEC, which, as I understand, makes it possible, hardware wise, for the modem to enable the microphone without the Application Processor (which ran Replicant) being involved. * The RAM chips were shared between the CPU of the GSM modem and the SOC CPU. This was also the case for some of the supported devices that had a Samsung Exynos SOC like the Nexus S. This could enable * more recent devices seemed to require more work than before due to the modem to take control increasing amount of the processor running Replicant. * proprietary libraries. The modem processor was in charge of booting the device. To do fact that it had to: ** Intialize all privacy sensitive hardware such as the system RAM ** Load CODEC is controlled by proprietary software (trough the bootloader modem), along with the perceived amount of work (due to the Application Processor in RAM big number of proprietary libraries and instruct that processor to run that code. * The modem also handled the GPS. This is also a concern for other their nature) explains why devices with different System On Qualcomm SOCs are not a Chip like the Nokia N900. priority for Replicant. Despite the huge amount of work required, when alternatives became available, that we switched away from still accepted contributions for devices with this such System On a Chip family because the gravity of the issues was a nightmare. While some of the above issues have been fixed in more recent Qualcomm System On a Chip families, the increasing amount of proprietary libraries for theses new families, Chip, and the lack of strong guarantees that would prevent the modem from being able several people worked to take control of the processor running Replicant made the project ignore and discourage the use of the newer Qualcomm System On a Chip families. add support for devices with them but didn't have enough time to complete their work. Despite that, Still, it may might be possible to make sure that the modem cannot physically access and modify the Application Processor's RAM content, for instance by using the SOC IOMMU, if there is one, but and if it is only controlled by the Application Processor and that we can have enough assurance that the software and hardware does their job correctly. This would require significant work. It would at least require: * Qualcomm to publish enough documentation on the hardware, and to be able to use a mainline kernel (to be able to have some trust in the code) * to have public documentation kernel[1] on the System On a Chip IOMMU. * to have people analyze the security of the IOMMU. * to make sure that the IOMMU setup even before the RAM is even initialized. Nonfree bootloader most probably prevent that. devices. Despite that we may still accept contributions for devices with such System On a Chip, but it's best to contact the Replicant project (for instance on the mailing list or on IRC) before starting to work on that, to collectively decide how to handle that. For instance some Some tablets use Qualcomm SOCs that have no modems. So if Assuming that the most important privacy sensitive hardware is under the control of the Application Processor, it such tablets might be possible to add support for such tablets if work interesting, assuming that the amount of proprietary libraries (and work) is done low enough to make sure that they can be useful without any proprietary libraries. worth it.