linux-kernel - Re: [patch 0/3] [Announcement] Performance Counters for Linux

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]

Date:	Thu, 04 Dec 2008 17:12:33 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	tglx@...utronix.de
Cc:	linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
	akpm@...ux-foundation.org, mingo@...e.hu, eranian@...glemail.com,
	dada1@...mosbay.com, robert.richter@....com, arjan@...radead.org,
	hpa@...or.com, a.p.zijlstra@...llo.nl, rostedt@...dmis.org,
	paulus@...ba.org
Subject: Re: [patch 0/3] [Announcement] Performance Counters for Linux

From: Thomas Gleixner <tglx@...utronix.de>
Date: Thu, 04 Dec 2008 23:44:39 -0000

>  - No interaction with ptrace: any task (with sufficient permissions) can
>    monitor other tasks, without having to stop that task.

This isn't going to work.

If you look at the things the perfmon libraries do, you do need to
stop the task.

Consider counter virtualization as the most direct example.  Perfmon
allows you to count 6 events even if you can only monitor 2 at a time
with your hardware.  It does this by periodically changing the counter
configuration during the run of the program(s) being inspected.  These
control register changes and counter captures have to be atomic or
else you'll get garbage or less accurate results.

There are entire families of cases where you want to perform a
sequence of operations on the control registers and counters if one of
them overflows.  And these operations must be atomic.  The only way
to ensure this is to stop the task, then let the library in the
monitoring task make the changes, and finally let the library
release that task.

The crux of the matter is, when a counter overflows, what you want to
do in response to that event is non-trivial and it must be performed
without letting the monitored task continue executing.  So you have to
stop the task, and unless you want tons of cpu specific knowledge and
counter virtualization support code in the kernel, we want userspace
telling the kernel how to program the registers.  And since we have
to stop the task, there is no benefit doing this work in the kernel
anyways.

If you don't like the NMI and IPI business on x86 in the perfmon
patches, suggest alternatives.
--
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/