Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1751719AbcDRGBw (ORCPT <rfc822;w@1wt.eu>);
	Mon, 18 Apr 2016 02:01:52 -0400
Received: from terminus.zytor.com ([198.137.202.10]:52442 "EHLO mail.zytor.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1750931AbcDRGBv (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Mon, 18 Apr 2016 02:01:51 -0400
Subject: Re: [PATCH] x86/entry/x32: Check top 32 bits of syscall number on the
 fast path
To: Andy Lutomirski <luto@amacapital.net>
References: <1460940317.9121.56.camel@decadent.org.uk>
 <20160418004731.GB3348@decadent.org.uk> <5714679B.3040806@zytor.com>
 <CALCETrUVuaTvYuLy=w6ZR8_1JAvOW=Gz5BT_3=OBK844r6e1Yg@mail.gmail.com>
 <57146ECA.5000901@zytor.com>
 <CALCETrXPXEuitgHc3iWMT0kCN7cQi1zsnvu3H=SYtSWjQNOurg@mail.gmail.com>
 <57147474.1090901@zytor.com>
 <CALCETrUSu5cnUfqwK1FK61UnQ6uo=QccPejtohuQRhhz7aP1iw@mail.gmail.com>
Cc: Ben Hutchings <ben@decadent.org.uk>, Andy Lutomirski <luto@kernel.org>,
        X86 ML <x86@kernel.org>, LKML <linux-kernel@vger.kernel.org>
From: "H. Peter Anvin" <hpa@zytor.com>
Message-ID: <57147837.2030706@zytor.com>
Date: Sun, 17 Apr 2016 23:01:27 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.1
MIME-Version: 1.0
In-Reply-To: <CALCETrUSu5cnUfqwK1FK61UnQ6uo=QccPejtohuQRhhz7aP1iw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 978
Lines: 22

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.

So I'm not sure this is a valid consideration.  The reason it generally
works is because the natural way for the user space code to work is to
load a value into %eax which will naturally zero-extend to %rax, but it
isn't inherently required to work that way.

	-hpa