Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964843AbbLGXU1 (ORCPT ); Mon, 7 Dec 2015 18:20:27 -0500 Received: from mail-ob0-f172.google.com ([209.85.214.172]:32831 "EHLO mail-ob0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932661AbbLGXUZ (ORCPT ); Mon, 7 Dec 2015 18:20:25 -0500 MIME-Version: 1.0 In-Reply-To: <11525805.FykVOSlruZ@wuerfel> References: <11525805.FykVOSlruZ@wuerfel> From: Andy Lutomirski Date: Mon, 7 Dec 2015 15:20:05 -0800 Message-ID: Subject: Re: [PSEUDOPATCH] rename is_compat_task To: Arnd Bergmann Cc: Linus Torvalds , X86 ML , "linux-kernel@vger.kernel.org" , 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 Content-Length: 1852 Lines: 43 On Mon, Dec 7, 2015 at 3:16 PM, Arnd Bergmann wrote: > On Monday 07 December 2015 15:12:59 Andy Lutomirski wrote: >> Hi all- >> >> Every time I look at is_compat_task, I cringe. That function >> determines whether we're in a compat syscall, not whether we're in a >> compat task. There are probably architectures (arm64?) under which >> these are the same conditions, but they are definitely *not* the same >> thing on x86. >> >> Can we just fix it? I propose the following patch: >> >> $ find -type f |xargs sed -i -e 's/is_compat_task/in_compat_syscall/g' >> >> If there's general agreement, can we do that at the end of the next >> merge window? >> >> I could also send a patch series to add in_compat_syscall, change all >> the users, then delete the old stuff, but that seems overcomplicated >> for something that's literally just renaming a token. > > As far as I know, x86 is the special case here, on all other architectures, > this actually checks the task, and it's impossible to call a system call > of the other kind. > Nonetheless, it's still nasty. I'm very slowly trying to get the kernel to stop checking "is this task a compat task" at all on x86 except in the *very* small number of cases where it's correct. I've already found and fixed one security bug that resulted from confusing the conditions. I don't think that the other (more sensible) architectures lose anything from making my proposed change. After all, most of the users are in generic code, and they'll still be correct on all architectures assuming that they were correct in the first place. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/