linux-kernel - Re: [PATCH 00/14] RFC: x86: relocatable kernel changes

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: <m14ovwz8ua.fsf@fess.ebiederm.org>
Date:	Thu, 07 May 2009 18:23:09 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	"H. Peter Anvin" <hpa@...ux.intel.com>
Cc:	linux-kernel@...r.kernel.org, vgoyal@...hat.com, hbabu@...ibm.com,
	kexec@...ts.infradead.org, ying.huang@...el.com, mingo@...e.hu,
	tglx@...utronix.de, sam@...nborg.org
Subject: Re: [PATCH 00/14] RFC: x86: relocatable kernel changes

Peter do you plan to update pxelinux or other bootloaders to use the
relocatable kernel feature?

Can we please kill the gosh awful impact lines?  They keep breaking my
concentration whenever I try and review these patches.  They are
horrible.  Something of very minimal significance jumping up and
screaming at me. 

The impact lines also fail to capture any of the significant ways I
can easily think of that this patch could cause problems.  A little
screw up could cause the kernel to fail to boot for a random portion
of our user base, and the patch as constructed will require changes
to existing bootloaders.

The direction of this patch seems reasonable.  The details are broken.
The common case for relocatable kernels today is kdump.  A situation
with very minimal memory.  In that situation the kernel needs to run
where we put it, modifying the kernel to not run where it gets put
is a problem.

With the code as it is today you can get the exact same behavior
by simply bumping up the minimum alignment to 16MB, and a lot less code
and no changes needed to any bootloaders.

Is your goal to setup a scenario where on small memory systems a bootloader
like pxelinux can support a relocatable kernel and load it a lower
address?  If so that seems reasonable.

With that said how about we change the logic to:

if (load_addr == legacy_load_addr) /* 0x100000 */
	use config_physical_start
else if aligned
	noop
else
        /* Crap this is bad align the kernel and hope something works. */

That gets the desired behavior we override bootloaders that are not
smart and taking relocation into account.  I am really not comfortable
with having code that will override a bootloader doing something
reasonable.

I expect we will still want to update kexec to be able to take
advantage of loadtime_size (runtime_size seems like the wrong name).

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/