linux-kernel - [PATCH] mechanism to disable built in cpu frequency drivers/governors. (v1)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <1331680720-18268-1-git-send-email-konrad.wilk@oracle.com>
Date:	Tue, 13 Mar 2012 19:18:38 -0400
From:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
To:	davej@...hat.com, cpufreq@...r.kernel.org,
	linux-kernel@...r.kernel.org, JBeulich@...e.com
Subject: [PATCH] mechanism to disable built in cpu frequency drivers/governors. (v1)

The purpose of these patches is two-fold:
 1) Remove weird performance issues encountered in the field where the
    Linux kernel cpufreq scaling drivers would change the P-states while the
    Xen hypervisor would do the same.
 2) Provide a runtime knob from within the kernel to disable the cpu frequency
    API (akin to the behavior of "#CONFIG_CPU_CPUFREQ is not set").

The patches are based on the mechanism that Len Brown came up for the cpuidle
drivers - where there is a disable_cpuidle() call. His patches also provided
a module parameter - but I wasn't sure whether that is something you would want.
(for reference, Len's patch is d91ee5863b71e8c90eaf6035bff3078a85e2e7b5)

The other way of disabling the cpufreq scaling drivers from being invoked
is by thwarting the cpufreq drivers from loading by influencing their startup
checks.  For powernow-k8 that is easy - disallow the RDMSR (and that is currently
happening). For acpi-cpufreq I am not sure what could be done - the calls it
makes are to the ACPI libraries which we need for other uses.

Another solution I thought off was to provide a cpufreq governor that would
be a nop, and hence end up not calling the cpufreq scaling drivers. But that
just seems heavy-handed and I am not sure how the decision of when to load it
(and set it) would be done.

 arch/x86/xen/setup.c      |    1 +
 drivers/cpufreq/cpufreq.c |   24 ++++++++++++++++++++++++
 include/linux/cpufreq.h   |    2 ++
 3 files changed, 27 insertions(+), 0 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/