WAI
Status Update
Comments
nn...@google.com <nn...@google.com> #2
Thank you for filing this bug report.
The removal of /proc/stat was intentional. /proc/stat leaks side channel information about applications which could allow one application to infer the state of other applications on the device. Seehttps://www.cl.cam.ac.uk/~lmrs2/publications/interrupts_pets16.pdf for example.
The removal of /proc/stat was intentional. /proc/stat leaks side channel information about applications which could allow one application to infer the state of other applications on the device. See
tl...@gmail.com <tl...@gmail.com> #3
Is there a replacement API available to retrieve basic CPU utilization information? Android 6/7/8 have gradually removed all /proc-based APIs without offering any replacement. There is little-to-no-means for a user to determine the cause of CPU-usage based battery drain.
There are multiple solutions to this problem:
1.) Adding an Android API to retrieve this information with a slight bit of noise and less precision. Simply reporting global CPU stime+utime with a maximum query interval of one second should do the trick.
2.) Add a permission to allow access to such system information, perhaps one that must be manually enabled (as is the case with accessibility services). In my previous report on a similar issue, this suggestion was vetoed on the basis that users would be tricked into granting it. I still fail to understand this reasoning given that APIs such as the accessibility service grant applications access to so much device-state information as to make a procfs side-channel attack irrelevant.
There are multiple solutions to this problem:
1.) Adding an Android API to retrieve this information with a slight bit of noise and less precision. Simply reporting global CPU stime+utime with a maximum query interval of one second should do the trick.
2.) Add a permission to allow access to such system information, perhaps one that must be manually enabled (as is the case with accessibility services). In my previous report on a similar issue, this suggestion was vetoed on the basis that users would be tricked into granting it. I still fail to understand this reasoning given that APIs such as the accessibility service grant applications access to so much device-state information as to make a procfs side-channel attack irrelevant.
mi...@gmail.com <mi...@gmail.com> #4
As a "common user" I would consider this a withdrawal of functionality. It would render some of my favorite (and most expensive) apps less useful. I would hope and expect the devs to find some way to deliver equivalent functionality.
fe...@gmail.com <fe...@gmail.com> #5
What about /proc/interrupts? Is this file still accessible in Android O?
All the sensitive interrupt information can be also read from there in addition to /proc/stat.
All the sensitive interrupt information can be also read from there in addition to /proc/stat.
de...@gmail.com <de...@gmail.com> #6
There is already API in Android to get CPU usage info, starting from API level 24:
HardwarePropertiesManager propertiesManager = (HardwarePropertiesManager)context.getSystemService(Context.HARDWARE_PROPERTIES_SERVICE);
CpuUsageInfo[] cpuUsages = propertiesManager.getCpuUsages();
But only system apps have access to this API, because only system apps can have android.permission.DEVICE_POWER permission, which is needed here.
So, I think, it would be enough to give all apps access to this API to solve the issue.
HardwarePropertiesManager propertiesManager = (HardwarePropertiesManager)context.getSystemService(Context.HARDWARE_PROPERTIES_SERVICE);
CpuUsageInfo[] cpuUsages = propertiesManager.getCpuUsages();
But only system apps have access to this API, because only system apps can have android.permission.DEVICE_POWER permission, which is needed here.
So, I think, it would be enough to give all apps access to this API to solve the issue.
nn...@google.com <nn...@google.com> #7
Re comment #5 : /proc/interrupts is also similarly restricted, as it leaks side channel information about the global state of the device.
Re comment #6 : opening up that API would defeat the intent of these changes. Applications needing per-process CPU information should likely use /proc/self/stat instead of /proc/stat.
Re
te...@gmail.com <te...@gmail.com> #8
Is there another way to get total CPU usage load in Android O now without access to /proc/stat? My app can no longer read CPU usage, and it was one of its main functions.
k....@gmail.com <k....@gmail.com> #9
Ok, having in mind that access to /proc/stat is restricted for a reason, tell me, as a "common user", how to see my CPU usage of device when all of apps stopped working? Having in mind that I OWN this device I MUST have access to this information. If we "common users" want to use our devices for only "facebook/phone/mail" then we can freely go for iOS, there is tons of restrictions already. These devices are first of all computers....
ma...@gmail.com <ma...@gmail.com> #10
On Android O, is there any system app that, as a *common user*, can use to see the total cpu usage?
tl...@gmail.com <tl...@gmail.com> #12
#11. That CPU monitor app, like my own, only shows CPU frequency on Android 8.
CPU clock is unfortunately a poor indicator of processor utilization and battery drain. I recently added clock frequency recording to my own SystemPanel2 app, and have noticed CPU usage and clock frequency can be *inversely proportional* in many cases. They'll line up when you're looking at intense CPU use (e.g. playing a game), but when a user is looking for inexplicable battery drain, CPU clock frequency is more often not useful.
Attached screenshot of SystemPanel2 is on an Android 7 device with root access (required to record CPU usage per-process on 7). Note that during the period of highest CPU utilization and battery drain, the average CPU clock frequency is quite low.
In my opinion there should be a permission-protected but publicly accessible API to retrieve recent CPU usage. Round the values and update it at 2 second intervals, leave out interrupt data, and these side channel attacks are irrelevant.
CPU clock is unfortunately a poor indicator of processor utilization and battery drain. I recently added clock frequency recording to my own SystemPanel2 app, and have noticed CPU usage and clock frequency can be *inversely proportional* in many cases. They'll line up when you're looking at intense CPU use (e.g. playing a game), but when a user is looking for inexplicable battery drain, CPU clock frequency is more often not useful.
Attached screenshot of SystemPanel2 is on an Android 7 device with root access (required to record CPU usage per-process on 7). Note that during the period of highest CPU utilization and battery drain, the average CPU clock frequency is quite low.
In my opinion there should be a permission-protected but publicly accessible API to retrieve recent CPU usage. Round the values and update it at 2 second intervals, leave out interrupt data, and these side channel attacks are irrelevant.
Description
It is no longer possible to determine the CPU utilization of the device.
This has severe negative consequences for system and battery monitoring applications and denies the user the ability to correct problems with his/her device.