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-next>] [day] [month] [year] [list]
Message-ID: <m1d5bk2046.fsf@ebiederm.dsl.xmission.com>
Date:	Tue, 01 Aug 2006 04:58:49 -0600
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	<fastboot@...l.org>
Cc:	<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>,
	Vivek Goyal <vgoyal@...ibm.com>, Linda Wang <lwang@...hat.com>
Subject: [RFC] ELF Relocatable x86 and x86_64 bzImages


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.

Currently there are 33 patches in my tree to do this.

The weirdest symptom I have had so far is that page faults did not
trigger the early exception handler on x86_64 (instead I got a reboot).

There is one outstanding issue where I am probably requiring too much alignment
on the arch/i386 kernel.  

Can anyone find anything else?

Eric
-
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