linux-kernel - RE: debugctl msr

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: <029E5BE7F699594398CA44E3DDF5544402B1F123@swsmsx413.ger.corp.intel.com>
Date:	Wed, 12 Nov 2008 10:59:39 -0000
From:	"Metzger, Markus T" <markus.t.metzger@...el.com>
To:	<eranian@...il.com>
Cc:	"Ingo Molnar" <mingo@...e.hu>, "Andi Kleen" <andi@...stfloor.org>,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	<linux-kernel@...r.kernel.org>,
	"Markus Metzger" <markus.t.metzger@...glemail.com>
Subject: RE: debugctl msr

>-----Original Message-----
>From: stephane eranian [mailto:eranian@...glemail.com] 
>Sent: Mittwoch, 12. November 2008 11:10
>To: Markus Metzger

>>> For perfmon, PEBS can be used for both per-thread and per-cpu. With
>>> perfmon, the allocation/initialization of the buffer is 
>separated from its
>>> activation. In other words, allocation/initialization may 
>be done before
>>> you
>>> actually have to write the DS_AREA MSR. 
>Allocation/initialization may not
>>> necessary be done on the cpu you want to measure in per-cpu 
>mode. The
>>> logic of DS is different, ds_request_pebs() allocates and 
>immediately
>>> writes
>>> DS_AREA. I cannot use that.
>>
>> DS_AREA contains a pointer to the actual configuration struct.
>> The idea is that once I allocated the configuration struct, 
>I can write
>> the pointer to it into DS_AREA. It won't be used unless I 
>turn on a feature
>> that uses DS.
>> So, the flow is:
>> 1. allocate configuration struct
>> 2. write DS_AREA
>
>What if you are allocating the buffer for another task. For instance,
>a tool is attaching
>to a running process and wants to use PEBS. The tool allocates and
>initializes the
>PEBS buffer and then attaches it to the task to monitor (which is
>stopped). When the
>task is scheduled again, it picks up the PEBS buffer, and 
>DS_AREA is written to.

That tool should request DS for the task it intends to attach its
PEBS buffer to. Who knows, maybe PEBS is already in use for that task
by someone else. Or maybe there is a system wide BTS or PEBS session
and the per-task request would need to be rejected (until we can
support this scenario).



>There is another reason why the DS_AREA is exposed. This is 
>the only way for
>tools to see the current position in the PEBS buffer. They may 
>want to poll on
>that position index. The PEBS buffer is not necessarily full. What if
>the session
>terminates with a partial buffer. There must be a way for the 
>tool to figure out
>where the last sample is. By exposing DS read-only the index 
>is always available
>and always guaranteed current. Without this, the kernel would have to
>extract the
>index (pebs_get_index) and store it somewhere so the user can 
>see it. This copy
>could be tirggered by a PEBS buffer overflow or a stop of 
>monitoring. Sampling
>buffers formats currently do not have a stop callback but this can be
>added easily.

With the current interface, you would need to call ds_get_pebs_index().

The rfc patch I sent out some weeks ago in the scope of multiplexing
uses the approach you described - at least in-kernel.
Upon ds_request_pebs(), you would get a const struct pebs_tracer* that
contains a const view of the DS configuration.


In any case, I think the DS configuration needs to be allocated by ds.c
since we have two independent users that need to share a single
configuration.

Would it help if we changed the DS interface as proposed in that rfc
patch (without all the multiplexing stuff)?


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/