chrome://power should report average frequency for cpu that use intel_pstate |
||||
Issue descriptionNewer Intel CPUs use pstate driver and no longer target specific frequency. In chrome://power, we used time in state to report cpu frequency. We should change it to report average frequency instead. https://crrev.com/c/1054578 has example code to query that in autotests.
,
Jun 11 2018
+Nikhil, as well who may already be working on this as part of a bigger chrome://power overhaul
,
Jun 11 2018
,
Jun 13 2018
While working on this, it was determined we needed access to /dev/cpu/*/msr (the autotests did this as well). This is readable/writable only by root. After discussing offline, it was determined that letting this be readable/writable from powerd was not a good idea due to security considerations. The power user is designed to be low-privileged and letting it access extremely precise hardware precision temperature/timing counters would expand the surface area for potential exploits. Additionally specific timing/temperature information is used in various security exploits such as spectre and if powerd had the ability to write to these registers, it would also be able to disable protections against hardware bugs. For a low-privileged daemon, it seems like this is too many privileges to allot it. The long-term solution to this problem seems to be to write a new native daemon that can give controlled access to information from the MSRs to specific users.
,
Jun 14 2018
Instead of new daemon for access MSRs, IMO it is easier to have new CHROMIUM kernel patch that expose aperf/mperf/tsc to debugfs or sysfs instead.
,
Jun 15 2018
Based on the conversation, I'm going to untag GoodFirstBug and unassign this. |
||||
►
Sign in to add a comment |
||||
Comment 1 by la...@chromium.org
, Jun 11 2018