linux-kernel - RE: [bug] kpti, perf_event, bts: sporadic truncated trace

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

Message-ID: <alpine.LSU.2.11.1807131111440.6085@eggly.anvils>
Date:   Fri, 13 Jul 2018 11:31:41 -0700 (PDT)
From:   Hugh Dickins <hughd@...gle.com>
To:     "Metzger, Markus T" <markus.t.metzger@...el.com>
cc:     Hugh Dickins <hughd@...gle.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...hat.com>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        "Shishkin, Alexander" <alexander.shishkin@...el.com>,
        "Kleen, Andi" <andi.kleen@...el.com>,
        "Hansen, Dave" <dave.hansen@...el.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Stephane Eranian <eranian@...gle.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: RE: [bug] kpti, perf_event, bts: sporadic truncated trace

On Fri, 13 Jul 2018, Metzger, Markus T wrote:
> Hello Hugh,
> 
> > A little "optimization" crept into alloc_bts_buffer() along the way, which now
> > places bts_interrupt_threshold not on a record boundary.
> > And Stephane has shown me the sentence in Vol 3B, 17.4.9, which says "This
> > address must point to an offset from the BTS buffer base that is a multiple of the
> > BTS record size."
> > 
> > Please give the patch below a try, and let us know if it helps (if it does not, then I
> > think we'll need perfier expertise than I can give).
> > 
> > Hugh
> > 
> > --- 4.18-rc4/arch/x86/events/intel/ds.c	2018-06-03 14:15:21.000000000 -0700
> > +++ linux/arch/x86/events/intel/ds.c	2018-07-12 17:38:28.471378616 -0700
> > @@ -408,9 +408,11 @@ static int alloc_bts_buffer(int cpu)
> >  	ds->bts_buffer_base = (unsigned long) cea;
> >  	ds_update_cea(cea, buffer, BTS_BUFFER_SIZE, PAGE_KERNEL);
> >  	ds->bts_index = ds->bts_buffer_base;
> > -	max = BTS_RECORD_SIZE * (BTS_BUFFER_SIZE / BTS_RECORD_SIZE);
> > -	ds->bts_absolute_maximum = ds->bts_buffer_base + max;
> > -	ds->bts_interrupt_threshold = ds->bts_absolute_maximum - (max / 16);
> > +	max = BTS_BUFFER_SIZE / BTS_RECORD_SIZE;
> > +	ds->bts_absolute_maximum = ds->bts_buffer_base +
> > +					max * BTS_RECORD_SIZE;
> > +	ds->bts_interrupt_threshold = ds->bts_absolute_maximum -
> > +					(max / 16) * BTS_RECORD_SIZE;
> >  	return 0;
> >  }
> > 
> 
> Your patch fixes it.

Oh, very welcome news! Thanks for putting in all the effort you did to
track down from your end: I'm relieved it was easier to fix than that.

> 
> Will you send it to the list for inclusion?

Sure, I'll send to x86 guys and lkml later today.  I can't promise that
it will make 4.18, since the regression it fixes pre-dates 4.18-rc; but
they don't usually insist on that rule for something as small and benign
as this, so I expect it'll make it.

> I'd appreciate if it could also be backported
> to 4.15, 4.16, and 4.17.

I'll mark it Cc stable, so that it will soon percolate through to the
4.14 longterm and 4.17 stable trees.  But 4.15 and 4.16 stable trees are
now EOL, so you'll have to apply the patch where you need it yourself -
it has no release-dependent subtlety, it should apply cleanly at offset.

Hugh