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

On Tuesday 08 August 2006 03:58, Horms wrote:
> On Tue, Aug 08, 2006 at 01:23:15AM -0600, Eric W. Biederman wrote:
> > Horms <horms@...ge.net.au> writes:
<snip>
> > For maintenance reasons I propose we introduce CONFIG_PHYSICAL_ALIGN.
> > Which will round our load address up to the nearest aligned address
> > and run the kernel there.  That is roughly what I am doing on x86_64
> > at this point.
> >
> > s/CONFIG_PHYSICAL_START/CONFIG_PHYSICAL_ALIGN/ gives me well defined
> > behavior and allows the alignment optimization without getting into
> > weird semantics.
> >
> > Before CONFIG_PHYSICAL_START we _always_ ran the arch/i386 kernel
> > where it was loaded and I assumed we always would.  Since people have
> > realized better aligned kernels can run better this assumption became
> > false.  Going to CONFIG_PHYSICAL_ALIGN allows us to return to the
> > simple assumption of always running the kernel where it is loaded
> > modulo a little extra alignment.
>
> That sounds reasonable to me. Though it is a little less flexible,
> do you think that could be a problem? Perhaps we could have both,
> though that would probably be quite confusing.

More than reasonable. By changing this it seems that the kernel would still 
work with older bootloaders, function properly under kexec and might actually 
lead to a way to potentially recover a system from a crash without a reboot 
by allowing the kexec'd kernel to reset the system.

Of course the last is only a wish... Never happen because of the complexity 
involved. It would require a lot of work (I'd do this, but I'm currently 
arguing with the kernel over my attempts at building a functional DRM backed 
console) in having to switch back to real-mode to make the proper BIOS calls 
to reset the busses et. al. before switching *back* to kernel mode to run the 
standard startup.

Still, by letting a kernel run where it's loaded plus some modulo to get it 
properly aligned in memory solves several problems. It removes the need for 
CONFIG_PHYSICAL_START and the code involved in handling that. The kexec code 
that reserves memory for the new kernel image can be tweaked to always 
allocate the memory *aligned*...

Anyway, I'd better get back to the DRMCon code...

DRH
-
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/