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]

Message-ID: <20090522101455.GD13482@elte.hu>
Date:	Fri, 22 May 2009 12:14:55 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc:	Paul Mackerras <paulus@...ba.org>, 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 <a.p.zijlstra@...llo.nl> wrote:

> On Fri, 2009-05-22 at 10:57 +0200, Ingo Molnar wrote:
> > * Peter Zijlstra <a.p.zijlstra@...llo.nl> wrote:
> > 
> > > On Fri, 2009-05-22 at 14:27 +1000, Paul Mackerras wrote:
> > > 
> > > > The equivalence of contexts is detected by keeping a pointer in
> > > > each cloned context pointing to the context it was cloned from.
> > > > To cope with the situation where a context is changed by adding
> > > > or removing counters after it has been cloned, we also keep a
> > > > generation number on each context which is incremented every time
> > > > a context is changed.  When a context is cloned we take a copy
> > > > of the parent's generation number, and two cloned contexts are
> > > > equivalent only if they have the same parent and the same
> > > > generation number.  In order that the parent context pointer
> > > > remains valid (and is not reused), we increment the parent
> > > > context's reference count for each context cloned from it.
> > > 
> > > > +	u32			generation;
> > > 
> > > 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?
> > 
> > i think it should be an u64.
> 
> So at to make the attack infeasible by death of the attacker and 
> burnout of the solar-system? :-)

Yeah. We only have to make it for the next 1 billion years anyway - 
then due to the sun being ~50% brighter the planet as we know it 
will be scorched up anyway. (Unless some entity puts it under 
massive space based shades until then, to preserve the ancient 
biosphere for nostalgic or museologic reasons or so.)

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