mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Andrew Vagin <avagin@openvz.org>, Arun Sharma <asharma@fb.com>,
	Oleg Strikov <OSTRIKOV@nvidia.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Ingo Molnar <mingo@kernel.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC] [PATCH 0/5] Teach perf tool to profile sleep times (V4)
Date: Mon, 04 Jun 2012 09:46:38 -0400	[thread overview]
Message-ID: <1338817598.13348.497.camel@gandalf.stny.rr.com> (raw)
In-Reply-To: <1338813658.28282.43.camel@twins>

On Mon, 2012-06-04 at 14:40 +0200, Peter Zijlstra wrote:

> The one thing I'm not entirely sure of is if this is a sekjoerity issue
> or not.. anybody? I would think a task was entitled to know who woke it
> and wherefrom etc..

"sekjoerity"? Sure, play games with us native English speakers, who
would pronounce that as "seek-joe-rity" and be totally confused :-p
Who's joe, and why are we seeking him?

Anyway, the answer is yes it is. Well, that's because *everything* in
the kernel is a security issue. Now the real question is, can someone
use it to do harm. Well, yes. But can they use it to do more harm than
they can with other methods that exist today? Probably not.

An attacker with an unprivileged account could probably analyze a system
with just 'ps', to figure out what they can and cannot do. Perhaps they
could use perf to analyze what other things are happening, and even set
up their tools to use perf to time attacks. A wakeup can tell a user if
they were blocked on a mutex, and who just let go of that mutex to wake
the user up.

Can this information be used to continue some other kind of attack?
Maybe. But is it a big enough risk that it outweighs the usefulness of
the tool? Probably not.

As I said earlier, all kernel issues deal with finding joe. But the
question is a simple matter of risk vs usability. If you want your
system to be really secure, then lock it in a vault and do not allow
anything to connect to it. That is minimizing risk, but at the cost of
usability.

If a sysadmin doesn't want this open, then just have them keep the
paranoid level up for activating perf, and do not let users run it.

-- Steve



  parent reply	other threads:[~2012-06-04 13:46 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-04  8:09 Andrew Vagin
2012-06-04  8:09 ` [PATCH 1/5] sched: event: add trace events when a task starts executing on a cpu Andrew Vagin
2012-06-04  8:09 ` [PATCH 2/5] sched: send the event sched_switch before perf_event_task_sched_out Andrew Vagin
2012-06-04  8:09 ` [PATCH 3/5] sched: save a previous state on task_struct Andrew Vagin
2012-06-04  8:09 ` [PATCH 4/5] perf: teach "perf inject" to work with files Andrew Vagin
2012-06-04  8:09 ` [PATCH 5/5] perf: teach perf inject to merge sched_switch* events for profiling sleep times Andrew Vagin
2012-06-04 12:40 ` [RFC] [PATCH 0/5] Teach perf tool to profile sleep times (V4) Peter Zijlstra
2012-06-04 12:50   ` Peter Zijlstra
2012-06-04 13:46   ` Steven Rostedt [this message]
2012-06-04 17:01   ` Arun Sharma
2012-06-04 20:52     ` Peter Zijlstra
2012-06-06  8:32   ` Ingo Molnar
2012-06-12 13:15   ` Andrew Wagin
2012-06-12 17:46     ` Peter Zijlstra
2012-06-04 17:03 ` Arun Sharma

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1338817598.13348.497.camel@gandalf.stny.rr.com \
    --to=rostedt@goodmis.org \
    --cc=OSTRIKOV@nvidia.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=asharma@fb.com \
    --cc=avagin@openvz.org \
    --cc=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®