linux-kernel - Re: [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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 16 Mar 2007 13:06:46 -0600
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Jeremy Fitzhardinge <jeremy@...p.org>
Cc:	Ingo Molnar <mingo@...e.hu>, Zachary Amsden <zach@...are.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Jan Beulich <jbeulich@...ell.com>,
	Rusty Russell <rusty@...tcorp.com.au>, Andi Kleen <ak@...e.de>,
	Chris Wright <chrisw@...s-sol.org>,
	Andrew Morton <akpm@...l.org>,
	Linus Torvalds <torvalds@...l.org>,
	Virtualization Mailing List <virtualization@...ts.osdl.org>
Subject: Re: [RFC, PATCH] Fixup COMPAT_VDSO to work with CONFIG_PARAVIRT

Jeremy Fitzhardinge <jeremy@...p.org> writes:

> Ingo Molnar wrote:
>> that's what is the case right now, but much of the intention behind the 
>> vma based vDSO is to enable per-process randomized vdso locations, and 
>> various distributions do that. So the 'modern' vDSO concept is very much 
>> relocatable.
>
> No, the point is that it never needs relocating.  The kernel can map it
> anywhere and userspace can cope.  Its only the broken glibcs which
> require relocation.

Ok.  So to summarize.
There are three ways of finding the VDSO.
- AT_SYSINFO
- AT_SYSINFO_EHDR
- known fixed address (see x86_64)

Currently it doesn't sound like you need to deal with the known fixed
address case but COMPAT_VDSO also provides that.

If userspace uses AT_SYSINFO the premise is that it is not expecting
not to need to perform any relocation processing.

If userspace uses AT_SYSINFO_EHDR it expects it needs to perform
relocation processing and fixes up whatever needs fixing up.

With the module code we have shown the kernel is capable of performing
relocation processing at times and it works.

So is it possible to simply relocate the normal vdso and fixup
it's program header so it shows that relocation is not necessary.
If you can do that and still export AT_SYSINFO so the problem user
space still runs you are good.  (If you can relocate the vdso
you should be able to relocate it anywhere).

Otherwise it probably just make sense to simply not export a VDSO
on those systems.

This would leave COMPAT_VDSO for the case where you must use one magic
fixed address, and if user space does not require that it means
COMPAT_VDSO could be completely removed.

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/