linux-kernel - Re: [PATCH 2/4] check_unsafe_exec: kill the dead -EAGAIN and clear_in

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:	Fri, 22 Nov 2013 15:27:14 -0500
From:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
To:	oleg@...hat.com, akpm@...ux-foundation.org
CC:	kosaki.motohiro@...fujitsu.com, viro@...IV.linux.org.uk,
	keescook@...omium.org, mhocko@...e.cz, snanda@...omium.org,
	dserrg@...il.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/4] check_unsafe_exec: kill the dead -EAGAIN and clear_in_exec
 logic

(11/22/2013 12:54 PM), Oleg Nesterov wrote:
> fs_struct->in_exec == T means that this ->fs is used by a single
> process (thread group), and one of the treads does do_execve().
> 
> To avoid the mt-exec races this code has the following complications:
> 
> 	1. check_unsafe_exec() returns -EBUSY if ->in_exec was
> 	   already set by another thread.
> 
> 	2. do_execve_common() records "clear_in_exec" to ensure
> 	   that the error path can only clear ->in_exec if it was
> 	   set by current.
> 
> However, after 9b1bf12d5d51 "signals: move cred_guard_mutex from
> task_struct to signal_struct" we do not need these complications:
> 
> 	1. We can't race with our sub-thread, this is called under
> 	   per-process ->cred_guard_mutex. And we can't race with
> 	   another CLONE_FS task, we already checked that this fs
> 	   is not shared.
> 
> 	   We can remove the  dead -EAGAIN logic.
> 
> 	2. "out_unmark:" in do_execve_common() is either called
> 	   under ->cred_guard_mutex, or after de_thread() which
> 	   kills other threads, so we can't race with sub-thread
> 	   which could set ->in_exec. And if ->fs is shared with
> 	   another process ->in_exec should be false anyway.
> 
> 	   We can clear in_exec unconditionally.
> 
> This also means that check_unsafe_exec() can be void.
> 
> Signed-off-by: Oleg Nesterov <oleg@...hat.com>

I have found no problem in this patch. However, I have a very basic question.
Why do we need to keep fs->in_exec? If I understand correctly, it is needed for
retrieving fork() and exec() race in the same process. If it is correct,
can't we move it it to signal->in_exec? It seems to match signal->cred_guard_mutex
and _I_ can easily understand what the code want.

In the other words, currently we have no protection against making new thread when
p->fs is shared w/ another process and I have no idea why multi process sharing influence
multi thread behavior.

I am not expert in this area and I may overlook something. Please correct me if I am silly.


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