From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AH8x226QlHnu676GXtMDpqvvIP6BrB7yDjAo0LKN8yVKZjy0p8yA+MOZRkQYtt/U6Lo0bPg70iV+ ARC-Seal: i=1; a=rsa-sha256; t=1517231983; cv=none; d=google.com; s=arc-20160816; b=oUD1xOPWXXysZCWTBRIQpBk1aGdYfugzYm69HjCl4vuWqBYLuwE5ACzTGQ9PVYZ6bK 7JwYzCHzT1OotzyvqBod31fJHib0lasF9DjXLpzsw/mOur+NdzUEfjtL0Gw9xhfB38yQ vA5aaKfq6FJsYke0xAsUhFLWcCpgOpQSB3ILGQKUnLtzZehNmDZg5bG/HCCBkdEMU2IY 1p6RF1qY9EHAKbgYi3ZLdTV5GEBxJ2VigpBhYUv/EV0Qn3xc92wWhMWB9MWgqEOpghqm 0n3PSgyqCPrcclFxGt9S0TJFc7yP4RINz1HZ5Svvi1D9QiFoX4yIwRF5S7uBSJl/NQbX VR0g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:arc-authentication-results; bh=ZXea6+J7ItYKB83dP7bKOGylm34PksCC395745ErZ7s=; b=mAcKITSxI5EQLqdV97rlJmkdYr0dw9yIOUX3XQi7JTbXNFAta7FdkJJ1tiBL2suCun apQXTbqT7tZAV6xGHMqFDmBE+SrGFWeg0yGo3jmT0nSelhQ+w8R3fRotshxlCqH5di0i n0Qb9bVELW2/4/+u/3A426hpMfXpdsUqQ3HLWB+cnBTD6YhrGY1/zGuqHsG1SENk6cHm EmSfdiCoYd3RSQxO6bpwTPIzHY2xfBb0QJitu6LwfSytL45poOxgTlavSRCOIy/knVqt EZ5MFAKP9zX5lhJjTaPiC3H+9ew0kMSo5VunLjKq5YpC3avcbForFqKtgts1TL5+/w0h Vi8w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of will.deacon@arm.com designates 217.140.101.70 as permitted sender) smtp.mailfrom=will.deacon@arm.com Authentication-Results: mx.google.com; spf=pass (google.com: domain of will.deacon@arm.com designates 217.140.101.70 as permitted sender) smtp.mailfrom=will.deacon@arm.com Date: Mon, 29 Jan 2018 13:19:42 +0000 From: Will Deacon To: Andy Lutomirski Cc: Linus Torvalds , Al Viro , Alan Cox , David Laight , the arch/x86 maintainers , LKML , Greg Kroah-Hartman , Jann Horn , Samuel Neves , Dan Williams , Kernel Hardening , Borislav Petkov Subject: Re: [PATCH] x86/retpoline/entry: Disable the entire SYSCALL64 fast path with retpolines on Message-ID: <20180129131942.GC25549@arm.com> References: <1516976647.5438.6.camel@linux.intel.com> <20180126180722.GA13338@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1590316784671066673?= X-GMAIL-MSGID: =?utf-8?q?1590933044174703089?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: Hi Andy, On Fri, Jan 26, 2018 at 10:23:23AM -0800, Andy Lutomirski wrote: > On Fri, Jan 26, 2018 at 10:13 AM, Linus Torvalds > wrote: > > On Fri, Jan 26, 2018 at 10:07 AM, Al Viro wrote: > >> > >> Umm... What about other architectures? Or do you want SYSCALL_DEFINE... > >> to be per-arch? I wonder how much would that "go through pt_regs" hurt > >> on something like sparc... > > > > No, but I just talked to Will Deacon about register clearing on entry, > > and so I suspect that arm64 might want something similar too. > > > > So I think some opt-in for letting architectures add their own > > function would be good. Because it wouldn't be all architectures, but > > it probably _would_ be more than just x86. > > > > You need to add architecture-specific "load argX from ptregs" macros anyway. > > I mocked that up, and it's straightforward. I ended up with something like: > > #define __ARCH_SYSCALL_ARGS(n, ...) (regs->di, ...) > > (obviously modified so it actually compiles.) > > The issue is that doing it this way gives us, effectively: > > long sys_foo(int a, int b) > { > body here; > } > > long SyS_foo(const struct pt_regs *regs) > { > return sys_foo(regs->di, regs->si); > } > > whereas what we want is *static* long sys_foo(...). So I could split > the macros into: > > DEFINE_SYSCALL2(foo, ....) > > and > > DEFINE_EXTERN_SYSCALL2(foo, ...) > > or I could just fix up all the code that expects calling sys_foo() > across files to work. Another issue with this style of macro definition exists on architectures where the calling convention needs you to carry state around depending on how you packed the previous parameters. For example, on 32-bit ARM, 64-bit values are passed in adjacent pairs of registers but the low numbered register needs to be even. This is what stopped me from trying to use existing helpers such as syscall_get_arguments to unpack the pt_regs and it generally means that anything that says "get me argument n" is going to require constructing arguments 0..n-1 first. To do this properly I think we'll either need to pass back the size and current register offset to the arch code, or just allow the thing to be overridden per syscall (the case above isn't especially frequent). Will