linux-kernel - Re: Proposal for finishing the 64-bit x86 syscall cleanup

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, 25 Aug 2015 09:59:10 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Brian Gerst <brgerst@...il.com>, X86 ML <x86@...nel.org>,
	Denys Vlasenko <dvlasenk@...hat.com>,
	Borislav Petkov <bp@...en8.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Jan Beulich <jbeulich@...e.com>
Subject: Re: Proposal for finishing the 64-bit x86 syscall cleanup

On Tue, Aug 25, 2015 at 9:28 AM, Andy Lutomirski <luto@...capital.net> wrote:
>
> I bet that, with a bit of tweaking, that would actually end up faster
> than what we do right now for everything except fully fast-path
> syscalls.  This would also be a *huge* sanity improvement for the
> compat case in which the args are currently jumbled in asm.  It would
> become:
>
> if (nr < max)
>   call the syscall(regs->bx, regs->cx, regs->dx, ...);
>
> which completely avoids the unreadable and probably buggy mess we have now.

I'm willing to try it.  Just pass in the system call number and the
regs pointer as the arguments, and keep the asm portion as the minimal
"save regs, call function, restore regs, return" sequence with
absolutely nothing else going on.

The main cost would be a few more push/pop instructions, and then the
loads from the stack frame in the C function. Go for it.

The system calls where the extra five cycles might be noticeable are
all irrelevant anyway (ie "getppid()" etc). They aren't actually
performance-critical, even if they may be used for benchmarks.

But please do make it be very tight push/pop sequences, not those
crazy "movq %reg,%off(%rsp)" things.

                     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/