Qualcomm binaries #691

Closed
securesearch opened this Issue Aug 9, 2017 · 5 comments

Comments

Projects
None yet
2 participants
@securesearch

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.

@thestinger

This comment has been minimized.

Show comment Hide comment
@thestinger

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.

Contributor

thestinger commented Aug 9, 2017

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.

@securesearch

This comment has been minimized.

Show comment Hide comment
@securesearch

securesearch Aug 9, 2017

Does RCSService need to be present though?

Does RCSService need to be present though?

@thestinger

This comment has been minimized.

Show comment Hide comment
@thestinger

thestinger Aug 9, 2017

Contributor

There isn't a compelling reason to remove it.

Contributor

thestinger commented Aug 9, 2017

There isn't a compelling reason to remove it.

@securesearch

This comment has been minimized.

Show comment Hide comment
@securesearch

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.

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.

@thestinger

This comment has been minimized.

Show comment Hide comment
@thestinger

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.

Contributor

thestinger commented Aug 9, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment