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: <20160122153428.8422f42877c7707dbcba0259@linux-foundation.org>
Date:	Fri, 22 Jan 2016 15:34:28 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Ard Biesheuvel <ard.biesheuvel@...aro.org>
Cc:	linux-kernel@...r.kernel.org, linux-s390@...r.kernel.org,
	linuxppc-dev@...ts.ozlabs.org, x86@...nel.org,
	keescook@...omium.org, mingo@...nel.org, hpa@...or.com,
	heiko.carstens@...ibm.com, benh@...nel.crashing.org,
	mpe@...erman.id.au, mmarek@...e.cz, rusty@...tcorp.com.au,
	arnd@...db.de, linux-arch@...r.kernel.org
Subject: Re: [PATCH v3] kallsyms: add support for relative offsets in
 kallsyms address table

On Thu, 21 Jan 2016 18:19:43 +0100 Ard Biesheuvel <ard.biesheuvel@...aro.org> wrote:

> Similar to how relative extables are implemented, it is possible to emit
> the kallsyms table in such a way that it contains offsets relative to some
> anchor point in the kernel image rather than absolute addresses. The benefit
> is that such table entries are no longer subject to dynamic relocation when
> the build time and runtime offsets of the kernel image are different. Also,
> on 64-bit architectures, it essentially cuts the size of the address table
> in half since offsets can typically be expressed in 32 bits.
> 
> Since it is useful for some architectures (like x86) to retain the ability
> to emit absolute values as well, this patch adds support for both, by
> emitting absolute addresses as positive 32-bit values, and addresses
> relative to the lowest encountered relative symbol as negative values, which
> are subtracted from the runtime address of this base symbol to produce the
> actual address.
> 
> Support for the above is enabled by default for all architectures except
> IA-64, whose symbols are too far apart to capture in this manner.

scripts/kallsyms.c: In function 'record_relative_base':
scripts/kallsyms.c:744: error: 'ULLONG_MAX' undeclared (first use in this function)
scripts/kallsyms.c:744: error: (Each undeclared identifier is reported only once
scripts/kallsyms.c:744: error: for each function it appears in.)

That's with (ancient) glibc-headers-2.5-3.  It appears that limits.h's
ULLONG_MAX requires "#ifdef __USE_ISOC99".  I'm not sure what's the
correct way of turning this on.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ