linux-kernel - Re: [PATCH 0/3] x86_64,entry: Rearrange the syscall exit optimizations

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:	Wed, 3 Dec 2014 17:42:28 -0800
From:	Andy Lutomirski <luto@...capital.net>
To:	X86 ML <x86@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>, Eric Paris <eparis@...hat.com>,
	Richard Guy Briggs <rgb@...hat.com>
Cc:	Frédéric Weisbecker <fweisbec@...il.com>,
	Oleg Nesterov <oleg@...hat.com>,
	kvm list <kvm@...r.kernel.org>,
	Andy Lutomirski <luto@...capital.net>
Subject: Re: [PATCH 0/3] x86_64,entry: Rearrange the syscall exit optimizations

[adding potentially interested people]

On Fri, Nov 7, 2014 at 3:58 PM, Andy Lutomirski <luto@...capital.net> wrote:
> The syscall exit asm is a big mess.  There's a really fast path, some
> kind of fast path code (with a hard-coded optimization for audit), and
> the really slow path.  The result is that it's very hard to work with
> this code.  There are some asm paths that are much slower than they
> should be (context tracking is a major offender), but no one really
> wants to add even more asm to speed them up.
>
> This series takes a different, unorthodox approach.  Rather than trying
> to avoid entering the very slow iret path, it adds a way back out of the
> iret path.  The result is a dramatic speedup for context tracking, user
> return notification, and similar code, as the cost of a few lines of
> tricky asm.  Nonetheless, it's barely a net addition of asm code,
> because we get to remove the fast path optimizations for audit and
> rescheduling.
>
> Thoughts?  If this works, it opens the door for a lot of further
> consolidation of the exit code.
>
> Note: patch 1 in this series has been floating around on the list
> for quite a while.  It's mandatory for this series to work, because
> the buglet that it fixes almost completely defeats the optimization
> that I'm introducing.

It turns out that sysret_audit may be rather buggy.  I think it leaves
edx and edi in a confused state, and it interacts badly with
SCHEDULE_USER if context tracking is on.  My preferred long-term
solution is to delete sysret_audit entirely, which this patch set
does.  Can you (x86 people and people who, for reasons that escape me,
enjoy reviewing this stuff) take a look?

This clearly isn't 3.18 material, and it may want to soak in -next
(can -tip do that?  I can do it myself, I suppose), but it might also
be a good idea to try to do this for 3.19 to get rid of sysret_audit.

For those who haven't followed all the recent threads: the asm that's
deleted in patch 3 currently has a nasty RCU + context tracking +
audit bug that has become much easier to trigger as a result of the
seccomp changes in 3.18.  This isn't directly a bug in the seccomp
changes -- it's just that the seccomp changes make it much easier to
cause the offending ask to be executed.

--Andy

>
> Andy Lutomirski (3):
>   x86_64,entry: Fix RCX for traced syscalls
>   x86_64,entry: Use sysret to return to userspace when possible
>   x86_64,entry: Remove the syscall exit audit and schedule optimizations
>
>  arch/x86/kernel/entry_64.S | 103 ++++++++++++++++++++++++---------------------
>  1 file changed, 55 insertions(+), 48 deletions(-)
>
> --
> 1.9.3
>



-- 
Andy Lutomirski
AMA Capital Management, LLC
--
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/