linux-kernel - Re: [PATCH 2/2] perf_counter: optimize context switch between identical inherited contexts

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:	Fri, 22 May 2009 19:29:31 +1000
From:	Paul Mackerras <paulus@...ba.org>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc:	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org,
	Corey Ashford <cjashfor@...ux.vnet.ibm.com>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 2/2] perf_counter: optimize context switch between
 identical inherited contexts

Peter Zijlstra writes:

> Suppose someone writes a malicious proglet that inherits the counters,
> puts the child to sleep, does 2^32 mods on the counter set, and then
> wakes up the child.
> 
> Would that merely corrupt the results, or make the kernel explode?

You'd have to do something like create some counters on yourself,
fork, do the 2^32 counter creations and deletions, then do another
fork.  All that would happen is that some of the counters would count
on one of the child processes when they should be counting on the
other.

But it would be easy and cheap to make the generation count be 64
bits, and then it won't overflow in my lifetime at least, and after
that I don't care. :)  So I agree with Ingo that we should just do
that.

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