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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ