linux-kernel - [RFC][PATCH 0/2] /proc/<pid>/timerslack_ns & changes to extend timer_slack

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]

Date:	Mon,  8 Feb 2016 15:23:14 -0800
From:	John Stultz <john.stultz@...aro.org>
To:	lkml <linux-kernel@...r.kernel.org>
Cc:	John Stultz <john.stultz@...aro.org>,
	Arjan van de Ven <arjan@...ux.intel.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Oren Laadan <orenl@...lrox.com>,
	Ruchi Kandoi <kandoiruchi@...gle.com>,
	Rom Lemarchand <romlem@...roid.com>,
	Kees Cook <keescook@...omium.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Android Kernel Team <kernel-team@...roid.com>
Subject: [RFC][PATCH 0/2] /proc/<pid>/timerslack_ns & changes to extend timer_slack_ns to u64 on 32bit systems

Here's a first pass on some patches discussed on Friday, to add
a /proc/<pid>/timerslack_ns interface which would allow
controlling processes to be able to set the timerslack value on
other processes in order to save power by avoiding wakeups
(Something Android currently does via out-of-tree patches).

The first patch tries to fix the internal timer_slack_ns usage
which was defined as a long, which limits the slack range to
~4 seconds on 32bit systems. It converts it to a u64, which
provides the same basically unlimited slack (500 years) on both
32bit and 64bit machines.

The second patch introduces the /proc/<pid>/timerslack_ns
interface which allows the full 64bit slack range for a task
to be read or set on both 32bit and 64bit machines.

With these two patches, on a 32bit machine, after setting the
slack on bash to 10 seconds:
$ time sleep 1

real    0m10.747s
user    0m0.001s
sys     0m0.005s

The first patch is a little ugly, since I had to chase the slack
delta arguments through a number of functions converting them to
u64s. Let me know if it makes sense to break that up more or not.

The second patch is fairly straight forward. My only slight
concern is that I'm worried the change suggested to move from
CAP_SYS_NICE to PTRACE_MODE_ATTACH might be problematic, because
it means the controlling thread will need elevated permissions.

While I agree CAP_SYS_NICE normally can only tweak scheduling
priority, and can't stall processes as much as adjusting
timerslack, I worry PTRACE_MODE_ATTACH might be too high,
allowing for much more invasive interactions, making the
controlling task a problematic attack surface. So if there are
suggestions for some in-between permission to use, that might
be helpful.

Feedback and review thoughts would be greatly appreciated!

thanks
-john

Cc: Arjan van de Ven <arjan@...ux.intel.com>
Cc: Thomas Gleixner <tglx@...utronix.de>
Cc: Oren Laadan <orenl@...lrox.com>
Cc: Ruchi Kandoi <kandoiruchi@...gle.com>
Cc: Rom Lemarchand <romlem@...roid.com>
Cc: Kees Cook <keescook@...omium.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>
Cc: Android Kernel Team <kernel-team@...roid.com>

John Stultz (2):
  timer: Convert timer_slack_ns from unsigned long to u64
  proc: Add /proc/<pid>/timerslack_ns interface

 Documentation/filesystems/proc.txt | 18 ++++++++++
 fs/eventpoll.c                     |  2 +-
 fs/proc/base.c                     | 69 ++++++++++++++++++++++++++++++++++++++
 fs/select.c                        |  8 ++---
 include/linux/freezer.h            |  2 +-
 include/linux/hrtimer.h            | 12 ++++---
 include/linux/poll.h               |  2 +-
 include/linux/sched.h              |  4 +--
 kernel/sys.c                       |  5 ++-
 kernel/time/hrtimer.c              |  8 ++---
 kernel/time/timer.c                |  4 +--
 11 files changed, 113 insertions(+), 21 deletions(-)

-- 
1.9.1