Modem shared memory¶
This section documents in more details the architecture of system on a chip and devices that have shared memory between the modem and the processor running Android. Since the modem runs (only) proprietary software, devices that doesn't have any mechanism that prevent the modem from taking control of the processor running Android are a grave concern for users freedom ans security.
This section focuses on that issue. Some Qualcomm System On a Chip that are affected by this issue also have other issues that aren't mentioned here but in the Qualcomm System On a Chip page.
Documenting the issue more in depth might allow us to understand if some devices with shared memory between the modem and the processor running Android might be able to be used safely.
Having the modem and the processor running Android in separate chip, connected through a bus (like USB) that doesn't allow the modem to access the Android processor's memory offers pretty good guarantee that the modem cannot take the control of the processor running Android at a hardware level.
When the modem and the Android processor are in the same chip or when they use shared memory to communicate, and that memory is also used by the processor operating system, such guarantees are gone.
- Some smartphones manufacturer could connect the modem to the processor running Android with separate dedicated memory that is not used for things other than enabling them to communicate.
- IOMMUs are hardware dedicated to prevent peripherals (like a modem) from taking control of the processor (that is here running Android). To have enough guarantee, such hardware should have good technical documentation and the code using it should have good peer review (It should be good enough if it is in upstream Linux).
System on a chip¶
This lists system on a chip that also Include a modem and have shared memory between the modem and the processor running Android, and the way the modem and the processor running Android are isolated or not.
|Vendor||System on a chip||Isolation||Market share||References|
|Qualcomm||Mobile Station Modem (MSM) Snapdragon 7x30|| Bad:
* The modem is in charge of loading the bootloader of the processor running Android. Because of that it can temper with that bootloader and take control of the processor running Android.
* The modem can access the memory of the processor running Android, and can take control of it through that way.
* The modem has access to the storage of the processor running Android, so it can take control of it through that.
|Qualcomm||Snapdragon S4|| Unknown:
* The modem is booted by the processor running Android (which in turn is booted by a separate boot processor called RPM)
* There is not enough public documentation to understand if there is enough isolation between the modem and the processor running android.
The Security of chip fabric page of rpw-pacsec2013-hexagon.pdf
This lists devices that have the modem and the processor running Android in separate chips and use shared memory between them, along with the way the processor running Android is isolated from the modem, or not.
|Samsung||Galaxy Nexus (I9250)||MIPI||* With MIPI it's most probably not possible for the peripheral to access the host RAM|| * board-tuna.c:
#ifdef CONFIG_OMAP_HSI_DEVICE if (TUNA_TYPE_MAGURO == omap4_tuna_get_type()) omap_hsi_init(); #endif
|Galaxy Tab 2 7.0 (P31xx)||* espresso_defconfig: CONFIG_LINK_DEVICE_MIPI=y|
|Galaxy Tab 2 10.1 (P51xx)|
|Galaxy S 3 (I9300)||HSIC||* HSIC is a subset of the USB protocol => the peripheral has no access to the host RAM
* The device cannot change USB IDs without the host powering up and down the bus
|* lineageos_i9300_defconfig: CONFIG_MODEM_M0
* lineageos_i7000_defconfig: CONFIG_LINK_DEVICE_HSIC=y
* lineageos_i7100_defconfig: CONFIG_MODEM_M0
* lineageos_i5100_defconfig: CONFIG_MODEM_M0
* lineageos_i9100_defconfig: CONFIG_LINK_DEVICE_HSIC=y
|Galaxy Note (N7000)|
|Galaxy Note 2 (N7100)|
|Galaxy Note 8.0 (N51xx)|
|Galaxy S 2 (I9100)|
Powering off the modem¶
Android airplane mode interface¶
The RIL_REQUEST_RADIO_POWER command is used by the airplane mode.
current libsamsung-ril and libsamsung-ipc implementation¶
In libsamsung-ril, RIL_REQUEST_RADIO_POWER is implemneted in the ril_request_radio_power function which doesn't turn off the modem but asks it not to transmit by asking it to go in low power mode. This looks very similar to the AT command AT+CFUN.
The airplane mode could be implemented in another way where the modem is powered off. The advantage of using the airplane mode for that is that it's already implemented in the Android GUI.
We would also need to explain users that we implemented it this way, but that other Android distributions might have different implementations as their goal might differ. Doing again a full modem bootstrap will take longer than just asking the modem to go out of low power mode.
To do that we would need to understand what exactly the kernel modem power off interface do in hardware, and look at the kernel APIs that could be used to do that.
On Replicant 9, at the time of writing a GPIO interface (/sys/devices/platform/xmm6262/modem_power) is available for that, but we would need to look deeper into it to understand what it does exactly at the hardware level. That interface may change when the modem drivers are modified, for instance during the work to mainline them.
On Samsung kernel, the interface is different but probably expose the same hardware controls but in a different way.
At this point, libsamsung-ipc will need to be modified to use such interfaces instead.
Libsamsung-ipc and libsamsung-ril might also need to be modified to take into account the fact that the modem needs to be re-bootstraped again.