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]

Message-ID: <551AC449.6030909@redhat.com>
Date:	Tue, 31 Mar 2015 17:59:05 +0200
From:	Denys Vlasenko <dvlasenk@...hat.com>
To:	Andy Lutomirski <luto@...capital.net>
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 03/31/2015 03:54 PM, Andy Lutomirski wrote:
> 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

Your version is better :/

I'd only suggest    s/pop %rsp/mov (%rsp),%rsp/

I suspect "pop %rsp" is not an easy insn for CPU to digest.

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

Good idea, we can even be paranoid and jump to real IRET if any
of "unusual" flags are set.

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

I kinda hoped POPF is secretly a shadowing insn too.
Experiments show it is not.

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