linux-kernel - Re: [RFC PATCH] x86: optimize IRET returns to kernel

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]

Date:	Tue, 31 Mar 2015 06:54:41 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Denys Vlasenko <dvlasenk@...hat.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Ingo Molnar <mingo@...nel.org>, Borislav Petkov <bp@...en8.de>,
	"H. Peter Anvin" <hpa@...or.com>, Oleg Nesterov <oleg@...hat.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Alexei Starovoitov <ast@...mgrid.com>,
	Will Drewry <wad@...omium.org>,
	Kees Cook <keescook@...omium.org>, X86 ML <x86@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH] x86: optimize IRET returns to kernel

On Tue, Mar 31, 2015 at 5:46 AM, Denys Vlasenko <dvlasenk@...hat.com> wrote:
> This is not proposed to be merged yet.
>
> Andy, this patch is in spirit of your crazy ideas of repurposing
> instructions for the roles they weren't intended for :)
>
> Recently I measured IRET timings and was newly "impressed"
> how slow it is. 200+ cycles. So I started thinking...
>
> When we return from interrupt/exception *to kernel*,
> most of IRET's doings are not necessary. CS and SS
> do not need changing. And in many (most?) cases
> saved RSP points right at the top of pt_regs,
> or (top of pt_regs+8).
>
> In which case we can (ab)use POPF and RET!
>
> Please see the patch.

I have an old attempt at this here:

https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=fast-return-to-kernel&id=6cfe29821979c42cd812878e05577f69f99fafaf

If I were doing it again, I'd add a bit more care: if saved eflags
have RF set (can kgdb do that?), then we have to use iret.  Your patch
may need that.  Sadly, this may kill any attempt to completely prevent
NMI nesting.

I think that, if returning to IF=1, you need to do sti;ret to avoid an
infinite stack usage failure in which, during an IRQ storm, each IRQ
adds around one word of stack utilization because you haven't done the
ret yet before the next IRQ comes in.  To make that robust, I'd adjust
the NMI code to clear IF and back up one instruction if it interrupts
after sti.

This should dramatically speed up in-kernel page faults as well as IRQ
handling from kernel mode.

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