Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Qualcomm binaries #691
Comments
thestinger
added
the
Status: invalid
label
Aug 9, 2017
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
thestinger
Aug 9, 2017
Contributor
Presume this has to do with VoLTE/WiFi calling
Yes, and also because we're including it on Pixels from the start since it was included in the 'naked' android-prepare-vendor list so we should be including it on Nexus devices for consistency. If we choose to leave out an app, that needs to be done consistently. It's referenced by AOSP so it doesn't count as an optional carrier component which we're currently leaving out (thus Sprint doesn't work at all) but rather part of the baseline SoC support.
It's Java code so you can audit it almost as easily as sources. It's only missing comments, variable names, etc. The libraries it uses were already included via vendor.img and those are native code so they're harder to audit but not black boxes. It's not like people are exhausting auditing the open source code.
The app runs as system which is very privileged but not actually as full root:
u:r:system_app:s0 system 1674 691 1514088 79948 SyS_epoll_ 0000000000 S com.quicinc.cne.CNEService
I just have from personal experience little trust in Qualcomm, then again what do I know.
They make the SoC including the CPU, GPU, baseband, DSP, ISP, IOMMU, memory controller, storage controller, GPS, media acceleration (video / audio decode/encode and more), crypto acceleration, etc. There's very little that doesn't involve Qualcomm on a Qualcomm SoC device. The Nexus 5X and Pixel phones also have a Qualcomm WiFi SoC too.
Yes, and also because we're including it on Pixels from the start since it was included in the 'naked' android-prepare-vendor list so we should be including it on Nexus devices for consistency. If we choose to leave out an app, that needs to be done consistently. It's referenced by AOSP so it doesn't count as an optional carrier component which we're currently leaving out (thus Sprint doesn't work at all) but rather part of the baseline SoC support. It's Java code so you can audit it almost as easily as sources. It's only missing comments, variable names, etc. The libraries it uses were already included via vendor.img and those are native code so they're harder to audit but not black boxes. It's not like people are exhausting auditing the open source code. The app runs as system which is very privileged but not actually as full root:
They make the SoC including the CPU, GPU, baseband, DSP, ISP, IOMMU, memory controller, storage controller, GPS, media acceleration (video / audio decode/encode and more), crypto acceleration, etc. There's very little that doesn't involve Qualcomm on a Qualcomm SoC device. The Nexus 5X and Pixel phones also have a Qualcomm WiFi SoC too. |
thestinger
closed this
Aug 9, 2017
thestinger
added
Device: Nexus 5X
Device: Nexus 6P
labels
Aug 9, 2017
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
securesearch
commented
Aug 9, 2017
|
Does RCSService need to be present though? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment|
There isn't a compelling reason to remove it. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
securesearch
Aug 9, 2017
Hmm, OK. As I said, sorry for wasting your time if that is what I'm doing. It would seem compelling to disable/remove unnecessary services if it doesn't cause breakage to remove potentially exploitable code especially since there are no plans to support RCS. I realize it is not a major issue and I won't press it further, just seems logical to me. Thanks for replying.
securesearch
commented
Aug 9, 2017
|
Hmm, OK. As I said, sorry for wasting your time if that is what I'm doing. It would seem compelling to disable/remove unnecessary services if it doesn't cause breakage to remove potentially exploitable code especially since there are no plans to support RCS. I realize it is not a major issue and I won't press it further, just seems logical to me. Thanks for replying. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
thestinger
Aug 9, 2017
Contributor
I don't want to deviate more from the baseline for SoC support right now, it causes too many problems. There's no one available to spend time properly testing the removing code like that and it hasn't been confirmed that it's even reachable in the first place right now.
|
I don't want to deviate more from the baseline for SoC support right now, it causes too many problems. There's no one available to spend time properly testing the removing code like that and it hasn't been confirmed that it's even reachable in the first place right now. |
securesearch commentedAug 9, 2017
Hope you can forgive if this is a waste of your time. Noticed that the latest update added Qualcomm's com.quicinc.cne.CNEService.CNEServiceApp. Under the impression this was proprietary Qualcomm code to deal with "seamless" WiFi-Cellular transitions that appeared back in 2013.
Presume this has to do with VoLTE/WiFi calling and is likely not too major an issue, even though there have been some unverified claims that CNEService uses mobile data aggressively and potentially sends sensitive metadata to Qualcomm. That CNEService runs with root privileges would also seem problematic, but then again is not surprising. Sorry if you view this as low priority. I just have from personal experience little trust in Qualcomm, then again what do I know.
Also recall you tweeted a while back saying Rich Communication Services (RCS) were dated and unnecessary (I agree) and that CopperheadOS would not be supporting it. If so, imho it would seem unnecessary to keep RCSService around which is present on the current release unless there is something I have overlooked.
Forgive me if I just wasted your time. I am grateful for what you do. Your project is still the most practical and security conscious, least invasive, and likely most user-transparent mobile OS out there. I hope it will stay that way to the extent possible and have many sustainable years to come.