linux-kernel - RE: [patch 0/2] x86, ptrace: support for branch trace store(BTS)

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: <029E5BE7F699594398CA44E3DDF5544401090315@swsmsx413.ger.corp.intel.com>
Date:	Tue, 4 Dec 2007 08:52:13 -0000
From:	"Metzger, Markus T" <markus.t.metzger@...el.com>
To:	"Andi Kleen" <ak@...e.de>, "Roland McGrath" <roland@...hat.com>
Cc:	<tglx@...utronix.de>, "Andrew Morton" <akpm@...ux-foundation.org>,
	<linux-kernel@...r.kernel.org>, <hpa@...or.com>,
	"Siddha, Suresh B" <suresh.b.siddha@...el.com>,
	"Michael Kerrisk" <mtk-manpages@....net>,
	<markus.t.metzger@...il.com>, "Ingo Molnar" <mingo@...e.hu>,
	"Markus Metzger" <markus.t.metzger@...glemail.com>
Subject: RE: [patch 0/2] x86, ptrace: support for branch trace store(BTS)

>-----Original Message-----
>From: Andi Kleen [mailto:ak@...e.de] 
>Sent: Montag, 3. Dezember 2007 17:22

>> What did you have in mind when you asked for kernel-mode support?
>
>I asked about that earlier too and I would like to see per CPU traces
>for ring 0 with some way to dump that on crashes or on user trigger.

I will split it into two layers:
- a lower layer that does the DS/BTS configuration
- a higher layer that provides the ptrace interface

The lower layer works on a parameter DS pointer. Unfortunately,
this will be an unsigned long, since we have different DS/BTS layout
for different architectures.

The higher layer uses the lower layer to do the real work. It stores
a per-thread DS pointer in the thread_struct.

Kernel tracing would allocate a per_cpu array of DS pointers
and use the lower layer for all the real work. I would leave it
to someone who is more familiar with the kgdb patch, if that is OK.

What's left is proper resource managememt. The kernel use of
DS_SAVE_AREA
and DEBUGCTL conflicts with the ptrace use of those MSR's. As far as I
can
tell, this is missing for all MSR's. The single/block_stepping support 
certainly uses an optimistic approach.

I guess this is a certain amount of work. It needs the idea of an
'owner'
of such an MSR, some means to acquire and release it, a global
allocation 
order, some protection from others who simply try to use it. It needs to
be on register granularity for some; on bit granularity for others. It
needs to be global for some; per-thread for others. And it probably
needs 
a lot of error handling code in a lot of different areas.

I would hope that utrace is tackling some or all of these problems.
I would therefore stay optimistic in this patch and rework it once
utrace is in and provides a proper framework.
This seems to be the approach that the new block-stepping support takes.

thanks and regards,
markus.
---------------------------------------------------------------------
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen Germany
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer
Registergericht: Muenchen HRB 47456 Ust.-IdNr.
VAT Registration No.: DE129385895
Citibank Frankfurt (BLZ 502 109 00) 600119052

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
--
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/