Forums » Devices evaluations »
i9500 (Galaxy S4)
Added by steve . almost 10 years ago
Has anyone evaluated the i9500 in depth? I obviously like the newer specs compared to the i9300.
It seems to still have an Exynos processor, which implies the modem might be isolated. This is my #1 concern.
Looking through its CM11 proprietary-files.txt, I see the firmware blob for audio codec as mentioned in the i9505 thread. I personally view proprietary firmware similar to proprietary silicon, and I would use wifi/bluetooth blob on Replicant, but realize the project stance is a bit different.
Other than those, it seems to have the usual closed libraries that could be stripped out. For my use, I don't even necessarily require the cell radio (mifi instead), but that option would be nice and I would imagine it would be necessary for official Replicant support.
Replies (13)
RE: i9500 (Galaxy S4) - Added by steve . almost 10 years ago
The only information I can find mentions X-GOLD636 (PMB9820) for both the i9500 and SM-G900H (S5). The i9300/i9100 are XGOLD626, so I'd guess the 636 is an incremental upgrade that wouldn't be hard to make work with Replicant.
I found a block diagram in a business presentation (http://www.slideshare.net/jjwu6266/smart-phone-in-2013 p63/p69) where the baseband processor's main RAM is contained in the same package as the eMMC flash.
However, the million dollar question is what the heck that interface between processor/cell modem actually looks like! I can't find a data sheet for XGOLD636. I found a torrent of some 626 information at xda-developers that mentions AHB/AXI buses, which seem like common ARM things. I could dig into that to see what power the slave has, but I'm not entirely sure that's even the correct interface, or what else might be going on between the chips.
What was done to investigate the i9300's isolation? There's obviously a scale from "does not use snapdragon" to "ongoing randomized reverse engineering of PCBs", with the Replicant due diligence being somewhere in the middle. It would be nice to see the specifics on the wiki.
RE: i9500 (Galaxy S4) - Added by Paul Kocialkowski almost 10 years ago
Well I'm a bit worried about the huge screen resolution, it may be too slow. I think modem isolation could be good, I'd have to look in-depth and do a proper evaluation. It would be a shame if audio was to require loaded firmwares, but that's not a show-stopper. The bootloader is certainly signed and non-free, as usual.
RE: i9500 (Galaxy S4) - Added by steve . almost 10 years ago
I went ahead and got one. What I really wanted was a wifi-only tablet, but I couldn't find anything that would fit in my pocket and had a modern amount of RAM.
I didn't look close enough to realize Cyanogenmod is still only releasing nightlies (if it follows the S3 schedule then a snapshot will drop in January?). It is a CM11 only device which implies a future Replicant 4.4 (and why would CM backport?) so perhaps the project isn't ready for that.
It's currently running a CM11 nighty, with a Debian installation along side (no SIM card, so no idea about radio functionality). I'll probably take a look inside some time, but wait to start fooling with removing proprietary software bits until CM stabilizes.
Is there a general Replicant porting guide somewhere? How do most Android apps react when you start removing eg 3d graphics libraries?
RE: i9500 (Galaxy S4) - Added by Paul Kocialkowski almost 10 years ago
Indeed, the Galaxy S 4 (I9500) won't be supported in Replicant 4.2, but if it could make an interesting target for 4.4, it's worth taking a good look at it.
Is there a general Replicant porting guide somewhere? How do most Android apps react when you start removing eg 3d graphics libraries?
Well, it's more complicated than that, you have to somewhat adapt the rest of the system to handle the lack of graphics acceleration as best as possible, so it involves code changes (that are specific to each version of Android apparently) and hence rebuilding the image from scratch. Just taking CM a removing a few libraries won't do.
RE: i9500 (Galaxy S4) - Added by Paul Kocialkowski almost 10 years ago
In the meantime, could you provide some radio logs: adb logcat -b radio? and perhaps dmesg too.
RE: i9500 (Galaxy S4) - Added by Kurtis Hanna about 5 years ago
I think that the exynos versions of the Galaxy S4 and the Galaxy S5 are the last versions in the Galaxy S series that still have decent modem isolation.
RE: i9500 (Galaxy S4) - Added by Jack K almost 5 years ago
Hi Kurtis,
What makes you think that later Galaxy S series phones with Exynos SoCs have poor modem isolation?
Thanks,
Jack
RE: i9500 (Galaxy S4) - Added by Kurtis Hanna almost 5 years ago
Hi Jack,
Thanks for your question. The Exynos version of the Samsung Galaxy S6 uses the Exynos7420 SoC, which has a LTE Modem on the SoC itself. https://en.wikipedia.org/wiki/Exynos#List_of_Exynos_Modems
All Galaxy S series phones that came after this one also has a LTE modem on the SoC. It is my assumption that if there is a modem on the SoC it isn't isolated to the degree that Replicant requires.
Cordially,
Kurtis
RE: i9500 (Galaxy S4) - Added by Andrés D almost 5 years ago
They maybe have IOMMU like recent Qualcomm SOCs have. GrapheneOS uses that IOMMU to isolate radios (NFC, Wi-Fi, Bluetooth, Cellular), among other hardware like GPU, media engine, image processor, etc.
Before considering the modem correctly isolated, we need to investigate if IOMMU exist and how to configure it to not allow the modem access the RAM freely.
Andrés
RE: i9500 (Galaxy S4) - Added by Denis 'GNUtoo' Carikli almost 5 years ago
- QualcommSOCs This has infos on what would be required to support devices with Qualcomm SOCs, including infos about why having an IOMMU is not sufficient.
- HardwareRequirements has infos on Android versions requirements. For newer devices this is less an issue.
We can add any target in the TargetsEvaluation page. All you need to do to do that is to ask for wiki write permissions and source the information.
More recently I've been adding some devices there to understand which devices with an Exynos SOC have or lack a removable battery.
One day I'd like to add also the devices we support as the kind of information stored there is also interesting when working on Replicant supported devices.
I also added Qualcomm devices as well in the Upstream page as it helps getting a more global picture of the devices supported upstream.
It's for instance important to know about it when interacting with people or doing conferences about Replicant or to plan the Replicant project directions.
- Replicant 9 would, technically, be able to support upstream devices regardless of the freedom issues they have
- Replicant want to limit the damage as much as possible with freedom, so we don't want to support the worst devices freedom wise.
Note that devices supported by Replicant are far from being good for freedom, but we try to improve things over time, for instance by supporting better devices and dropping the worst ones or working to improve the ones we have if we can.
So if we find some upstream project willing to accept to support the devices with the "worst freedom":- Replicant could share the maintenance of the code made for Replicant 9 with another Android distribution
- The other Android distribution would be able to support more devices in return
- Replicant would not have any pressure to support the devices that are the worst for freedom
Though when we look at the Galaxy SIII (I9300) there is still a lot to do before everything gets upstream as the modem driver will need to be seriously adapted.
So even if it looks very close there is still work to do. The Note II also needs some work to upstream its display drivers among other things.
RE: i9500 (Galaxy S4) - Added by Kurtis Hanna almost 5 years ago
Denis on IRC said, related to the IOMMU being used for modem isolation, "Also we'd need a free bootloader and more freedom to make sure that the mode is isolated else how can you make sure that the isolation is done before the RAM is initialized?"
The Exynos version of the Galaxy S6's bootloader was hacked here: https://wikileaks.org/ciav7p1/cms/files/cadmium.pdf
Perhaps the same principles could be used for the Galaxy S4 or S3.
RE: i9500 (Galaxy S4) - Added by Denis 'GNUtoo' Carikli almost 5 years ago
If I remember well, the cadmium document doesn't help at all in replacing the nonfree bootloader.
When you buy a device new, the bootloader checks the signature of the boot.img, this document explains how to bypass that.
So you have the bootrom which checks the signature of the bootloader, which checks the signature of the boot.img and recovery.img.
When you unlock the bootloader, you can replace the boot.img and recovery.img but doing that often erase the data.
So the CIA exploits the bootloader, probably to dump or modify the data.
If the bootloader wasn't signed you could simply run another bootloader to bypass all security checks.
- The bootloader is nonfree and loads another OS (Mobicore) in TrustZone so we cannot trust our devices anymore
- The security benefits are void because the CIA and the free software community can bypass it very easily:
- We also do have working free software exploit for the Galaxy SIII. This gives you the ability to run your own C code in the bootloader environment, so you can do whatever you want with that and it's easy to work with. If we find a register to make the bootrom boot on a microSD at next boot, we could experiment with u-boot very easily but as far as I know no one knows if such register exists for that SOC.
- For the Galaxy SIII (I9300), Galaxy SIII 4G (I9305), Galaxy Note II (N7100), Galaxy Note II 4G (n7105) you can simply boot a nonfree version of u-boot instead of the stock bootloader. This is even documented on Replicant wiki as it is relevant to the work to understand if we can completely get rid of the nonfree bootloader.
- On xda-developers forum there are ways to recover devices (this is called unbrickable mod) to do that without needing to port u-boot to your device.
RE: i9500 (Galaxy S4) - Added by Denis 'GNUtoo' Carikli almost 5 years ago
Note that for the IOMMU spefifically, there is some information in the QualcommSOCs page
Ideally we should probably make this page more generic as it doesn't only apply to Qualcomm SOCs.
The page is about Qualcomm SOCs because:- They are more common and well known than other SOCs with similar freedom issues
- We have more knowledge about it (that we gained while working on the early Replicant version that supported Qualcomm SOCs)