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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 20 Jan 2016 11:33:25 +0100
From:	Ingo Molnar <mingo@...nel.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, akpm@...ux-foundation.org, hpa@...or.com,
	heiko.carstens@...ibm.com, benh@...nel.crashing.org,
	mpe@...erman.id.au, mmarek@...e.cz, rusty@...tcorp.com.au
Subject: Re: [PATCH 0/4] support for text-relative kallsyms table


* Ard Biesheuvel <ard.biesheuvel@...aro.org> wrote:

> This implements text-relative kallsyms address tables. This was developed as 
> part of my series to implement KASLR/CONFIG_RELOCATABLE for arm64, but I think 
> it may be beneficial to other architectures as well, so I am presenting it as a 
> separate series.
> 
> The idea is that on 64-bit builds, it is rather wasteful to use absolute 
> addressing for kernel symbols since they are all within a couple of MBs of each 
> other. On top of that, the absolute addressing implies that, when the kernel is 
> relocated at runtime, each address in the table needs to be fixed up 
> individually.
> 
> Since all section-relative addresses are already emitted relative to _text, it 
> is quite straight-forward to record only the offset, and add the absolute 
> address of _text at runtime when referring to the address table.
> 
> The reduction ranges from around 250 KB uncompressed vmlinux size and 10 KB 
> compressed size (s390) to 3 MB/500 KB for ppc64 (although, in the latter case, 
> the reduction in uncompressed size is primarily __init data)

So since kallsyms is in unswappable kernel RAM, the uncompressed size reduction is 
what we care about mostly. How much bootloader load times are impacted is a third 
order concern.

IOW a nice change!

Thanks,

	Ingo

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ