linux-kernel - Re: [RFC] ELF Relocatable x86 and x86

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:	Tue, 1 Aug 2006 15:26:28 -0400
From:	Vivek Goyal <vgoyal@...ibm.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	fastboot@...l.org, linux-kernel@...r.kernel.org,
	Horms <horms@...ge.net.au>,
	Jan Kratochvil <lace@...kratochvil.net>,
	"H. Peter Anvin" <hpa@...or.com>,
	Magnus Damm <magnus.damm@...il.com>,
	Linda Wang <lwang@...hat.com>
Subject: Re: [RFC] ELF Relocatable x86 and x86_64 bzImages

On Tue, Aug 01, 2006 at 04:58:49AM -0600, Eric W. Biederman wrote:
> 
> The problem:
> 
> We can't always run the kernel at 1MB or 2MB, and so people who need
> different addresses must build multiple kernels.  The bzImage format
> can't even represent loading a kernel at other than it's default address.
> With kexec on panic now starting to be used by distros having a kernel
> not running at the default load address is starting to become common.
> 
> The goal of this patch series is to build kernels that are relocatable
> at run time, and to extend the bzImage format to make it capable of
> expressing a relocatable kernel.
> 
> In extending the bzImage format I am replacing the existing unused bootsector
> with an ELF header.  To express what is going on the ELF header will
> have type ET_DYN.  Just like the kernel loading an ET_DYN executable
> bootloaders are not expected to process relocations.  But the executable
> may be shifted in the address space so long as it's alignment requirements
> are met.
> 
> The x86_64 kernel is simply built to live at a fixed virtual address
> and the boot page tables are relocated.  The i386 kernel is built
> to process relocations generated with --embedded-relocs (after vmlinux.lds.S)
> has been fixed up to sort out static and dynamic relocations.

Hi Eric,

Can't we use the x86_64 relocation approach for i386 as well? I mean keep
the virtual address space fixed and updating the page tables. This would
help in the sense that you don't have to change gdb if somebody decides to
debug the relocated kernel.

Any such tool that retrieves the symbol virtual address from vmlinux will
be confused.

Thanks
Vivek 
-
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/