[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b8ea504729db4073abf82ebd5d8a53c6@AcuMS.aculab.com>
Date: Fri, 26 Jan 2018 11:17:29 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Andy Lutomirski' <luto@...nel.org>, Linus Torvalds
<torvalds@...ux-foundation.org>
CC: the arch/x86 maintainers <x86@...nel.org>, LKML
<linux-kernel@...r.kernel.org>, Greg Kroah-Hartman
<gregkh@...uxfoundation.org>, Alan Cox <alan@...ux.intel.com>, Jann Horn
<jannh@...gle.com>, Samuel Neves <samuel.c.p.neves@...il.com>, Dan Williams
<dan.j.williams@...el.com>, Kernel Hardening
<kernel-hardening@...ts.openwall.com>, Borislav Petkov <bp@...en8.de>
Subject: RE: [PATCH] x86/retpoline/entry: Disable the entire SYSCALL64 fast
path with retpolines on
From: Andy Lutomirski
> Sent: 25 January 2018 21:31
...
> Another potentially useful if rather minor optimization would be to
> rejigger the SYSCALL_DEFINE macros a bit. Currently we treat all
> syscalls like this:
>
> long func(long arg0, long arg1, long arg2, long arg3, long arg4, long arg5);
>
> I wonder if we'd be better off doing:
>
> long func(const struct pt_regs *regs);
>
> and autogenerating:
>
> static long SyS_read(const struct pt_regs *regs)
> {
> return sys_reg(regs->di, ...);
> }
Hmmm....
NetBSD (and the other BSD?) defines a structure for the arguments to each syscall.
On systems where all function arguments are put on stack the user stack that
contains the arguments is copied into a kernel buffer.
For amd64 I changed the register save area layout so that the arguments were in
the right order [1]. Then added an extra area for the extra arguments that had to be
read from the user stack.
Just passing a pointer into the save area has to be better than reading
all the values again.
[1] There was some horrid fallout from that :-(
David
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
