linux-kernel - Re: [RFC/INCOMPLETE 08/13] x86/entry/64: Migrate 64-bit syscalls to new exit hooks

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

Message-ID: <20150617100009.GA5673@gmail.com>
Date:	Wed, 17 Jun 2015 12:00:09 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Andy Lutomirski <luto@...nel.org>
Cc:	x86@...nel.org, linux-kernel@...r.kernel.org,
	Frédéric Weisbecker <fweisbec@...il.com>,
	Rik van Riel <riel@...hat.com>,
	Oleg Nesterov <oleg@...hat.com>,
	Denys Vlasenko <vda.linux@...glemail.com>,
	Borislav Petkov <bp@...en8.de>,
	Kees Cook <keescook@...omium.org>,
	Brian Gerst <brgerst@...il.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [RFC/INCOMPLETE 08/13] x86/entry/64: Migrate 64-bit syscalls to
 new exit hooks

* Andy Lutomirski <luto@...nel.org> wrote:

> This is separate for ease of bisection.
> 
> Signed-off-by: Andy Lutomirski <luto@...nel.org>
> ---
>  arch/x86/entry/entry_64.S | 68 +++++------------------------------------------
>  1 file changed, 7 insertions(+), 61 deletions(-)
> 
> diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
> index 33acc3dcc281..a5044d7a9d43 100644
> --- a/arch/x86/entry/entry_64.S
> +++ b/arch/x86/entry/entry_64.S
> @@ -229,6 +229,11 @@ entry_SYSCALL_64_fastpath:
>  	 */
>  	USERGS_SYSRET64
>  
> +GLOBAL(int_ret_from_sys_call_irqs_off)
> +	TRACE_IRQS_ON
> +	ENABLE_INTERRUPTS(CLBR_NONE)
> +	jmp int_ret_from_sys_call

Any reason why irq state tracking cannot be done in C as well, like the rest of 
the irq state tracking code?

(Btw., context tracking could in theory be merged with irq state tracking, they 
have similar needs.)

One complication would be that we have not saved pt_regs yet:

> @@ -272,69 +277,10 @@ tracesys_phase2:
>   * Has correct iret frame.
>   */
>  GLOBAL(int_ret_from_sys_call)
>  	SAVE_EXTRA_REGS
> +	movq	%rsp, %rdi
> +	call	syscall_return_slowpath	/* returns with IRQs disabled */
>  	RESTORE_EXTRA_REGS

... but we can stipulate that IRQs can be enabled after we've constructed pt_regs. 
The few cycles constant added latency there isn't an issue - maintainability of 
the code is.

... this would also allow us to get rid of paravirt interface uglies like 
'CLBR_NONE' which has no place in generic entry code.

With such a conversion very little 'high level, complex logic' should be left in 
assembly and as much as possible should be moved to C: that way we can integrate 
it all on the C level and achieve similar speedups as with assembly. Half-done 
will reduce that potential of speedups through integration.

A bit like how we have done it with do_page_fault(): there's very little left at 
the assembly level, still it has not kept people from micro-optimizing the heck 
out of the low level page fault code.

Thanks,

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