public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mark Rutland <mark.rutland@arm.com>
To: Jin Yao <yao.jin@linux.intel.com>
Cc: acme@kernel.org, jolsa@kernel.org, peterz@infradead.org,
	mingo@redhat.com, alexander.shishkin@linux.intel.com,
	Linux-kernel@vger.kernel.org, ak@linux.intel.com,
	kan.liang@intel.com, yao.jin@intel.com, will.deacon@arm.com
Subject: Re: [PATCH v2] perf/core: Drop kernel samples even though :u is specified
Date: Tue, 23 May 2017 11:58:21 +0100	[thread overview]
Message-ID: <20170523105820.GC14542@leverpostej> (raw)
In-Reply-To: <1495534570-3964-1-git-send-email-yao.jin@linux.intel.com>

Hi,

On Tue, May 23, 2017 at 06:16:10PM +0800, Jin Yao wrote:
> When doing sampling, for example,
> 
> perf record -e cycles:u ...
> 
> On workloads that do a lot of kernel entry/exits we see kernel
> samples, even though :u is specified. This is due to skid existing.
> 
> This is a security issue because it can leak kernel addresses even
> though kernel sampling support is disabled.
> 
> The patch drops the kernel samples if exclude_kernel is specified.

[...]

> +static bool skid_kernel_samples(struct perf_event *event, struct pt_regs *regs)

The name is a bit opaque, especially where it is used in
__perf_event_overflow(). 

How about we invert the polarity and call this sample_is_allowed() ?

> +{
> +	/*
> +	 * We may get kernel samples even though exclude_kernel
> +	 * is specified due to potential skid in sampling.
> +	 * The skid kernel samples could be dropped or just do
> +	 * nothing by testing the flag PERF_PMU_CAP_NO_SKID.
> +	 */
> +	if (event->pmu->capabilities & PERF_PMU_CAP_NO_SKID)
> +		return false;

Do we need this new cap?

I'd expect user_mode(regs) to be about as cheap as testing the cap, and
the common case is going to be that we we have test both.

For those PMUs without skid, when not sampling the kernel,
user_mode(regs) should always be true.

IMO, it would make more sense to just check user_mode(regs), which also
avoids any surprises with unexpected skid...

> +
> +	if (event->attr.exclude_kernel &&
> +	    !user_mode(regs) &&
> +	    (event->attr.sample_type & PERF_SAMPLE_IP)) {
> +		return true;
> +	}
> +
> +	return false;
> +}

How about:

static bool sample_is_allowed(struct perf_event *event, struct pt_regs *regs)
{
	/*
	 * Due to interrupt latency (AKA "skid"), we may enter the
	 * kernel before taking an overflow, even if the PMU is only
	 * counting user events.
	 *
	 * To avoid leaking information to userspace, we must always
	 * reject kernel samples when exclude_kernel is set.
	 */
	if (!user_mode(regs) && event->attr.exclude_kernel &&
	    (event->attr.sample_type & PERF_SAMPLE_IP))
		return false;

	return true;
}

... do we need to reject any other sample types, or do we definitely
avoid leaks by other means?

> +
>  /*
>   * Generic event overflow handling, sampling.
>   */
> @@ -7337,6 +7357,12 @@ static int __perf_event_overflow(struct perf_event *event,
>  	ret = __perf_event_account_interrupt(event, throttle);
>  
>  	/*
> +	 * For security, drop the skid kernel samples if necessary.
> +	 */
> +	if (skid_kernel_samples(event, regs))
> +		return ret;
> +

.. with the above changes, this can be:

	if (!sample_is_allowed(event, regs))
		return ret;

Thanks,
Mark.

  reply	other threads:[~2017-05-23 10:59 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-23 10:16 [PATCH v2] perf/core: Drop kernel samples even though :u is specified Jin Yao
2017-05-23 10:58 ` Mark Rutland [this message]
2017-05-23 12:32   ` Jin, Yao

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=20170523105820.GC14542@leverpostej \
    --to=mark.rutland@arm.com \
    --cc=Linux-kernel@vger.kernel.org \
    --cc=acme@kernel.org \
    --cc=ak@linux.intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=jolsa@kernel.org \
    --cc=kan.liang@intel.com \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=will.deacon@arm.com \
    --cc=yao.jin@intel.com \
    --cc=yao.jin@linux.intel.com \
    /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