linux-kernel - Re: managing kallsyms

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] [day] [month] [year] [list]

Date:	Thu, 31 Jan 2008 17:44:27 -0500
From:	Robin Getz <rgetz@...ckfin.uclinux.org>
To:	"Paulo Marques" <pmarques@...popie.com>
Cc:	"Rusty Russell" <rusty@...tcorp.com.au>,
	linux-kernel@...r.kernel.org, "Sam Ravnborg" <sam@...nborg.org>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: managing kallsyms_addresses

On Thu 31 Jan 2008 12:27, Paulo Marques pondered:
> Robin Getz wrote:
> > When the kernel needs to find out what symbol is at a specific address, it 
> > uses kallsyms_lookup() This seems to work pretty well - almost.
> > 
> > The problem is today, we don't to remove the symbols from the init section 
> > when the init section is freed. There is invalid data in
> > kallsyms_addresses. 
> > [...]
> > There would be two solutions:
> >  - when freeing the init section, remove all the init labels from the 
> > kallsyms_addresses, and resort/pack it.
> 
> This should be doable, but to be worth it, we would need to use 
> different structures for the init symbols, that would be stored in 
> __initdata.
> 
> Then, ideally we would have separate functions in the __init section to 
> look up symbols in those structures that would only be called until we 
> released the init sections.
> 
> On the plus side, this would avoid the "repacking" the kallsyms 
> structures to remove the init labels.

I think this would be a good long term thing, but would require restructuring 
of all the kallsyms scripts, as well as everything in the kernel...

> >  - if the init section is unloaded, have is_kernel_inittext always 
> >  return 0. 
> 
> This is by far the simplest solution. I even STR a patch floating around 
> to do this, by I can't seem to locate it now... :(

I can put something together if Rusty agrees this is the way to go.

> > I assume that similar things need to be handled for module init too, but I 
> > have not run into that yet.
> 
> It seems that at least the last solution should be easy enough to 
> implement there.
> 
> > Thoughts?
> 
> I think that the simplest solution (the second one) is probably the best 
> for now.
> 
> One thing that did cross my mind though, is stuff like lockdep.

Hmmm - I would need to defer to Ingo to understand the dependencies in lockdep 
and init labels/addresses in kallsyms_addresses.

> If we run a locking sequence that is called from init code, and later a 
> different locking sequence is used when we already freed init data, how 
> can the debug information show the names of the functions that generated 
> the previous locking sequence?

Maybe the lockdep needs to keep track of the label, not the address.

> It seems that the only "correct" approach would be to store a "before 
> freeing init sections" flag together with the function pointer, and then 
> have a kallsyms interface that could receive this flag to know where to 
> look.
> 
> In that case, the first solution can not be used at all (because we need 
> to keep the init symbols anyway) and the second solution could be simply 
> implemented by having a default value for the flag that is the "current 
> state" for that flag...

That seems a little cumbersome to me...

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