linux-kernel - Re: [RFC] [patch 1/2] add non_init_kernel_text

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: <200712181823.54382.rusty@rustcorp.com.au>
Date:	Tue, 18 Dec 2007 18:23:53 +1100
From:	Rusty Russell <rusty@...tcorp.com.au>
To:	Srinivasa Ds <srinivasa@...ibm.com>
Cc:	ananth@...ibm.com, Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org,
	Masami Hiramatsu <mhiramat@...hat.com>,
	Jim Keniston <jkenisto@...ibm.com>
Subject: Re: [RFC] [patch 1/2] add non_init_kernel_text_address

On Tuesday 18 December 2007 17:46:15 Srinivasa Ds wrote:
> Rusty Russell wrote:
> > On Friday 14 December 2007 18:51:06 Ananth N Mavinakayanahalli wrote:
> >> On Thu, Dec 13, 2007 at 11:09:16PM -0800, Andrew Morton wrote:
> >>> regular_kernel_text_address()?  Dunno.
> >>
> >> Sounds better :-)
> >
> > The better answer was to invert it and use
> > "discarded_kernel_text_address()", which is what you actually care about
> > (rather than the details of whether it was init or not).
>
> Requirement is to ensure the address is really a kernel_text address and
> doesn't lie in __init section. Hence I used
> persistent_kernel_text_address().

Hi Srinivasa!

    That's not my point.  What you care about is that the text still be there.  
The fact that it's the __init section which is discarded is a detail; if some 
other text section were discarded you'd want that excluded too.  Hence 
non_init_ was a bad name; persistent is a bad name because it usually means 
something else in operating systems...

> > However, you have, in fact, located a potential bug.  If someone were to
> > kmalloc module text, then symbol_put() could fail.
>
> I don't think so, symbol_put() makes use of lookup_symbol() within
> __start_ksymtab and  stop_ksymtab.

Sorry, I meant symbol_put_addr().

> > How's this?
> > ---
> > Don't report discarded init pages as kernel text.
> >
> > In theory this could cause a bug in symbol_put() if an arch used for
> > a module: we might think the symbol belongs to the core kernel.
>
> Yes, usage of symbol_put_addr() cause the BUG() if it fails
> to find the address in core kernel.

No, symbol_put_addr() will fail to decrement the module count, thinking it's 
part of the (now-discarded) init section.

> > The downside is that this might make backtraces through (discarded)
> > init functions harder to read on some archs.
>
> I think it is better to make use of new function than sacrificing
> __init function symbol information in backtrace.

Perhaps, but two new functions is v. ugly.  I'll try to come up with something 
neater, and audit all the callers.

Thanks,
Rusty.
--
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/