linux-kernel - Re: [rfc 08/45] cpu alloc: x86 support

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: <200711202159.36377.ak@suse.de>
Date:	Tue, 20 Nov 2007 21:59:36 +0100
From:	Andi Kleen <ak@...e.de>
To:	Christoph Lameter <clameter@....com>
Cc:	akpm@...ux-foundation.org, travis@....com,
	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
	linux-kernel@...r.kernel.org
Subject: Re: [rfc 08/45] cpu alloc: x86 support

> 
> Right so I could move the kernel to
> 
> #define __PAGE_OFFSET     _AC(0xffff810000000000, UL)
> #define __START_KERNEL_map_AC(0xfffffff800000000, UL)

That is -31GB unless I'm miscounting. But it needs to be >= -2GB
(31bits) 

Right now it is at -2GB + 2MB,  because it is loaded at physical +2MB
so it's convenient to identity map there. In theory you could avoid that
with some effort, but that would only buy you 2MB and would also
break some early code and earlyprintk I believe.

> > You could in theory move the modules, but then you would need to implement
> > a full PIC dynamic linker for them  first and also increase runtime overhead
> > for them because they would need to use a GOT/PLT.
> 
> Why is it not possible to move the kernel lower while keeping bit 31 1?

The kernel model relies on 32bit sign extension. This means bits [31;63] have
to be all 1

> > I suspect all of this  would cause far more overhead all over the kernel than 
> > you could ever save with the per cpu data in your fast paths.
> 
> Moving the kernel down a bit seems to be trivial without any of the weird 
> solutions.

Another one I came up in the previous mail would be to do the linker reference
variable allocation in [0;2GB] positive space; but do all real references only
%gs relative. And keep the real data copy on some other address. That would
be a similar trick to the old style x86-64 vsyscalls. It gets fairly
messy in the linker map file though.

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