linux-kernel - Re: [PATCH 2/3] x86: set_personality_ia32() abuses TS

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 for Android: free password hash cracker in your pocket

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

Date:	Tue, 16 Feb 2010 07:40:35 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Oleg Nesterov <oleg@...hat.com>
cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Andi Kleen <andi@...stfloor.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Roland McGrath <roland@...hat.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3] x86: set_personality_ia32() abuses TS_COMPAT

On Tue, 16 Feb 2010, Oleg Nesterov wrote:
> 
> In fact I'd say this is not right, but fortunetely do_execve() can
> never return something which could confuse syscall_get_error().
> And apart from do_signal() we never check TS_COMPAT during return
> to user-mode.

But 'do_signal()' _can_ happen the first thing after an execve(), no?

And after we have switched to 32-bit mode, we _are_ inside a 32-bit system 
call: the execve has "changed" from a 64-bit one to a 32-bit one.

So I really don't understand why you dislike TS_COMPAT here.

I understand not liking TS_COMPAT in the first place (it would be nice to 
not have that flag at all), but considering that it exists, and it is 
supposed to be set while in 32-bit system calls, setting it on a 32-bit 
execve() seems to be the RightThing(tm) to do.

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