Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751874AbcDRGOh (ORCPT ); Mon, 18 Apr 2016 02:14:37 -0400 Received: from mail-oi0-f51.google.com ([209.85.218.51]:34186 "EHLO mail-oi0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751174AbcDRGOg (ORCPT ); Mon, 18 Apr 2016 02:14:36 -0400 MIME-Version: 1.0 In-Reply-To: <57147837.2030706@zytor.com> References: <1460940317.9121.56.camel@decadent.org.uk> <20160418004731.GB3348@decadent.org.uk> <5714679B.3040806@zytor.com> <57146ECA.5000901@zytor.com> <57147474.1090901@zytor.com> <57147837.2030706@zytor.com> From: Andy Lutomirski Date: Sun, 17 Apr 2016 23:14:15 -0700 Message-ID: Subject: Re: [PATCH] x86/entry/x32: Check top 32 bits of syscall number on the fast path To: "H. Peter Anvin" Cc: Ben Hutchings , Andy Lutomirski , X86 ML , LKML Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1849 Lines: 47 On Sun, Apr 17, 2016 at 11:01 PM, H. Peter Anvin wrote: > On 04/17/16 22:48, Andy Lutomirski wrote: >> >> I think I prefer the "reject weird input" behavior over the "accept >> and normalize weird input" if we can get away with it, and I'm fairly >> confident that we can get away with "reject weird input" given that >> distro kernels do exactly that already. >> > > It's not "weird", it is the ABI as defined. We have to do this for all > the system call arguments, too; you just don't notice it because the > compiler does it for us. Some other architectures, e.g. s390, has the > opposite convention where the caller is responsible for normalizing the > result; in that case we have to do it *again* in the kernel, which is > one of the major reasons for the SYSCALL_*() macros. What ABI? Even the man page says: #define _GNU_SOURCE /* See feature_test_macros(7) */ #include #include /* For SYS_xxx definitions */ long syscall(long number, ...); musl's 64-bit syscall wrappers use long I can't confidently decipher glibc's wrappers, because they're approximately as obfuscated as the rest of glibc, but the code that I think matters looks like: # define DO_CALL(syscall_name, args) \ DOARGS_##args \ movl $SYS_ify (syscall_name), %eax; \ syscall; which doesn't correspond to any particular C type but leaves the high bits clear. For all I know, some day we'll want to use the syscall instruction for something that isn't a normal syscall, and having high bits available for that could be handy. Also, the behavior in which fail the syscall if any high bits are set is faster -- it's one fewer instruction. Admittedly, the CPU can probably do that instruction for free, but still... --Andy