public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jamie Lokier <jamie@shareable.org>
To: Ulrich Drepper <drepper@redhat.com>
Cc: john stultz <johnstul@us.ibm.com>, lkml <linux-kernel@vger.kernel.org>
Subject: Re: [RFC][PATCH] linux-2.6.2-rc2_vsyscall-gtod_B1.patch
Date: Fri, 30 Jan 2004 17:34:40 +0000	[thread overview]
Message-ID: <20040130173440.GB6285@mail.shareable.org> (raw)
In-Reply-To: <4019E713.1010107@redhat.com>

Ulrich Drepper wrote:
> Your entire scheme is based on this and therefore not worth the bits
> used to store it.  Your understanding of how and where syscalls are made
> and how ELF works is flawed.  There is no "group the syscalls nicely
> together", they are all over the place, inlined in many places.

That's a choice.  There is no reason why you cannot put the entry path
of all the stub functions called "read", "write" etc. in a special
section.  For syscalls inlined in larger functions, then it's
reasonable to avoid text relocation in those places and use an
indirect call as done now.  Surely there aren't too many of those,
though, because LD_PRELOAD libraries which override syscall stubs
rather depend on all normal calls to a syscall going through the stubs?

> there is no concept of weak aliases in dynamic linking.  Finding all
> the "aliases" requires lookups by name for now more than 200 syscall
> names and growing.

See Ingo's post.

> Prelinking can help if it is wanted, but if the vDSO address is
> changed or randomized (this is crucial I'd say) or the vDSO is not
> setup up for a process, the full price has to be paid.

I agree; it is not reasonable to depend on prelinking.

> With every kernel change the whole prelinking has to be redone.

Not really, that's an implementation limitation, there's no reason to
prelink the entire system just to alter the jumps in libc.so on those
occasions when a new kernel is run.  If vDSO randomisation is per boot
rather than per task (because the latter implies an MSR write per
context switch), then a libsyscall.so can be patched at boot time.

Yes I know, extravagent ideas, just wanted to write them for folk to
be aware of the possibilities.

> If gettimeofday() is the only optimized syscall, just add a simple
> 
>   cmp $__NR_gettimeofday, %eax
>   je  __vsyscall_gettimeofday
> 
> to the __kernel_vsyscall code.

That does seem to be a very practical answer for now :)

-- Jamie

  parent reply	other threads:[~2004-01-30 17:35 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-29  2:46 [RFC][PATCH] linux-2.6.2-rc2_vsyscall-gtod_B1.patch john stultz
2004-01-29  5:06 ` Ulrich Drepper
2004-01-29 13:26   ` Jamie Lokier
2004-01-29 18:05     ` Ulrich Drepper
2004-01-29 19:15       ` Jamie Lokier
2004-01-29 23:59         ` john stultz
2004-01-30  0:40           ` Ulrich Drepper
2004-01-30  0:31         ` Ulrich Drepper
2004-01-30  4:17           ` Jamie Lokier
2004-01-30  5:09             ` Ulrich Drepper
2004-01-30  9:29               ` Ingo Molnar
2004-02-03  4:38                 ` Ulrich Drepper
2004-01-30 17:34               ` Jamie Lokier [this message]
2004-01-30  8:33             ` Jakub Jelinek
2004-01-30 17:21               ` Jamie Lokier
2004-01-31  0:10     ` Eric W. Biederman
2004-01-31  2:41       ` Jamie Lokier
2004-01-31  5:54         ` Eric W. Biederman
2004-02-01  1:28   ` Andrea Arcangeli
2004-02-03  4:35     ` Ulrich Drepper
2004-02-03  5:34       ` Andrea Arcangeli
2004-02-03  8:52       ` Jamie Lokier
2004-02-03 16:25         ` Andrea Arcangeli
2004-02-03 17:37           ` Jamie Lokier
2004-02-03 18:10             ` Andrea Arcangeli
2004-02-03 18:23               ` Jamie Lokier
2004-02-03 18:34                 ` Andrea Arcangeli
2004-01-31  0:17 ` Eric W. Biederman
2004-01-31  2:20   ` john stultz
     [not found] <1075344395.1592.87.camel@cog.beaverton.ibm.com.suse.lists.linux.kernel>
     [not found] ` <401894DA.7000609@redhat.com.suse.lists.linux.kernel>
     [not found]   ` <20040201012803.GN26076@dualathlon.random.suse.lists.linux.kernel>
     [not found]     ` <401F251C.2090300@redhat.com.suse.lists.linux.kernel>
     [not found]       ` <20040203085224.GA15738@mail.shareable.org.suse.lists.linux.kernel>
     [not found]         ` <20040203162515.GY26076@dualathlon.random.suse.lists.linux.kernel>
     [not found]           ` <20040203173716.GC17895@mail.shareable.org.suse.lists.linux.kernel>
     [not found]             ` <20040203181001.GA26076@dualathlon.random.suse.lists.linux.kernel>
     [not found]               ` <20040203182310.GA18326@mail.shareable.org.suse.lists.linux.kernel>
2004-02-04  2:27                 ` Andi Kleen
2004-02-04  2:40                   ` Andrea Arcangeli
2004-02-04  4:21                   ` Jamie Lokier
2004-02-05 21:43                     ` Andrea Arcangeli
2004-02-06  4:15                       ` Rik van Riel
2004-02-06  4:28                         ` Andrea Arcangeli
2004-02-06  9:23                           ` Ulrich Drepper
2004-02-06 15:49                             ` Andrea Arcangeli
2004-02-07  0:37                               ` Ulrich Drepper
2004-02-07  2:19                                 ` Andrea Arcangeli
2004-02-07  3:37                                   ` Daniel Jacobowitz
2004-02-07  4:36                                     ` Andrea Arcangeli
2004-02-07  4:53                                       ` Jamie Lokier

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=20040130173440.GB6285@mail.shareable.org \
    --to=jamie@shareable.org \
    --cc=drepper@redhat.com \
    --cc=johnstul@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox