mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andrea Arcangeli <andrea@suse.de>
To: john stultz <johnstul@us.ibm.com>
Cc: lkml <linux-kernel@vger.kernel.org>, Andi Kleen <ak@suse.de>,
	Ulrich Drepper <drepper@redhat.com>,
	Jamie Lokier <jamie@shareable.org>,
	Chris McDermott <lcm@us.ibm.com>,
	Wim Coekaerts <wim.coekaerts@oracle.com>,
	Joel Becker <Joel.Becker@oracle.com>,
	"Martin J. Bligh" <mbligh@aracnet.com>
Subject: Re: [RFC][PATCH] linux-2.6.2_vsyscall-gtod_B2.patch
Date: Fri, 6 Feb 2004 05:01:23 +0100	[thread overview]
Message-ID: <20040206040123.GN31926@dualathlon.random> (raw)
In-Reply-To: <1076037045.757.21.camel@cog.beaverton.ibm.com>

On Thu, Feb 05, 2004 at 07:10:46PM -0800, john stultz wrote:
> @@ -6,6 +9,8 @@
>  	.globl __kernel_vsyscall
>  	.type __kernel_vsyscall,@function
>  __kernel_vsyscall:
> +	cmp $__NR_gettimeofday, %eax
> +	je .Lvgettimeofday
>  .LSTART_vsyscall:

this is the sort of slowdown that could be avoided with the fixed
address.

with regards to Ulrich's security related comments, this won't make any
difference compared to the fixed address version either, since the
vsyscall page is still at a fixed address in the fixmap area, and
nevertheless regardless the vgettimeofday api, the sysenter instruction
is always placed at a fixed address in the address space for the
sysenter vsyscall support, so at the light of the i386 current status,
those comments w.r.t to security make even less sense.

This has the feature that it doesn't need the LD_PRELOAD and it's sort
of backwards compatible, but it is equivalent in terms of security and
as a matter of fact it's less efficient and the worst part is that not
only it makes gettimeofday slower, it makes _all_ the syscall slower
(slowing down vgettimeofday wouldn't matter since we're improving it
huge anyways).

I prefer the previous version, glibc has to be changed at the same time
with the kernel anyways to use the sysenter. I think it's not nice to
speedup gettimeofday by slowing down all other syscalls, when we can
implement it running all syscalls at full speed with the optimal API of
x86-64.

  reply	other threads:[~2004-02-06  4:01 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-06  3:10 john stultz
2004-02-06  4:01 ` Andrea Arcangeli [this message]
2004-02-06  9:28   ` Ulrich Drepper
2004-02-06 15:54     ` Andrea Arcangeli
2004-02-07  3:18   ` 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=20040206040123.GN31926@dualathlon.random \
    --to=andrea@suse.de \
    --cc=Joel.Becker@oracle.com \
    --cc=ak@suse.de \
    --cc=drepper@redhat.com \
    --cc=jamie@shareable.org \
    --cc=johnstul@us.ibm.com \
    --cc=lcm@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mbligh@aracnet.com \
    --cc=wim.coekaerts@oracle.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®