linux-kernel - RE: [PATCH] x86, perf, bts: disable BTS from Nehalem to Ivy Bridge

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: <A78C989F6D9628469189715575E55B2307B648E7@IRSMSX102.ger.corp.intel.com>
Date:	Thu, 24 Jan 2013 16:17:26 +0000
From:	"Metzger, Markus T" <markus.t.metzger@...el.com>
To:	Ingo Molnar <mingo@...nel.org>
CC:	"mingo@...hat.com" <mingo@...hat.com>,
	"mingo@...e.hu" <mingo@...e.hu>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Mark Kettenis <kettenis@....org>,
	Pedro Alves <palves@...hat.com>,
	Jan Kratochvil <jan.kratochvil@...hat.com>,
	"gdb-patches@...rceware.org" <gdb-patches@...rceware.org>
Subject: RE: [PATCH] x86, perf, bts: disable BTS from Nehalem to Ivy Bridge

> -----Original Message-----
> From: gdb-patches-owner@...rceware.org [mailto:gdb-patches-owner@...rceware.org] On Behalf Of Ingo Molnar
> Sent: Thursday, January 24, 2013 4:47 PM

> > Starting with Nehalem, the BTS "from" information may in some cases be
> > incorrect (AAJ122).
> >
> > This has been detected while adding branch tracing support to gdb, where it
> > results in sporadic test fails.
> >
> > Disable BTS support on Nehalem, Westmere, Sandy Bridge, and Ivy Bridge.
> 
> But the failures are rare, so the BTS data is still correct
> statistically, by and large, right? So why not just keep it
> as-is and teach tooling to be more robust about implausible
> trace entries? It has to be ready for that eventuality *anyway*.

Yes, the fails are rare. They are frequent enough, however, to cause sporadic test fails.

The problem is that you can't reliably detect such fails. In the worst case, GDB would show wrong but plausible trace. Typically, GDB just shows garbage (i.e. impossible trace) in such cases.

I'm afraid one might endlessly debate whether the feature as-is is useful or not. It is working fine on Atom so I chose to disable it on core.

The GDB folks would rather not disable the feature inside GDB; they prefer that it is disabled in the kernel. There will be an additional check inside GDB to support older kernel versions.

Regards,
markus.
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen, Deutschland
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk
Registergericht: Muenchen HRB 47456
Ust.-IdNr./VAT Registration No.: DE129385895
Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052

--
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/