From: Jeremy Fitzhardinge <jeremy@goop.org>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Ingo Molnar <mingo@elte.hu>, Zachary Amsden <zach@vmware.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Jan Beulich <jbeulich@novell.com>,
Rusty Russell <rusty@rustcorp.com.au>, Andi Kleen <ak@suse.de>,
Chris Wright <chrisw@sous-sol.org>, Andrew Morton <akpm@osdl.org>,
Linus Torvalds <torvalds@osdl.org>,
Virtualization Mailing List <virtualization@lists.osdl.org>
Subject: Re: [RFC, PATCH] Fixup COMPAT_VDSO to work with CONFIG_PARAVIRT
Date: Fri, 16 Mar 2007 12:46:56 -0700 [thread overview]
Message-ID: <45FAF430.4060903@goop.org> (raw)
In-Reply-To: <m1ps79m2ih.fsf@ebiederm.dsl.xmission.com>
Eric W. Biederman wrote:
> 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.
>
Yes, I don't think any 32-bit userspace expects a fixed address any
more. 64-bit is another matter.
> 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.
>
Correct.
> With the module code we have shown the kernel is capable of performing
> relocation processing at times and it works.
>
Good point. It would be good to reuse that machinery.
> 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).
>
Yes. The plan is to map the relocated compat vdso at some fixed address
in all processes, and map a non-relocated non-compat vdso at some
randomized address (it will probably be the same bits in either case).
We could map a relocated vdso to a randomized address (ie, only one vdso
mapping), but that would require a per-process copy of the vdso and
effort to relocate on each exec.
> Otherwise it probably just make sense to simply not export a VDSO
> on those systems.
>
We did that in an earlier version of the patch, and Ingo complained,
with some justification.
> 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.
>
FC1 and SuSE 9 both shipped with broken glibcs which require
weak-COMPAT_VDSO (not fixed address, but pre-relocated). There are
still enough of these around that we need to cater to them.
J
next prev parent reply other threads:[~2007-03-16 19:46 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-16 2:47 [RFC, PATCH] Fixup COMPAT_VDSO to work with CONFIG_PARAVIRT Zachary Amsden
2007-03-16 3:20 ` Jeremy Fitzhardinge
2007-03-16 3:20 ` Jeremy Fitzhardinge
2007-03-16 4:03 ` Zachary Amsden
2007-03-16 4:03 ` Zachary Amsden
2007-03-16 5:10 ` Jeremy Fitzhardinge
2007-03-16 5:58 ` Zachary Amsden
2007-03-16 5:58 ` Zachary Amsden
2007-03-16 8:08 ` Jan Beulich
2007-03-16 8:41 ` Zachary Amsden
2007-03-16 16:46 ` Jeremy Fitzhardinge
2007-03-16 17:09 ` Jan Beulich
2007-03-16 23:09 ` Jan Engelhardt
2007-03-16 11:56 ` Eric W. Biederman
2007-03-16 11:56 ` Eric W. Biederman
2007-03-16 16:25 ` Jeremy Fitzhardinge
2007-03-16 16:25 ` Jeremy Fitzhardinge
2007-03-16 16:31 ` Ingo Molnar
2007-03-16 16:33 ` Jeremy Fitzhardinge
2007-03-16 16:33 ` Jeremy Fitzhardinge
2007-03-16 19:06 ` Eric W. Biederman
2007-03-16 19:06 ` Eric W. Biederman
2007-03-16 19:46 ` Jeremy Fitzhardinge [this message]
2007-03-16 19:38 ` Zachary Amsden
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=45FAF430.4060903@goop.org \
--to=jeremy@goop.org \
--cc=ak@suse.de \
--cc=akpm@osdl.org \
--cc=chrisw@sous-sol.org \
--cc=ebiederm@xmission.com \
--cc=jbeulich@novell.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rusty@rustcorp.com.au \
--cc=torvalds@osdl.org \
--cc=virtualization@lists.osdl.org \
--cc=zach@vmware.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.