linux-kernel - Re: [Fastboot] [CFT] 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, 01 Aug 2006 03:09:28 -0600
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Jan Kratochvil <lace@...kratochvil.net>
Cc:	vgoyal@...ibm.com, fastboot@...l.org, Horms <horms@...ge.net.au>,
	"H. Peter Anvin" <hpa@...or.com>,
	Magnus Damm <magnus.damm@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [Fastboot] [CFT] ELF Relocatable x86 and x86_64 bzImages

Jan Kratochvil <lace@...kratochvil.net> writes:

> On Tue, 01 Aug 2006 04:31:43 +0200, Eric W. Biederman wrote:
> ...
>> 4MB is a little harsh, but I haven't worked through what the exact rules
>> are, I know 4MB is the worst case alignment for arch/i386.
>> 
>> The rule is that we have to be at the same offset from 4MB as we
>> were built to run at.  So in this case address where (address %4MB) == 1MB.
>
> In such case your patch is not optimal.  The original VA Linux Japan patch 2.0
> 	http://mkdump.sourceforge.net/cvs.html
> 	cvs -q -z3
> -d:pserver:anonymous:@mkdump.cvs.sourceforge.net:/cvsroot/mkdump rdiff -u -r
> bp_linux-2_6-minik -r linux-2_6-minik linux
> had lower alignment requirements and these were really tested that time.
>
> i386 had alignment requirement:
> 	/* current_thread_info()&co. are 8192-alignment fixed (for the initial
> stack). */
> 	#if CONFIG_PHYSICAL_START & 0x1FFF
> 	#error "CONFIG_PHYSICAL_START must be 2*PAGE_SIZE (0x2000) aligned!"
> 	#endif
> as IIRC those i386 2MB/4MB pages must be (apparently) 2MB/4MB aligned in the
> virtual address space but their physical target address can be arbitrary.

I know you can't use huge pages if your physical address is not
properly aligned.   Which can be a performance impact if nothing else.
Not something I want to encourage in a general purpose kernel. 

If it is actually a problem once we get past the user confusion
aspect of this I will happily revisit it.  The big confusion in all of
this is that with a 4MB alignment and a 1MB offset the useable cases
are: 1MB, 5MB, 9MB, 13MB, 17MB, 21MB... 

What I did that is rather unique is I actually enforce this in misc.c
so there is no way we can slip by our alignment requirements.

I'm not terribly comfortable with the 8K alignment number as we only
tell the linker we need 4K alignment.  So there might be other
implicit things out there as well.  Although I admit head.S may be
the only place we can get away with that kind of thing, as the linker
can move everything else around.  Groan yet another kernel audit if
we go this route.

> and x86_64 alignment requirement was:
> 	#if (CONFIG_PHYSICAL_START - 0x100000) & 0x1FFFFF
> 	#error "CONFIG_PHYSICAL_START must be '2MB * x + 1MB' aligned!"
> 	#endif
> while IIRC those x86_64 2MB pages need to have even the physical target address
> 2MB aligned.  Lower alignment would require suboptimal execution by not using
> the 2MB pages (and the patch would have to handle it appropriately).

Yes. I have that check.  Except now the check really is
(CONFIG_PHYSICAL_START & 0x1FFFFF) == 0 because the x86_64 kernel lives at
2MB by default now, so it can really get the benefit of huge pages.

> ( I did not check your patches as they are locked in that useless GIT anyway. )
( As opposed to the unuseable CVS I presume :)

I guess I should just post them so we can have a sane conversation :)

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/