linux-kernel - Re: [PATCH] oprofile: disable write access to oprofilefs while profiler is running

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 11 Oct 2010 17:39:42 +0200
From:	Robert Richter <robert.richter@....com>
To:	Maynard Johnson <maynardj@...ibm.com>
CC:	LKML <linux-kernel@...r.kernel.org>,
	oprofile-list <oprofile-list@...ts.sourceforge.net>,
	William Cohen <wcohen@...hat.com>,
	"Suthikulpanit, Suravee" <Suravee.Suthikulpanit@....com>
Subject: Re: [PATCH] oprofile: disable write access to oprofilefs while
 profiler is running

On 11.10.10 09:48:02, Maynard Johnson wrote:
> Robert, I don't have any issue with this patch except I'm not sure what problem 
> it's fixing.  From my read of oprofile userland code, I don't see where 
> profiling parameters are ever written to oprofilefs when profiling is active. 
> Is your patch intended to guard against potential non-intentional cases 
> occurring in userland code?  Or is there some case existing right now?

The kernel updates the counter configuration during profiling only
when the counters are started. Since sampling data and its
representation depends on the counter configuration, we do not want to
change the configuration in-flight. Otherwise the daemon may not know
which configuration was used for which sample.

Instead, userland is required to restart profiling which also flushes
cpu buffers. Thus, the daemon always is aware of the configuration
which was used when the kernel wrote a sample.

This may happen e.g. for IBS samples, where certain options may be
enabled using oprofilefs. We want to know which options are set while
a sample is written and make sure, the options do not change. There is
another case, the latest patch I sent that implements IBS branch
target address reporting extends the IBS sample size if its option is
set. To always proper parse the sampling data by the daemon, we must
ensure the sampling data is consistent over one profiling session and
sample size does not change.

As we rely on not writing to the configuration while profiling and
since this works with the current daemon, I added the check.

-Robert

-- 
Advanced Micro Devices, Inc.
Operating System Research Center

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