linux-kernel - [PATCH 0/3] vsyscall emulation compatibility fixes

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-next>] [day] [month] [year] [list]

Message-Id: <cover.1312988155.git.luto@mit.edu>
Date:	Wed, 10 Aug 2011 11:15:29 -0400
From:	Andy Lutomirski <luto@....EDU>
To:	x86@...nel.org
Cc:	"H. Peter Anvin" <hpa@...or.com>, Andi Kleen <andi@...stfloor.org>,
	linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
	lueckintel@...oo.com, kimwooyoung@...il.com,
	Ingo Molnar <mingo@...e.hu>, Borislav Petkov <bp@...en8.de>,
	Andy Lutomirski <luto@....edu>
Subject: [PATCH 0/3] vsyscall emulation compatibility fixes

This is the latest attempt to make vsyscall emulation compatible with
dynamic insrumentation tools like DynamoRIO and pin
(http://pintool.org).  They make assumptions about how the int
instruction works that were false with the original vsyscall emulation
code.

There is now a vsyscall boot parameter.  In "native" mode, vsyscalls are
just syscall instructions.  Emulation works fine.  In "emulate" mode
(default), vsyscalls appear to be syscall instructions, but attempts to
execute them are trapped by the NX bit and the instructions are emulated
instead.  This is slower than the old interrupt-based code (because I
hooked a slow path in the page fault code) but it means that nothing too
sneaky goes on behind the backs of the tools.  In "none" mode, vsyscalls
send SIGSEGV just like any other attempt to execute from an NX page.

This still has corner cases.  For example, single-stepping through a
vsyscall will step across the whole thing instead of across just one
instruction.  I suspect that nothing cares.  Somewhat more
significantly, if an exploit (or exploit-like program) jumps to a
syscall instruction in the vsyscall page under pin, then it will work,
whereas without pin in vsyscall=emulate mode, it would receive SIGSEGV.
Pin is welcome to fix this corner case if it cares.

If this still causes problems, we can just default the vsyscall
parameter to native for 3.1

The first patch is pure cleanup and is not required.  The second patch
wires up the getcpu syscall and is required for the native code to work.
The third patch is the meat.

For extra points, if you ignore the documentation in
kernel-parameters.txt, this patch set removes more lines than it adds.

Andy Lutomirski (3):
  x86: Remove unnecessary compile flag tweaks for vsyscall code
  x86-64: Wire up getcpu syscall
  x86-64: Rework vsyscall emulation and add vsyscall= parameter

 Documentation/kernel-parameters.txt |   21 +++++++++
 arch/x86/include/asm/irq_vectors.h  |    4 --
 arch/x86/include/asm/traps.h        |    2 -
 arch/x86/include/asm/unistd_64.h    |    2 +
 arch/x86/include/asm/vsyscall.h     |    6 +++
 arch/x86/kernel/Makefile            |   13 ------
 arch/x86/kernel/entry_64.S          |    1 -
 arch/x86/kernel/traps.c             |    6 ---
 arch/x86/kernel/vmlinux.lds.S       |   33 --------------
 arch/x86/kernel/vsyscall_64.c       |   82 +++++++++++++++++++++--------------
 arch/x86/kernel/vsyscall_emu_64.S   |   36 ++++++++++------
 arch/x86/mm/fault.c                 |   12 +++++
 12 files changed, 113 insertions(+), 105 deletions(-)

-- 
1.7.6

--
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/