linux-kernel - Re: [RFC/HACK] x86: Fast return 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: <CA+55aFzfDgeFmzk18xJ+ZvCcm-qCsCtd4RrNxYi0CXdfNbZn_A@mail.gmail.com>
Date:	Fri, 2 May 2014 12:31:42 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"the arch/x86 maintainers" <x86@...nel.org>,
	"H. Peter Anvin" <h.peter.anvin@...el.com>,
	Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [RFC/HACK] x86: Fast return to kernel

On Fri, May 2, 2014 at 12:04 PM, Andy Lutomirski <luto@...capital.net> wrote:
> This speeds up my kernel_pf microbenchmark by about 17%.  The cfi
> annotations need some work.

Sadly, performance of page faults in kernel mode is pretty much
completely uninteresting. It simply doesn't happen on any real load.

That said, regular *device* interrupts do often return to kernel mode
(the idle loop in particular), so if you have any way to measure that,
that might be interesting, and might show some of the same advantages.

And NMI not being re-enabled might just be a real advantage. Adding
Steven to the cc to make him aware of this patch.

So I like the patch, I just think that selling it on a "page fault
cost" basis is not very interesting. The real advantages would be
elsewhere. The page fault case is mainly a good way to test that it
restores the registers correctly.

Also, are you *really* sure that "popf" has the same one-instruction
interrupt shadow that "sti" has? Because I'm not at all sure that is
true, and it's not documented as far as I can tell. In contrast, the
one-instruction shadow after "sti" very much _is_ documented.

You may need to have a separate paths for do/don't enable interrupts,
with the interrupt-enabling one clearing the IF bit on stack, and then
finishing with "popf ; sti ; retq" instead.

Side note related to the whole IF shadow: that thing is also really
easy to get wrong in emulation etc, so we should check with the
virtualization people..

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