linux-kernel - Re: [PATCH 5/9] perf/x86: implement cross-HT corruption bug workaround

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CABPqkBQ9_HWN-LbwoxqDY52gHjevA_8fSoYbcv=wp04Rtp2ESg@mail.gmail.com>
Date:	Thu, 5 Jun 2014 16:26:38 +0200
From:	Stephane Eranian <eranian@...gle.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	"mingo@...e.hu" <mingo@...e.hu>,
	"ak@...ux.intel.com" <ak@...ux.intel.com>,
	Jiri Olsa <jolsa@...hat.com>,
	"Yan, Zheng" <zheng.z.yan@...el.com>,
	Maria Dimakopoulou <maria.n.dimakopoulou@...il.com>
Subject: Re: [PATCH 5/9] perf/x86: implement cross-HT corruption bug workaround

On Thu, Jun 5, 2014 at 4:21 PM, Peter Zijlstra <peterz@...radead.org> wrote:
> On Thu, Jun 05, 2014 at 04:15:17PM +0200, Stephane Eranian wrote:
>> On Thu, Jun 5, 2014 at 4:04 PM, Peter Zijlstra <peterz@...radead.org> wrote:
>> > On Wed, Jun 04, 2014 at 11:34:14PM +0200, Stephane Eranian wrote:
>> >> +
>> >> +     /*
>> >> +      * Modify static constraint with current dynamic
>> >> +      * state of thread
>> >> +      *
>> >> +      * EXCLUSIVE: sibling counter measuring exclusive event
>> >> +      * SHARED   : sibling counter measuring non-exclusive event
>> >> +      * UNUSED   : sibling counter unused
>> >> +      */
>> >> +     for_each_set_bit(i, cx->idxmsk, X86_PMC_IDX_MAX) {
>> >> +             /*
>> >> +              * exclusive event in sibling counter
>> >> +              * our corresponding counter cannot be used
>> >> +              * regardless of our event
>> >> +              */
>> >> +             if (xl->state[i] == INTEL_EXCL_EXCLUSIVE)
>> >> +                     __clear_bit(i, cx->idxmsk);
>> >> +             /*
>> >> +              * if measuring an exclusive event, sibling
>> >> +              * measuring non-exclusive, then counter cannot
>> >> +              * be used
>> >> +              */
>> >> +             if (is_excl && xl->state[i] == INTEL_EXCL_SHARED)
>> >> +                     __clear_bit(i, cx->idxmsk);
>> >> +     }
>> >> +
>> >> +     /*
>> >> +      * recompute actual bit weight for scheduling algorithm
>> >> +      */
>> >> +     cx->weight = hweight64(cx->idxmsk64);
>> >
>> > So I think we talked about this a bit; what happens if CPU0 (taking your
>> > 4 core HSW-client) is first to program its counters and takes all 4 in
>> > exclusive mode?
>> >
>> > Then there's none left for CPU4.
>> >
>> > Did I miss where we avoid that problem, or is that an actual issue?
>>
>> Yes, this patch series does not address this problem yet. It will be
>> in a second series.
>> Don't have a good solution yet.
>
> We could limit each cpu to num_counters/2 exclusive slots. That'll still
> be painful with some constrained events I imagine, but in general that
> should 'work' I suppose.

That is probably the easiest solution, just modify the dynamic constraint
mask some more. Have not yet tried it.

The repatriation of the leaked count is not so easy either. Need to IPI
the other HT. There may be some restrictions as to when we can
safely do this.
--
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/