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]
Date:	Thu, 24 Oct 2013 09:45:59 +0100
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Rusty Russell <rusty@...tcorp.com.au>
Cc:	Ming Lei <tom.leiming@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, Chen Gang <gang.chen@...anux.com>,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [RFC PATCH] kernel/kallsyms.c: only show legal kernel symbol

On Thu, Oct 24, 2013 at 11:51:18AM +1030, Rusty Russell wrote:
> Ming Lei <tom.leiming@...il.com> writes:
> > Address of non-module kernel symbol should always be located
> > from CONFIG_PAGE_OFFSET on, so only show these legal kernel
> > symbols in /proc/kallsyms.
> >
> > On ARM, some symbols(see below) may drop in relocatable code, so
> > perf can't parse kernel symbols any more from /proc/kallsyms, this
> > patch fixes the problem.
> >
> > 	00000000 t __vectors_start
> > 	00000020 A cpu_v7_suspend_size
> > 	00001000 t __stubs_start
> > 	00001004 t vector_rst
> > 	00001020 t vector_irq
> > 	000010a0 t vector_dabt
> > 	00001120 t vector_pabt
> > 	000011a0 t vector_und
> > 	00001220 t vector_addrexcptn
> > 	00001224 t vector_fiq
> > 	00001224 T vector_fiq_offset
> >
> > The issue can be fixed in scripts/kallsyms.c too, but looks this
> > approach is easier.
> 
> This fix looks hacky; if these symbols are not available, don't just
> remove them from /proc/kallsyms, but don't put them in the kernel at
> all.

How do you "don't put them in the kernel at all" when they're used by
the kernel internally as offsets?

If you mean, just get rid of them, shall I just add these as magic
numbers instead based on the values in this email?  Is that really a
sane solution?

No, we have to keep these symbols IMHO.
--
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