[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrWt0HVLdBfSW1Li2fuzRE0sBO07o0FqXpABQ1uvfcq=TA@mail.gmail.com>
Date: Mon, 7 Dec 2015 15:20:05 -0800
From: Andy Lutomirski <luto@...capital.net>
To: Arnd Bergmann <arnd@...db.de>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
X86 ML <x86@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
linux-arch <linux-arch@...r.kernel.org>
Subject: Re: [PSEUDOPATCH] rename is_compat_task
On Mon, Dec 7, 2015 at 3:16 PM, Arnd Bergmann <arnd@...db.de> 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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists