From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753118AbeDITNy (ORCPT ); Mon, 9 Apr 2018 15:13:54 -0400 Received: from mail-io0-f196.google.com ([209.85.223.196]:38809 "EHLO mail-io0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751610AbeDITNw (ORCPT ); Mon, 9 Apr 2018 15:13:52 -0400 X-Google-Smtp-Source: AIpwx4/3Q+E3ritXQR09/7nPP46hWQIViOHQECPK/yHllEt3p4YewrRJRIB9/oxBIiAFfC6oAOuNz2xrNm+du7TKwRc= MIME-Version: 1.0 In-Reply-To: <20180409063921.wkrqbnv4lzxb3isg@gmail.com> References: <20180407074651.29014-1-linux@dominikbrodowski.net> <20180408083550.32d65b6ra6yca5p7@gmail.com> <20180408091536.GA10120@light.dominikbrodowski.net> <20180409063921.wkrqbnv4lzxb3isg@gmail.com> From: Linus Torvalds Date: Mon, 9 Apr 2018 12:13:50 -0700 X-Google-Sender-Auth: 0SlGy8dE6rl3fc-jTIyNJzcL66I Message-ID: Subject: Re: [PATCH 0/3] syscalls: clean up stub naming convention To: Ingo Molnar Cc: Dominik Brodowski , Linux Kernel Mailing List , Al Viro , Andi Kleen , Andrew Morton , Andy Lutomirski , Brian Gerst , Denys Vlasenko , "H. Peter Anvin" , Ingo Molnar , Peter Zijlstra , Thomas Gleixner , "the arch/x86 maintainers" , Maninder Singh , Arnd Bergmann , linux-arch Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Apr 8, 2018 at 11:39 PM, Ingo Molnar wrote: > > I see - so it's _not_ the same function call signature, but a wrapper with a > sign-extended version, which is fair and useful. So on architectures where this > matters there's type conversion and active code generated. Exactly. Some architectures have that as part of their ABI. On Powerpc, for example, when you pass an "int" argument, the ABI specifies that you have to sign-extend the register in the caller to 64 bits. And the generated code actually depends on that behavior, in that maybe it first tests the 32 bit value, but then _uses_ the full 64 bits, knowing that the caller sign-extended it properly. This is a problem with the system call interface, since the caller isn't a trusted entity, and user space could pass an "int" value with the high bits set to something that _isn't_ the sign-extended thing, so then the compiler generates unsafe code. On x86, this never happens, since x86 doesn't have that "hidden higher bits matter" ABI model. So that part of the wrapper will be a complete no-op. But some other architectures depend on it. Linus