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: <7c86c4470811190459y5996f51bp24ab38c9e856c2eb@mail.gmail.com>
Date:	Wed, 19 Nov 2008 13:59:30 +0100
From:	"stephane eranian" <eranian@...glemail.com>
To:	"Metzger, Markus T" <markus.t.metzger@...el.com>
Cc:	"Markus Metzger" <markus.t.metzger@...glemail.com>,
	"Ingo Molnar" <mingo@...e.hu>, "Andi Kleen" <andi@...stfloor.org>,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: debugctl msr

Markus,

You are right about the reserved field, it was missing from my code
but that was harmless.

I had to hack ds.c some more to make forward progress with PEBS. First
of all my PEBS code is
in a kernel module, so all PEBS functions have to be exported.
Furhtermore, I need a
ds_get_pebs_thres() and ds_set_pebs_thres() calls.

But the one key problem is ds_validate_access(). I had to disable this
function. The problem is that
with perfmon there can be several threads who need access to the PEBS
fields. Take the simple
case of a tool attaching to a running process to attach the monitoring
harness. The tool's thread
is called ds_request_pebs(), so it is marked as the owner. But on PEBS
buffer full overflow, the
monitored thread is the current thread and it needs to know the
position in the buffer, therefore
it calls ds_get_pebs_index(). With perfmon a session is identified by
a file descriptor, any thread
with access to the file descriptor can access the session's data and
thus may need PEBS access.
For instance, if the monitoring tool is multi-threaded, then any
thread can access the PEBS data.

On Wed, Nov 19, 2008 at 1:14 PM, Metzger, Markus T
<markus.t.metzger@...el.com> wrote:
>>-----Original Message-----
>>From: stephane eranian [mailto:eranian@...glemail.com]
>>Sent: Dienstag, 18. November 2008 23:01
>>To: Markus Metzger
>>Cc: Metzger, Markus T; Ingo Molnar; Andi Kleen; Andrew Morton;
>>linux-kernel@...r.kernel.org
>>Subject: Re: debugctl msr
>>
>
>>I think your definition for ds_cfg_64 is wrong. On Core, the PEBS
>>record ALWAYS includes r8-r15 even on
>>32 bits (zero filled). Also the DS_AREA has 9 fields, not 8.
>>Consequently, I think the structure should be defined
>>as follows:
>>
>>static const struct ds_configuration ds_cfg_64 = {
>>        .sizeof_ds    = 8 * 9,
>
> You are right that there are 9 fields.
> However, the 9th field is double the size of the other fields and the entire structure is padded.
> The original code should read 8 * 12 to reflect that.
>
>>        .sizeof_field = 8,
>>        .sizeof_rec[ds_bts]   = 8 * 3,
>>        .sizeof_rec[ds_pebs]  = 8 * 18
>
> You're right about the PEBS size.
>
> I will send a patch some time this week.
>
> thanks,
> 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/