ModemIsolationResearch » History » Revision 58
h1. Modem isolation 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. Because of that the Replicant project decided not to support anymore devices that don't have enough assurance that the modem is isolated. If you really want to add support for a device with a modem that is not isolated, several options are possible: * The Replicant project can help you upstream the code in some other projects like Linux or LineageOS * If the modem runs fully free software the isolation is not an issue anymore, but making the modem run fully free software would be a huge amount of work. * It is probably possible to isolate modems with shared memory but it could require a big amount of work and/or require fully free bootloaders with IOMMU support. h2. History and modem shared memory When Replicant was started, the HTC Dream was the only available Android phone, and it had a Qualcomm System On a Chip (SOC) with an integrated modem. We then also added support for other very similar devices. The System On a Chip family used by these devices was the MSM7K. While working on Replicant, very serious flaws were discovered with that System On a Chip family: * The modem (which runs only non-free software) handled things that were too 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 the modem to take control of the processor running Replicant. * The modem processor was in charge of booting the device. To do that it had to: ** Intialize all the system RAM ** Load the bootloader of the Application Processor in RAM and instruct that processor to run that code. * The modem also handled the GPS. This is also a concern for other devices with different System On a Chip like the Nokia N900. Despite the huge amount of work required, when alternatives became available, we switched away from devices with this 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, and the lack of strong guarantees that would prevent the modem from being able 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. Despite that, it may 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 that would require significant work. It would at least require: * to be able to use a mainline kernel (to be able to have some trust in the code) * to have public documentation 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. 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 tablets use Qualcomm SOCs have no modems. So if the most important privacy sensitive hardware is under the control of the Application Processor, it might be possible to add support for such tablets if work is done to make sure that they can be useful without any proprietary libraries. h2. Requirements 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. Several hardware mechanism that can bring them back exist: * 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). Note that some IOMMUs are very complicated to setup in a secure way. h2. System on a chip |_. 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. | | "boot process":http://tjworld.net/wiki/Android/HTC/Vision/BootProcess | | 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. | | *"Boot process":https://forum.xda-developers.com/showthread.php?t=1769411&page=25 *"The Security of chip fabric page of rpw-pacsec2013-hexagon.pdf":https://web.archive.org/web/20131224103934if_/https://rpw.io/slides/rpw-pacsec2013-hexagon.pdf | | Qualcomm | APQ* | No modem | | | | Samsung | Exynos 4210 | No modem | | | | Samsung | Exynos 4412 | No modem | | | | Texas Instruments (TI) | OMAP 4460 | * No modem * Has some DSP cores (no known use as modem, typically used for audio and video decoding offload) | | | h2. Devices 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. |_. Vendor |_. Device |_. Isolation |_. References | | Samsung | Nexus S | ? | ? | | Samsung | Galaxy S | ? | ? | h1. Isolated modems h2. Supported devices |_. Vendor |_. Device |_. Link |_. Isolation |_. References | |/8. Samsung | Galaxy Nexus (I9250) |/3. MIPI |/3. * With MIPI it's most probably not possible for the peripheral to access the host RAM | * "board-tuna.c:":https://git.replicant.us/replicant/kernel_samsung_tuna/plain/arch/arm/mach-omap2/board-tuna.c <pre> #ifdef CONFIG_OMAP_HSI_DEVICE if (TUNA_TYPE_MAGURO == omap4_tuna_get_type()) omap_hsi_init(); #endif </pre> * "modem_link_device_mipi.c":https://git.replicant.us/replicant/kernel_samsung_tuna/plain/drivers/misc/modem_if/modem_link_device_mipi.c | | Galaxy Tab 2 7.0 (P31xx) |/2. * "espresso_defconfig:":https://git.replicant.us/replicant/kernel_samsung_espresso10/plain/arch/arm/configs/espresso_defconfig?h=replicant-6.0 CONFIG_LINK_DEVICE_MIPI=y | | Galaxy Tab 2 10.1 (P51xx) | | Galaxy S 3 (I9300) |/5. HSIC |/5. * 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":https://github.com/fourkbomb/linux/commit/5c71c549206351c16412d23c38e3d8d62763f454 |/5. * "lineageos_i9300_defconfig:":https://git.replicant.us/replicant/kernel_samsung_smdk4412/plain/arch/arm/configs/lineageos_i9300_defconfig CONFIG_MODEM_M0 * "lineageos_i7000_defconfig:":https://git.replicant.us/replicant/kernel_samsung_smdk4412/plain/arch/arm/configs/lineageos_i7000_defconfig CONFIG_LINK_DEVICE_HSIC=y * "lineageos_i7100_defconfig:":https://git.replicant.us/replicant/kernel_samsung_smdk4412/plain/arch/arm/configs/lineageos_i7100_defconfig CONFIG_MODEM_M0 * "lineageos_i5100_defconfig:":https://git.replicant.us/replicant/kernel_samsung_smdk4412/plain/arch/arm/configs/lineageos_i5100_defconfig CONFIG_MODEM_M0 * "lineageos_i9100_defconfig:":https://git.replicant.us/replicant/kernel_samsung_smdk4412/plain/arch/arm/configs/lineageos_i9100_defconfig CONFIG_LINK_DEVICE_HSIC=y * "board-m0-modems.c":https://git.replicant.us/replicant/kernel_samsung_smdk4412/plain/arch/arm/mach-exynos/board-m0-modems.c | | Galaxy Note (N7000) | | Galaxy Note 2 (N7100) | | Galaxy Note 8.0 (N51xx) | | Galaxy S 2 (I9100) | h2. Powering off the modem h3. Android airplane mode interface The "RIL_REQUEST_RADIO_POWER command":https://git.replicant.us/LineageOS-mirror/android_hardware_ril/tree/include/telephony/ril.h#n2112 is used by the airplane mode. h3. current libsamsung-ril and libsamsung-ipc implementation "In libsamsung-ril, RIL_REQUEST_RADIO_POWER":https://git.replicant.us/replicant/hardware_ril_samsung-ril/tree/samsung-ril.c#n262 is implemneted in the "ril_request_radio_power":https://git.replicant.us/replicant/hardware_ril_samsung-ril/tree/power.c#n72 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. h3. Better implementation 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. h2. Research *Exploiting qualcomm wlan and modem over the air ("mp4":https://media.defcon.org/DEF%20CON%2027/DEF%20CON%2027%20video%20and%20slides/DEF%20CON%2027%20Conference%20-%20Xiling%20Gong%20-%20Exploiting%20Qualcomm%20WLAN%20and%20Modem%20Over%20The%20Air.mp4 "srt":https://media.defcon.org/DEF%20CON%2027/DEF%20CON%2027%20video%20and%20slides/DEF%20CON%2027%20Conference%20-%20Xiling%20Gong%20-%20Exploiting%20Qualcomm%20WLAN%20and%20Modem%20Over%20The%20Air.srt "srt": https://media.defcon.org/DEF%20CON%2027/DEF%20CON%2027%20video%20and%20slides/DEF%20CON%2027%20Conference%20-%20Xiling%20Gong%20-%20Exploiting%20Qualcomm%20WLAN%20and%20Modem%20Over%20The%20Air.srt "pdf":https://media.defcon.org/DEF%20CON%2027/DEF%20CON%2027%20presentations/DEFCON-27-Xiling-Gong-Peter-Pi-Exploiting-Qualcomm-WLAN-and-Modem-Over-The-Air.pdf is a presentation about gaining code execution in the Linux kernel by using bugs in code that runs in the modem. It shows that bypassing the IOMMU worked in certain conditions.