public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Liang, Kan" <kan.liang@linux.intel.com>
To: peterz@infradead.org
Cc: mingo@redhat.com, acme@kernel.org, linux-kernel@vger.kernel.org,
	ak@linux.intel.com, Mark Rutland <mark.rutland@arm.com>
Subject: Re: [PATCH] perf/x86: Reset the counter to prevent the leak for a RDPMC task
Date: Thu, 30 Jul 2020 11:54:35 -0400	[thread overview]
Message-ID: <cd65635b-d226-3089-cb4a-8f60ae408db5@linux.intel.com> (raw)
In-Reply-To: <20200730125817.GL2655@hirez.programming.kicks-ass.net>



On 7/30/2020 8:58 AM, peterz@infradead.org wrote:
> On Thu, Jul 30, 2020 at 05:38:15AM -0700, kan.liang@linux.intel.com wrote:
>> From: Kan Liang <kan.liang@linux.intel.com>
>>
>> The counter value of a perf task may leak to another RDPMC task.
> 
> Sure, but nowhere did you explain why that is a problem.
> 
>> The RDPMC instruction is only available for the X86 platform. Only apply
>> the fix for the X86 platform.
> 
> ARM64 can also do it, although I'm not sure what the current state of
> things is here.
> 
>> After applying the patch,
>>
>>      $ taskset -c 0 ./rdpmc_read_all_counters
>>      index 0x0 value 0x0
>>      index 0x1 value 0x0
>>      index 0x2 value 0x0
>>      index 0x3 value 0x0
>>
>>      index 0x0 value 0x0
>>      index 0x1 value 0x0
>>      index 0x2 value 0x0
>>      index 0x3 value 0x0
> 
> You forgot about:
> 
>   - telling us why it's a problem,

The non-privileged RDPMC user can get the counter information from other 
perf users. It is a security issue. I will add it in the next version.

>   - telling us how badly it affects performance.

I once did performance test on a HSX machine. There is no notable slow 
down with the patch. I will add the performance data in the next version.

> 
> I would feel much better if we only did this on context switches to
> tasks that have RDPMC enabled.

AFAIK, at least for X86, we can only enable/disable RDPMC globally.
How can we know if a specific task that have RDPMC enabled/disabled?

> 
> So on del() mark the counter dirty (if we don't already have state that
> implies this), but don't WRMSR. And then on
> __perf_event_task_sched_in(), _after_ programming the new tasks'
> counters, check for inactive dirty counters and wipe those -- IFF RDPMC
> is on for that task.
> 

The generic code doesn't have counters' information. It looks like we 
need to add a new callback to cleanup the dirty counters as below.

In the specific implementation of pmu_cleanup(), we can check and wipe 
all inactive dirty counters.

Is it OK?

diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
index 1cbf57dc2ac8..3daaf0a7746d 100644
--- a/arch/x86/events/core.c
+++ b/arch/x86/events/core.c
@@ -3774,6 +3781,15 @@ static void perf_event_context_sched_in(struct 
perf_event_context *ctx,
         if (!RB_EMPTY_ROOT(&ctx->pinned_groups.tree))
                 cpu_ctx_sched_out(cpuctx, EVENT_FLEXIBLE);
         perf_event_sched_in(cpuctx, ctx, task);
+
+	/*
+	 * Some leftovers from the previous task may still exist on the unused
+	 * counters. The new task may illegally read the counters, e.g. via
+	 * RDPMC. The information from the previous task will be leaked. Clean
+	 * up the PMU before enabling it.
+	 */
+	if (ctx->pmu->pmu_cleanup)
+		ctx->pmu->pmu_cleanup(pmu);
	perf_pmu_enable(ctx->pmu);

  unlock:



Thanks,
Kan

  reply	other threads:[~2020-07-30 15:54 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-30 12:38 [PATCH] perf/x86: Reset the counter to prevent the leak for a RDPMC task kan.liang
2020-07-30 12:58 ` peterz
2020-07-30 15:54   ` Liang, Kan [this message]
2020-07-30 16:44     ` peterz
2020-07-30 16:50       ` peterz
2020-07-31 18:08       ` Liang, Kan

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=cd65635b-d226-3089-cb4a-8f60ae408db5@linux.intel.com \
    --to=kan.liang@linux.intel.com \
    --cc=acme@kernel.org \
    --cc=ak@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.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