Messages in this thread | | | From | Andy Lutomirski <> | Subject | [PATCH v3 00/10] Remove syscall instructions at fixed addresses | Date | Tue, 31 May 2011 09:15:54 -0400 |
| |
Patch 1 is just a bugfix from the last vdso series. The bug should be harmless but it's pretty dumb. This is almost certainly 3.0 material.
Patch 2 adds documentation for entry_64.S. A lot of the magic in there is far from obvious.
Patches 3, 4, and 5 remove a bunch of syscall instructions in kernel space at fixed addresses that user code can execute. Several are data that isn't marked NX. Patch 2 makes vvars NX and 5/10 makes the HPET NX.
The time() vsyscall contains an explicit syscall fallback. Patch 3/10 removes it.
At this point, there is only one explicit syscall left in the vsyscall page: the fallback case for vgettimeofday. The rest of the series is to remove it and most of the remaining vsyscall code.
Patch 6 is pure cleanup. venosys (one of the four vsyscalls) has been broken for years, so patch 6 removes it.
Patch 7 pads the empty parts of the vsyscall page with 0xcc. 0xcc is an explicit trap.
Patch 8 removes the code implementing the vsyscalls and replaces it with magic int 0xcc incantations. These incantations are specifically designed so that jumping into them at funny offsets will either work fine or generate some kind of fault. This is a significant performance penalty (~220ns here) for all vsyscall users, but there aren't many left. Because current glibc still uses the time vsyscall (although it's fixed in glibc's git), the option CONFIG_UNSAFE_VSYSCALLS (default y) will leave time() alone.
This patch is also nice because it removes a bunch of duplicated code from vsyscall_64.s.
Patch 9/10 randomizes the int 0xcc incantation at bootup. It is pretty much worthless for security (there are only three choices for the random number and it's easy to figure out which one is in use) but it prevents overly clever userspace programs from thinking that the incantation is ABI. One instrumentation tool author offered to hard-code special handling for int 0xcc; I want to discourage this approach.
Patch 10/10 adds CONFIG_UNSAFE_VSYSCALLS to feature-removal-schedule.txt. Removing it won't break anything but it will slow some older code down.
Changes from v2: - Reordered the patches. - Removed the option to leave gettimeofday and getcpu as native code. - Clean up the int 0xcc handler and registration. - sched_getcpu works now (thanks, Borislav, for catching my blatant arithmetic error). - Numerous small fixes from review comments. - Abandon my plan to spread turbostat to the masses.
Changes from v1: - Patches 6-10 are new. - The int 0xcc code is much prettier and has lots of bugs fixed. - I've decided to let everyone compile turbostat on their own :)
Andy Lutomirski (10): x86-64: Fix alignment of jiffies variable x86-64: Document some of entry_64.S x86-64: Give vvars their own page x86-64: Remove kernel.vsyscall64 sysctl x86-64: Map the HPET NX x86-64: Remove vsyscall number 3 (venosys) x86-64: Fill unused parts of the vsyscall page with 0xcc x86-64: Emulate legacy vsyscalls x86-64: Randomize int 0xcc magic al values at boot x86-64: Add CONFIG_UNSAFE_VSYSCALLS to feature-removal-schedule
Documentation/feature-removal-schedule.txt | 9 + Documentation/x86/entry_64.txt | 98 +++++++++ arch/x86/Kconfig | 17 ++ arch/x86/include/asm/fixmap.h | 1 + arch/x86/include/asm/irq_vectors.h | 6 +- arch/x86/include/asm/pgtable_types.h | 6 +- arch/x86/include/asm/traps.h | 4 + arch/x86/include/asm/vgtod.h | 1 - arch/x86/include/asm/vsyscall.h | 6 + arch/x86/include/asm/vvar.h | 24 +- arch/x86/kernel/Makefile | 1 + arch/x86/kernel/entry_64.S | 4 + arch/x86/kernel/hpet.c | 2 +- arch/x86/kernel/traps.c | 4 + arch/x86/kernel/vmlinux.lds.S | 47 ++-- arch/x86/kernel/vsyscall_64.c | 327 +++++++++++++++++----------- arch/x86/kernel/vsyscall_emu_64.S | 42 ++++ arch/x86/vdso/vclock_gettime.c | 55 ++--- 18 files changed, 448 insertions(+), 206 deletions(-) create mode 100644 Documentation/x86/entry_64.txt create mode 100644 arch/x86/kernel/vsyscall_emu_64.S
-- 1.7.5.1
| |