Re: [PATCH v2 08/10] x86-64: Emulate vsyscalls

[Jan Beulich]

>>> On 30.05.11 at 05:48, Andy Lutomirski <luto@xxxxxxx> wrote:
> This causes vsyscalls to be a little more expensive than real
> syscalls.  Fortunately sensible programs don't use them.

Hmm - weren't vsyscalls there for performance reasons?

Besides that, just a mostly cosmetic remark:

> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -1650,6 +1650,23 @@ config COMPAT_VDSO
>  
>  	  If unsure, say Y.
>  
> +config UNSAFE_VSYSCALLS
> +	def_bool y
> +	prompt "Unsafe fast legacy vsyscalls"
> +	depends on X86_64
> +	---help---
> +	  Legacy user code expects to be able to issue three syscalls
> +	  by calling fixed addresses in kernel space.  If you say N,
> +	  then the kernel traps and emulates these calls.  If you say
> +	  Y, then there is actual executable code at a fixed address
> +	  to implement these calls efficiently.
> +
> +	  On a system with recent enough glibc (probably 2.14 or
> +	  newer) and no static binaries, you can say N without a
> +	  performance penalty to improve security
> +
> +	  If unsure, say Y.
> +
>  config CMDLINE_BOOL
>  	bool "Built-in kernel command line"
>  	---help---
> --- a/arch/x86/kernel/Makefile
> +++ b/arch/x86/kernel/Makefile
> @@ -42,6 +42,9 @@ obj-$(CONFIG_X86_32)	+= probe_roms_32.o
>  obj-$(CONFIG_X86_32)	+= sys_i386_32.o i386_ksyms_32.o
>  obj-$(CONFIG_X86_64)	+= sys_x86_64.o x8664_ksyms_64.o
>  obj-$(CONFIG_X86_64)	+= syscall_64.o vsyscall_64.o vread_tsc_64.o
> +ifndef CONFIG_UNSAFE_VSYSCALLS
> +	obj-$(CONFIG_X86_64)	+= vsyscall_emu_64.o
> +endif

With the Kconfig dependency on X86_64 above and the new
variable being a boolean one, these three lines can be written
as just

obj-$(CONFIG_UNSAFE_VSYSCALLS) += vsyscall_emu_64.o

Jan

>  obj-y			+= bootflag.o e820.o
>  obj-y			+= pci-dma.o quirks.o topology.o kdebugfs.o
>  obj-y			+= alternative.o i8253.o pci-nommu.o hw_breakpoint.o


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/