From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AH8x226h0+I+fi2hI7/BaBjVhQewnJ8FwUFVjHLwT4cymc9fOhHhjz1597XKCWFOigfhqxaKdQu6 ARC-Seal: i=1; a=rsa-sha256; t=1517167308; cv=none; d=google.com; s=arc-20160816; b=BB7S+N/KEm8GdJOrx5wK9x54khIzO4GPnGo5urSdwkiCEbpO5x6yYqTev3p7nGCy/p 3WQBh3LIdNwJG8t626SkfNbmW8+/wDwLi93VTdKBe+Exc61VqPjcnPuG6pMghLfBrfAu 0wZiycFI6/UAtH0oNPY+iNmnsJ/b5HgOQcIGf9LRWXWl+tEyGiMe0blgXFpa25akJ4ZJ f4zbBrMc3CgxoC/qHet7cz481d/t+InM9fbQspDkdVaaRYX2cWCXxlvmueOqj9PqN13V 3j9lXVqqp6cwxM+rfEh95oYg8Tov8PRn9pSRvR5UuoGeS/RUdM8YUu9+ez7ZcFp+lHW9 7RPA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=subject:user-agent:in-reply-to:content-disposition:mime-version :references:message-id:cc:to:from:date:sender:dkim-signature :delivered-to:list-id:list-subscribe:list-unsubscribe:list-help :list-post:precedence:mailing-list:arc-authentication-results; bh=bknbWkpwr+Bi6YxYkrobCfDN4Yj9k9wg4HWqfbKWfVk=; b=oyrFwY/qAwEWc2oP3Hx3QnmfMGnszvLgcGQVMkW/h5sCoyq6/oXlSBBlx3GRMqoZJC cnHoqIWZmvoxpP5kFPxpuKt4TCj/kt09QBDTDdZ+feTllM62WyHkJmrSLBufNGqyWSF5 3OVzT58uvwuE0Ul/GfEvgMDsmlq66FxyQ+lnU01fm+JJDDb65bSEkeUolw/NZcPdfSB9 xq9sebiSy5TfMQZNOJ/utdbCkOx5Km3coGgfuNi2QZDoJivuqYFM4kqmkYIn8w6AV0fu EvGYGYKUxbaef/sVLDP35jBNwcpdAmQnAgfnZRbuINfa6D8aQRR/mDukofu6StU5ux1w mehg== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=dzmVyEJ6; spf=pass (google.com: domain of kernel-hardening-return-11497-gregkh=linuxfoundation.org@lists.openwall.com designates 195.42.179.200 as permitted sender) smtp.mailfrom=kernel-hardening-return-11497-gregkh=linuxfoundation.org@lists.openwall.com Authentication-Results: mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=dzmVyEJ6; spf=pass (google.com: domain of kernel-hardening-return-11497-gregkh=linuxfoundation.org@lists.openwall.com designates 195.42.179.200 as permitted sender) smtp.mailfrom=kernel-hardening-return-11497-gregkh=linuxfoundation.org@lists.openwall.com Mailing-List: contact kernel-hardening-help@lists.openwall.com; run by ezmlm List-Post: List-Help: List-Unsubscribe: List-Subscribe: Sender: Ingo Molnar Date: Sun, 28 Jan 2018 20:21:28 +0100 From: Ingo Molnar To: Andy Lutomirski Cc: x86@kernel.org, LKML , Linus Torvalds , Kernel Hardening , Borislav Petkov Message-ID: <20180128192128.x5pb3bzjn3znxdyn@gmail.com> References: <4dd5a4d0f6b694f17eaf64c80c36a2560993b9ea.1517164461.git.luto@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4dd5a4d0f6b694f17eaf64c80c36a2560993b9ea.1517164461.git.luto@kernel.org> User-Agent: NeoMutt/20170609 (1.8.3) Subject: [kernel-hardening] Re: [PATCH 3/3] syscalls: Add a bit of documentation to __SYSCALL_DEFINE X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1590862555674165882?= X-GMAIL-MSGID: =?utf-8?q?1590865227257755745?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: * Andy Lutomirski wrote: > __SYSCALL_DEFINE is rather magical. Add a bit of documentation. > > Signed-off-by: Andy Lutomirski > --- > include/linux/syscalls.h | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h > index a78186d826d7..d3f244a447c5 100644 > --- a/include/linux/syscalls.h > +++ b/include/linux/syscalls.h > @@ -207,6 +207,16 @@ static inline int is_syscall_trace_event(struct trace_event_call *tp_event) > __SYSCALL_DEFINEx(x, sname, __VA_ARGS__) > > #define __PROTECT(...) asmlinkage_protect(__VA_ARGS__) > + > +/* > + * For a syscall like long foo(void *a, long long b), this defines: > + * > + * static inline long SYSC_foo(void *a, long long b): the actual code > + * > + * asmlinkage long SyS_foo(long a, long long b): wrapper that calls SYSC_foo > + * > + * asmlinkage long sys_foo(void *a, long long b): alias of SyS_foo > + */ Nit, would it be more readable to write this as pseudo-code, i.e. something like: /* * For a syscall like long foo(void *a, long long b), this defines: * * static inline long SYSC_foo(void *a, long long b) { /* the actual code following */ } * * asmlinkage long SyS_foo(long a, long long b) { /* wrapper that calls SYSC_foo() */ } * asmlinkage long sys_foo(void *a, long long b); /* as GCC alias of SyS_foo() */ */ Also, I wanted to suggest to also document that in practice the three methods map to the very same function in the end, with the SYSC_ variant being eliminated due to inlining - but when double checking an x86-64 defconfig that does not appear to be so for all system calls: triton:~/tip> grep accept4 System.map ffffffff8170d710 t SYSC_accept4 ffffffff8170f940 T SyS_accept4 ffffffff8170f940 T sys_accept4 While for others there's just 2: triton:~/tip> grep sched_getattr System.map ffffffff8107b9a0 T SyS_sched_getattr ffffffff8107b9a0 T sys_sched_getattr The only difference appears to be that accept4() is called internally within the kernel, by socketcall: SYSCALL_DEFINE3(accept, int, fd, struct sockaddr __user *, upeer_sockaddr, int __user *, upeer_addrlen) { return sys_accept4(fd, upeer_sockaddr, upeer_addrlen, 0); } But why does that result in SYSC_accept4() being a different symbol? The difference between the two appears to be rather dumb as well: ffffffff8170f940 : ffffffff8170f940: e9 cb dd ff ff jmpq ffffffff8170d710 Using GCC 7.2.0. What am I missing? Thanks, Ingo