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:	Tue, 8 Dec 2015 05:36:49 +0100
From:	Ingo Molnar <mingo@...nel.org>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	Andy Lutomirski <luto@...capital.net>,
	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

* 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.

Well, even on architectures that don't allow mixed mode system calls for the same 
task the name 'in_compat_syscall()' is still correct: it just happens to also be a 
permanent condition for the life time of a task.

On architectures that allow mixed mode syscalls the assumption and confusion 
carried by the 'is_compat_task()' misnomer has resulted in real security bugs, 
hence Andy's suggestion for a rename.

So without my x86 hat on I'd still argue that 'is_compat_syscall()' is the more 
expressive (and hence more robust, safer) name. On architectures that don't care 
the change carries zero costs.

So are there any deep objections to doing this rename in a single, quick, 
pain-minimized fashion right at the end of the next merge window, when the amount 
of pending patches in various maintainer trees is at a cyclical minimum? We can 
also keep an is_compat_task() migratory define for one more cycle just in case.

Thanks,

	Ingo
--
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/