linux-kernel - Re: [PATCH 5/9] jump label: Add register_jump_label_key/unregister_jump_label

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: <20101018140339.GA2814@redhat.com>
Date:	Mon, 18 Oct 2010 10:03:39 -0400
From:	Jason Baron <jbaron@...hat.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Steven Rostedt <rostedt@...dmis.org>, linux-kernel@...r.kernel.org,
	Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Frederic Weisbecker <fweisbec@...il.com>
Subject: Re: [PATCH 5/9] jump label: Add
	register_jump_label_key/unregister_jump_label_key

On Mon, Oct 18, 2010 at 02:05:21PM +0200, Peter Zijlstra wrote:
> On Fri, 2010-10-15 at 23:13 +0200, Peter Zijlstra wrote:
> > On Fri, 2010-10-15 at 17:09 -0400, Steven Rostedt wrote:
> > > On Fri, 2010-10-15 at 23:03 +0200, Peter Zijlstra wrote:
> > > 
> > > > Urgh, this sucks.. :-(
> > > > 
> > > > So now we have to actually track all JUMP_LABEL() sites and call
> > > > register muck on them.. even though we already track them through the
> > > > special data section.
> > > > 
> > > > Is there really no way around this?
> > > 
> > > I'll take a look to see if we can monkey with magic and automate it.
> > 
> > So the problem is something like:
> > 
> > core kernel:
> > 
> >  jump_label_enable()
> > 
> > module:
> > 
> >  JUMP_LABEL()
> > 
> > And then because we don't have a proper __jump_table section, the
> > jump_label_enable() won't properly work?
> > 
> > Why not let jump_label_enable() add a dummy entry with the enabled bit
> > and once you load the module merge the real entry into it.
> 
> Or actually use the value of the key pointer.. it would mean either
> standardizing the size (int/atomic_t would work), or using a version of
> the fallback JUMP_LABEL implementation to sort out the type issues.


So I initially implmented this as 'jump_label_enable()' would add a new
entry for the key, if it didn't already exist. However, I was concerned
about the case where module 'a' defined the key variable, and then
module 'b' did the enable/disable, and then module 'a' was removed and
thus the key value could be re-used, and module's 'b' key would mean
something different.

However, I'm not sure that is possible - since module 'b' would have
symbol dependency on module 'a', and thus module 'a' could not be
unloaded before module 'b'.

Thus, when a module is freed, I think we can scan all the keys and check
if any key is contained within the text section of the module that is
about to be freed. If so, we simply remove that key entry. does this
make sense?

thanks,

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