linux-kernel - Re: [PSEUDOPATCH] rename is_compat

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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/