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, 1 Aug 2006 11:43:51 +0200
From:	Jan Kratochvil <lace@...kratochvil.net>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
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

On Tue, 01 Aug 2006 11:09:28 +0200, Eric W. Biederman wrote:
> Jan Kratochvil <lace@...kratochvil.net> writes:
...
> > 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. 

So you rather crash than running in that unmeasurably lower performance?

IIRC those 2MB/4MB pages performance "gain" is still present (in my patch)
even if the kernel location is not 2MB/4MB aligned because the i386 2MB/4MB
pagetable entries can have arbitrary physical memory target address.
But maybe I lie here, sorry, I really do not remember it much.
(It 100% worked with the "full performance" if aligned and it "worked" if
unaligned but I do not remember if it worked "full performance" if unaligned.)

...
> I'm not terribly comfortable with the 8K alignment number as we only
> tell the linker we need 4K alignment.

Yes, it should be fixed there so that the stacks get allocated 8KB-aligned not
depending on the kernel code position at all.  That means allocating the
initial stack by code and not relying on its autoallocation by the linker.
There would remain the 4KB alignment requirement due to the physical target
address of the pagetable entries.

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

Yes, it has the same unusability as CVS, just it looses the feature of being
the standard.  I assume some CVS flamewar already occured some time ago.

Regards,
Lace
-
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/