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+55aFxiwYXk9r-7BqxujyA0+p1eSAGcQh7nyh04K--t+71zAw@mail.gmail.com>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ