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: <20131031225022.GJ16735@n2100.arm.linux.org.uk>
Date:	Thu, 31 Oct 2013 22:50:22 +0000
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Ming Lei <tom.leiming@...il.com>, linux-kernel@...r.kernel.org,
	Rusty Russell <rusty@...tcorp.com.au>,
	linux-arm-kernel@...ts.infradead.org, Michal Marek <mmarek@...e.cz>
Subject: Re: [PATCH] scripts/kallsyms: filter symbols not in kernel address
	space

On Thu, Oct 31, 2013 at 03:43:11PM -0700, Andrew Morton wrote:
> On Mon, 28 Oct 2013 23:48:59 +0800 Ming Lei <tom.leiming@...il.com> wrote:
> 
> > This patch uses CONFIG_PAGE_OFFSET to filter symbols which
> > are not in kernel address space because these symbols are
> > generally for generating code purpose and can't be run at
> > kernel mode, so we needn't keep them in /proc/kallsyms.
> > 
> > For example, on ARM there are some symbols which are
> > linked in relocatable code section, then perf can't parse
> > symbols any more from /proc/kallsyms, and this patch fixes
> > the problem.
> 
> This is a non-back-compatible change and I'd like to see a much
> stronger assurance that it is safe to merge and will not break any
> existing application on the planet, please.
> 
> For a start, please describe with great precision what these excluded
> symbols are (examples would help) and explain why no application will
> conceivably have had any use for them.

These symbols are used to build what is relocatable code; the code which
ends up being placed in the machine vectors and the following page.

Rather than have to manually calculate them, I merged a patch which used
the tools we have, namely the assembler and linker, to do the job for us.
Unfortunately, these symbols have ended up in kallsyms, which various
programs read, and having symbols down at the lower 8k is not what they
expect.

What it means is we don't have to play these kinds of games in the
assembler:

-       .equ    stubs_offset, __vectors_start + 0x1000 - __stubs_start
 __vectors_start:
-       W(b)    vector_rst + stubs_offset
-       W(b)    vector_und + stubs_offset
-       W(ldr)  pc, .LCvswi + stubs_offset
-       W(b)    vector_pabt + stubs_offset
-       W(b)    vector_dabt + stubs_offset
-       W(b)    vector_addrexcptn + stubs_offset
-       W(b)    vector_irq + stubs_offset
-       W(b)    vector_fiq + stubs_offset

where each vector_* symbol is located at an address greater than
__stubs_start.  Here's the obvious question: can you understand what's
going on with all that?
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ