linux-kernel - [RFC, PATCH] Fixup COMPAT_VDSO to work with CONFIG

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-next>] [day] [month] [year] [list]

Message-ID: <45FA054F.6020107@vmware.com>
Date:	Thu, 15 Mar 2007 18:47:43 -0800
From:	Zachary Amsden <zach@...are.com>
To:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...e.hu>, Jan Beulich <jbeulich@...ell.com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Jeremy Fitzhardinge <jeremy@...p.org>, Andi Kleen <ak@...e.de>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Chris Wright <chrisw@...s-sol.org>,
	Andrew Morton <akpm@...l.org>,
	Linus Torvalds <torvalds@...l.org>,
	Virtualization Mailing List <virtualization@...ts.osdl.org>
Subject: [RFC, PATCH] Fixup COMPAT_VDSO to work with CONFIG_PARAVIRT

Paravirt-ops guests which move the fixmap also end up moving the syscall 
VDSO.  This fails if it is prelinked at a fixed address, which is why 
COMPAT_VDSO is broken under CONFIG_VMI (and also under CONFIG_XEN).  
Several options are available to try to address this.  Jan had cooked up 
a patch for Xen that used build magic to find the parts of the VDSO that 
need relocation.  I don't like the idea of having auto-generated 
relocations, as someday something could change between two linked 
objects (timestamp, elf notes perhaps) that is not a relocation.  So I 
prefer human supervision over the relocation and explicitly fixing 
everything by hand.  I'm not necessarily advocating one solution over 
the other; my way is more code to maintain if the VDSO linkage changes.  
I'm looking for feedback about which way is best.

Also, it appears that COMPAT_VDSO could disappear entirely.  Since this 
approach should work with older broken ld.so (2.3.2 is the version, I 
believe), we should be able to switch over completely to using the gate 
vma style of linking the vdso.  One can even get the address 
randomization benefits by simply running fixup on the vdso if you are 
prepared to take the cost of allocating an extra page per process.  Or 
you could randomize just once at boot, which makes the randomization 
per-machine, still sufficient to slow network based worm attacks which 
might rely on a fixed VDSO address.

Clearly this patch needs more testing and feedback, which I'm sure it 
will get...

<zach ducks>

Zach

P.S. - Eric, I've copied you as you appear to be an ELF expert, or at 
least have a greater grasp of Elven Magic than me, and I'm hoping I got 
all the dynamic tags which need relocation right.

View attachment "vdso-relocation-for-paravirt.patch" of type "text/plain" (9295 bytes)