All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Lutomirski <luto@MIT.EDU>
To: x86@kernel.org
Cc: Andy Lutomirski <luto@MIT.EDU>, "H. Peter Anvin" <hpa@zytor.com>,
	Andi Kleen <andi@firstfloor.org>,
	linux-kernel@vger.kernel.org, torvalds@linux-foundation.org,
	lueckintel@yahoo.com, kimwooyoung@gmail.com,
	Ingo Molnar <mingo@elte.hu>, Borislav Petkov <bp@alien8.de>,
	Suresh Siddha <suresh.b.siddha@intel.com>
Subject: [PATCH 0/4] vsyscall tweaks
Date: Tue,  9 Aug 2011 10:27:46 -0400	[thread overview]
Message-ID: <cover.1312899174.git.luto@mit.edu> (raw)

With the new vsyscall emulation code, int 0xcc's behavior depends on
where it is called from.  A few dynamic instrumentation tools cleverly
copy the instruction out of the vsyscall page and execute it, resulting
in a segfault.  This is nothing new: sysenter would die in a similar way
(unless the code got lucky).  The only examples I know of are pin and
DynamoRIO -- valgrind is already smart enough not to recompile vsyscalls
0 and 1 and "smart" enough to crash unconditionally on vsyscall 2.  I
can't test pin because it refuses to run on newfangled things like Linux
3.0+ (and I don't want to muck with my kernel version to run a program
that's broken anyway).  Patch 1 in this series fixes DynamoRIO in
limited testing.

Bug reports against valgrind and DynamoRIO exist, and I haven't managed
to get permission to post to pin's message board yet.

The other three patches are minor.  Patch 2 removes compile flags that
are now unnecessary because vsyscall_64.c does not get called in user
mode.  Patch 3 wires up the getcpu syscall on x86-64 as further
encouragement to stop using the vsyscall.  Patch 4 adds a
feature-removal-schedule.txt entry suggesting that vsyscalls might be
disabled in some configurations some day.

x86 maintainers / Linus: feel free to drop any of patches 2-4.  I think
the getcpu syscall should be added, though, since it's rather odd to
have a "syscall" in the vdso and the vsyscall page that can't be called
the old-fashioned way.

Changes from RFC v2:
 - Fix some more int 0xcc references.
 - Add patches 2-4.

Andy Lutomirski (4):
  x86-64: Allow emulated vsyscalls from user addresses
  x86: Remove unnecessary compile flag tweaks for vsyscall code
  x86-64: Wire up getcpu syscall
  Add vsyscalls to feature-removal-schedule.txt

 Documentation/feature-removal-schedule.txt |   14 +++
 arch/x86/include/asm/irq_vectors.h         |   11 ++-
 arch/x86/include/asm/traps.h               |    8 ++-
 arch/x86/include/asm/unistd_64.h           |    2 +
 arch/x86/kernel/Makefile                   |   13 ---
 arch/x86/kernel/entry_64.S                 |    4 +-
 arch/x86/kernel/traps.c                    |   14 +++-
 arch/x86/kernel/vsyscall_64.c              |  131 ++++++++++++++--------------
 arch/x86/kernel/vsyscall_emu_64.S          |    6 +-
 9 files changed, 111 insertions(+), 92 deletions(-)

-- 
1.7.6


             reply	other threads:[~2011-08-09 14:28 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-09 14:27 Andy Lutomirski [this message]
2011-08-09 14:27 ` [PATCH 1/4] x86-64: Allow emulated vsyscalls from user addresses Andy Lutomirski
2011-08-09 18:59   ` H. Peter Anvin
2011-08-09 19:16     ` Andrew Lutomirski
2011-08-09 14:27 ` [PATCH 2/4] x86: Remove unnecessary compile flag tweaks for vsyscall code Andy Lutomirski
2011-08-09 14:27 ` [PATCH 3/4] x86-64: Wire up getcpu syscall Andy Lutomirski
2011-08-09 14:27 ` [PATCH 4/4] Add vsyscalls to feature-removal-schedule.txt Andy Lutomirski
2011-08-12 18:25   ` NACK! " Andi Kleen
2011-08-12 19:13     ` Andrew Lutomirski
2011-08-17 20:35       ` Ingo Molnar

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=cover.1312899174.git.luto@mit.edu \
    --to=luto@mit.edu \
    --cc=andi@firstfloor.org \
    --cc=bp@alien8.de \
    --cc=hpa@zytor.com \
    --cc=kimwooyoung@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lueckintel@yahoo.com \
    --cc=mingo@elte.hu \
    --cc=suresh.b.siddha@intel.com \
    --cc=torvalds@linux-foundation.org \
    --cc=x86@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 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.